OP25 OP25 (boatbod) update

[boatbod]

OP25 boatbod has been updated to include the ability to handle TDMA control channels. I've made a bunch of other P25 protocol related changes under the hood which should mostly be transparent, but ultimately will provide for better extendability if there is a need to support additional signaling messaging. Unlike Max/Osmocom's recent update, mine doesn't have an updated GUI or logging to a database, but has a good track record when used for headless streaming on low power hardware such as RPI4.

Enabling TDMA control channel:
rx.py : add the "--tdma-cc" command lin option
multi_rx.py : enable th "tdma_cc" option in the trunking section of cfg.json. See p25_rtl_example.json for syntax

NOTE: do not enable TDMA control channel unless you actually need to do so because this parameter internally sets the symbol rate to 6000 (from 4800) so FDMA control channels will become inaccessible.

For normal day-to-day operation I like running at log level "-v 1". If you want more detail, try running at "-v 9" to see IMBE/AMBE codwords, or "-v 11" to see everything including protocol decode. Log level can be changed on the fly from the terminal ("l" key or "LOG/V" button) so you don't have to run permanently at max verbosity if you have limited disk space or marginal cpu capabilities.

 

[krutzy]

Boatbod,
I currently use your fork on a RPi3B+. I was considering up going through with the new osmocom OP25 upgrade as I would like the updated GUI and the logging. My area does use TDMA by with roaming CC.
Question: why did you decide to only to use the single TDMA CC and not the rest of the upgrade? If I do the osmocom upgrade, will that screw up the rest of your build (liquidsoap and icecast).
Thank you.

 

[boatbod]

Boatbod,
Question: why did you decide to only to use the single TDMA CC and not the rest of the upgrade? If I do the osmocom upgrade, will that screw up the rest of your build (liquidsoap and icecast).

At this point they are really two separate codebases moving in similar but diverging directions since 2017. There is some commonality and features, but for example the trunking code used by multi_rx.py in my repo is 90% of my own creation with little of the original op25 left in it, while th rx.py trunking is more similar but still heavily modified. Some of my features have made it back into Osmocom while others have not, and frankly for either Max or myself to pick up features from the other codebase requires re-implementation of the concepts/ideas rather than a merge or copy. In the bigger picture, I should probably just rename my version so that it's less confusing from a support standpoint.

At the end of the day I would encourage anyone to try both variants and pick the one that does the best job for you. Snazzy GUIs aren't everything... if they were, we'd probably all be using sdrtrunk!

By the way, when you switch between the two repos you will need to "cd ~/op25/build; make uninstall" before you install the other version.

 

[krutzy]

Thank you Boatbod. See I didn't understand your under the hood mods and the multi_rx.py is something I would love, when I get the extra money for a couple more SDR's (based on my area's frequency range).

To be honest it really isn't the so much the gui as the logging I like. I have yours recording by date / hour. But it would be nice to know what hour to look at.

Time to get another SD card to experiment.

Thank you for your thorough explanation.

Kevin

 

[boatbod]

Thank you Boatbod. See I didn't understand your under the hood mods and the multi_rx.py is something I would love, when I get the extra money for a couple more SDR's (based on my area's frequency range).

To be honest it really isn't the so much the gui as the logging I like. I have yours recording by date / hour. But it would be nice to know what hour to look at.

Time to get another SD card to experiment.

Thank you for your thorough explanation.

Kevin

I'd like to make the logging more configurable so that you can enable individual pieces separately rather than all or nothing. e.g. protocol messages, call control, data structure dumps etc.

 

[maus92]

I kinda like the GUI (-ish) and logging, although I get that now using UT2. But I have the luxury of running an OP25 P25P2 NUC for voice and UT2 for logging the cch data.

 

[Carter911]

Boatbod,
I updated my RPi 3B+ single RTL-SDR Rx'er system yesterday with the new version.
Thank you for providing the Rebuild script, it appears to have executed without any difficulties, and it made the upgrade painless for a newbie!

JC

 

[hdphil]

Is it possible to extract the "alfa Tags" information and display it on a OLED type of display, maybe use the "import" to another file and call it OLED.py ? a adjustable delay to align my speaker audio with the alfa tag?
Thank,
Philip

 

[hdphil]

I guess not..

 

[wgbecks]

I guess not..

I haven't a clue as to the display properties of your OLED, but you might enable the HTTP Console feature available and providing that your display resolution is great enough to support use of a browser to monitor op25.

 

[hdphil]

I'm trying to get away from terminals, would like to use a ssd1306 type of display or a led matrix to display the alfa tag.

 

[boatbod]

Is it possible to extract the "alfa Tags" information and display it on a OLED type of display, maybe use the "import" to another file and call it OLED.py ? a adjustable delay to align my speaker audio with the alfa tag?
Thank,
Philip

Anything is possible given sufficient inclination. You'll probably have to write your own minimal terminal app or something that emulates the http terminal in order to gain access to the messaging containing the alpha tags. It's a pretty simple interface which just passes a JSON data block.

 

[hdphil]

BoatBod,
I agree that would be the best way to handle the information, but your solution is a little out of my programming skills, So i took a different route, i added a new UDP server in your code to send "metatext" to my client python file which contains the oled drivers.



i still have to do some more work to do, i suppose it would work for a small portable scanner.....

Philip

 

[boatbod]

BoatBod,
I agree that would be the best way to handle the information, but your solution is a little out of my programming skills, So i took a different route, i added a new UDP server in your code to send "metatext" to my client python file which contains the oled drivers.

View attachment 109016

i still have to do some more work to do, i suppose it would work for a small portable scanner.....

Philip

There's always more than one way to solve a problem. Great work!

 

[hdphil]

My next endeavor is to use a motion detector to mute/unmute my scanner audio when i leave the room..... it'll save a trip in the middle of the night, LOL

 

[jmayson]

This might not be the correct place for this question, but is anyone using rdio-scanner and if so, has anyone gotten it to work with op25 (I don't think the two talk at all). From what I can tell, rdio-scanner is the GUI and I still need something under the covers doing the work. I'm just not in the mood to wrestle with anything new given op25 works great for me.

 

[boatbod]

This might not be the correct place for this question, but is anyone using rdio-scanner and if so, has anyone gotten it to work with op25 (I don't think the two talk at all). From what I can tell, rdio-scanner is the GUI and I still need something under the covers doing the work. I'm just not in the mood to wrestle with anything new given op25 works great for me.

OP25 (boatbod version) produces an audio stream sent direct to the linux sound system or to a streaming server. rdio-scanner is looking for a directory with audio files (presumably .wav or .mp3) so the two are fundamentally incompatible.

 

[jmayson]

OP25 (boatbod version) produces an audio stream sent direct to the linux sound system or to a streaming server. rdio-scanner is looking for a directory with audio files (presumably .wav or .mp3) so the two are fundamentally incompatible.

Thank you. That's what I thought. I'll stick with OP25.

 

[maus92]

I just moved my OP25 installation to a Dell 3050 Micro i5-6500T, and OP25 seems much happier with its expanded processor resources. Previously it was on an i5-4250U NUC, which did better than the Raspberry Pis Model 3/4s which IMO are too underpowered for the application (and overheat resulting in CPU throttling.)