OP25 OP25 No Audio output.
- Thread starter VA4JOE
- Start date
- Status
boatbod
Member
I'll need "-v 11" detailed logs and screen shots of the plots when tuned to voice channel as requested in my previous post please.
boatbod
Member
I really must retire that "-2" option and make it simply default to on. There is no benefit in not including it...
How old is your dongle? Most of the current generation don't need an offset (-o 25000) to avoid the dc spike because they don't have one to start with. Either way, I doubt that's significant because it doesn't seem to affect your ability to receive the control channel.
wgbecks
Active Member
Joeseph,
The receive timeouts that you're experiencing may be due to radio frequency interference that could be coming from nearby
electronic devices or perhaps from a 700 MHz LTE site. To make any such determination, we'll need spectrum (FFT) plots made
with the SDR tuned to specific frequencies.
From the logfile you emailed to me, I was able to extract the frequencies of the primary and alternate control channels in addition
to four others that consistently fail to decode whenever voice traffic is assigned to them.
Primary Control Channel: 770.20625
Secondary Control Channels: 770.70625 and 770.95625
Voice Trunk Channels: 771.20625, 771.45625, 771.70625, and 771.95625
I would like you to shutdown op25 then using GQRX, tune in the last know active control channel of 770.20625 and carefully
apply frequency (PPM) corrections as necessary to center the spectrum on the red vertical centerline. It should resemble the
example shown below. It is important for this operation to set the Frequency zoom to a value for your SDR and sample rate
that produces a similar spectral display as the example.
With GQRX now setup, tune in each of the Voice Trunk Channels as listed above, one at a time, and make screen captures of the
FFT display, then post those to the forum that we can try to determine if there is any radio interference or other reason for a
high noise floor that may be impacting decodes.
The receive timeouts that you're experiencing may be due to radio frequency interference that could be coming from nearby
electronic devices or perhaps from a 700 MHz LTE site. To make any such determination, we'll need spectrum (FFT) plots made
with the SDR tuned to specific frequencies.
From the logfile you emailed to me, I was able to extract the frequencies of the primary and alternate control channels in addition
to four others that consistently fail to decode whenever voice traffic is assigned to them.
Primary Control Channel: 770.20625
Secondary Control Channels: 770.70625 and 770.95625
Voice Trunk Channels: 771.20625, 771.45625, 771.70625, and 771.95625
I would like you to shutdown op25 then using GQRX, tune in the last know active control channel of 770.20625 and carefully
apply frequency (PPM) corrections as necessary to center the spectrum on the red vertical centerline. It should resemble the
example shown below. It is important for this operation to set the Frequency zoom to a value for your SDR and sample rate
that produces a similar spectral display as the example.
With GQRX now setup, tune in each of the Voice Trunk Channels as listed above, one at a time, and make screen captures of the
FFT display, then post those to the forum that we can try to determine if there is any radio interference or other reason for a
high noise floor that may be impacting decodes.
wgbecks
Active Member
When your well enough, I am interested in GQRX capturs while tuned one at a time
to the following "Voice Trunk" channels; 771.20625, 771.45625, 771.70625, and 771.95625.
to the following "Voice Trunk" channels; 771.20625, 771.45625, 771.70625, and 771.95625.
I think all those frequencies are off to the side a little bit from these numbers on my dongle. At least that is what I believe. They are already captured on the previous post. Could the Control Channel be a wild goose chase?
Last edited:
lwvmobile
DSD-FME
Just from looking at your screenshots of GQRX, I would wager your PPM is off significantly, and perhaps OP25 can't find the proper error on it with such a wide difference. If I may demonstrate. What you want to do is put the frequency for the control channel (or a voice channel) in as the tuned frequency in GQRX (don't adjust the frequency to match the actual RF signal). For example. Here I am tuned to 851.375Mhz which is the frequency I want, but the PPM is set incorrectly (intentionally so for demonstration). If you click on the input control tab and manually adjust the Freq. correction arrows up and down, the signal in the waterfall will begin to shift closer or further away from the target signal.
What you want to do is find the ppm value where your red line is dead center (or as close as it gets to that RF signal.
For example, if I were using your commands, and you were currently using
When you ascertain this PPM value, this will be the -q value you wish to use when calling rx.py.
./rx.py --args 'rtl' -N 'LNA:47' -S 1000000 -f 770.19375e6 -o 25000 -D fsk4 -q 0 -T trunk.tsv -U -V -v 10 -X 2> stderr-stream0.2
I would change the underlined portion from -q 0 to the value that you found for the correct PPM error, in my case, that would be -q -3
In your case, judging by how far those frequency values are off, I would guess the ppm error could be much higher (or much lower) such as 48-52 or negative 48-52. I do have one dongle whose PPM error is off that much, but its consistently off by that much, so just knowing that value, I can still use it well enough.
What you want to do is find the ppm value where your red line is dead center (or as close as it gets to that RF signal.
For example, if I were using your commands, and you were currently using
When you ascertain this PPM value, this will be the -q value you wish to use when calling rx.py.
./rx.py --args 'rtl' -N 'LNA:47' -S 1000000 -f 770.19375e6 -o 25000 -D fsk4 -q 0 -T trunk.tsv -U -V -v 10 -X 2> stderr-stream0.2
I would change the underlined portion from -q 0 to the value that you found for the correct PPM error, in my case, that would be -q -3
In your case, judging by how far those frequency values are off, I would guess the ppm error could be much higher (or much lower) such as 48-52 or negative 48-52. I do have one dongle whose PPM error is off that much, but its consistently off by that much, so just knowing that value, I can still use it well enough.
boatbod
Member
PPM values more that +/-0-3 are usually indicative of a non temperature compensated dongle. They can be made to work with op25 quite successfully, but you have to get them warm (i.e. use them for a while) before you figure out the ppm correction.
Can the op please identify the brand and model of RTL device in use please.
Can the op please identify the brand and model of RTL device in use please.
It's blue in color, bought by me a few weeks ago from china. It says "NEW GEN. RTL2832" and under that "R828D & SDR". It has a small 800mhz antenna with it. The connector for the antenna is tiny and plugs(not screws) into the dongle. The "lsusb" shows "Bus 002 Device 002: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T"
lwvmobile
DSD-FME
./rx.py --args 'rtl' -N 'LNA:47' -S 1000000 -f 770.19375e6 -o 25000 -D fsk4 -q 0 -T trunk.tsv -U -V -v 10 -X 2> stderr-stream0.2
07/26/23 12:06:59.250690 [0] tsbk(0x3a) rfss_sts_bcst: syid: 9ee rfid: 1 stid: 88 ch1: 1520(770.206250)
07/26/23 12:06:59.251048 [0] tsbk(0x3b) net_sts_bcst: wacn: bee00 syid: 9ee ch1: 1520(770.206250)
Are you still starting up with this frequency loaded? The command you are using has frequency 770.19375 but the RFSS indicates it should be 770.20625
07/26/23 12:06:59.250690 [0] tsbk(0x3a) rfss_sts_bcst: syid: 9ee rfid: 1 stid: 88 ch1: 1520(770.206250)
07/26/23 12:06:59.251048 [0] tsbk(0x3b) net_sts_bcst: wacn: bee00 syid: 9ee ch1: 1520(770.206250)
Are you still starting up with this frequency loaded? The command you are using has frequency 770.19375 but the RFSS indicates it should be 770.20625
lwvmobile
DSD-FME
Is the garbled voice intelligible (like actual people talking) or is it just garbled for a moment, and then changes to ENC?
Like for a second or so...
lwvmobile
DSD-FME
Probably isn't catching the HDU or MAC_PTT to get the initial encryption identifiers, and only silences when it gets a completed LDU2 or ESS from the superframe. That'd be my guess. PPM could still be a partial problem if it doesn't land dead center, it may take a brief split second to adjust properly and demodulate good dibits.
boatbod
Member
Retune time is approx 750-800msec so it's not unusual to miss the HDU. Limitation of the current op25 demodulator unfortunately.
- Status
