-edit: The other thing that could be done is to add an option to ignore the WACN field. I'll plan on adding an option for this.
I think I like this 'option to ignore' the WACN field best. Although I do not have any systems that share the same SYSID, having the WACN option could be handy if ever needed. I tried looking for duplicate SYSID's in the RR database but it's not really setup to search the SYSID field using a wildcard so I could not create a list just to see how bad this problem is.
I input a few common SYSID guesses and did see where they are duplicated in some areas of the country so allowing the WACN option to be used is probably a good idea as long as it does not cause headaches for those not adding the needed WACN!
I lied earlier as I found that I do have a duplicate 010 SYSID here that is shared between a Harris P25 system at our power utility and a system at the
Joint National Capital Region Trunking System, Various, Multi-State - Scanner Frequencies which uses a system from an unknown manufacturer. The JNCR system is out of my normal range when at home so it's not been an issue with the P25RX so far. I can see where it could be an issue though even though I did not see any duplicate TGIDs between the systems. At least not yet.
I'd also ran into the 'unknown' talkgroup entries issue after upgrading to the first version that allowed for CSV export/import the day it was released. I was going to post about that issue but figured out the problem from the version notes on the BTConfig download page.
The lack of me adding the correct WACN with each of my talkgroups was indeed what was causing the same issue that
@yodermans mentioned.
Since I had the issue, I added the WACN to all my TGs, I've not had another duplicate but unknown TG logged unless it really was unknown.
Adding the correct WACN's to my CSV export was very easy using Excel.
For the allow unknown talkgroups thing, I've always allowed them so I've not seen an issue with that. I prefer to monitor them so I can start trying to ID them. As long as those I uncheck for monitoring stay silent, it's all good!
I also like the feature of BTConfig unchecking those new TGs where encryption is detected. That works well for the most part. I have seen it pass new TGs that are encrypted as in the clear so they remain checked for monitoring. 9 times out of 10 though, BTConfig gets it right and unchecks encrypted talkgroups so I don't consider this a problem. I think it's probably just the fact that the ENC flag may not always be seen when a new TG is logged. And even when an encrypted TG slips through the cracks and is checked for monitoring, the P25RX itself has always done a great job of going about its business and skipping encrypted chatter so it's never been heard. I'm not certain but leaving the encrypted TGs checked for monitoring here does not seem to slow down the search for active TGs when it does detect a TG using encryption that has not been ignored. Even though BTConfig is set to monitor the encrypted TG, the P25RX seems to override that and continues looking for another active TG which is perfect in my opinion.
I do have some TGs here that have a mix of in the clear and encrypted RIDs. The P25RX handles this situation just fine and monitors the voice traffic when it's in the clear but searches for new TGs when the radio switches to a user that's using encryption.
Other than the minor stuff above, all is well and the P25RX has been a joy to use!