I lowered the gains and now get this, but I can't tell what the X and Y axis values/numbers mean:
The X-axis is relative to frequency, whereby the trace (spike) at the center is the frequency the SDR is currently tuned.
The Y-axis is relative to amplitude (signal level) expressed in decibels (dB).
In your screen capture (FFT Plot), the signal at the center or of the spectrum (tuned frequency) as a peak level of approximately
-38 dB as best that can be interpellated from the course "20" dB graduations of the Y-axis.
Of more importance, is the level of the signal above the noise floor. The noise floor in your case if the average horizontal trace along
the bottom of the graph at about -90 (ish) dB where its desirable to adjust the LNA gain such that the tuned signal is 30-25 dB above
the noise floor. This assumes the received signal strength lends itself to achieving this degree of S/N.
Excessive LAN gain can cause the SDR to overload in the presence of multiple stronger signals driving the RF Amplifier into clipping
whereby numerous unwanted spurious signal products mix and interfere with the desired signals. These artifacts definitely create bit
errors that disrupt decoding of the desired digital signals, that will among other things, cause poor quality decoded audio.
View attachment 177653
And I've always found PPM confusing. How do I know which was to go, negative or positive. So if I see a tune error of -446 like above, does that mean the dongle is 446 Hz below frequency and I need a positive PPM value to bring it up? And, is there a way to change the PPM / -q value without having to keep closing the program and re-running it everytime I wanna try a new value?
PPM is an acronym for "Parts Per Million" and is a unit that describes the degree of frequency error. In your case, a tune error of
-446 is an indication that the SDR's internal time base (Oscillator) is off frequency in the negative direction by 446 Hz.
While this is not horrible, it ideally trimmed to maintain a tolerance of +/- 100 Hz if at all possible. It really depends upon the ability of
the digital demodulator to phase lock onto the incoming signal. Other op25 repos such as Boatbod has a much wider acceptance range
and can tolerate greater frequency error.
Therefore, if the tuning error is a negative value (-446), then the PPM value needs to move in a positive direction from its current value.
Conversely, if the tuning error is a positive value (446), then the PPM value needs to move in a negative direction from its current value.
Keep in mind to make small incremental changes. This is especially true when you remove the "-X" frequency tracking in that you could
apply an overcorrection that will cause the total loss of Trunk Signaling Blocks (TSBK Count). Make notes of where you start that you can revert back if necessary.
The Osmocom GUI has no provisions to input PPM corrections on the fly. You'll have to make an adjustment in the JSON, then restart
the op25 application to observe the result.
I am assuming that perhaps you're typing the multi_rx.py command line string manually via a terminal session each time you run the
application and may want to write a script to run op25 that will shorten the process. Alternatively, the same script can be executed
or controlled via a system service control that is especially desirable for headless operation.
The following is an example op25.sh script that works with Osmocom's muti_rx.py application.
./multi_rx.py -c your_system.json -T trunk.tsv -l http:0.0.0.0:8080 -v 5 -M false 2>stderr.2
