OP25 Can Boatbod and Osmocom exist on the same physical machine?
- Thread starter maus92
- Start date
- Status
wgbecks
Active Member
The simple answer is no! The codebase of the two versions have diverged in different directions over the years,
yet they share many common folders and file names in that both are built on, and interface to Gnuradio.
See the side-by-side comparions shown below.
| Boatbod | Osmocom |
| /usr/local/include/op25/api.h | /usr/local/include/op25/api.h |
| /usr/local/include/op25/fsk4_demod_ff.h | /usr/local/include/op25/fsk4_demod_ff.h |
| /usr/local/include/op25/fsk4_slicer_fb.h | /usr/local/include/op25/fsk4_slicer_fb.h |
| /usr/local/include/op25/decoder_ff.h | /usr/local/include/op25/decoder_ff.h |
| /usr/local/include/op25/decoder_bf.h | /usr/local/include/op25/decoder_bf.h |
| /usr/local/include/op25/pcap_source_b.h | /usr/local/include/op25/pcap_source_b.h |
| /usr/local/lib/libgnuradio-op25.so | /usr/local/lib/libgnuradio-op25.so |
| /usr/local/lib/python3.8/dist-packages/op25/_op25_swig.so | /usr/local/lib/python2.7/dist-packages/op25/_op25_swig.so |
| /usr/local/lib/python3.8/dist-packages/op25/op25_swig.py | path of "/usr/local/lib/python2.7/dist-packages/op25/_op25_swig.so" to "" |
| /usr/local/lib/python3.8/dist-packages/op25/op25_swig.pyc | /usr/local/lib/python2.7/dist-packages/op25/op25_swig.py |
| /usr/local/lib/python3.8/dist-packages/op25/op25_swig.pyo | /usr/local/lib/python2.7/dist-packages/op25/op25_swig.pyc |
| /usr/local/include/op25/op25/swig/op25_swig.i | /usr/local/lib/python2.7/dist-packages/op25/op25_swig.pyo |
| /usr/local/include/op25/op25/swig/op25_swig_doc.i | /usr/local/include/op25/op25/swig/op25_swig.i |
| /usr/local/lib/python3.8/dist-packages/op25/__init__.py | /usr/local/include/op25/op25/swig/op25_swig_doc.i |
| /usr/local/lib/python3.8/dist-packages/op25/__init__.pyc | /usr/local/lib/python2.7/dist-packages/op25/__init__.py |
| /usr/local/lib/python3.8/dist-packages/op25/__init__.pyo | /usr/local/lib/python2.7/dist-packages/op25/__init__.pyc |
| /usr/local/share/gnuradio/grc/blocks/op25_fsk4_demod_ff.xml | /usr/local/lib/python2.7/dist-packages/op25/__init__.pyo |
| /usr/local/share/gnuradio/grc/blocks/op25_fsk4_slicer_fb.xml | /usr/local/share/gnuradio/grc/blocks/op25_fsk4_demod_ff.xml |
| /usr/local/share/gnuradio/grc/blocks/op25_decoder_ff.xml | /usr/local/share/gnuradio/grc/blocks/op25_fsk4_slicer_fb.xml |
| /usr/local/share/gnuradio/grc/blocks/op25_decoder_bf.xml | /usr/local/share/gnuradio/grc/blocks/op25_decoder_ff.xml |
| /usr/local/share/gnuradio/grc/blocks/op25_pcap_source_b.xml | /usr/local/share/gnuradio/grc/blocks/op25_decoder_bf.xml |
| /usr/local/include/op25_repeater/api.h | /usr/local/share/gnuradio/grc/blocks/op25_pcap_source_b.xml |
| /usr/local/include/op25_repeater/vocoder.h | /usr/local/include/op25_repeater/api.h |
| /usr/local/include/op25_repeater/gardner_cc.h | /usr/local/include/op25_repeater/vocoder.h |
| /usr/local/include/op25_repeater/p25_frame_assembler.h | /usr/local/include/op25_repeater/gardner_costas_cc.h |
| /usr/local/include/op25_repeater/frame_assembler.h | /usr/local/include/op25_repeater/p25_frame_assembler.h |
| /usr/local/include/op25_repeater/analog_udp.h | /usr/local/include/op25_repeater/frame_assembler.h |
| /usr/local/include/op25_repeater/rmsagc_ff.h | /usr/local/include/op25_repeater/ambe_encoder_sb.h |
| /usr/local/include/op25_repeater/ambe_encoder_sb.h | /usr/local/include/op25_repeater/ysf_tx_sb.h |
| /usr/local/include/op25_repeater/ysf_tx_sb.h | /usr/local/include/op25_repeater/dstar_tx_sb.h |
| /usr/local/include/op25_repeater/dstar_tx_sb.h | /usr/local/include/op25_repeater/nxdn_tx_sb.h |
| /usr/local/include/op25_repeater/fsk4_slicer_fb.h | /usr/local/include/op25_repeater/fsk4_slicer_fb.h |
| /usr/local/lib/libgnuradio-op25_repeater.so | /usr/local/lib/libgnuradio-op25_repeater.so |
| /usr/local/bin/scan4sync | /usr/local/lib/python2.7/dist-packages/op25_repeater/_op25_repeater_swig.so |
| /usr/local/bin/BER | path of "/usr/local/lib/python2.7/dist-packages/op25_repeater/_op25_repeater_swig.so" to "" |
| /usr/local/lib/python3.8/dist-packages/op25_repeater/_op25_repeater_swig.so | /usr/local/lib/python2.7/dist-packages/op25_repeater/op25_repeater_swig.py |
| /usr/local/lib/python3.8/dist-packages/op25_repeater/op25_repeater_swig.py | /usr/local/lib/python2.7/dist-packages/op25_repeater/op25_repeater_swig.pyc |
| /usr/local/lib/python3.8/dist-packages/op25_repeater/op25_repeater_swig.pyc | /usr/local/lib/python2.7/dist-packages/op25_repeater/op25_repeater_swig.pyo |
| /usr/local/lib/python3.8/dist-packages/op25_repeater/op25_repeater_swig.pyo | /usr/local/include/op25_repeater/op25_repeater/swig/op25_repeater_swig.i |
| /usr/local/include/op25_repeater/op25_repeater/swig/op25_repeater_swig.i | /usr/local/include/op25_repeater/op25_repeater/swig/op25_repeater_swig_doc.i |
| /usr/local/include/op25_repeater/op25_repeater/swig/op25_repeater_swig_doc.i | /usr/local/lib/python2.7/dist-packages/op25_repeater/__init__.py |
| /usr/local/lib/python3.8/dist-packages/op25_repeater/__init__.py | /usr/local/lib/python2.7/dist-packages/op25_repeater/__init__.pyc |
| /usr/local/lib/python3.8/dist-packages/op25_repeater/__init__.pyc | /usr/local/lib/python2.7/dist-packages/op25_repeater/__init__.pyo |
| /usr/local/lib/python3.8/dist-packages/op25_repeater/__init__.pyo | /usr/local/share/gnuradio/grc/blocks/op25_repeater_vocoder.xml |
| /usr/local/share/gnuradio/grc/blocks/op25_repeater_vocoder.xml | /usr/local/share/gnuradio/grc/blocks/op25_repeater_gardner_costas_cc.xml |
| /usr/local/share/gnuradio/grc/blocks/op25_repeater_gardner_costas_cc.xml | /usr/local/share/gnuradio/grc/blocks/op25_repeater_p25_frame_assembler.xml |
| /usr/local/share/gnuradio/grc/blocks/op25_repeater_p25_frame_assembler.xml | /usr/local/share/gnuradio/grc/blocks/op25_repeater_fsk4_slicer_fb.xml |
| /usr/local/share/gnuradio/grc/blocks/op25_repeater_fsk4_slicer_fb.xml |
It can, and has been done...but there's some moderately heavy lifting there. Linux has amazing capabilities along the lines of jails.
If you
The biggest issues pop out in the post made by the esteemed @wgbecks above, which show two separate versions of python (2.7 & 3.8) and the consequent divergences in the code path. A practiced dev should have no problem doing it, but the average RR "i run linux to listen to my local police" user would not like it very much.
Simple answer remains "no".
If you
chroot jail each one you may have them on the same physical machine, but it's not for the faint of heart. I would not recommend it for 99% of the users here, unless they are intimately comfortable with the inner workings of the Linux. The biggest issues pop out in the post made by the esteemed @wgbecks above, which show two separate versions of python (2.7 & 3.8) and the consequent divergences in the code path. A practiced dev should have no problem doing it, but the average RR "i run linux to listen to my local police" user would not like it very much.
Simple answer remains "no".
Last edited:
wgbecks
Active Member
Most of my instances of op25 (several of them at various remote locations) run on SBC's, but at the same time, I love and use the crap
out of Virtualization locally on both Linux and Windows hosts.
boatbod
Member
As noted by others, you cannot run osmocom and boatbod simultaneously on the same hardware without some sort of virtualization (pick your flavor.... chroot, vmware, virtualbox, kvm, ...) because you have to keep the libraries from interfering with each other. With virtualization it's pretty straight-forward, but there is a performance penalty (stuttery audio, underruns) that may be apparent if your cpu or memory gets overtaxed.
I suspected that they could not, but I thought I would ask. I don't want to run VMs on the current host machine, but I have another Windows box that has the power and resources. Currently experimenting with the osmocom variant on a fresh install of Linux - it has frozen once after a few hours running but not sure why. TSBKs stopped incrementing but the times continued to increment.
I was able to get Osmocom OP25 stable by installing the associated sql packages that support the GUI - I'm letting it burn in for a few more hours. Then I will start the adventure to install both variants on VirtualBox VMs hosted on a Windows 10 box. I remember trying this before, but I could not resolve the USB issues - does anyone have any tips?
lwvmobile
DSD-FME
Make sure to download and install the extension pack so you can use USB 2.0 and USB 3.0, otherwise you'll be stuck at the lower transfer speeds.
boatbod
Member
Virtualbox is what I use to run different flavors of OS when testing op25 compatibility. It works pretty smoothly once you have everything installed properly.
I got both versions installed as separate VMs on VMWare in Windows 10. They both work great and wrote a guide to set it up: OP25 - OP25 Windows 10 Basic Setup Guide
I love VMs - not! Trying to install Boatbod OP25 on a new Mint 20.3 VM on VirtualBox 7.0.2 - Mint is not allowing the user that I set up in the initial install of the OS to install git - which is needed to install OP25. I did basic research on the issue surrounding git on VMs but did not find a solution. Any ideas?
LOL - disregard - changing the user to Administrator from Custom AND rebooting VirtualBox fixed it.
LOL - disregard - changing the user to Administrator from Custom AND rebooting VirtualBox fixed it.
Last edited:
lwvmobile
DSD-FME
OK, so I got boatbod op25 version working in the VM using the DisplayPort audio output into the monitor speakers. The USB 3.0 ports are grayed - out, but the single Nooelec dongle still works as a 2.0 device.
I currently have the VM set to use 2 cores and 2GB of RAM - it seems to run fine, but is there a better config? Sounds as good as it can when using monitor speakers.
I currently have the VM set to use 2 cores and 2GB of RAM - it seems to run fine, but is there a better config? Sounds as good as it can when using monitor speakers.
lwvmobile
DSD-FME
If everything is running well for you, no need to tempt fate by introducing changes that might effect thing negatively. That being said, its a good time to mention, depending on which VM software you are using, it will be worthwhile to make a snapshot or copy and paste the virtual hard drive file to another place for safe keeping. If something breaks in the future, you can always have a snapshot or a copy of that image to fall back on in case your configurations get broken, or you do something in your VM that you can't undo easily.
Edit: 2GB is probably just fine, but meh, 2 cores or threads is probably fine for a single instance of OP25 (or maybe several) just as long as its all in the terminal window and you don't do anything too intensive otherwise. I usually tend to go either 2 or 4 threads on a Ryzen 5 2600 6-core (12 thread), just depends on how much you have to allocate, but too many would be a waste of resource
lwvmobile
DSD-FME
Not sure which VM software you are using, but in Virtualbox, you can open the machine settings, and under USB, set up a filter so it will automatically capture selected USB devices on boot up if that is your preferece. I usually don't set it, because my host machine may or may not be using it when I need the VM.
This is insane! I'm running Boatbod OP25 in a VirtualBox VM that runs LM Linux 20.3 with a single Nooelec, and it's using <1% CPU - and sounds very good - better than DSD-FL or a P25RX-II. The host machine is a bunch of spare parts that I cobbled together and stuffed into a FormD T1 box. The host CPU is a Ryzen 7 5800X so a fairly powerful last gen AMD, and I assigned it 2 cores and 2 GB of RAM. Much more efficient than SDR Trunk, but I think SDR Trunk sounds better - the best of all SDR software available IMO.
OP25 has excellent audio quality and has become my main way of monitoring P25. No need to spend $700 on an SDS or Unication.
I am contemplating selling one or both of my SDS 200 radios, the BCD536 and the P25RX-II - once our county deprecates its SmartZone system.
- Status
