Yes, you are correct. I do this intentionally here because it gives better results the vast majority of the time on my local system. I see why this would not always be the case. I appreciate you bringing it up. Again, I will do some testing / experiments with this and let you know when I have some changes.
P25RX P25 Phase 1/2/DMR Receiver With Bluetooth Audio Support
- Thread starter btt
- Start date
- Status
@relicwr and I did some back and forth testing on some changes to the Java audio playback. It isn't a perfect solution yet, but it sounds really good now for the TDMA playback. There is some overlap sometimes between buffer playbacks and popping on occasion. I will work on this some more tomorrow and see if I can get those issues fixed. Overall, I think this is a big improvement for now with regard to TDMA playback. I will try to remember to include the date for the versions from here on out to avoid day to day confusion. New version available for download: 28_1717
I don't think the issue @Mike_G_D has brought up will be an issue for Phase 2 - only systems with the current firmware. This issue he has brought up relates to Phase 1 and hearing multiple talk groups on a single voice channel before returning to the control channel. (if I understand correctly).
Testing with _0934
Audio has drastically improved. I'd put it to being comparable to any of the older generation P2 scanners like my trusty and very tired Pro 668.
I've attached a roughly 4:30 video. I'm sure with more tweaking, the audio will get better but I'm going to start focusing on TG logging since logging is really what I bought the P25RX for.
I want something self contained and highly portable that can just silently log all of the TG's that come across a system.
I've tried this before with a RaspPi and SDR but it almost always ends up taking a dump. Not to mention having this setup in my backpack or computer bag when I'm traveling never worked. The P25RX seems to be up to the task.
bandicam 2020-08-28 17-48-41-193.mp4
Audio has drastically improved. I'd put it to being comparable to any of the older generation P2 scanners like my trusty and very tired Pro 668.
I've attached a roughly 4:30 video. I'm sure with more tweaking, the audio will get better but I'm going to start focusing on TG logging since logging is really what I bought the P25RX for.
I want something self contained and highly portable that can just silently log all of the TG's that come across a system.
I've tried this before with a RaspPi and SDR but it almost always ends up taking a dump. Not to mention having this setup in my backpack or computer bag when I'm traveling never worked. The P25RX seems to be up to the task.
bandicam 2020-08-28 17-48-41-193.mp4
@kinglou0, Thanks for the video. The audio quality for TDMA java playback was still pretty bad until the latest. From what I understand, you should be hearing good audio from the line-out or bluetooth with version 28_0934 though. If you are up to it this evening, give 28_1717 a try. It should sound much better.
Testing with _1717
Audio again is pretty good. If anyone watches through the included video and wonders about the audio quality while listening to the WSP TG's, they sound like garbage on everything I listen to them with. Has to be on WSP's side. On VHF, they sound great. Listen to them on a trunked system and they all sound like they have socks in their mouths. This system, their system, and the few times I've heard them on IWIN.
I had a audio glitch come up while listening that wasn't captured on the video. Traffic from the previous TG played for a second when the P25RX should have been decoding the audio for the current TG. Was maybe a second and then it cut back to correct audio. Hasn't happened again.
Btw, line out and bluetooth have similar audio to the PC audio.
Scratch that. I plugged in a good set of headphones to the line out. The audio is much better than the PC audio. I think you're on to something with Java.
You can also hear the software trying to decode/play the paging tones that go out before the automated dispatcher on Charlie/Bravo 1.
If I can find my Zoom recorder, I'll see if I can get some line out recordings.
bandicam 2020-08-28 18-33-13-737.mp4
Audio again is pretty good. If anyone watches through the included video and wonders about the audio quality while listening to the WSP TG's, they sound like garbage on everything I listen to them with. Has to be on WSP's side. On VHF, they sound great. Listen to them on a trunked system and they all sound like they have socks in their mouths. This system, their system, and the few times I've heard them on IWIN.
I had a audio glitch come up while listening that wasn't captured on the video. Traffic from the previous TG played for a second when the P25RX should have been decoding the audio for the current TG. Was maybe a second and then it cut back to correct audio. Hasn't happened again.
Scratch that. I plugged in a good set of headphones to the line out. The audio is much better than the PC audio. I think you're on to something with Java.
You can also hear the software trying to decode/play the paging tones that go out before the automated dispatcher on Charlie/Bravo 1.
If I can find my Zoom recorder, I'll see if I can get some line out recordings.
bandicam 2020-08-28 18-33-13-737.mp4
Last edited:
To everyone testing the P2 software, I would highly, highly recommend using external audio outputs to listen to the decoded audio. It's not perfect but considering what btt has been working with, this is nothing short of amazing to think how quickly P2 has progressed.
Mine is working great
@kinglou0
Thank you sir! That second video sounded *much* better. I should have the remaining glitches that I mentioned earlier fixed in the Java software by tomorrow.
The audio quality from the P25RX should be second to none from what I've heard from multiple people. I think you're right about the radios. If it audio quality doesn't sound good, it is probably the transmitting side. I guess they are putting a new system in over here in Grant county. I've heard their new radios sound like you are in the same room with the speaker (when listening with the P25RX). I think some really good improvements have been made to the PDM type microphones over the past few years. (I assume that is what they are using in them).
We are almost there now. Just give it a few more days. We progressed from the beginning all the way through excellent simulcast performance in harsh environments, to DMR support, and now to Phase II TDMA support since June. It wouldn't have happened without help from @relicwr, @KC1UA, and everyone else here who has contributed their time. It keeps me going from early morning to late at night. It has been a great ride so far.
Thank you sir! That second video sounded *much* better. I should have the remaining glitches that I mentioned earlier fixed in the Java software by tomorrow.
The audio quality from the P25RX should be second to none from what I've heard from multiple people. I think you're right about the radios. If it audio quality doesn't sound good, it is probably the transmitting side. I guess they are putting a new system in over here in Grant county. I've heard their new radios sound like you are in the same room with the speaker (when listening with the P25RX). I think some really good improvements have been made to the PDM type microphones over the past few years. (I assume that is what they are using in them).
We are almost there now. Just give it a few more days. We progressed from the beginning all the way through excellent simulcast performance in harsh environments, to DMR support, and now to Phase II TDMA support since June. It wouldn't have happened without help from @relicwr, @KC1UA, and everyone else here who has contributed their time. It keeps me going from early morning to late at night. It has been a great ride so far.
New version for testing available: 28_2356
Changes:
- Java audio fixes ( Tested here on Linux and Windows 10. All issues appear to be fixed. Please test this with TDMA and in general).
- Now that talk group timeouts work across channel grants, the max timeout has been increased to 30 seconds.
- Instead of waiting a period of time after TDU and TDULC to return to the control channel as it has been for some time now, this version will wait 'rtc_to xx' ms (default 250) after a voice subframe or TDU, and 1ms after a TDULC before returning to the control channel. (this only applies to Phase 1 for now). Phase II will timeout after no voice sub-frames received for 'rtc_to xx' ms. (default 250) before returning to the control channel.
This change may help with the issues mentioned by @Mike_G_D on larger, busy networks. It is a pretty big change, so need feedback on this one.
Changes:
- Java audio fixes ( Tested here on Linux and Windows 10. All issues appear to be fixed. Please test this with TDMA and in general).
- Now that talk group timeouts work across channel grants, the max timeout has been increased to 30 seconds.
- Instead of waiting a period of time after TDU and TDULC to return to the control channel as it has been for some time now, this version will wait 'rtc_to xx' ms (default 250) after a voice subframe or TDU, and 1ms after a TDULC before returning to the control channel. (this only applies to Phase 1 for now). Phase II will timeout after no voice sub-frames received for 'rtc_to xx' ms. (default 250) before returning to the control channel.
This change may help with the issues mentioned by @Mike_G_D on larger, busy networks. It is a pretty big change, so need feedback on this one.
I've been testing 28_2356 for about an hour now.
Still bad with the "mixed up" or "interfering" talk groups, at least using the default of 250 ms for the rf_sig_to setting.
It's pretty obvious now and weird - you might be listening to a PD manhunt and in the middle of the conversation in pops some traffic from a public works group about moving trucks around:-0!
And the other way around too...would be kinda comical if it weren't for the desired operation being impaired!
Also lots of cases of fire traffic suddenly coming over PD and Sheriff's groups and vice versa, etc.
I have noticed that this problem seems worse on one site versus another.
I monitor a very large county system with a lot of simulcast sites.
I am in range of two sites - West and North. At this time, early morning, North is not as busy as West. That seems to change over the course of the day. But, for now, seems like I have a major issue with the West site with this problem while not nearly as much with the North site.
From my location with my inside antenna, North is the stronger of the two in the -75 dBm range but West is not horribly low - in the -90 dBm range. Audio sounds really good on both sites.
Also, the West site seems to have more P2 traffic than the North site. So maybe an issue with a "mixed" system, P1 and P2 traffic?
I just tried setting the rf_sig_to to 50 to see if that helps.
Also set the Talk Group Timeout to 5 seconds now that that is available.
Still happens, sorry to say, on the West site. Those busy PW or road workers or whatever keep popping in to PD and Sheriffs traffic at the weirdest times! Like I said - would be funny but...
It's obvious the actual subscribers are not having this problem or they would certainly be mentioning it themselves.
I think has been happening for a while - for quite some time I was hearing a lot of traffic on a "Training" talk group such that I, at first, thought it was being repurposed as a different use. But then I noticed that the traffic was all over the place - snippets from many different groups. It got so annoying that I de-selected it. I think it was just a "quiet" little used talk group and this issue caused it to "collect" a lot of bits and pieces of traffic.
Anyway, yeah - definitely still a big issue for me, unfortunately, even with the rf_sig_to set to 50 ms. Guess I could try increasing the time beyond the default 250 ms but I would think that would make it worse. May try anyway.
I don't think there would be any point to sending logs as they wouldn't show anything - you have to know the system and hear the audio while seeing the displayed talk groups. Sometimes it's super obvious with just the audio, though, as mentioned above...could be hearing a tense situation on a PD talk group discussing a manhunt and all of a sudden a discussion about where to send the dump trucks pops in!
But the audio does SOUND good, at least through the line out. Have never tried the Bluetooth yet.
-Mike
Still bad with the "mixed up" or "interfering" talk groups, at least using the default of 250 ms for the rf_sig_to setting.
It's pretty obvious now and weird - you might be listening to a PD manhunt and in the middle of the conversation in pops some traffic from a public works group about moving trucks around:-0!
And the other way around too...would be kinda comical if it weren't for the desired operation being impaired!
Also lots of cases of fire traffic suddenly coming over PD and Sheriff's groups and vice versa, etc.
I have noticed that this problem seems worse on one site versus another.
I monitor a very large county system with a lot of simulcast sites.
I am in range of two sites - West and North. At this time, early morning, North is not as busy as West. That seems to change over the course of the day. But, for now, seems like I have a major issue with the West site with this problem while not nearly as much with the North site.
From my location with my inside antenna, North is the stronger of the two in the -75 dBm range but West is not horribly low - in the -90 dBm range. Audio sounds really good on both sites.
Also, the West site seems to have more P2 traffic than the North site. So maybe an issue with a "mixed" system, P1 and P2 traffic?
I just tried setting the rf_sig_to to 50 to see if that helps.
Also set the Talk Group Timeout to 5 seconds now that that is available.
Still happens, sorry to say, on the West site. Those busy PW or road workers or whatever keep popping in to PD and Sheriffs traffic at the weirdest times! Like I said - would be funny but...
It's obvious the actual subscribers are not having this problem or they would certainly be mentioning it themselves.
I think has been happening for a while - for quite some time I was hearing a lot of traffic on a "Training" talk group such that I, at first, thought it was being repurposed as a different use. But then I noticed that the traffic was all over the place - snippets from many different groups. It got so annoying that I de-selected it. I think it was just a "quiet" little used talk group and this issue caused it to "collect" a lot of bits and pieces of traffic.
Anyway, yeah - definitely still a big issue for me, unfortunately, even with the rf_sig_to set to 50 ms. Guess I could try increasing the time beyond the default 250 ms but I would think that would make it worse. May try anyway.
I don't think there would be any point to sending logs as they wouldn't show anything - you have to know the system and hear the audio while seeing the displayed talk groups. Sometimes it's super obvious with just the audio, though, as mentioned above...could be hearing a tense situation on a PD talk group discussing a manhunt and all of a sudden a discussion about where to send the dump trucks pops in!
But the audio does SOUND good, at least through the line out. Have never tried the Bluetooth yet.
-Mike
Update - tried the rf_sig_to set to 500 ms and, as I expected, seemed to make things worse.
In looking over the latest posts I see, btt, that you mentioned "rtc_to_xx" settings; is that something I should also experiment with or no? What exactly does it do? You mentioned voice frames ending so I am thinking it sets the time period to wait to go back to the CC after the ending of voice data or something like that while the earlier one you brought up, "rf_sig_to" refers to the time period after a carrier drop to check the CC?
Think I will leave that alone until you can explain that and I will stick with the rf_sig_to and try setting that lower than 50; I know you said the agc might have problems with that but given how bad this is now I think I will try it.
Just set rf_sig_to to 25 ms so we'll see...
-Mike
In looking over the latest posts I see, btt, that you mentioned "rtc_to_xx" settings; is that something I should also experiment with or no? What exactly does it do? You mentioned voice frames ending so I am thinking it sets the time period to wait to go back to the CC after the ending of voice data or something like that while the earlier one you brought up, "rf_sig_to" refers to the time period after a carrier drop to check the CC?
Think I will leave that alone until you can explain that and I will stick with the rf_sig_to and try setting that lower than 50; I know you said the agc might have problems with that but given how bad this is now I think I will try it.
Just set rf_sig_to to 25 ms so we'll see...
-Mike
Oh I understand!
At some point you have to sleep - diminishing returns after too long awake in the lab! Been there done that have T-shirt!
I'll do what I can to help with what I observe. Still think this is a great device for the price and well aware of the infancy of the development and limitations of your ability to actually have access to real systems to test on.
Thanks for your continued efforts!
-Mike
Ok, I think I found it. At least one related bug anyway (only one I could spot for now). New untested version available. 29_0748
The 'rf_sig_to' command was removed. It doesn't really need to be adjusted anymore since the TDULC will force the unit back to the cc well before the carrier drops.
Several logging messages related to the talk group timeout setting were added to help debug this new feature.
To enable:
$logging 1
The 'rf_sig_to' command was removed. It doesn't really need to be adjusted anymore since the TDULC will force the unit back to the cc well before the carrier drops.
Several logging messages related to the talk group timeout setting were added to help debug this new feature.
To enable:
$logging 1
Are there still java audio issues then? Sounds good on Linux and Windows 10 here with Phase 1.
I just heard an issue with talk group timeout. It appeared to be a new talk group that showed up immediately after the TDULC.
New untested version 29_0829 available.
This version does not wait 1ms after TDULC. Once the TDULC is received, it will return to the control channel.
[edit]
Still issues with the new talk group timeout. I'll work on figuring this out and test it here for a while before posting another link.
New untested version 29_0829 available.
This version does not wait 1ms after TDULC. Once the TDULC is received, it will return to the control channel.
[edit]
Still issues with the new talk group timeout. I'll work on figuring this out and test it here for a while before posting another link.
Last edited:
New untested version 29_9021 available.
This will most likely fix the new talk group timeout issue. The grant-2 update has two talk groups / channels. The talk group priority algorithm picks one of the talk groups, but it wasn't always heading to the correct of the two possible channels. This is why it would report the correct talk group, but you would hear the wrong voice.
Hopefully that was it.
I'm going to leave the TDULC return to control channel code as is for now. I'll continue to test and listen for any remaining issues.
This will most likely fix the new talk group timeout issue. The grant-2 update has two talk groups / channels. The talk group priority algorithm picks one of the talk groups, but it wasn't always heading to the correct of the two possible channels. This is why it would report the correct talk group, but you would hear the wrong voice.
Hopefully that was it.
I'm going to leave the TDULC return to control channel code as is for now. I'll continue to test and listen for any remaining issues.
- Status
Similar threads
