RadioReference on Facebook   RadioReference on Twitter   RadioReference Blog
 

Go Back   The RadioReference.com Forums > Computer Aided Monitoring and Programming > Software Defined Radio


Software Defined Radio - A forum for general discussion of software defined radio (SDR) receiver equipment.

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
  #81 (permalink)  
Old 07-16-2017, 11:00 PM
Member
  Amateur Radio Operator
Amateur Radio
 
Join Date: Apr 2003
Location: Green Bay, WI
Posts: 87
Default

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.
Reply With Quote
Sponsored links
  #82 (permalink)  
Old 07-16-2017, 11:27 PM
Member
  Premium Subscriber
Premium Subscriber
 
Join Date: Mar 2007
Location: Talbot Co, MD
Posts: 609
Default

Quote:
Originally Posted by kb9mwr View Post
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.
Reply With Quote
  #83 (permalink)  
Old 07-17-2017, 12:38 PM
Member
  Amateur Radio Operator
Amateur Radio
 
Join Date: Aug 2008
Posts: 389
Default

Quote:
Originally Posted by kb9mwr View Post
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
Reply With Quote
  #84 (permalink)  
Old 07-17-2017, 5:52 PM
Member
  Premium Subscriber
Premium Subscriber
 
Join Date: Mar 2007
Location: Talbot Co, MD
Posts: 609
Default

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.
Reply With Quote
  #85 (permalink)  
Old 07-21-2017, 8:31 PM
Member
  Amateur Radio Operator
Amateur Radio
 
Join Date: Apr 2003
Location: Green Bay, WI
Posts: 87
Default

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.

Last edited by kb9mwr; 07-21-2017 at 8:38 PM..
Reply With Quote
Sponsored links
  #86 (permalink)  
Old 07-22-2017, 6:16 AM
Member
  Premium Subscriber
Premium Subscriber
 
Join Date: Mar 2007
Location: Talbot Co, MD
Posts: 609
Default

Does it switch any faster if you reduce the sample size? My laptop likes 1440000 and my RPi3 960000.
Reply With Quote
  #87 (permalink)  
Old 07-26-2017, 6:54 PM
Member
  Amateur Radio Operator
Amateur Radio
 
Join Date: Apr 2003
Location: Green Bay, WI
Posts: 87
Default

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} ´
Reply With Quote
  #88 (permalink)  
Old 08-13-2017, 4:47 PM
Member
  Amateur Radio Operator
Amateur Radio
 
Join Date: Apr 2003
Location: Green Bay, WI
Posts: 87
Default

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.
Reply With Quote
  #89 (permalink)  
Old 08-13-2017, 5:58 PM
Member
  Premium Subscriber
Premium Subscriber
 
Join Date: Mar 2007
Location: Talbot Co, MD
Posts: 609
Default

Quote:
Originally Posted by kb9mwr View Post
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.
Reply With Quote
  #90 (permalink)  
Old 08-31-2017, 10:24 PM
Newbie
   
Join Date: Oct 2013
Posts: 1
Default

Quote:
Originally Posted by kb9mwr View Post
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.
Reply With Quote
  #91 (permalink)  
Old 09-14-2017, 6:27 AM
Member
  Amateur Radio Operator
Amateur Radio
 
Join Date: Apr 2003
Location: Green Bay, WI
Posts: 87
Default

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.
Reply With Quote
  #92 (permalink)  
Old 09-14-2017, 6:53 AM
Member
  Premium Subscriber
Premium Subscriber
 
Join Date: Mar 2007
Location: Talbot Co, MD
Posts: 609
Default

Quote:
Originally Posted by kb9mwr View Post
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).
Reply With Quote
  #93 (permalink)  
Old 09-14-2017, 11:48 AM
Member
  Amateur Radio Operator
Amateur Radio
 
Join Date: Apr 2003
Location: Green Bay, WI
Posts: 87
Default

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.
Reply With Quote
  #94 (permalink)  
Old 09-14-2017, 5:56 PM
Member
  Premium Subscriber
Premium Subscriber
 
Join Date: Mar 2007
Location: Talbot Co, MD
Posts: 609
Default

Quote:
Originally Posted by kb9mwr View Post
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.
Reply With Quote
  #95 (permalink)  
Old 09-23-2017, 9:17 PM
Member
  Premium Subscriber
Premium Subscriber
 
Join Date: Mar 2007
Location: Talbot Co, MD
Posts: 609
Default

Quote:
Originally Posted by frerk View Post
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.
Reply With Quote
  #96 (permalink)  
Old 10-02-2017, 1:24 PM
Member
  Premium Subscriber
Premium Subscriber
Amateur Radio Operator
Amateur Radio
 
Join Date: Feb 2007
Posts: 23
Default

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.
Reply With Quote
  #97 (permalink)  
Old 10-02-2017, 7:09 PM
Member
  Premium Subscriber
Premium Subscriber
 
Join Date: Mar 2007
Location: Talbot Co, MD
Posts: 609
Default

Quote:
Originally Posted by Hmaxim View Post
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
Reply With Quote
  #98 (permalink)  
Old 10-03-2017, 9:25 AM
Member
  Premium Subscriber
Premium Subscriber
Amateur Radio Operator
Amateur Radio
 
Join Date: Feb 2007
Posts: 23
Default

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!
Reply With Quote
  #99 (permalink)  
Old 10-03-2017, 1:10 PM
Member
  Premium Subscriber
Premium Subscriber
 
Join Date: Mar 2007
Location: Talbot Co, MD
Posts: 609
Post

Quote:
Originally Posted by Hmaxim View Post
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.
Reply With Quote
  #100 (permalink)  
Old 10-03-2017, 3:15 PM
Member
  Premium Subscriber
Premium Subscriber
Amateur Radio Operator
Amateur Radio
 
Join Date: Feb 2007
Posts: 23
Default

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
Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On



All times are GMT -5. The time now is 8:14 AM.


Powered by vBulletin® Version 3.8.2
Copyright ©2000 - 2017, vBulletin Solutions, Inc.
All information here is Copyright 2012 by RadioReference.com LLC and Lindsay C. Blanton III.Ad Management by RedTyger
Copyright 2015 by RadioReference.com LLC Privacy Policy  |  Terms and Conditions