RPi 3 & RTL-SDR/OP25?

[n5pwp]

Oh OK. I didn't find anything that documented what each of the things in the terminal window were so I 'assumed' it was the agency sending and the agency receiving. Your explanation makes sense too. Everything we ask the RPi to do has a cost in CPU cycles. I'm still impressed with how good the little Pi does handling this stuff. I'm building a whole menagerie of RPis and dedicating them to different tasks. Thanks again for all you guys do for the hobby. I'm enjoying the heck out of it. I still do need to learn Python and see what I can contribute to the growth of this project.

Mike

 

[boatbod]

Oh OK. I didn't find anything that documented what each of the things in the terminal window were so I 'assumed' it was the agency sending and the agency receiving. Your explanation makes sense too. Everything we ask the RPi to do has a cost in CPU cycles. I'm still impressed with how good the little Pi does handling this stuff. I'm building a whole menagerie of RPis and dedicating them to different tasks. Thanks again for all you guys do for the hobby. I'm enjoying the heck out of it. I still do need to learn Python and see what I can contribute to the growth of this project.

Mike

Messing around in op25 has by necessity forced me to learn a lot. I've been a c/c++ guy for a long time so the concepts come easily (and once upon a different lifetime I knew pearl) but intermixing python and c++ has been an interesting learning experience.

Sorry, the documentation is rather sparse, but I'm happy to answer anything you want to know, assuming I can figure it out myself. Max is obviously an excellent resource too, especially when it comes to the nitty gritty of the SDR. (I'm familiar with the higher levels such as framing and trunking, but when people start discussing IQ samples, filtering etc, my eyes glaze over!)

 

[n5pwp]

Thanks, Boatbod. That's what life is. A series of learning new things. My programming skills started with MS BASIC and then progressed through some proprietary programming languages for the company I worked for and then on to Turbo Pascal and I dabbled a bit in Borlund C. I have an understanding of some of the logic concepts but am by no means skilled at it. I've read a lot about Python and it seems that is what is being used in all the projects that I'm interested in. It is also one of the reasons I started with the RPi. I have played with the SDR dongles for several years and managed, with the help of the users of RR forums to get the stuff working and have a superficial understanding of what's going on. I have an interest in the digital modes of communications but I probably don't have enough of the engineering level to understand the mathematics behind it all. After all I did flunk differential Calculus in college.

Anyway, I'm going to do some behind the scenes exploring of Python and see if I can muster enough knowledge to try to contribute. I appreciate the offer of help. You and Max have already gotten me this far.

Mike

 

[boatbod]

I remember Turbo Pascal. That was back when we had to book time in the computer lab!
My first computer was a Sinclair ZX81...

 

[n5pwp]

I started with a Timex-Sinclair 1000 with the 16KB RAM pack and used a cassette player to load programs into it. Ran CP/M for a while on a Z80 PC with 8" floppies and no hard drive before I moved to DOS and then on to Windows and Linux. I also got to work with graphics workstations on the internet before the civilians got on it. I worked for Xerox and I learned about GUIs and the internet and the DEC gateway for passing UUEncoded binary files over the internet. I did it on the 8010 and the 6085 from Xerox. Playing Maze Wars with other people all around the world in the early 80s was a blast. Now, to bring this back to the appropriate subject, I just got into playing with RPi3. I have two of them and am having a blast getting OP25 running on one of them. How's that for bringing it back home? 8-D

Mike

 

[royldean]

My first programming was a "turtle graphics" class on TRS80's in the early 80's.

 

[n5pwp]

I'll see your Turtle Graphics on a TRS80 and raise you an assembler on a DEC PDP8 in the late 60s. I didn't create the program. It was from the PDP8 manual our instructor used when I was in electronics class in High-School. OK, who wants to raise us a patch panel program on a Univac in the 1940's? :-D

Mike

 

[royldean]

If you used punch cards, you win (I'm sure you did!).

Back on topic:

I've got op25 running on my pi, but what I'm trying to do now is upon boot, automatically open a tmux session and start op25. This way I can ssh into the pi occasionally (when I'm not around to hear it) and check to make sure it's still active.

Alternatively, is there some way I can get it to just flat out launch on reboot (without tmux?). I've tried adding it to my crontab, but while the scrip will run just fine if I manually start it, it won't execute from my crontab. I must be missing something.

 

[boatbod]

If you used punch cards, you win (I'm sure you did!).

Back on topic:

I've got op25 running on my pi, but what I'm trying to do now is upon boot, automatically open a tmux session and start op25. This way I can ssh into the pi occasionally (when I'm not around to hear it) and check to make sure it's still active.

Alternatively, is there some way I can get it to just flat out launch on reboot (without tmux?). I've tried adding it to my crontab, but while the scrip will run just fine if I manually start it, it won't execute from my crontab. I must be missing something.

When you figure it out, let me know too!

 

[royldean]

When you figure it out, let me know too!

Ah, a chance for me to contribute! I'm up for the challenge.

 

[royldean]

Ok - It's not running

I thought op25 was running on my pi when I installed it at home, but it appears it is not. I tried running it with all the control frequencies (one at a time in the trunk.tsv file) and I always got this:

gr-osmosdr 0.1.3 (0.1.3) gnuradio 3.7.5
built-in source types: file osmosdr fcd rtl rtl_tcp uhd miri hackrf bladerf rfspace airspy
Using device #0 Realtek RTL2838UHIDIR SN: 00000001
Found Rafael Micro R820T tuner
p25_demodulator::connect_chain() demod_type=cqpsk
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_udp::open_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]
audio device: default
p25_framer::rx_sym() tuning error +1200
p25_framer::rx_sym() tuning error +1200
p25_framer::rx_sym() tuning error +1200
p25_framer::rx_sym() tuning error +1200
p25_framer::rx_sym() tuning error +1200
p25_framer::rx_sym() tuning error +1200
p25_framer::rx_sym() tuning error +1200
p25_framer::rx_sym() tuning error +1200
p25_framer::rx_sym() tuning error +1200
p25_framer::rx_sym() tuning error +1200
p25_framer::rx_sym() tuning error +1200
p25_framer::rx_sym() tuning error +1200
p25_framer::rx_sym() tuning error +1200
p25_framer::rx_sym() tuning error +1200
1509022345.190425 p25p1_fdma::rx_sym() timeout
1509022345.191284 control channel timeout
p25_framer::rx_sym() tuning error +1200

With essentiall the block of "p25_framer....." errors repeating indefinitely. Any suggestions as to what is going on here?

 

[boatbod]

That message is generated when the frame check sequence (FS) can be decoded, but the actual value received is incorrect because the cqpsk tuning is off by 90 degrees. [If you recall, the constellation plot shows all the dots clustered in one of four corners. If you were to sweep the tuning you would see brief rotation of the plot either CW or CCW. When it rotates just far enough it will "lock in" at the new position 90 degrees from previous.]

The solution is to adjust the tuning by (approximately) 1200hz using PPM control or Fine Tune so that the FS is decoded properly and the 'tuning error' messages go away. At that point you should see a stream of incoming "tsbks" in the terminal window.

If you have the LATEST copy of my repo and have cleanly done a cmake ../ and build, you should be able to sweep the fine tuning using the ,.<> keys from the terminal and at some point the signal will lock properly. If you have x-term capability on your PI3, you can also enable the plot of the I/F output by pressing the "5'" key on the terminal. Adjust fine tune until the signal is centered and symmetrical.

NOTE: slightly earlier versions of my repo don't behave entirely properly when adjusting fine tune due to persistence within the Costas loop. The most recent fix addresses this but does require a full regeneration of the op25 library code as I had to modify the api.

I thought op25 was running on my pi when I installed it at home, but it appears it is not. I tried running it with all the control frequencies (one at a time in the trunk.tsv file) and I always got this:

gr-osmosdr 0.1.3 (0.1.3) gnuradio 3.7.5
built-in source types: file osmosdr fcd rtl rtl_tcp uhd miri hackrf bladerf rfspace airspy
Using device #0 Realtek RTL2838UHIDIR SN: 00000001
Found Rafael Micro R820T tuner
p25_demodulator::connect_chain() demod_type=cqpsk
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_udp::open_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]
audio device: default
p25_framer::rx_sym() tuning error +1200
p25_framer::rx_sym() tuning error +1200
p25_framer::rx_sym() tuning error +1200
p25_framer::rx_sym() tuning error +1200
p25_framer::rx_sym() tuning error +1200
p25_framer::rx_sym() tuning error +1200
p25_framer::rx_sym() tuning error +1200
p25_framer::rx_sym() tuning error +1200
p25_framer::rx_sym() tuning error +1200
p25_framer::rx_sym() tuning error +1200
p25_framer::rx_sym() tuning error +1200
p25_framer::rx_sym() tuning error +1200
p25_framer::rx_sym() tuning error +1200
p25_framer::rx_sym() tuning error +1200
1509022345.190425 p25p1_fdma::rx_sym() timeout
1509022345.191284 control channel timeout
p25_framer::rx_sym() tuning error +1200

With essentiall the block of "p25_framer....." errors repeating indefinitely. Any suggestions as to what is going on here?

 

[royldean]

Looks like that worked! Many thanks.

So I'm seeing 85% cpu during closed squelch. When squelch opens, it shoots up to 130%. Any advice on lowering those numbers?

[edit] Change sample rate to 960000, dropped idle cpu to 75%, open squelch cpu to 110%. I was hoping for much lower. My pi is in a cana-kit box, I popped it open and the cpu heatsink is very hot. I guess for $35 I shouldn't be too surprised, huh?

 

[n5pwp]

One of the things that I learned from Boatbod is to turn off the plot. I was used to the scope.py version of OP25 on my desktop Linux system. I always kept the Constellation plot up. When I went to the Pi I tried to do the same thing. It worked OK but I would get late and / or choppy audio some times. I dropped the plot and it has made the audio very fluent and not starting late. Before that I watched the CPU and was running at about 37%. Boatbod told me the changes that affect the processor and it dropped it down to 18% on idle and about 23% on audio traffic being passed. I don't know why your Pi's processor is that high. Mine is a CanaKit also.
Mike

 

[royldean]

Wow, that's crazy. Would you mind posting what your command line is? Mine is the following:

./rx.py --args "rtl=0" --gains 'lna:36' -O 'default' -f 853.1125e6 -S 960000 -T trunk.tsv -v 1 -q 0 -d 0 -2 -U 2> stderr.2

Only changes from my laptop are removal of the plot and change the sample rate to 960000 (was 1440000).

 

[n5pwp]

./rx.py --args 'rtl' -N LNA:46 -f 773.431250 -S 960000 -T trunk.tsv -U -V -2 2>stderr.

I too dropped my sampling rate down following Boatbod's direction. Turned off the plot and used the -V -U for turning on the vocoder and using the internal audio handling vs the aplay (listen.sh). In the screen grab notice the CPU meter at the upper left near the Linux menu. It's at 20% while decoding audio. It averages about 23% during audio decoding. Idling is around 17-18%. Now this is after Boatbod's mods for the CPU. If you built your OP25 using his git repo then you already have it. I think the RPi is freaking awesome in this app. When I ran the older scope.py version on a Linux desktop PC it ran all the time about 45%. But then it had the GUI and the plot was running all the time. Max and Boatbod are doing a very nice job with OP25 for the RPi.

Mike

 

[boatbod]

On my PI3 I have the sample rate set to "-S 274000" which is almost (but not quite) the lowest you can reliably go. With the code from my repo I see idle cpu running ~45%, but that's with darkice running in the background as well.

Plots do consume LOTS of cpu, so unless you really want to run one I recommend leaving them off by default. This is one of the reasons I added the capability to turn then on/off dynamically

 

[n5pwp]

Yeah, I'm not streaming anywhere. I just listen to the audio in my office. I turned off the plot and now I don't really miss it. Like oyu said, use it to set up and then turn it off. I usually have the window minimized that goes to the RPi. I use RDP for a headless Pi. At 960000 sample rate I have perfect audio. You probably had to lower yours because of the feed going to DarkIce. I stopped using the listen.sh shell script and that may have been a savings also. I should probably fire it back up just to compare the relative efficiencies of the two different methods. Unless you've already done that, Boatbod. ;-)

Mike

 

[boatbod]

Yeah, I'm not streaming anywhere. I just listen to the audio in my office. I turned off the plot and now I don't really miss it. Like oyu said, use it to set up and then turn it off. I usually have the window minimized that goes to the RPi. I use RDP for a headless Pi. At 960000 sample rate I have perfect audio. You probably had to lower yours because of the feed going to DarkIce. I stopped using the listen.sh shell script and that may have been a savings also. I should probably fire it back up just to compare the relative efficiencies of the two different methods. Unless you've already done that, Boatbod. ;-)

Mike

I've never actually compared sockaudio.py to the nc | aplay method (which I assume is what the listen.sh script does?) but there are technical reasons why sockaudio is preferred. You can run either locally or remotely, depending on choice of rx.py command line options. Offloading audio to a remote machine (assuming you have one) does save some noticeable cpu. There is a python front end you can run on the remote machine called "audio.py" that only needs sockaudio.py to make a full remote audio client.

 

[n5pwp]

Here's a quick and dirty test. I shut off the internal audio (sockaudio.py) and turned on aplay and after watching for a few minutes I can't really see there's a significant difference between them. The audio seems to play the same (no drops or late starts). The CPU is at about the same %. The only thing is I can see the under-runs in the aplay because of the program not knowing when more data is coming after a transmission stops. I don't see that on sockaudio. Maybe it handles that more gracefully. Mine findings (unscientifically)show that going either way doesn't impact the CPU usage. Like Boatbod says if you want to save some load send the audio to a remote device. I'm happy with my setup.

Mike