P25RX-II P25RX-II Firmware Updates / Testing

[btt]

I know Con+ systems in the 900mhz range are not the focus of a lot of users. I am at the fringes of reception for this system, but generally capture all calls using an SDR dongle and DSD+ FL.
With that preface, here's some feedback.

Prior experience tells me that a manually set LNA gain of 22 dB results in best possible reception on this particular Con+ system.
This morning I've been working with the AGC target setting on the advanced tab, and monitoring the LNA gain readout on the Signal Insights tab. From prior experience I also watch the DMR BLKS_PER_SEC reading as I know it needs to remain above 30 for reliable voice reception. Also watch EVM% as I want to see this in the single digits during voice calls or reception is choppy.

Initial default AGC target = 65. This results in an LNA gain of 32 dB and very poor reception (control channel is often lost).
Slowly increasing AGC target and at 75 I start to have OK, but not great reception (control channel reception, but 20% of voice calls not received).
Increase AGC target to 76 on Advanced tab, results in AGC target actual reading of 71-73 dB, and LNA gain reading of 32 dB
Increase AGC target to 77 on Advanced tab, results in AGC target actual reading of 72-74 dB, and LNA gain reading of 26-28 dB; voice call reception is good, but not quite equal to DSD+FL dongle
Increase AGC target to 78 on Advanced tab, results in AGC target actual reading of 80-82 dB, and LNA gain reading of 2 dB (Not a typo, 2); control channel reception is completely lost.

Also, after trying various AUTO settings, I attempted to write manual LNA gain of 22 dB. Setting did not take and appeared to be using last AUTO/AGC target setting. So I closed software, unplugged/re-plugged RX-II. Advanced tab reads my desired LNA gain 22 dB, but signal insights now reads AGC target: ~80 dB and LNA gain of 2-6 dB (varied after restart several times). I also tried using "reset to defaults" (and unplug/re-plug) and this also does not get the manual LNA gain to take. At present I can't find a way to set LNA gain to manual. (Did not try button hold restart yet). Written AGC targets do appear to take.

I have come close, but have not quite found a setting that equals manually setting LNA gain to 22 dB on this system.

A note for others trying to optimize AGC target setting, you need to allow the system to run for several minutes (maybe even 5-10) to allow eventual settling of LNA gain.

@btt , let me know if you want some samples. I understand Con+ is not a priority...and honestly performance is so good on manual LNA = 22 dB I have no complaints.

Yes, please send some IQ samples recorded with the latest version. Set the target to the best value you found. I will have a version that doesn't force the auto gains and other settings later this week. The initial results are looking good. As of last evening, two people that were previously having issues with P25 reception report that it is almost there now! I don't know why you are having to wait for gains to settle for several minutes. It should be nearly instantaneous. I can't think of anything specific to DMR that would cause this.

 

[pcman67]

@btt Release 2021-11-14_1911 is the best yet for the P25RX-II! I am noticing much improved P2 EVM and error rates, overall better reception and excellent P1 and P2 sounding audio. The RF sig level also seems less erratic and more stable in terms of the dBM signal levels. I honestly was very happy with the latest releases and really didn't think it could improve much beyond those, but this "Experimental Version" hits it out of the park -- at least for me! I also took it for a drive yesterday evening in my car and it did wonderfully during the drive in diverse terrain and in challenging simulcast environments. Definitely a noticeable improvement and a step in the right direction! I hope this resolves the issues that some of the folks were having or at least they see an improvement like I did.

 

[pcman67]

@btt , I just tried saving the I/Q File just to see how it works, but it generates a 0-byte file. It does go through the motions of writing out the file, according to the software, but when it is complete, the file is null. This is on a Windows 10 computer.

 

[pcman67]

@btt , nevermind. The file did eventually show up as a 5.1 MB file. I guess I didn't wait long enough for it to generate. Please ignore my last post.

 

[btt]

@btt , nevermind. The file did eventually show up as a 5.1 MB file. I guess I didn't wait long enough for it to generate. Please ignore my last post.

Thank you for letting me know. On Windows, the files can be zero length if the file has not been closed. (it was probably closed when you exited the software?). I uploaded a new version that closes the file at the end. Version that closes the file is 11-15_0731.

 

[pcman67]

Thank you for letting me know. On Windows, the files can be zero length if the file has not been closed (or flushed). (it was probably closed when you exited the software?). I uploaded a new version that closes the file at the end. Version that closes the file is 11-15_0731.

Yep, the file gets closed at the end of the save I/Q recording process now in Windows. Thanks!

 

[Vermonster]

Yes, please send some IQ samples recorded with the latest version. Set the target to the best value you found. I will have a version that doesn't force the auto gains and other settings later this week. The initial results are looking good. As of last evening, two people that were previously having issues with P25 reception report that it is almost there now! I don't know why you are having to wait for gains to settle for several minutes. It should be nearly instantaneous. I can't think of anything specific to DMR that would cause this.
edit: One thing that might be causing confusion is that there is currently a 6 dB hysteresis for gain changes. (was previously 3 dB).

Confirming it can change over the course of 5 or so minutes and sometimes longer. Example, I just restarted device and wrote AGC Target 76; initially LNA gain 32 dB; after about 2 minutes drops to 28 dB. Earlier today I saw continued drop to 24 dB. I suppose it's possible the signal is changing.

I/Q files sent to your gmail as they were too large to attach here.

 

[btt]

Confirming it can change over the course of 5 or so minutes and sometimes longer. Example, I just restarted device and wrote AGC Target 76; initially LNA gain 32 dB; after about 2 minutes drops to 28 dB. Earlier today I saw continued drop to 24 dB. I suppose it's possible the signal is changing.

I/Q files sent to your gmail as they were too large to attach here.

Thank you for the samples! The hysteresis is currently 6dB for a hw-based gain change. The ADC has a large dynamic range, so there is no need for the hw gains to change constantly. As long as the current calculated value is within 6dB of the target, then the hw-based gains don't change.

 

[rr60]

@btt 2021-11-16-21 07:50. Note on P25-P2 Trunking. The first 500-750 ms of encryption messages get through. The TG is then muted for the duration of that transmission. Next key up same thing all over.

P25-P2 audio sounding fantastic.

 

[btt]

@btt 2021-11-16-21 07:50. Note on P25-P2 Trunking. The first 500-750 ms of encryption messages get through. The TG is then muted for the duration of that transmission. Next key up same thing all over.

P25-P2 audio sounding fantastic.

Thank you. Please try 11-16_1126 for a fix to that issue and more improvements to the P1/P2 decoding. The I/Q files being sent are helping to get things figured out!

 

[rr60]

Thank you. Please try 11-16_1126 for a fix to that issue and more improvements to the P1/P2 decoding. The I/Q files being sent are helping to get things figured out!

Thank-you Indeed _1126 fix has stopped all of the encrypted traffic. Working well. An observation however. On a very busy system with significant activity of both encrypted and traffic in the clear I see the following.

Display shows “Status: skipping TG”, when this occurs, decoding of CC does not instantly resume. The result is on a busy system, grants and messages are missed while RX-II waits the second or so to move on.

Importance level, slightly noticeable.

 

[btt]

Thank-you Indeed _1126 fix has stopped all of the encrypted traffic. Working well. An observation however. On a very busy system with significant activity of both encrypted and traffic in the clear I see the following.

Display shows “Status: skipping TG”, when this occurs, decoding of CC does not instantly resume. The result is on a busy system, grants and messages are missed while RX-II waits the second or so to move on.

Importance level, slightly noticeable.

The delay when "Status: Skipping TG" shows could be because of the "Talk Group Timeout". The default value is 1 second. In this case, the receiver will return to the control channel if the conversation ends. It will continue to wait for that "active" talk group for the TG Group Timeout period before accepting another voice grant. You can set the timeout to be as low as 100ms. I can make options for less time if that would help. I'm not saying there isn't a bug, but if this is what is happening, then it is intentional.

 

[pcman67]

The delay when "Status: Skipping TG" shows could be because of the "Talk Group Timeout". The default value is 1 second. In this case, the receiver will return to the control channel if the conversation ends. It will continue to wait for that "active" talk group for the TG Group Timeout period before accepting another voice grant. You can set the timeout to be as low as 100ms. I can make options for less time if that would help. I'm not saying there isn't a bug, but if this is what is happening, then it is intentional.

I see this too, where I will be listening to my statewide system and monitoring talkgroups and it will just randomly pop up with the Status: Skipping TG". I've noticed that I'll see this when receiving/listening to a transmission and when it's displaying the other active talkgroups during the transmission, it will sometimes pop up with the skipping TG status message. I've always thought that perhaps the receiver was sensing an encrypted talk group while I'm listing to a P1 talk group or something like that, but now it's got me thinking that it could be a bug?

 

[rr60]

The delay when "Status: Skipping TG" shows could be because of the "Talk Group Timeout". The default value is 1 second. In this case, the receiver will return to the control channel if the conversation ends. It will continue to wait for that "active" talk group for the TG Group Timeout period before accepting another voice grant. You can set the timeout to be as low as 100ms. I can make options for less time if that would help. I'm not saying there isn't a bug, but if this is what is happening, then it is intentional.

Thanks Todd! Wondering out loud. No delay needed for encrypted TG’s. Perhaps that can happen “behind the scenes”. There is good reason to have TG’s at minimum of 1 second. I have a chance to push the hold button (thanks🤣). Perhaps all TG’s should not be treated equally? Importance level: Low

 

[btt]

I will look into this some more and see if I can find an issue. It also shows "Skipping" if there is a grant for a disabled talk group. I should probably get rid of that message.

 

[btt]

Thanks Todd! Wondering out loud. No delay needed for encrypted TG’s. Perhaps that can happen “behind the scenes”. There is good reason to have TG’s at minimum of 1 second. I have a chance to push the hold button (thanks🤣). Perhaps all TG’s should not be treated equally? Importance level: Low

I see what you are saying. If encrypted talk groups are causing a 1 second delay, then that is not right. I will get that fixed. Also, there is a "talk group priority interrupt" option that you can enable. If enabled, then the talk group with a higher priority can interrupt an active conversation.

 

[btt]

Thanks Todd! Wondering out loud. No delay needed for encrypted TG’s. Perhaps that can happen “behind the scenes”.

Please give 11-16_1520 a try when you can. I think I may have this issue fixed. When an encrypted talk group is disabled, the "TG timeout period" is zeroed.

 

[btt]

In version 11-16_1550, if an encrypted talk group is detected, and the "return to cc when encrypted" option is enabled, then the talk group will be disabled for 30 seconds. Prior to this version, this would not occur if the talk group was specifically enabled in the talk group editor. I realize that this will probably not be what someone wanted. If this is the case, then there should probably be an additional specific option to prevent this. Thoughts?

 

[rr60]

In version 11-16_1550, if an encrypted talk group is detected, and the "return to cc when encrypted" option is enabled, then the talk group will be disabled for 30 seconds. Prior to this version, this would not occur if the talk group was specifically enabled in the talk group editor. I realize that this will probably not be what someone wanted. If this is the case, then there should probably be an additional specific option to prevent this. Thoughts?

Yippie…test tomorrow.

 

[btt]

Thought I would post a recent screenshot of local monitoring. I like these colors and fonts.