P25RX P25 Phase 1/2/DMR Receiver With Bluetooth Audio Support

[btt]

Well! I think we're going backwards, at least in my case. I tried downloading the 1218 version for today that I just saw on the website and installed it. Now - no audio at all! No matter what I do. Console looks like everything is working but not getting any audio out of the Line out.

Question - can we revert to older software and firmware (they seem to be linked)? I think, for now, I'd just like to go back to the 8/22/2020 1846 version for normal monitoring until some more bugs are worked out.

Oh well.

-Mike

Mike, you can go back to previous versions without an issue. If you continue to have issues, you could try to do a 'factory' command in the console. This will reset most configuration values to defaults. I'll look into what might be causing the issues you reported. Thanks for the testing / reports today. I think it is getting close now.

 

[Mike_G_D]

Mike, you can go back to previous versions without an issue. If you continue to have issues, you could try to do a 'factory' command in the console. This will reset most configuration values to defaults. I'll look into what might be causing the issues you reported. Thanks for the testing / reports today. I think it is getting close now.

Whew! Well I tried resetting, etc. and no good. Finally gave up and went back to the 8/22 version and it works as it was. No P2 but otherwise "normal" like it was before the P2 testing. So, at least the reversion fall back works fine. Good to know.

I think I'll quit testing for a while and wait for a bit. But it was interesting!

 

[kinglou0]

kinglou0,
I see looking up the system on RR shows that the system_id should be 0x1e7, but the P25RX is showing a sys_id of 0x3ac. Can you verify the wacn, sys_id, and nac that the P25RX is displaying are all correct? (wacn and sys_id should be correct. they are crc checked). The P2 voice can't be decoded correctly without those 3 parameters being correct when the device receives the voice channel grant.

The system id is 1e7 but...there as a connected system that id’s as 3ac. It’s listed as the PSRS Tacoma/Puyallup System here on RR. 1e7 is listed as South Sound 911 but in reality it was the county radio system that got folded into SS911 when the PSRS system came online.

unitrunker and pro com96 both report the control channel I’m monitoring as 1e7. I included video in my previous post that shows Unitrunker and the P25RX software running at the same time.

 

[kinglou0]

The '*' characters are audio frames that decoded without errors, so I'm wondering if the voice audio in the video is encrypted since it was completely unintelligible. The new firmware can't detect Phase 2 encryption yet because I don't have the fec for that portion implemented.

No encrypted audio in the video I posted. I had Unitrunker running as well to show system traffic. I can post something later with a Unication G5 running along with the P25RX. Appreciate you getting this out for us to test. We’re close....

 

[btt]

The system id is 1e7 but...there as a connected system that id’s as 3ac. It’s listed as the PSRS Tacoma/Puyallup System here on RR. 1e7 is listed as South Sound 911 but in reality it was the county radio system that got folded into SS911 when the PSRS system came online.

No encrypted audio in the video I posted. I had Unitrunker running as well to show system traffic. I can post something later with a Unication G5 running along with the P25RX. Appreciate you getting this out for us to test. We’re close....

I apologize. I didn't catch that from the other software running in the video. I think I understand now. The scramber is most likely initializing incorrectly in this case. I'm wondering what I should do if the system_id is reported differently by the control channel than what is needed by the descrambler. There must be another message that indicates this somewhere. I will be looking into that. It definitely won't be able to decode P2 voice without the wacn, system_id, and nac that it was scrambled with.

 

[btt]

There is another version for P2 testing available (_1432). It might fix things. It might not work. P2 voice audio will still probably be choppy with the java software playback, but should probably be ok with line-out and bluetooth. (I'm still working on trying to figure out how to improve the java audio playback on a PC). Phase 1 sounds good here with this version.

[edit]
@kinglou0, the issues that you experienced with the garbled audio may just have been related to the other bugs which may have caused the de-scrambler to be initialized with the wrong values.

[edit2]
I just realized that _1432 will still have issues if a P2 channel grant is aborted due to various reasons. Don't bother testing. I will have another version ready soon.

 

[btt]

Last post for the day from me. I definitely found why the P2 voice grants have been causing some strange issues. Hopefully the issues have been fixed in (untested) version _1736 available on the web site. I'll wait for some feedback before continuing. Thanks for all the testing today everyone! I'm sure we are close to getting this working.

Note, I think the java audio playback on PC might still be choppy with P2, but lineout and bluetooth should probably be ok.

 

[relicwr]

For 250ms, it wouldn't lock on. Going to 500ms and 1sec, it just skips on this:

$TDMA VOICE GRANT_02, freq 855.987500,  tgroup: 1001, slot: 0

It looks to be broken again.

 

[btt]

It looks to be broken again.

Thank you! I found a good reason for that. (untested P2) version _1934 up for testing. This was actually quite a few changes, so it may still have issues, but we are getting close. Almost all the hard stuff for P2 TDMA support is done now. At this point, we are just struggling with normal logic stuff that would be fixed within 30-60 minutes if there was P2 here locally. I really appreciate the help getting this going!

 

[kinglou0]

Did some testing with _1934. Here are my notes.

**During testing - NO Encrypted Audio was transmitted** (Video attached again has Unitrunker running along with P25RX software. No P4 Service types)


Startup on initial flash of new software _1934

1 - System ID still alternating between 0x1e7 and 0x3ac

2 - No NAC registered. Console reports NAC as 0x000. ProCom96 and Unitrunker both report this system as having a NAC of 1E3

3 - Site ID is correct. System Zone reported by Unitrunker as BEE00-1E7 and Site ID is 001-003

4 - On a voice grant - P25RX is getting the reported frequency/talkgroup/slot correct (Can confirm with SDR Trunk running on alternate computer) but still have an error message of:
$TDMA need wacn, sys_id, and nac before P2 can decode. please wait.

5 - No logged TGID's

6 - No audio at all. (Not surprising since no NAC. Previous test, the P25RX did pickup a NAC but audio was garbled)



Changing the Talkgroup Timeout to 500ms/1 second/3 seconds

Same as on initial flash.

***************************************************************************************
If you watch the video attached, there's a decent (it's a smaller site than the Orting or Tacoma sites) amount of traffic coming through. You can see the voice grants on the left in Unitrunker and see the error messages in the P25RX console on the right. Even see a system busy indicator on the left in Unitrunker for a WSP unit trying to access the system.

I've included the console log this time as well.

bandicam 2020-08-26 20-09-42-623.mp4
BTConfig-2020-08-26_1934.exep25rx_conlog_2020-08-26.txt

I'm not sure what I can provide to help out. Raw IQ recordings, diagnostic logs from my Unication G5, or whatever. I'll have the chance on Saturday to travel into other areas of the county and can do some testing of the other sites (I'll most likely head towards Orting since that site has a very nice mix of traffic on the County system/1E7 and it's in a good place to monitor SS911/3AC)

The architecture of these 2 systems is interesting to say the least.

 

[btt]

@kinglou0,

Thank you for the detailed notes, video, and log! Although the NAC is checked by a BCH ecc, it is possible that it is wrong when the signal is really bad, etc. I had some extra logic in there to try and prevent issues arising from when it is wrong. I think this may be the source of the issue. There is a new untested version available _2106. It only checks the nac for a good result from the BCH and that it is non-zero. I think this version might get past the P2 grant.

 

[btt]

1 - System ID still alternating between 0x1e7 and 0x3ac

I figured out why this is happening. It was updating the value of the network sys_id when receiving op-codes for the alternate and adjacent sites containing a sys_id. There is a new version available with that issue fixed. untested _0457

This could have also been causing issues with talk groups for phase 1 systems with multiple system_ids.

 

[btt]

"Where has it tested in a true Simulcast environment and what was it tested against?"

It was developed around the Tri-cities, Wa area. See here: Benton County 800 Trunking System, Benton County, Washington - Scanner Frequencies
From RR description: "Two additional sites were added to the network, to help boost handheld coverage in fringe areas that the old radio system had coverage problems in; thus, making it a nine-site simulcast system, using linear phase modulation (CQPSK)."

During development, simulcast issues were resolved by getting testers in the 3 worst locations I could find (due to simulcast) in Pasco, Richland, and Kennewick. All of these locations were being hit by multiple towers. In the beginning, it was definitely a problem for those 3 testers. Many voice segments frames being dropped at all 3 locations. After improvements to the quadrature decoder, filters, and the multi-rate, poly-phase symbol synchronizer, all three testers ended up with excellent out-of-box performance at these locations.

This might seem like a nitpick, but someone just asked me about this. The above quoted is a reply from me at the very beginning of this thread months ago explaining where the P25RX was tested in a simulcast environment. When I linked to the system information for the Benton County 800 system information in that post, the stated date that it came online was correct. It came online in 2010. It appears from looking at the change log that someone changed the RR database on 2020-08-06 to imply that this system has only been simulcast for the past 3 weeks instead of the past 10 years. I wish I could edit that post and explain this to newcomers to this thread.

[edit] (attached image of what it looked like before 8/6/20)

 

[Mike_G_D]

Errrgh! Sooo close! I've been running the latest test version - audio sounds great on P1 and P2. Seems better than ever but that might be my imagination. Would be almost perfect eeeeexxxxxxxcceeeeeppppptt....for some odd reason whenever it receives a P2 signal it winds up hanging on that talkgroup. Scrolling stops. Dead, well, except for traffic on that one talk group.

Edit: When it hangs like this it doesn't just hang on the talk group - it hangs on the last used voice frequency. So unless you get more traffic for that one stuck talk group on that one stuck voice frequency you won't hear anything.

Dern! Re-writing config to receiver seems to reset everything but don't want to have to do that all the time, of course.

-Mike

 

[btt]

Would be almost perfect eeeeexxxxxxxcceeeeeppppptt....for some odd reason whenever it receives a P2 signal it winds up hanging on that talkgroup.

Thank you! Off to find that issue right now.

 

[Mike_G_D]

Thank you! Off to find that issue right now.

Hmm...unsure but this issue may have something to do with the console logging being enabled. If I just set it to "Enter Commands" and disable logging it seems to work better - as in at least after a short while it moves on, but I'm not 100% sure about this. Need to observe more.

Also - one other semi-major thing - it seems to be ignoring my Talk Group Timeout setting. No matter what it seems to no longer have any delay and just immediately jumps to the next talk group with traffic after traffic ends on the currently active one. So, delay went away, it looks like.

Edit: Well I think we can scratch the logging link - still hangs on TDMA groups.

-Mike

 

[btt]

Also - one other semi-major thing - it seems to be ignoring my Talk Group Timeout setting. No matter what it seems to no longer have any delay and just immediately jumps to the next talk group with traffic after traffic ends on the currently active one. So, delay went away, it looks like.

Edit: Well I think we can scratch the logging link - still hangs on TDMA groups.

I was able to re-produce the timeout issue by making p1 grants act as p2 grants (and calculate the frequency as if it was p1). I think that issue may be fixed now. Thank you for testing/reporting. There is a new version available: _0945

[edit]
Also changed it to only print every 5th TDMA Sync line in the console.

 

[Mike_G_D]

I was able to re-produce the timeout issue by making p1 grants act as p2 grants (and calculate the frequency as if it was p1). I think that issue may be fixed now. Thank you for testing/reporting. There is a new version available: _0945

[edit]
Also changed it to only print every 5th TDMA Sync line in the console.

Testing - looks good so far. Fingers crossed.

 

[Mike_G_D]

I am loving the audio now! With the 8/22/2020 1846 version and prior I noticed a lot of dropouts that almost sounded like cut outs at the peaks. I wasn't sure if it was an AF or RF issue. But now, not seeming to hear that so much. Signal seems much more stable based on the "RF Sig Level" indicator also (which would seem to wig out when those weird peak dropouts occurred which points to an RF origin).

Anyway, I am now not seeing the hangups on the TDMA groups and traffic channels. But am still seeing something else I didn't mention before as it was a lesser issue - I am not seeing TDMA P2 talk groups showing up in the "Talk Group Log", only P1 talk groups. Minor but still something, of course.

Really making good progress here from what I can tell!

-Mike

 

[btt]

- I am not seeing TDMA P2 talk groups showing up in the "Talk Group Log", only P1 talk groups. Minor but still something, of course.

Are you seeing lines that look like: $TDMA Phase II sync, freq: %4.6f, rssi: %d dBm, TGroup: %d, Desc: %s ?

Could you provide some sample output if so?

Thanks for continuing to test! Sounds like we almost have it working now.