OP25 OP25 (boatbod) Trouble Acquiring Control Channel

[HankFrank]

Hi

I have mostly successfully gotten OP25 running on a Chromebook. (Using Crostini) The linux container is buster (Debian 10), but I have also used an Ubuntu 22.04 container with the same symptoms.

I am having trouble setting getting OP25 to acquire control channels on a consistent basis (Using NooElec RTL Dongles). Sometimes different PPM values work, sometimes nothing seems to work and I get timeouts. It seems random whether it works or not. Sometimes on the tenth try, it acquires the CC and works. Sometimes on the first or second try. Behavior is the same with multi_rx and rx.py.

One thing I have noticed, is that on occasions when the CC can't be acquired (times out) the Frequency Error on the console will always slowly climb up to 850 or so hertz, doubling or so every second. The tuning available on the console also doesn't seem to help... So I can't "dial" things in after startup.

I've used these dongles on earlier versions of boatbod's fork without any issues, the needed PPM values are consistent.

So any ideas? I have attached some screenshots of the plots when the CC can't be acquired. The constellation is kind of weird, in that there is always one tight cluster in the corner. (But only one)

Thanks

 

[wgbecks]

I am having trouble setting getting OP25 to acquire control channels on a consistent basis (Using NooElec RTL Dongles). Sometimes different PPM values work, sometimes nothing seems to work and I get timeouts. It seems random whether it works or not. Sometimes on the tenth try, it acquires the CC and works. Sometimes on the first or second try. Behavior is the same with multi_rx and rx.py.

What specific NooElec SDR? Your "Tuned Mixer" plot indicates the SDR is high in frequency. You should be using an SDR with a TCXO for
best overall stability. That said, voltage fluctuations (power) to the SDR can cause the frequency instability problems such as you reported.

Suggestions: Remove any USB extension cables used to connect the SDR and plug it directly into your Chromebook. Bypass the use of any
external USB hubs and then reattempt to set the PPM (frequency compensation) again to center the "Tuned Mixer" spectrum.

It's also possible that you simply have a bad SDR.

 

[HankFrank]

Three of them are NESDR Smart V3, and a single RTL-SDR 2832U. They all have TXCOs in them and are plugged directly into the Chromebook. I have tried 4 different ones and have all the same behavior. All of these work fine (consistently) on another system with typical ppm settings. However, that system has an older version of boatbod's code. (Compiled maybe 10 months ago)

I've also used these to decode Radiosondes very recently so I think they are OK.

 

[wgbecks]

All of these work fine (consistently) on another system with typical ppm settings. However, that system has an older version of boatbod's code. (Compiled maybe 10 months ago)

Sorry, I am not familiar with the Chromebook but wonder if using Crostini to run the Linux container (Debian Buster) is responsible for
latency in data transfers between the NooElec SDR and the Chromebooks's USB internal hardware? Are they any settings that allow you
to select the type of USB controller? In VirtualBox VM's, it's often necessary to set a USB 3.x controller when running op25.

 

[boatbod]

Both the raw mixer and tuned mixer plots are showing a significant spike in the center which is characteristic of a single-frequency carrier rather than a qpsk/fsk4 signal. Add to that the single cluster in the constellation plot and I'd have to conclude you are not tuned to a control channel but some other non-P25 signal.

 

[HankFrank]

I'm definitely tuned to a control channel. Here are some caps of when this is working, and when it is not. (Note the same CC freq)

 

[wgbecks]

Did you check to determine if you can define (set) the USB Controller version? It would be very helpful to post your FFT plots that might
reveal a source of radio frequency interference. Set logging verbose to -v 11 then allow op25 to run for several minutes then post that
logfile (stderr.2) here.

 

[boatbod]

Unless you are monitoring a Motorola system that only uses it's alternate control channels in case of failure, it's quite possible for the control channel to rotate to different frequencies.

 

[HankFrank]

Did you check to determine if you can define (set) the USB Controller version? It would be very helpful to post your FFT plots that might
reveal a source of radio frequency interference. Set logging verbose to -v 11 then allow op25 to run for several minutes then post that
logfile (stderr.2) here.

Can't do that, but one setting I have been able to change is to Allow "More Permissive USB Passthrough" which I have done. Doesn't seem to make a difference.

Unless you are monitoring a Motorola system that only uses it's alternate control channels in case of failure, it's quite possible for the control channel to rotate to different frequencies.

This is a Motorola System, the CCs haven't changed in many many years.

 

[boatbod]

This is a Motorola System, the CCs haven't changed in many many years.

Ok. Presumably you would agree that your mixer plot looks nothing like the one I posted. The appearance of the big center spike may be a related to the presence of DC at 0Hz on your SDR dongle. You could try putting in an offset to see if the spike moves out of the way.
rx.py: "-o 20000" command line parameter
multi_rx.py: "offset": 20000 cfg.json parameter in 'devices' section

 

[maus92]

Chromebooks use commodity grade components. I would try a different host to rule out host, sdr, cabling and antenna issues.

 

[wgbecks]

Did you check to determine if you can define (set) the USB Controller version?

Can't do that, but one setting I have been able to change is to Allow "More Permissive USB Passthrough" which I have done. Doesn't seem to make a difference.

OK, let's attempt to figure out if there is a USB hardware virtualization problem. Stop op25 then run rtl_test in a terminal session.

A failed RTL SDR -or- corrupted data transfer with the RTL SDR will produce repeating lost bytes per the example shown below.



A functional RTL SDR without any data transfer issues will produce a static display free of reoccurring lost byte reports.



Perform this test and report back.

 

[HankFrank]

Hey wgbecks

Thanks for reminding me about rtl_test. You're definitely on the right track.

I have been going down the rabbit hole reading about Crostini/Termina USB support. Apparently it's not 100% yet, with Chrome OS only supporting serial USB devices on containers recently, without any mention of most other devices. Originally, only Android devices were supported on containers via USB (so Android Developers could run ADB I suppose). From what I can tell USB Passthrough support is still being developed, and YMMV.

Here is the output of rtl_test on the Container:

Found 1 device(s):
  0:  Realtek, RTL2838UHIDIR, SN: NOOELEC3

Using device 0: Generic RTL2832U OEM
No supported tuner found
Enabled direct sampling mode, input 1
Supported gain values (1): 0.0
Sampling at 2048000 S/s.

Info: This tool will continuously read from the device, and report if
samples get lost. If you observe no further output, everything is fine.

Reading samples in async mode...
Allocating 15 zero-copy buffers
lost at least 68 bytes
lost at least 120 bytes
lost at least 120 bytes
lost at least 140 bytes
lost at least 52 bytes
lost at least 188 bytes
lost at least 52 bytes
lost at least 136 bytes
lost at least 120 bytes
lost at least 52 bytes
lost at least 36 bytes
lost at least 204 bytes
^CSignal caught, exiting!

User cancel, exiting...
Samples per million lost (minimum): 10

I know the hardware is good, because I performed the test with the same dongle on another machine (Native Ubuntu Install) and I don't get any sample loss.

So, Chrome OS passthrough USB support on LXC Containers is definitely flakey, at least for RTL devices. I have noticed however, that performing a soft reset of the USB device (usbreset "RTL2838UHIDIR") before launching OP25 seems to help somewhat, and the control channel acquisition is more reliable (still not 100% though). Once I manage to get it running though, it seems to perform fine.

So for now, I think I can say it "kinda works". Support might also depend on the particular device firmware (the HW ID for this device is BLOOGLET / Gemini Lake) with some devices working better than others.

Thanks all.

 

[wgbecks]

So for now, I think I can say it "kinda works". Support might also depend on the particular device firmware (the HW ID for this device is BLOOGLET / Gemini Lake) with some devices working better than others.

Although I suspect a "Real Time" latency issue in the processing of the USB data, perhaps you might investigate increasing USBFS to see
if that helps?

 

[wgbecks]

Although I suspect a "Real Time" latency issue in the processing of the USB data, perhaps you might investigate increasing USBFS to see
if that helps?

One last thought... Try lowering the sample rate to -S 1000000 if it's by chance it's set to a higher speed. OP25 tunes /retunes
the SDR in following trunk traffic and doesn’t require high bandwidth.

 

[wrnhokie]

I actually can confirm this CAN work. I have an Asus C423 Chromebook and have it running Boatbod OP25 continuously with Crostini. I even have it using liquidsoap and icecast2 to stream it to my laptop or phone. I set it to not sleep when the lid is closed and it just sits on my shelf with the SDR sitting on top of it. I reboot it about once a week so it can install updates. The only annoying part is having to restart the Linux VM and re-enable USB passthrough and port forwarding when it reboots.

I monitor the Denton County and Cooke County P25 Phase 2 system, specifically the Denton Simulcast site using an official RTLSDRv3 on a 6 inch USB 3.0 extension cable and a little 700-800MHz rubber duck antenna.

I actually have experienced the same symptom before where it can't lock to a control channel and can usually make it go away with some combination of unplugging and replugging the SDR and moving the SDR around to get a strong signal and rebooting the Chromebook. It absolutely is caused by some sort of slowness or delay or resource contention issue on processing the USB packets.

My advice would be to try unplugging and replugging the SDR a few times and repassing it through to the Linux VM. Make sure you are using a low enough sample rate so as not to exceed the low processing power of the Chromebook. I use 960000. Turn off the plots when you don't need them to save precious CPU cycles.

 

[wrnhokie]

Oh and if you're using local audio, try -O pulse to use pulse instead of ALSA. I get less stuttery audio that way. And I think this goes without saying, make sure you're not doing anything else on the Chromebook as it takes. Essentially almost all the processing power of the low power Celeron to be able to run OP25.

 

[HankFrank]

Although I suspect a "Real Time" latency issue in the processing of the USB data, perhaps you might investigate increasing USBFS to see
if that helps?

Good idea! Unfortunately it looks like Google has locked the modification of this down (even as root). The memory buffer size is 16 MB.

One last thought... Try lowering the sample rate to -S 1000000 if it's by chance it's set to a higher speed. OP25 tunes /retunes
the SDR in following trunk traffic and doesn’t require high bandwidth.

I've been using this sample rate and it doesn't seem to help much.

Oh and if you're using local audio, try -O pulse to use pulse instead of ALSA. I get less stuttery audio that way. And I think this goes without saying, make sure you're not doing anything else on the Chromebook as it takes. Essentially almost all the processing power of the low power Celeron to be able to run OP25.

Thanks for registering and chiming in, good to know someone else is down with the struggle.


More Info:


Here's more to chew on. I decided to try running OP25 on this container alternately trying both an Airspy R2 and an Ettus Research B200mini I have. And it works GANGBUSTERS on both... No issues with CC acquisition, decodes are good, etc.

Something about the Chrome OS USB abstraction and the RTL drivers seems to be going on... They aren't playing well together for some reason. Very weird.