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, 10:00 PM
Member
  Amateur Radio Operator
Amateur Radio
 
Join Date: Apr 2003
Location: Green Bay, WI
Posts: 81
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. Its 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, 10:27 PM
Member
  Premium Subscriber
Premium Subscriber
 
Join Date: Mar 2007
Location: Talbot Co, MD
Posts: 373
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, 11:38 AM
Member
  Amateur Radio Operator
Amateur Radio
 
Join Date: Aug 2008
Posts: 372
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, 4:52 PM
Member
  Premium Subscriber
Premium Subscriber
 
Join Date: Mar 2007
Location: Talbot Co, MD
Posts: 373
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, 7:31 PM
Member
  Amateur Radio Operator
Amateur Radio
 
Join Date: Apr 2003
Location: Green Bay, WI
Posts: 81
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 7:38 PM..
Reply With Quote
Sponsored links
  #86 (permalink)  
Old 07-22-2017, 5:16 AM
Member
  Premium Subscriber
Premium Subscriber
 
Join Date: Mar 2007
Location: Talbot Co, MD
Posts: 373
Default

Does it switch any faster if you reduce the sample size? My laptop likes 1440000 and my RPi3 960000.
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 9:53 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