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

[btt]

Can you post the notes for test versions between 10-11 1205 and 10-12 2252?

1) I already explained the difference with regards to how TSBK is counted with the new firmware for systems that use PDU with DUID=0x0c, so I'll skip that.

2) If we are on the control channel and the incoming DUID is not a TSBK or PDU, then we use a TSBK / PDU bit mask and xor it with the DUID to determine which one is closer and use that. Both TSBK and PDU are checked by FEC and CRC and the individual blocks are small.

3) If we are on a voice channel and the DUID is not LDU1, LDU2, HDU, TDU, or TDULC, then we do the bit mask xor for LDU1 and LDU2 to see which one is closer to the incoming DUID and use that. If they are equal, then use the complement of the previous. If previous was LDU1, use LDU2, etc.

These simple changes to compensate for errors in the DUID made a huge difference. Especially for sites that use the PDU style messages.

 

[cg]

Minor issue with 10-12 version that was likely me not knowing the commands.
Tried the ACARS commands, got it working. Then realized there was no commands listed in that section to return it to P25 trunking. So I tried the "factory" command. Started running and decoded System & Site but not the NAC so no decoding. Finally went back a version, reloaded the firmware and all is well.

chris

 

[btt]

Minor issue with 10-12 version that was likely me not knowing the commands.
Tried the ACARS commands, got it working. Then realized there was no commands listed in that section to return it to P25 trunking. So I tried the "factory" command. Started running and decoded System & Site but not the NAC so no decoding. Finally went back a version, reloaded the firmware and all is well.

chris

Thanks Chris. Did the NAC not show up at all or was it wrong? ( clarification for those reading: NAC is only required for Phase 2/TDMA decoding).

Regarding ACARS, I usually only enter the commands, watch the decodes. When I'm ready to return to P25, then just power down the device without ever doing a 'save' command.

 

[cg]

none at all, nac 0x000
That was the first time I ever entered a command so I figured I was messing something up. I did try shutting down and restarting but only did the software, didn't think to try cycling the unit's power.

chris

 

[btt]

none at all, nac 0x000
That was the first time I ever entered a command so I figured I was messing something up. I did try shutting down and restarting but only did the software, didn't think to try cycling the unit's power.

chris

Depending on the quality of the signal, it can take a while for the NAC to be "validated". Let me know if this continues to be an issue.

The ACARS commands only changes the mode in ram. If you don't issue a 'save' command or use the "Write Config" button in the BTConfig software, then then commands you entered will not survive a power cycle. If you do save some bad commands to flash, then the 'factory' command will restore everything to defaults.

[edit] you can also use the 'system_reset' command to reset the device without cycling power.

 

[W4KRR]

I can confirm that DMR Connect Plus trunking works fine. However Capacity Max Tier III does not. This is probably because Capacity Max (and also NXDN trunking) don't use LCN's, they use over the air channel numbers. The system administrator assigns these numbers when the system is set up. Apparently there are tables in which every frequency is assigned a number. The system administrator can use these tables, or modify them, or make up his own. So, instead of the control channel sending a command to "switch to LCN 2", it says "switch to channel 413" or whatever.

 

[btt]

I can confirm that DMR Connect Plus trunking works fine. However Capacity Max Tier III does not. This is probably because Capacity Max (and also NXDN trunking) don't use LCN's, they use over the air channel numbers.

Thank you for reporting on your tests. I found this excellent thread regarding NXDN channel mapping earlier when I was preparing to start working on NXDN trunking. It may be that the interface needed for this in the BTConfig software may also work for Max Tier III. I'll have to dig into that some more.

Understanding NexEdge Trunking

Hello, Some useful scribbles as programs decoding NexEdge trunking become available. NexEdge trunking has a dedicated control channel. NexEdge is defined as Type-C in Parts 1-A and 1-C of the NXDN Technical Specifications. The System ID is split into three Categories based on system size...

forums.radioreference.com

 

[W0RS]

Question For The Group: I am looking at the configuration page for the P25RX, I can see where the "control frequency" is put, but I am not quite sure what I should put in the place "ref freq". Would this be where the alternate control frequency is placed? I watched the configuration video on the website but I did not see any field for it on that particular software version.......

 

[btt]

Question For The Group: I am looking at the configuration page for the P25RX, I can see where the "control frequency" is put, but I am not quite sure what I should put in the place "ref freq". Would this be where the alternate control frequency is placed? I watched the configuration video on the website but I did not see any field for it on that particular software version.......

The reference frequency is the frequency of the internal reference. This determines frequency accuracy of the frequency synth and the A/D converters. You can use the ref freq value printed on the labels that the device came with or if you are currently monitoring a P25 Control Channel and the device has had some time to warm up, you can use the "Estimated Reference Frequency" shown on the "Signal Insights" page.

 

[btt]

I thought of something else I should have pointed out about the 27 vs 40 TSBK/sec discussion. The length of the sync words (plus related header bits) and the length of a TSBK are similar, so for 27 TSBK/sec with a 1:1 sync-to-TSBK ratio, you could think of it as 54 blocks sec (27 sync + 27 TSBK). For the 40 TSBK/sec with a 1:3 sync-to-TSBK ratio, you could think of that as approximately (14 syncs + 40 TSBK ) = 54 blocks/sec. So, this is how the 40 TSBK/sec systems fit 13 more TSBK blocks in there....

This gave me an idea today. I decided to change the TSBK/Sec CC signal quality reference to include Sync words as well. This gives a total possible count of 54 for both types of control channels. Signal quality is now reported as BLKS_PER_SEC. ALL TSBK and PDU messages are CRC validated before being counted in the BLKS_PER_SEC.

There is a new testing version available 2020-10-14_1930 with notes on the changes for today.

 

[Cody2020]

Btt,
Thank you for a fabulous piece of gear. I’ve been running mine for 2 weeks and am extremely impressed with functionality, clarity of reception, and feature set. Well done,

 

[kruser]

This gave me an idea today. I decided to change the TSBK/Sec CC signal quality reference to include Sync words as well. This gives a total possible count of 54 for both types of control channels. Signal quality is now reported as BLKS_PER_SEC. ALL TSBK and PDU messages are CRC validated before being counted in the BLKS_PER_SEC.

There is a new testing version available 2020-10-14_1930 with notes on the changes for today.

Things seem to have become worse with this version (1930) through 0546 posted this morning.
My blks per second or tsbk values are again swinging wildly and not just on the VHF systems like before. The values now swing from zero up into the upper 30's on 7/800 and VHF systems. It seems to be more pronounced on the VHF systems though.

Voice decoding on all systems still seems fine just as it did before the TSBK method was changed to try and help with VHF a few days ago.

All the systems I'm testing with have RSSI values of between -62 up to about -75 dBm so I have decent signal levels.

And of course the signal indicator on the front of the P25RX shows a lot of red again as the tsbk values dip into the single digits.
One other thing I've noticed is the Sync Status lines are not reflecting what the tsbk value is, another words, when TSBK drops below 10 for several seconds and the LED on the unit turns red, the Sync Status lines on the Signal Insights screen are humming along just fine and not showing any drops or fluctuations in the TSBK value like before.
The Sync State line above the graph also stays green with a value of 1 (synced) even though the tsbk drops down to single digits or even zero.

Other than the above, things are still working fine and I've not had any freezes since moving the P25RX off of my 3.1 ASMedia port!

 

[btt]

Things seem to have become worse with this version (1930) through 0546 posted this morning.
My blks per second or tsbk values are again swinging wildly and not just on the VHF systems like before. The values now swing from zero up into the upper 30's on 7/800 and VHF systems. It seems to be more pronounced on the VHF systems though.

Voice decoding on all systems still seems fine just as it did before the TSBK method was changed to try and help with VHF a few days ago.

All the systems I'm testing with have RSSI values of between -62 up to about -75 dBm so I have decent signal levels.

And of course the signal indicator on the front of the P25RX shows a lot of red again as the tsbk values dip into the single digits.
One other thing I've noticed is the Sync Status lines are not reflecting what the tsbk value is, another words, when TSBK drops below 10 for several seconds and the LED on the unit turns red, the Sync Status lines on the Signal Insights screen are humming along just fine and not showing any drops or fluctuations in the TSBK value like before.
The Sync State line above the graph also stays green with a value of 1 (synced) even though the tsbk drops down to single digits or even zero.

Other than the above, things are still working fine and I've not had any freezes since moving the P25RX off of my 3.1 ASMedia port!

Thank you for the feedback kruser.

This probably indicates that your systems are using the PDU style messages (duid=0x0c) vs the TSBK (duid=0x07). In the versions posted on the 12th and 13th, it was only checking if the FEC was ok for the PDU messages (not crc). The current version requires that the crc is ok before counting PDU blocks. This is why the BLKS_PER_SEC are showing lower values. The sync line in the signal insights tab does not indicate signal quality, but indicates that a sync word has been received within a timeout period when green. The length of the timeout period was variable in prior versions and is now a fixed period, so it is a different behavior. The main reason for changing this is because the sync status affects how the frequency correction works.

What I'm shooting for here is something that operates with maximum performance while also providing useful "insights" as to the quality of the incoming signal. If the general feedback is that it was better in prior versions, I will be fine with reverting the changes. Please feel free to let me know if it is heading in the wrong direction everyone. Sooner is better than later.

 

[kruser]

The current version requires that the crc is ok before counting PDU blocks. This is why the BLKS_PER_SEC are showing lower values.

Thanks for the info.
I did see the comment on passing CRC checks with the latest versions and figured this was likely the reason behind the lower BLKS_PER_SEC values I see. That makes total sense!

 

[btt]

Other than the above, things are still working fine and I've not had any freezes since moving the P25RX off of my 3.1 ASMedia port!

Forgot to mention it before, but thanks for letting us know that the lock-up issue wasn't P25RX firmware related!

Btt,
Thank you for a fabulous piece of gear. I’ve been running mine for 2 weeks and am extremely impressed with functionality, clarity of reception, and feature set. Well done,

Thank you. I'm really glad to hear it is working well for you.

 

[amcferrin90]

I just tried the latest firmware, the first time in a few weeks. The Columbus simulcast system operates very well now. Audio decode is pretty even with my SDS100 except there is a slight delay between the two, probably in audio processing and buffering. It's interesting that on a dispatch type call that goes for a minute the two audio streams sound almost in sync. The constellation looks very healthy and all at around -89 dbm. I need to try this mobile now. Good work!

 

[btt]

I just tried the latest firmware, the first time in a few weeks. The Columbus simulcast system operates very well now. Audio decode is pretty even with my SDS100 except there is a slight delay between the two, probably in audio processing and buffering. It's interesting that on a dispatch type call that goes for a minute the two audio streams sound almost in sync. The constellation looks very healthy and all at around -89 dbm. I need to try this mobile now. Good work!

amcferrin90,

Thank you for the feedback!

 

[kruser]

Forgot to mention it before, but thanks for letting us know that the lock-up issue wasn't P25RX firmware related!

My testing of the various versions you put out was why I never got back to you about this! All the testing took quite a while.

I let everything run under all the test versions including this mornings version for extended periods of time and it never froze up at all. I used the computer with btconfig running in the background for all tests as well.
If I moved the P25RX to one of the ASMedia 3.1 ports, it would freeze sometimes very quick after I started using the machine and sometimes not for an hour. That was frustrating trying to narrow it down!
One thing I did not do and may still try was seeing if the physical STMicro serial port also disconnects and disappears from the USB device list when things freeze. I don't know how I forgot that simple thing to watch for. At this point, I only know something interrupts communications between the P25RX and BTCONFIG when it's plugged into either ASMedia 3.1 USB port.
I don't have another machine here with ASMedia 3.1 ports to test so hopefully it's just something odd with my motherboard so others don't have the problem.
My motherboard is a very new Intel based ASUS board (I forget the model). It has several Intel based USB 2.0 and 3.0 ports built on the board and then two ASMedia 3.1 ports also built on the board. One ASMedia port is a USB C port which can be configured in the bios as a standard port or setup for high current charging if the plugged device requests it. I've had that port set to be a normal 3.1 port. I should play with the bios settings for that port and see if I can get things working with the P25RX.
All the Intel ports I tested worked flawlessly with BTConfig and the P25RX so that's where it will sit unless I test more.
I also tested external powered and non-powered USB 2.0 hubs plugged into the motherboards ASMedia and Intel ports.
As before, BTConfig froze when a hub was connected to an ASMedia port but all worked well when the hubs were plugged into any of the Intel ports.

 

[Mike_G_D]

Unfortunately for me, the old dreaded "talk group bleedthru" has returned with 10/12/2020 2252. I've noticed it being pretty severe over the last couple of days, just fyi.

I don't know if this actually came back in earlier versions as I have been so preoccupied with work and personal issues I really haven't been able to focus on the P25RX much until the last couple of days.

-Mike

 

[btt]

Unfortunately for me, the old dreaded "talk group bleedthru" has returned with 10/12/2020 2252. I've noticed it being pretty severe over the last couple of days, just fyi.

I don't know if this actually came back in earlier versions as I have been so preoccupied with work and personal issues I really haven't been able to focus on the P25RX much until the last couple of days.

-Mike

Mike,
I'm not sure what recent change would cause that. You mean that the talk group timeout doesn't hold on a talk group for the timeout period correct?

I went ahead and made the new stable version the same as testing (2020-10-15_0546).