Hi Todd,
I know it has been a long time since I last reported in - been busy both in terms of work and personal life; even so, I have tried to follow your new versions and keep updated.
I regret to say that my long standing issue of "talk group bleedthru" is still occuring in the system I monitor and, until recently, it was extremely frustrating for me because I could not find some kind of pattern associated with it's occurance that may assist you in solving the issue, BUT I MAY finally have an observation that may help you investigate this issue!
I usually only keep the "Talk Group Log" screen up as I find the Console too "busy" and distracting for me while I am working. Unfortunately, the Talk Group Log screen does not show whether the received signal is P1 or P2 and, as you may recall, the system I listen to is a P25 P1 and P2 system with most Talk Groups being P1 but with a growing number of P2 talk groups in the mix.
What I have started to notice most recently is that, if I am looking at the Console screen when I get the "bleedthru" issue is that it seems like it is happening to P2 talk groups with P1 audio from other talk groups leaking thru. I think I would have seen this earlier if I could have seen that the TG was being received as P1 or P2 in the Talk Group Log screen.
When I now watch the Console screen and see and hear this issue happening it now looks like while the P2 TG is active and a conversation is taking place, in between gaps in the conversation I will hear audio from a completely different P1 TG. I am now seeing that, at least sometimes when this occurs, I see the Console data suddenly shift to showing P1 and then switch rapidly back to P2 when the original "correct" conversation continues. Sometimes, the P1 interfering traffic may last long enough to cause the desired P2 TG reception to miss occasional replies but often the P1 interfering traffic will abruptly cease when a reply comes back on the desired P2 TG.
I am not sure but it looks like the P2 traffic is subject to "interference" from the P1 traffic (which, on this system, still comprises the majority of the traffic) and may be more pronounced during busy periods (which would make sense). Maybe when the P1 "interference" causes the missing of replies during a P2 TG conversation it might be because the reply was on another time slot in the P2 transmission? That is just conjecture as I can't tell which slot the P2 traffic is carried on, of course.
Assuming that the above observation is correct (P1 traffic bleeding thru into P2 traffic), then I am guessing that if one is monitoring a pure P2 system with no mixing of P1 TG's or a pure P1 system with no mixing of P2 TG's this issue would never show itself.
Also to add - I do not use Priority at all and they are all set to 1; the issue occurs even in standalone mode - just noticed that today as it was obvious to my ear; it happens regardless of whether or not I am roaming between two active receiveable systems or just locked on one; the current bleedthru mostly appears to come from TG's I am actively scanning and not usually from those I have not selected unlike back in the early days of owning the device; current sw/fw is 2021-02-23 1415 as of today, Wednesday, February 24th, 2021 at about 12:59 PM local.
So, hopefully, this observation will help you solve this issue!
But I have a feature request that I have always wanted but now, given the above observations,it has become more prominate: 1) Show in the Talk Group Log screen whether the traffic is P1 or P2; and 2) Show in both the Console screen and the Talk Group Log (if #1 is implimented, of course) which slot is being used during TDMA P2 traffic reception.
I really like that you have added RID logging, BTW! I knew this would be a heavily requested feature going forward. One thing that I think would be nice, if I may sneak in another "feature request" , is that I think it would aid the logging and analysis of RID's in using them to work out what unknown TG's are being used for if you added a column for listing the associated TG's for a given RID in the RID "Alias" tab. It might get too cluttered in busy systems but could be a user selectable feature.
All for now, hope the above info helps! Still love the device and am glad to see it gaining ground with more users and maturing in capability!
-Mike
