OP25 feature update

boatbod

Member
Joined
Mar 3, 2007
Messages
2,321
Location
Talbot Co, MD
For the past couple months I have been brewing a significant update to op25 with a lot of help from members wgbecks & maus92 along with some generous folks in the background how allowed me to run development code on their systems in MD and NJ. As a result I am pleased to announce that the boatbod variant of op25 now supports Smartnet/Smartzone/ASTRO25 trunking along with a bunch of features that enable P25 trunking to be run under the multi_rx.py wrapper.

The git log reads as follows:
Code:
    New major release adds the following to multi_rx.py:
    - P25 trunking (port of existing rx.py trunking capabilities)
    - Motorola ASTRO25 (Smartnet/Smartzone) analog and p25cai digital trunking
    - New 'tuner' gnuplot type (plot #6)
    - Support for built-in audio player
    - Support for interactive terminal types (curses and http)
    - Support for narrowband fm analog demodulator (can be used stand-alone)
    - Support for metadata updates for icecast streaming
    - Numerous minor bugfixes and tweaks
Since this is a major update involving numerous changes to the c/c++ libraries and interface routines, you ***must*** start the build process from scratch prior to attempting to run the code. The easiest way to accomplish this is by running the following commands:
Code:
cd ~/op25
git pull
./rebuild.sh
As is unfortunately true with most aspects of op25, the documentation is lacking... that said, Smartnet configuration notes can be found in the following files:
~/op25/op25/gr-op25_repeater/apps/README-smartnet
~/op25/op25/gr-op25_repeater/apps/smartnet_example.json
In fact smartnet_example.json serves as a pretty good reference for most of the new configuration parameters understood by multi_rx.py

Anyone using rx.py should find their existing configurations continue to work as before.
 

markrob7000

N4MDR
Joined
Apr 4, 2004
Messages
32
Location
Powhatan, VA
I was able to get a lock on the control channel for the Chesterfield site for the Richmond SmartZone system. I see it decoding voice channels and talkgroups, but I'm not able to get any audio output. I'm running it on a Pi4 with the latest version of Raspberry OS.

Any ideas on troubleshooting the audio?
 

boatbod

Member
Joined
Mar 3, 2007
Messages
2,321
Location
Talbot Co, MD
I was able to get a lock on the control channel for the Chesterfield site for the Richmond SmartZone system. I see it decoding voice channels and talkgroups, but I'm not able to get any audio output. I'm running it on a Pi4 with the latest version of Raspberry OS.

Any ideas on troubleshooting the audio?
Happy to assist with troubleshooting if you can PM me your stderr.2 and copy of your cfg.json
 

marklt1

Member
Joined
Mar 5, 2005
Messages
36
Location
Streetsboro, OH
Analog audio doesn't appear to squelch for me in calling multi_rx.py

I am able to successfully hear radio traffic streamed from OP25 on a Pi3B to a desktop audio client (ffplay).
The issue I am experiencing is that the audio is not sqhelched between calls so I just hear static between audio transmissions. I have tried every imaginable value in "nbfm_squelch": -60 to mute between calls without any luck.
I also updated the code and recompiled without any change

My analog.json file contents are as follows

{
"channels": [
{
"name": "voice channel",
"device": "",
"destination": "udp://10.1.1.3:23456",
"frequency": 428125000,
"enable_analog": "on",
"nbfm_deviation": 4000,
"nbfm_squelch": -60,
"demod_type": "fsk4",
"filter_type": "widepulse",
"excess_bw": 0.2,
"if_rate": 24000,
"symbol_rate": 4800,
"plot": ""

}
],
"devices": [
{
"args": "rtl=0",
"frequency": 428125000,
"gains": "lna:49",
"name": "device_0",
"offset": 0,
"ppm": 0.0,
"rate": 1000000,
"tunable": false
}
]
}


I am calling the following audio client on my desktop. The calls sound great otherwise.
ffplay -ac 2 -af "pan=stereo|c0=c0|c1=c0" -nodisp -f s16le -ar 8000 -ac 1 -vn -i udp://10.1.1.3:23456


Any thoughts?
 

wgbecks

Member
Joined
Jan 17, 2005
Messages
229
Location
Porterfield, Wisconsin
Analog audio doesn't appear to squelch for me in calling multi_rx.py

I am able to successfully hear radio traffic streamed from OP25 on a Pi3B to a desktop audio client (ffplay).
The issue I am experiencing is that the audio is not sqhelched between calls so I just hear static between audio transmissions. I have tried every imaginable value in "nbfm_squelch": -60 to mute between calls without any luck.
I also updated the code and recompiled without any change

My analog.json file contents are as follows

{
"channels": [
{
"name": "voice channel",
"device": "",
"destination": "udp://10.1.1.3:23456",
"frequency": 428125000,
"enable_analog": "on",
"nbfm_deviation": 4000,
"nbfm_squelch": -60,
"demod_type": "fsk4",
"filter_type": "widepulse",
"excess_bw": 0.2,
"if_rate": 24000,
"symbol_rate": 4800,
"plot": ""

}
],
"devices": [
{
"args": "rtl=0",
"frequency": 428125000,
"gains": "lna:49",
"name": "device_0",
"offset": 0,
"ppm": 0.0,
"rate": 1000000,
"tunable": false
}
]
}


I am calling the following audio client on my desktop. The calls sound great otherwise.
ffplay -ac 2 -af "pan=stereo|c0=c0|c1=c0" -nodisp -f s16le -ar 8000 -ac 1 -vn -i udp://10.1.1.3:23456


Any thoughts?
Please set "LNA:0" then capture and post your FFT and Mixer plots, labeling them as "LNA:0". This will serve to establish an document the baseline noise floor of the RTL operating at 428.125 MHz.

Now restore (set) "LNA:49" and with your antenna attached, repeat and capture the same plots as above when the channel is known to be idle or not receiving the target 428.125 MHz signal.

Lastly, repeat plot captures one last time when the channel is known to be occupied with the target 428.125 MHz signal. These three sets of plots can them be compared to establish the baseline device internal noise floor, the noise floor increase due to spectrum content in the near field of the antenna, and of the overall signal to noise ratio when receiving the target signal.

The squelch block is GNU Radio doesn't unfortunately operate like a true "Noise" operated squelch in the same sense that a real analog FM
receiver would have. Therefore it's possible there may be impulse type noise in and around the near spectrum of 428.125 MHz that is keeping
the squelch open between transmissions. Your efforts to follow this simple procedure will prove one way or the other if it's a noise source(s) at fault, the SDR is crappy, or there is something went south when you compiled and installed op25.

Bill
 
Last edited:

marklt1

Member
Joined
Mar 5, 2005
Messages
36
Location
Streetsboro, OH
Please set "LNA:0" then capture and post your FFT and Mixer plots, labeling them as "LNA:0". This will serve to establish an document the baseline noise floor of the RTL operating at 428.125 MHz.

Now restore (set) "LNA:49" and with your antenna attached, repeat and capture the same plots as above when the channel is known to be idle or not receiving the target 428.125 MHz signal.

Lastly, repeat plot captures one last time when the channel is known to be occupied with the target 428.125 MHz signal. These three sets of plots can them be compared to establish the baseline device internal noise floor, the noise floor increase due to spectrum content in the near field of the antenna, and of the overall signal to noise ratio when receiving the target signal.

The squelch block is GNU Radio doesn't unfortunately operate like a true "Noise" operated squelch in the same sense that a real analog FM
receiver would have. Therefore it's possible there may be impulse type noise in and around the near spectrum of 428.125 MHz that is keeping
the squelch open between transmissions. Your efforts to follow this simple procedure will prove one way or the other if it's a noise source(s) at fault, the SDR is crappy, or there is something went south when you compiled and installed op25.

Bill
I ended up trying your recommendation and interesting enough, if I kept LNA < 35, calls were squelched properly. With this value, I couldn't even get static if I tried changing the "nbfm_squelch" to any imaginative value for "nbfm_squelch". It would appear that this value is being passed in to the code but is ineffective.

I duplicated my test with SDRsharp and the squelch value work fine around the 50 to 60 value depending on the gain I had selected.

Suspecting that it could be the code, I looked at multi_rx.py for the "nbfm_squelch" value being processed. I didn't see nbfm_squelch inthe code but I did see nbfm_squelch_threshold. I changed my analog.json file to reflect this change and now the squelch works as designed with this line:
"nbfm_squelch_threshold": -40,

The example file will need to be updated to reflect this parameter.

Thanks again for your assistance!
 

boatbod

Member
Joined
Mar 3, 2007
Messages
2,321
Location
Talbot Co, MD
"nbfm_squelch_threshold": -40,

The example file will need to be updated to reflect this parameter.

Thanks again for your assistance!
I looked in the smartnet_example.json and it already appears to have "nbfm_squelch_threshold" as the parameter name. I'm a little reluctant to change the baseline setting from -60 as it is going to be highly system dependent.

Please report how well the Smartnet functionality is working for you. We have a couple systems in daily operation with good results, but the more feedback the better.
 

marklt1

Member
Joined
Mar 5, 2005
Messages
36
Location
Streetsboro, OH
I looked in the smartnet_example.json and it already appears to have "nbfm_squelch_threshold" as the parameter name. I'm a little reluctant to change the baseline setting from -60 as it is going to be highly system dependent.

Please report how well the Smartnet functionality is working for you. We have a couple systems in daily operation with good results, but the more feedback the better.
All of the systems I am monitoring are using are using P25. I have a dozen OP25 units running so I would be happy to share any results with you. (I'll PM you with more info).
I think the baseline of -60 is fine. I was just struggling with overriding that value just to find out that the parameter in the README-analog file is called out as "nbfm_squelch" while the code is looking for "nbfm_squelch_threshold". After looking in the code, I easily discovered the naming difference and I now I get my sanity back.
Thanks again.
 

boatbod

Member
Joined
Mar 3, 2007
Messages
2,321
Location
Talbot Co, MD
can op25 run in the windows 10 WSL Windows system for Linux (in Windows 10 v2004)
Does WSL support usb devices? When it first came out it did not, but perhaps that has changed now.
For op25 to work, the osmocom driver has to be able to talk to the hardware.
 

waterbwuk

Member
Feed Provider
Joined
Jul 8, 2010
Messages
34
Does WSL support usb devices? When it first came out it did not, but perhaps that has changed now.
For op25 to work, the osmocom driver has to be able to talk to the hardware.
Looks like someone has figured out a way to use USBIP to do it, just have to re-compile the kernel. Not sure if this would work with SDR devices, though..

 

blantonl

Founder and CEO
Staff member
Joined
Dec 9, 2000
Messages
9,662
Location
San Antonio, TX
Would it be possible to get boatbod op25 to support Broadcastify Calls?

If the architecture for op25 would support it, might be the easiest $2500 bucks you earned this year... :)
 

boatbod

Member
Joined
Mar 3, 2007
Messages
2,321
Location
Talbot Co, MD
Would it be possible to get boatbod op25 to support Broadcastify Calls?

If the architecture for op25 would support it, might be the easiest $2500 bucks you earned this year... :)
Happy to take a look. OP25 doesn't use quite the same decode model as Trunk Recorder so it's probably going to depend a lot on your API. Where can I find more information?
 

boatbod

Member
Joined
Mar 3, 2007
Messages
2,321
Location
Talbot Co, MD
So understanding that op25 is not trunk recorder in as much as it is designed to follow conversations on individual (or groups of) tgids rather than capturing an entire system all at once, would it be useful for it to be able to upload the traffic it captures via your "calls" api? I could see doing this as a way of eliminating the need for liquidsoap/darkice, but I don't see much mileage in re-implementing trunk recorder under a different name.

From a technical perspective, how do you differentiate between discrete calls on the same tgid if there is no actual break between traffic? i.e. a conversation going back and forth with RIDs changing but the carrier never drops.
 

Bote

Member
Joined
Dec 19, 2002
Messages
766
Location
Ft. Lauderdale, FL, U.S.A.
The squelch block is GNU Radio doesn't unfortunately operate like a true "Noise" operated squelch in the same sense that a real analog FM
receiver would have. Therefore it's possible there may be impulse type noise in and around the near spectrum of 428.125 MHz that is keeping
the squelch open between transmissions.

Bill
Sidebar: This is exactly my sad experience using the excellent SDR-Console to monitor analog FM railroad communications. Is there any hope for an analog FM SDR squelch system that does not require constant attention as the noise floor varies throughout the day? TNX.
 

KC2KQH

Member
Premium Subscriber
Joined
Apr 17, 2017
Messages
33
I caught notes about this update while skimming the repo the other day. I'm excited to take this for a spin. I'll be testing on the Delaware State 800 system. That system currently runs a SmartZone control channel with P25 CAI audio. I've been waiting for them to finish their upgrade to a true P25 system so I could move forward with another project, but now this feature update beats them to it. I'm happy to provide feedback when I get the new version running and configured here.

Regarding the question on running OP25 via WSL, would using rtl_tcp get around the need for WSL to support USB? (I'm not sure what WSL's support for audio might be, as I haven't had a chance to try it out myself yet.) I don't have a need to run within WSL here, but I nearly exclusively use rtl_tcp as my source with my current OP25 install, so that thought came to mind.

-Ryan
 
Top