New to OP25. No audio on RPI 4. Seems to be setup corrrectly?

[puppycrack]

Hello all. I just installed OP25 onto a RPI4 by following some online tutorials. I'm using an old NooElec RT820T radio. The radio is plugged into a powered USB hub, so I'm thinking it's getting enough power. When I run the cmd:

rx.py --args 'rtl' -N 'LNA:47' -S 960000 -f 769.08600e6 -o 25000

I'm seeing tsbks going up, and entries appearing on the screen. Here are the charts for the above command:



When I try to capture traffic and hear sound, I run:
rx.py --args 'rtl' -N 'LNA:47' -S 960000 -f 769.08600e6 -o 25000 -T trunk.tsv -V -2 -U -v 1 2>stderr-stream0.2

stderr-stream0.2:
gr-osmosdr 0.1.4 (0.1.4) gnuradio 3.7.13.4
built-in source types: file osmosdr fcd rtl rtl_tcp uhd miri hackrf bladerf rfspace airspy airspyhf soapy redpitaya freesrp
Using device #0 Realtek RTL2838UHIDIR SN: 00000001
Found Rafael Micro R820T tuner
[R82XX] PLL not locked!
gain: name: LNA range: start 0 stop 0 step 0
setting gain LNA to 47
supported sample rates 250000-2560000 step 24000
[R82XX] PLL not locked!
Using two-stage decimator for speed=960000, decim=10/4 if1=96000 if2=24000
Project 25 IMBE Encoder/Decoder Fixed-Point implementation
Developed by Pavel Yazev E-mail: pyazev@gmail.com
Version 1.0 (c) Copyright 2009
This program comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it
under certain conditions; see the file ``LICENSE'' for details.
op25_audio:pen_socket(): enabled udp host(127.0.0.1), wireshark(23456), audio(23456)
p25_frame_assembler_impl: do_imbe[1], do_output[0], do_audio_output[1], do_phase2_tdma[1], do_nocrypt[1]
metadata update not enabled
using ALSA sound system
audio device: default
Allocating 15 zero-copy buffers
05/02/20 17:57:47.948101 voice update: tg(1077), freq(770756250), slot(-), prio(3)
05/02/20 17:57:49.994645 voice update: tg(2403), freq(770056250), slot(1), prio(3)
05/02/20 17:57:52.588324 voice update: tg(1077), freq(774443750), slot(-), prio(3)
05/02/20 17:57:54.509964 voice update: tg(1077), freq(774443750), slot(-), prio(3)

But I never hear any audio.

trunk.tsv
"Sysname" "Control Channel List" "Offset" "NAC" "Modulation" "TGID Tags File" "Whitelist" "Blacklist" "Center Frequency"
"P25 SYSTEM" "769.08600" "0" "0x47f" "C4FM" "monroe.tsv" "" "" ""

If I run "aplay path_to_wav_file", it plays just fine. And I've opened a alsamixer to verify the volume isn't muted or otherwise low.

I am a very much radio newbie, but I am more than willing to learn and keep trying. I'd really love to hear a dispatcher or otherwise hear anything. Any help or guidance is very much appreciated.

Thanks,
-pc

 

[puppycrack]

Attached is the stderr-stream0.2 file after running the second command again, except with "-v 10", for about 1 min.

FWIW: I'm looking here Monroe/Ontario County Trunking System, Regional, New York - Scanner Frequencies for my area in case it's relevant.

Thanks,
-pc

 

[wgbecks]

Your command line "rx.py --args 'rtl' -N 'LNA:47' -S 960000 -f 769.08600e6 -o 25000 -T trunk.tsv -V -2 -U -v 1 2>stderr-stream0.2"
appears that alright and that you should get audio. A couple of thigs to check.

(1) Make sure you don't have an HDMI cable plugged into the Pi at the same time that you're trying to use the headphone jack
(2) Enter the command alsamixer then make sure the Master gain control is all the way up.
(3) Enter sudo alsactl store to retain the previous gain adjustment upon a reboot of the Pi.
(4) The 3.5 mm plug that inserts into the headphone jack of the Pi must be 3.5 mm 4-pole plug. If using amplified speakers with only a 3-pole plug then use a 3-pole to 4-pole adapter.
(5) Run sudo raspi-config. Select Advanced Settings then select A4 Audio and select Option-1 Force 3.5 mm('headphone') jack

Keep in mind that there is very little audio signal available on the headphone jack and you'll need amplified speakers. Other options are
to configure liquidsoap and icecast to stream your op25 audio to make it available on your home network.

You don't need the -o 2500 on your rx.py command line. You seem to have a good signal and the datascope (eye pattern) and constellation plots look fine but the mixer plot shows that you're a little off frequency yet. Remove the -o 2500 then see where you are in relation to the center line in the mixer plot. Add -d xxxx or -d -xxxx to trim the SDR to center frequency.

The above audio advise assumes that you have not installed and started pulseaudio or you have not installed liquidsoap at this point else
the configuration changes.

Bill

 

[boatbod]

Since this is apparently a mixed phase 1/phase 2 system it should be using qpsk modulation which is the default when no "-D fsk4" parameter is specified on the command line. That said, the log shows "voice updates" are being actioned but always followed by a "voice timeout" error which strongly suggests the application is not properly locking the voice channels. When this happens it's usually the result of incorrect ppm correction compensated with a large fixed tuning adjustment (-d), or incorrect modulation.

Please try the following:
1. Drop the -f and the -o parameters from the command line. Re-run rx.py with -v 10 logging and see if that changes anything.

2. Try adding -D fsk4 to the command line and re-run at -v 10. I would be surprised if this helps, but it's worth a shot.

 

[KA1RBI]

Curious, 769.086 (in your trunk TSV file) isn't a valid frequency for this system, nor for any of the adjacent sites in the neighbor list....

2. Try adding -D fsk4 to the command line

I happen to know this system is CQPSK (technically, WCQPSK), so fsk4 isn't going to work...


Max

 

[boatbod]

Curious, 769.086 (in your trunk TSV file) isn't a valid frequency for this system, nor for any of the adjacent sites in the neighbor list....


I happen to know this system is CQPSK (technically, WCQPSK), so fsk4 isn't going to work...


Max

Yeah, the datascope plot looks suspiciously qpsk-ish, but I'm running short of ideas why it wouldn't be locking the traffic channels unless they aren't actually there for some reason. Perhaps a look at the fft plot while tuned to a traffic channel might provide some clarity.

 

[sallen07]

FWIW: I'm looking here Monroe/Ontario County Trunking System, Regional, New York - Scanner Frequencies for my area in case it's relevant.

Where in the county are you? Which site are you trying to monitor? As was pointed out above, the frequency you have in your trunk.tsv isn't used by *any* of the six sites for this system.

Also, since this is a Harris system, you need to list *all* of the frequencies for the site you want to monitor, since any of them can be used as the control channel, and as also pointed out, you need "CQPSK", not "C4FM".

 

[KA1RBI]

running short of ideas why it wouldn't be locking the traffic channels

The OP reported an old RTL , presumably uncompensated. One (incorrect) way to compensate for the needed correction would be to enter a CC frequency manually that differs from the proper frequency by some tens of kHz and OP25 will lock to this CC. As a guess, when OP25 tunes to a voice channel it's tuning to the wrong frequency because the requested frequencies don't have the "benefit" of the manual compensation. If this is the problem the solution is as usual to determine the proper PPM value and set the -q option to it; also use -X.

It might be interesting to add logic to detect the difference between the frequency we think we're tuned to versus the actual frequency(s) as
advertised in the various control channel broadcasts. Any discrepancy would merit a warning message...

Max

 

[boatbod]

It might be interesting to add logic to detect the difference between the frequency we think we're tuned to versus the actual frequency(s) as
advertised in the various control channel broadcasts. Any discrepancy would merit a warning message...

That's an excellent idea, thanks Max!

 

[puppycrack]

Sorry to have disappeared for awhile, life gets in the way sometimes. Thank you all very much for your kind responses. I was never able to successfully get any voice with the old radio, as I didn't really have a good understanding of how the ppm worked (I feel like I have a better grasp now thanks to all of you!). I ended up buying a NooElec NESDR Smart v4 radio. I *was* successful with this radio, probably due to it being temperature controlled and not having to adjust for the ppm - or at least very little anyways. My ending command was:

rx.py --args 'rtl' -N 'LNA:47' -S 960000 -T trunk.tsv -V -2 -U -v 1 2>stderr-stream0.2

Using a frequency of 769.11875 in trunk.tsv (which *is* listed as a control channel in my area).

One question that I did have had to do with offset. Does the offset apply to both the control channel and voice channels? If so, would that mean the same thing can be achieved with ppm, since they both more or less create an offset from the desired frequency, albeit one a hard number, and the other a percentage of the frequency?

Also, since this is a Harris system, you need to list *all* of the frequencies for the site you want to monitor, since any of them can be used as the control channel, and as also pointed out, you need "CQPSK", not "C4FM".

Are you saying I should be putting ALL control channels from the area to be monitored into trunk.tsv? If so, I assume it is one line / frequency, with each line referencing the same call group tsv file?

In the hopes that this might help someone else, below are some responses to questions from others. Again, I want to say a BIG THANK YOU to everyone for their help. I feel a little bit smarter now .

Regards,
-pc

(4) The 3.5 mm plug that inserts into the headphone jack of the Pi must be 3.5 mm 4-pole plug. If using amplified speakers with only a 3-pole plug then use a 3-pole to 4-pole adapter.

While I do have amplified speakers, and they do have a TRC connector (3-conductor), I was ultimately successful in getting the system to work with them. May the RPI4 is different?

Since this is apparently a mixed phase 1/phase 2 system it should be using qpsk modulation which is the default when no "-D fsk4" parameter is specified on the command line. That said, the log shows "voice updates" are being actioned but always followed by a "voice timeout" error which strongly suggests the application is not properly locking the voice channels. When this happens it's usually the result of incorrect ppm correction compensated with a large fixed tuning adjustment (-d), or incorrect modulation.

Please try the following:
1. Drop the -f and the -o parameters from the command line. Re-run rx.py with -v 10 logging and see if that changes anything.

2. Try adding -D fsk4 to the command line and re-run at -v 10. I would be surprised if this helps, but it's worth a shot.

Dropping the -o parameter was ultimately what I did with the new radio - so THANK YOU.

The OP reported an old RTL , presumably uncompensated. One (incorrect) way to compensate for the needed correction would be to enter a CC frequency manually that differs from the proper frequency by some tens of kHz and OP25 will lock to this CC. As a guess, when OP25 tunes to a voice channel it's tuning to the wrong frequency because the requested frequencies don't have the "benefit" of the manual compensation. If this is the problem the solution is as usual to determine the proper PPM value and set the -q option to it; also use -X.

It might be interesting to add logic to detect the difference between the frequency we think we're tuned to versus the actual frequency(s) as
advertised in the various control channel broadcasts. Any discrepancy would merit a warning message...

Max

BINGO. This is exactly what I was (incorrectly) doing. I looked up the frequency on RR, and then attempted to "find" it in gqrx. The frequency reported by GQRX was the one I was attempting to use. I didn't realize that the PPM "fixed" not only the deviation from what I saw to what the true frequency was for the control channel, but also locking onto voice channels. Thank you very much for this, as it added another piece of the puzzle for me.

 

[sallen07]

Are you saying I should be putting ALL control channels from the area to be monitored into trunk.tsv? If so, I assume it is one line / frequency, with each line referencing the same call group tsv file?

Well, you don't *have* to, but when the control channel changes, you won't hear anything anymore.

They all go together in your trunk.tsv where you currently have one frequency listed, separated by commas. Like this:

"851.1125,851.1625,851.350,851.6125,852.0375,852.1375,852.275,852.4375,852.4875,852.8875,852.9125"

Since Monroe/Ontario county is a Harris system, *any* of the frequencies can be the control channel, so you need to list all of them for whichever site you are trying to listen to.

 

[boatbod]

Offset in the form of the "-o" parameter is used for DC-spike avoidance and, if required, is typically 15khz or so. When you configure the -o offset it should not affect the tuned frequency you enter into trunk.tsv (as seen by op25) but you may notice the tuning line in the FFT plot gets a little off-center as the offset is applied to the sample spectrum.

 

[KA1RBI]

Offset in the form of the "-o" parameter is used for DC-spike avoidance

Correct. The use of -o is mostly unnecessary with the RTL-SDR, but others such as the USRP have a DC spike at zero Hz that causes potential interference if -o isn't used.

When you configure the -o offset it should not affect the tuned frequency you enter into trunk.tsv (as seen by op25) but you may notice the tuning line in the FFT plot gets a little off-center as the offset is applied to the sample spectrum.

Tangential and not a major issue, but should be viewed as a definite bug. The *only* observable effect of changing -o should be to move the DC spike (if present) to a point off-center from 0 Hz. Any other effect such as movement in the spectrum shouldn't happen...

Max

 

[boatbod]

Tangential and not a major issue, but should be viewed as a definite bug. The *only* observable effect of changing -o should be to move the DC spike (if present) to a point off-center from 0 Hz. Any other effect such as movement in the spectrum shouldn't happen...

The fft plot is a view of the raw sample spectrum centered on the physical hardware tuning frequency in the center of the plot. The logical tuned frequency is indicated on the plot with a movable vertical line that shows where the mixer is extracting it's signal. I'm not sure I would call it a bug that the plot shows an offset in use, but if it were desired to make this behavior go away, you'd have to truncate the fft series on one side to recenter it.

 

[puppycrack]

Well, you don't *have* to, but when the control channel changes, you won't hear anything anymore.

They all go together in your trunk.tsv where you currently have one frequency listed, separated by commas. Like this:

"851.1125,851.1625,851.350,851.6125,852.0375,852.1375,852.275,852.4375,852.4875,852.8875,852.9125"

Since Monroe/Ontario county is a Harris system, *any* of the frequencies can be the control channel, so you need to list all of them for whichever site you are trying to listen to.

I hadn't implemented your suggestion, and noticed I was no longer getting anything. I then remebered your post, included all control channels as you indicated, and voila! Everything came back. Thanks.