RPi 3 & RTL-SDR/OP25?

[kb9mwr]

Okay thanks for the clarification. Initially I had the center freq in trunk.tsv set to the middle of my highest and lowest freq of my system, and that was leading to problems (not trunking) till I set it to zero.

For the most part the –o 12.5e3 offset has greatly reduced the missing audio segments but not completely. Every once in a while the start of a sentence get chopped. I wonder if an AirSpy would be any faster?

The ASUS Tinker-Board may be another good choice to run OP25 on. It’s supposed to be electrically compatible to the Raspberry PI so it should run the same Raspbian Jessie image.

 

[boatbod]

For the most part the –o 12.5e3 offset has greatly reduced the missing audio segments but not completely. Every once in a while the start of a sentence get chopped. I wonder if an AirSpy would be any faster?

I've not used an Airspy so I can't say whether it would be better or not. My concern however, would be that the more data you want to move the more cpu impact. By minimizing the sample size there is less work to do and lower utilization. The Pi boards are cpu limited in this application, so a faster sdr will not necessarily get you better results.

- - -

I've tweaked my audio player so that it can be used both locally and remotely (i.e. standalone). If you want to try it out, you'll need to pull my previous changes plus these two:
rx.py
audio.py

When you run this version of rx.py with a "-W host" option other than 127.0.0.1 it will disable the local sockaudio player and send the udp data out over the wire. On the target machine run audio.py and it will receive the incoming udp packets and play them.

Notes: the audio.py file will need to be chmod +x when you download it. Furthermore, it assumes you have a gnuradio installation because it reuses some of the options parsing. Ideally I need to make it truly stand-alone, but I didn't have time to do that tonight.

 

[KA1RBI]

Thanks for this report Max, and I appreciate the work you are doing on the project. Do you take donations?

Not necessary. We're fairly serious about this being Free Software under the GNU GPL.

However that said, I'd like to add NXDN, especially TX support (sooner or later), but there's no (known) NXDN activity in this area. Accordingly, if someone were to long term loan (or gift) a transceiver that's NXDN capable (including programming cables/software) that would open up that possibility...

Thx

Max

 

[boatbod]

I removed the dependency on having a gnuradio install for the stand-alone audio.py player. The only other file you need is sockaudio.py

Note: the audio will be better if you pull in the changes to p25p1_fdma and p25p2_tdma but it will work without, although you will experience more underruns.

 

[kb9mwr]

My friend reports, he has successfully built GNU Radio + OP25 (Max Branch) on Ubuntu 14.04 in Virtual Box on his Windows-10 computer to compare. (He had been running the prior branch [scope.py] before.)

He notes that rx.py still occasionally misses the start of some transmissions even when running on Ubuntu on a much faster processor environment. However, if you set the center frequency in trunk.tsv, set the sampling rate to 2560000, and remove the offset value on the command line it works perfectly.

Though we both more or less concluded the fault was due a lack of processor power, it appears that rx.py is inherently slow to switch between the CC and the voice trunks. So we are not so sure that running a Pine Rock64 (etc) will be much better than running a Raspberry Pi.

 

[boatbod]

Does it switch any faster if you reduce the sample size? My laptop likes 1440000 and my RPi3 960000.

 

[kb9mwr]

No, it doesn't appear to. A friend gave it a try on the Tinkerboard (with TinkerOS). He wasn't able to complete compiling. It craps out during the make of pitch_est.cc.o ẅith an error of ¨narrowing conversion ´32970´ from ´int´ to ´World6 {aka short int} ´

 

[kb9mwr]

As a follow up, figured I'd pass this along. The NooElectric SDR performs better. Extensive testing on busy days shows its working perfectly. No chopped audio with few if any chirps on the beginning or end of transmissions.

One note, you can’t and don’t need to use the -o 12.5e3 offset on your rx.py command line. We have tested two of them and they work just fine with -q 0 specified.

 

[boatbod]

As a follow up, figured I'd pass this along. The NooElectric SDR performs better. Extensive testing on busy days shows its working perfectly. No chopped audio with few if any chirps on the beginning or end of transmissions.

One note, you can’t and don’t need to use the -o 12.5e3 offset on your rx.py command line. We have tested two of them and they work just fine with -q 0 specified.

The NooElec dongles do not seem to exhibit any significant DC spike so the -o offset is unnecessary, but if you use one it should work as intended. Conversely, my older cheap crappy dongle has a massive DC spike and won't work at all unless you define an offset.

 

[frerk]

No, it doesn't appear to. A friend gave it a try on the Tinkerboard (with TinkerOS). He wasn't able to complete compiling. It craps out during the make of pitch_est.cc.o ẅith an error of ¨narrowing conversion ´32970´ from ´int´ to ´World6 {aka short int} ´

Thanks for all of the work you guys have done. I have OP25 working great for Phase 2 stations in a VirtualBox and am following your footsteps to try it on a Pi3.

That narrowing error also occurs on the latest Raspian build. It appears to be caused by the later versions of GCC. You can get around it by using: make CXX_FLAGS="-Wno-narrowing"

After that I got an error about ‘isnan’ was not declared in this scope on more than one file. You can fix this by going into the base directory and running: sed -i 's/isnan/std::isnan/g' `grep "isnan" -rl` . It will recurse and fix all of them. It's just replacing usages of isnan with std::isnan.

 

[kb9mwr]

Wondering if anyone else has had problems with the program locking up on the Raspberry Pi?

The program is running, but the counters just keep counting up, like no activity was/has been detected, and of course, no audio. If I stop both programs and restart them, everything comes back just fine.

Seems to happen every 3-5 days, of continuous running.

 

[boatbod]

Wondering if anyone else has had problems with the program locking up on the Raspberry Pi?

The program is running, but the counters just keep counting up, like no activity was/has been detected, and of course, no audio. If I stop both programs and restart them, everything comes back just fine.

Seems to happen every 3-5 days, of continuous running.

Yes I have seen this, and it seems to be related to ssh going to sleep. I solved it by always running rx.py under the "screen" utility. You can then disconnect/reconnect at any time using ctrl-a,ctrl-d (disconnect) and screen -R (reconnect).

 

[kb9mwr]

I am running the op25 stand alone/headless (started rx.py with nohup), not ssh'ed in. I'll play with screen, but I get the impression you ssh'd in to the thing to start it/control it etc. I thought maybe the lockup stuff was related to the PI temp.

 

[boatbod]

I am running the op25 stand alone/headless (started rx.py with nohup), not ssh'ed in. I'll play with screen, but I get the impression you ssh'd in to the thing to start it/control it etc. I thought maybe the lockup stuff was related to the PI temp.

My pi3 is headless too, and I always ssh to access the command line, but I use the screen utility to make sure rx.py can run in the background when the ssh session is disconnected. Since I stated doing that I've experienced no more lockups.

 

[boatbod]

Thanks for all of the work you guys have done. I have OP25 working great for Phase 2 stations in a VirtualBox and am following your footsteps to try it on a Pi3.

That narrowing error also occurs on the latest Raspian build. It appears to be caused by the later versions of GCC. You can get around it by using: make CXX_FLAGS="-Wno-narrowing"

After that I got an error about ‘isnan’ was not declared in this scope on more than one file. You can fix this by going into the base directory and running: sed -i 's/isnan/std::isnan/g' `grep "isnan" -rl` . It will recurse and fix all of them. It's just replacing usages of isnan with std::isnan.

I pushed fixes to the imbe_vocoder code my github repo so you can now build it on Raspbian Stretch without needing the -Wno-narrowing workaround. A patch has also been submitted to Max for his consideration and inclusion in the main osmocom repo.

 

[Hmaxim]

I got as far as cmake ../ and i get "bash: cmake: command not found".. I did the updates and upgrades first..any advice? Sure could use a helping hand.

 

[boatbod]

I got as far as cmake ../ and i get "bash: cmake: command not found".. I did the updates and upgrades first..any advice? Sure could use a helping hand.

sudo apt-get install cmake

 

[Hmaxim]

Thanks..now I get this error at make
op25/build $ make
make[2]: *** No rule to make target '/usr/lib/libboost_filesystem-mt.so', needed by 'op25/gr-op25/lib/libgnuradio-op25.so'. Stop.
CMakeFiles/Makefile2:210: recipe for target 'op25/gr-op25/lib/CMakeFiles/gnuradio-op25.dir/all' failed
make[1]: *** [op25/gr-op25/lib/CMakeFiles/gnuradio-op25.dir/all] Error 2
Makefile:127: recipe for target 'all' failed
make: *** [all] Error 2

Slow but painful process..never say die..not yet anyway..appreciate all help!

 

[boatbod]

Thanks..now I get this error at make
op25/build $ make
make[2]: *** No rule to make target '/usr/lib/libboost_filesystem-mt.so', needed by 'op25/gr-op25/lib/libgnuradio-op25.so'. Stop.
CMakeFiles/Makefile2:210: recipe for target 'op25/gr-op25/lib/CMakeFiles/gnuradio-op25.dir/all' failed
make[1]: *** [op25/gr-op25/lib/CMakeFiles/gnuradio-op25.dir/all] Error 2
Makefile:127: recipe for target 'all' failed
make: *** [all] Error 2

Slow but painful process..never say die..not yet anyway..appreciate all help!

You could try:
sudo apt-get install libboost-dev
in case libboost has not been installed.

 

[Hmaxim]

Thanks will give it a try ASAP..will let you know. I find there is so much missing from the Pi3 OS..lots of dependencies and libraries that I had to dig up..not easy when you have no idea whay you are doing