OP25 Experiments with op25 and liquidsoap

[KA1RBI]

That eye diagram looks qpsk but noisy. You can compare with two of mine; the first is the control channel (has two nice well defined eyes) and the second is from an active voice channel (kinda messy). C4FM would be a single wider eye.

1. The first eye diagram is a clean CQPSK plot. The second plot appears to be an attempt to render a 6,000 baud channel in the usual 4,800 baud time frame utilized by default to display the traces. None of the traces correlate and the result is not a lot different from random noise...

2. Both of the valid ones clearly show two symbol periods. For some reason this doesn't seem correct, it looks as if the sps= value in the call to eye_sink_f() is somehow set to twice the proper value...

C4FM would be a single wider eye.

Incorrect - the number of symbol periods in C4FM is always the same as the number of symbol periods for CQPSK... The width of the eye relative to its height is the main clue...

Max

 

[IQ_imbalance]

Tight clusters on the constellation plot is your main goal. Perhaps you need a better antenna?

Antenna is not optimized for 800MHz (it's a D-130J discone) but the frequencies are definitely within its envelope. I'm in a terrain-challenged location which may have more to do with any reception issues (i can't get any GSM850 calibration signals, for example!). I still think that tuning is my primary problem; trial and error has produced useful results on a few talkgroups.

What i'm having trouble comprehending is why i would get any results when I tune so far away from the indicated control frequency. For example, i get decoding when i tune to 774.044930 MHz (with no q- or d- correction) but the control frequency is clearly visible at 774.044563 MHz using gqrx (or rtlsdr_scanner).

 

[boatbod]

What i'm having trouble comprehending is why i would get any results when I tune so far away from the indicated control frequency. For example, i get decoding when i tune to 774.044930 MHz (with no q- or d- correction) but the control frequency is clearly visible at 774.044563 MHz using gqrx (or rtlsdr_scanner).

I very much doubt your control channel is being broadcast on 774.044563 MHz as that value does not align to a correct channel boundary. Your network is reporting its control channel frequency as 774.043750 Mhz (in the terminal screen) so this is the frequency that you should put in trunk.tsv and then tune the PPM error correction and fine tuning to center in the mixer plot.

 

[boatbod]

1. The first eye diagram is a clean CQPSK plot. The second plot appears to be an attempt to render a 6,000 baud channel in the usual 4,800 baud time frame utilized by default to display the traces. None of the traces correlate and the result is not a lot different from random noise...

2. Both of the valid ones clearly show two symbol periods. For some reason this doesn't seem correct, it looks as if the sps= value in the call to eye_sink_f() is somehow set to twice the proper value...

The second plot was a tdma phase 2 voice channel so I suppose the baud rate would be different from the control channel. I don't think the sps is being updated when the hardware is re-tuning. Thanks for the hint, I shall experiment further.

Incorrect - the number of symbol periods in C4FM is always the same as the number of symbol periods for CQPSK... The width of the eye relative to its height is the main clue..

I suck at identifying these signal plots thanks for correcting me.

As an aside, what causes a cqpsk constellation diagram to tend towards an "X" rather than four tight clusters? I'm pretty sure noise widens out the clusters into broader circles, but this is a distinct shape that seems unrelated to weak signals. When the "X" get more dense I experience control channel timeouts but I've not figured out what's going on so that I can drop hints to our local radio engineers.

Thanks Max.

 

[Covack]

Thanks to Boatbod and Darksky , op25 /liquidsoap are working great, on new install of Linuxmint mate 18.2
Metadata is better in sync than darkice, not much delay at all

 

[IQ_imbalance]

I very much doubt your control channel is being broadcast on 774.044563 MHz as that value does not align to a correct channel boundary. Your network is reporting its control channel frequency as 774.043750 Mhz (in the terminal screen) so this is the frequency that you should put in trunk.tsv and then tune the PPM error correction and fine tuning to center in the mixer plot.

I was trying to tune to the center of the signal at the frequency as my RTLSDR is seeing it....the tuning is off by a bit.

 

[KA1RBI]

As an aside, what causes a cqpsk constellation diagram to tend towards an "X" rather than four tight clusters?

I've seen this "X" pattern in constellations for a long time, but never 100% understood. It's limited to simulcast and as far as I can tell it's most pronounced in /\/\ LSM. The constellation space can be thought of as a circle divided into four quadrants as a Pizza is cut into four slices. If the symbol appears anywhere inside one of the quadrants it's assigned to that quadrant. The dividing lines between quadrants are the X and Y axes. The distance (radius) from the center of the circle to each data point is the magnitude of the point. The angular offset (0-360 degrees) is what solely determines in which of the four quadrants the point resides - the magnitude is ignored. In standard PSK the radius is always constant (modulo any fading) and is normalized to 1.0 via AGC.

It's known that the OP25 Gardner/Costas differential demod loop is less than ideal so it's possible something could be falling into an edge case or partially losing lock, etc.

I think more likely there are two interrelated causes of the "X" (i.e., points whose magnitude or radius from center is < 1.0)... The first one is improved by increasing the signal/noise ratio, i.e., maximizing the height of the FFT spectral pip relative to the noise floor. The second problem may be due to cancellation effects caused by the usual "simulcast distortion" - reception of an ensemble of signals from multiple transmitters with symbols arriving somewhat out of phase.

In many cases if using a directional antenna the two issues may be addressed at the same time by re-aiming the antenna.

When many points in the "X" are very close to the center (indicating magnitudes approaching zero) those symbols are the most likely to be received as errors. Sometime the symbols skate close to the edge and approach zero magnitude but still have a perimeter about the origin where the symbols mostly stay out of. In theory reception would be close to 100% error free in this case. It's speculated that the "X" phenomenon isn't just an artifact but may actually be something exploited by the LSM designers to squeeze out a few dB of additional ISI margin, or something...

I'd also suspect trouble if you were to take a particular receiving location that has a good strong "X" pattern and then (without moving the antenna) try to receive the station on a conventional FSK4-style scanner after reconnecting the antenna. I.e., this may be a good method to find locations where FSK4 scanners have the most trouble...

Max

 

[boatbod]

Thanks for the interesting explanation Max.

The site I monitor is indeed /\/\ LSM and most of the time comes in rock solid with four nice tight clusters. Every now and again it degenerates chaotically into an X,stays that way for a while (minutes) and then comes back to normal. Monitoring multiple copies of op25 running on different machines with different dongles in physically disparate locations shows similar behavior so I'm inclined to think it's a real RF phenomena and not something going wrong inside op25's demod. Curiously it only "recently" started happening (~2 months ago) after there was an upgrade to the site to add additional voice frequencies.

 

[KA1RBI]

Some of the things I've seen in LSM suggest that not all voice calls in the system always use the same sets of transmit tower sites (even within a specific SysID/SiteID/RfssID). Some system frequencies seem to be consistently stronger or weaker than others, although LSM signal strength measurement is never an exact science due to short term fluctuations.

I'd be interested if the "X" pattern correlates with particular subsets of system frequencies and/or talkgroups...

Max

 

[boatbod]

Some of the things I've seen in LSM suggest that not all voice calls in the system always use the same sets of transmit tower sites (even within a specific SysID/SiteID/RfssID). Some system frequencies seem to be consistently stronger or weaker than others, although LSM signal strength measurement is never an exact science due to short term fluctuations.

I'd be interested if the "X" pattern correlates with particular subsets of system frequencies and/or talkgroups...

Max

It's almost exclusively on the control channel (which never changes frequency). I've never seen it happen on the voice frequencies.

 

[IQ_imbalance]

changed from the D130J discone to a 800MHz yagi. The extra 8-10db made a world of difference.

 

[boatbod]

I just added a couple example systemd service scripts to enable liquidsoap and op25 to be automatically started at boot time. Somewhat vague installation instructions are included at the end of ~/op25/README-rpi3-liquidsoap

~/op25/op25/gr-op25_repeater/apps/op25-liq.service
~/op25/op25/gr-op25_repeater/apps/op25-rx.service

Note that these scripts cannot be used without editing to customize to your system environment.
- home directory
- uid/gid
- op25 script name (script that has all the rx.py command line options)
- liquidsoap .liq recipe name

 

[james18211]

I've gotten a single stream up and running with liquidsoap. Audio seems noticeably better quality than with darkice - fewer pops and crackles, and clearer transmissions.

I noticed that if outputting to pulseaudio for local playback, the stream to Icecast has an echo. Disabling local playback fixed that.

I'll leave this alone for a while to make sure it's stable (so I don't run into the silent audio issue w/ ALSA I had before), then move everything into a single system.

Thank you!

 

[boatbod]

I've gotten a single stream up and running with liquidsoap. Audio seems noticeably better quality than with darkice - fewer pops and crackles, and clearer transmissions.

I noticed that if outputting to pulseaudio for local playback, the stream to Icecast has an echo. Disabling local playback fixed that.

I'll leave this alone for a while to make sure it's stable (so I don't run into the silent audio issue w/ ALSA I had before), then move everything into a single system.

Thank you!

I just got done migrating my two production streams over to liquidsoap. Even though they run on an Intel NUC7 and weren't affected by the alsa aloop issues I figured it was time to move them now that I have working systemd.service files to start things at boot time. Audio appears to be excellent.

Not sure why you would have echo unless your stream definition somehow inputs from pulseaudio as well as the input.external adjunct. Weird... it certainly didn't do that on my RPi test system.

 

[thedrizzle]

Hi all,

Just coming in to this and kind of skimmed the first page (and skipped all the plot stuff, where I know little) but I just went through something similar (with some excellent advice from Boatbod in November, you're in great hands) and am in a good spot with it now and wondered if I could give any tips or resources.

A lot of what you (I think) are doing is documented in this wiki article that I used a lot as a framework. https://wiki.radioreference.com/index.php/Streaming_with_Trunk_Recorder_and_Liquidsoap I almost assume you've already seen it, but I didn't see that link as I skimmed so I'll put it there.

I ended up skipping the Icecast part as I was familiar with Shoutcast which I already run on Windows. Also I monitor a super busy system and needed ability to manage a queue; at least crudely. Its working great now (knock on wood), and I added a new end section to that wiki above with my modifications that might spark some ideas for you. Good luck!

(Edit to add) Just did an additional readthrough an saw you're not using Trunk Recorder. Sorry about that, I still hope maybe something there might help you see a way someone else did it. My apologies if a time waste

 

[james18211]

I just got done migrating my two production streams over to liquidsoap. Even though they run on an Intel NUC7 and weren't affected by the alsa aloop issues I figured it was time to move them now that I have working systemd.service files to start things at boot time. Audio appears to be excellent.

Not sure why you would have echo unless your stream definition somehow inputs from pulseaudio as well as the input.external adjunct. Weird... it certainly didn't do that on my RPi test system.

It could be an artifact of running in a VM, not entirely sure. I'll test it out a bit more once I'm sure it's stable in a VM with 1 stream, before I move the others over.

 

[Night_Watchman]

I have been testing the liquidsoap setup on my spare rpi 3b and have a couple of observations:
First, the audio level is lower than I would like and the -x parameter in the rx.py command line appears to have no effect.
Second, there is a high frequency component in the audio that makes it sound tinny.
I am running darkice on my main rpi and have a lowpass filter set in the configuration file, but have not found a similar setting for liquidsoap.

 

[boatbod]

I have been testing the liquidsoap setup on my spare rpi 3b and have a couple of observations:
First, the audio level is lower than I would like and the -x parameter in the rx.py command line appears to have no effect.
Second, there is a high frequency component in the audio that makes it sound tinny.
I am running darkice on my main rpi and have a lowpass filter set in the configuration file, but have not found a similar setting for liquidsoap.

You are correct that the -x parameter won't help on the rx.py command line because the audio processing is happening outside of rx.py. Try putting the -x parameter on the ./audio.py command line in your .liq script instead.

Sorry, can't help on the high frequency noise. I've noticed that with my RPi3 as well (doesn't happen on other types of hardware) and I suspect it is something to do with either the power supply or simply poor hardware design of the audio circuit. Perhaps you could use a USB sound card?

 

[DRL-XM43]

My X pattern cleared up when I solved a USB/dongle issue. Probably unrelated but I just encountered the issue yesterday.

 

[james18211]

It's probably unrelated to liquidsoap, but I moved my second feed over to the same system and after a few hours it stopped updating tskbks and the stderr had thousands of the following:

p25_framer::rx_sym() tuning error +1200

interspersed with a few of:

1548813396.650205 control channel timeout

Restarting OP25 brought it back. First feed still going just fine.