Peaberry V2 and older/processor limited hardware

General discussion and support for the Peaberry SDR V2.

Re: Peaberry V2 and older/processor limited hardware

Postby smull » Mon Mar 23, 2015 1:53 pm

I have a couple of older B model pi's I have used for things over the past few years. I have found that the USB power supplies they use are very noisy in the HF bands. I guess most are using battery power with regulators or non-switching power supplies for pi's and radio applications in the HF bands.

I installed linrad following the standard directions listed here: http://www.sm5bsz.com/linuxdsp/install/ ... ompile.htm
The only change I had to make was to change the following line in the file si570.c

#define PRODUCT_NAME_DG8SAQ "Peaberry SDR"

You can run lsusb -v and read what product name your system reads. Mine returned "Peaberry SDR" so that is what I changed the define to above. If your system returns anything else, you'll need to replace "Peaberry SDR" with whatever that is. The si570.c accommodates a few variations of si570 usb control. You could perhaps cull the code for the other methods out, but this was a simple one line fix.

When you start linrad, it will prompt you for all your settings before allowing you to operate a radio. Tell it to use the peaberry usb sound card as input, and the computer default as output. It should detect your si570 interface as well. Use 96000 as a sample rate of course.

You can be up and running in a few minutes. This is how linux software used to look in the old days; no frills, no eye candy ;).
smull
 
Posts: 27
Joined: Mon Feb 16, 2015 9:27 pm

Re: Peaberry V2 and older/processor limited hardware

Postby W4MMP » Mon Mar 23, 2015 3:36 pm

Hi,
Thanks again for the info. I will give it a go.
FWIW, I down loaded and compiled FLDIGI on the RPI 2. It runs but that is far as I have gotten with it. I need to move one of the Peaberrys to the RPI 2 and test. Simply running FLDIGI bumps one of the four cores to 25% with an average of 8% across all four cores. Looks promising.

If things keep progressing in this fashion, I just might give up on Windows and move all my HAM activities to the RPI 2. There are interesting developments that will help with CPU intensive applications. One is a FFT library created specifically to use the RPI (any model) GPU (http://www.aholme.co.uk/GPU_FFT/Main.htm). The second is NEON. This is library created by ARM and significantly improves FFT performance (https://projectne10.github.io/Ne10/).

I believe one my next steps along this line is to see if I can compile and run the ExpertSDR source (there is post in this forum regarding this). One thing it has going for it, is it uses the Qt IDE.
73
Ron / W4MMP
W4MMP
 
Posts: 579
Joined: Fri Jan 03, 2014 3:31 pm
Location: Lovettsville, Virginia FM19EG

Re: Peaberry V2 and older/processor limited hardware

Postby smull » Mon Mar 23, 2015 4:15 pm

I have found that fldigi is very reasonable with resource usage also. It might get a bit heavy when decoding modes like Olivia, but I think the pi2 will have no problem keeping up.

Have you every used sdr-shell or sdr-core under linux? I found a link to this on the forum:

http://kb8ojh.net/sdr/linuxsdr.html#sdr-shell

It looks a bit complicated and uses jack but It might allow fldigi to do rig control via hamlib.

If we could leverage the GPU on the RP, that would do wonders for the SDR community. It would be nice to have a easy to roll out peaberry SDR solution for the pi and pi2. Maybe when it is all working, you can put up a diskimage.

BTW, what are you using for a power supply for the RP when you are doing radio?
smull
 
Posts: 27
Joined: Mon Feb 16, 2015 9:27 pm

Re: Peaberry V2 and older/processor limited hardware

Postby W4MMP » Tue Mar 24, 2015 2:17 am

smull wrote:I have found that fldigi is very reasonable with resource usage also. It might get a bit heavy when decoding modes like Olivia, but I think the pi2 will have no problem keeping up.

Have you every used sdr-shell or sdr-core under linux? I found a link to this on the forum:

http://kb8ojh.net/sdr/linuxsdr.html#sdr-shell

It looks a bit complicated and uses jack but It might allow fldigi to do rig control via hamlib.

If we could leverage the GPU on the RP, that would do wonders for the SDR community. It would be nice to have a easy to roll out peaberry SDR solution for the pi and pi2. Maybe when it is all working, you can put up a diskimage.

BTW, what are you using for a power supply for the RP when you are doing radio?


No, I have looked into sdr-shell or sdr-core. I'm just now coming back up to speed on Linux and learning about things I did not need to know until now. I have been playing around with X11 and learning about sound device issues. My original RPI runs headless and has been sitting in a utility room for over two years just humming along running a couple really plain vanilla programs written C that accesses my solar equipment and reports the stats to PVOUTPUT.org. So the short of it I have a bit of a learning curve.

The power supply for the new RPI 2 is some no name brand wall wart I picked up at Micro Center when I purchased the RPI 2. I have not noticed any hash or spurs. But I do place mix 31 chokes on everything. As the commercial says: Frank’s Red Hot “I Put That SH*T On Everything” :lol: :lol:
73
Ron / W4MMP
W4MMP
 
Posts: 579
Joined: Fri Jan 03, 2014 3:31 pm
Location: Lovettsville, Virginia FM19EG

Re: Peaberry V2 and older/processor limited hardware

Postby smull » Tue Mar 24, 2015 12:44 pm

Almost any usb power supply I have makes HF noise without a power cord. Even a powered USB hub I use to power one of my pi's has to be unplugged. I wish I could choke it out but it is coming from the switching electronics. I use battery power for all my radios and might have to go that way for my pi's too. My laptop has to run on battery when I use it with a radio because the AC converter makes so much noise when plugged in.

It would be nice to have a cheap 110AC to 5v converter with a 3-5A supply that was silent in the HF bands for my pi.
smull
 
Posts: 27
Joined: Mon Feb 16, 2015 9:27 pm

Re: Peaberry V2 and older/processor limited hardware

Postby W4MMP » Wed Mar 25, 2015 1:24 am

Hi Steve,
If I may be so bold, I would look into your RF grounding arrangement. I have several wall warts in proximity to my station and I don't have a problem. The most problem I have is due to two Peaberrys sitting on top of each other. There are times when the Peaberry that is not actively being used emits a bunch of spurs until I power cycle it.

On the Linux front, Fldigi is working great! Perfect Olivia copy. PSK works fine also (I not could find an rtty signals on 40M this evening). The CPU utilization is modest. It will occasionally drive one of the cores to about 25/30%. The most I have seen is an average CPU utilization of %25 across all four cores. It appears that SMP processing is pretty good with Raspbian and appears to do a good job of keeping the cores balanced. I think I could get Fldigi to even lower utilization if I could figure out how to make the Fldigi configuration utility tell the g++ compiler to use optimization of -o2. The real test will when I get a SDR application running that needs to crunch some serious numbers.


My configuration is a bit kludged at the moment. I have always run two high quality USB sound cards back to back for audio transport between the SDR application and the digital application(s). So I simply moved the sound card designated for the digital applications to the RPI2. Configured Fldigi to use and it worked first time. So, I have HDSDR running on the PC feeding audio to the RPI 2. The only issue I have with Fldigi is that crashes X11 if the server is running on the PC. I have tried several different X servers for the PC and they all crash when I start Fldigi. I will submit something to the linuxham yahoo group.

I did compile and install linrad but I need to perform more software and hardware configuration work before it will function correctly.
Make progress ;)
73
Ron / W4MMP
W4MMP
 
Posts: 579
Joined: Fri Jan 03, 2014 3:31 pm
Location: Lovettsville, Virginia FM19EG

Re: Peaberry V2 and older/processor limited hardware

Postby smull » Wed Mar 25, 2015 1:22 pm

The USB power supplies do not have a grounding pin. I do not even think they are polarized. Are you using transformer type walwarts and running that through a linear regulator or are you using switching type walmarts that do not have a grounding plug?

You could leave X on the Pi and remote in with tightnvc. I think you will have better performance.

I did not know about the linuxham group. Thanks for mentioning it. I think a lot of what we are talking about would be better discussed there.

Good luck with your work!

73 Steve KV4XD
smull
 
Posts: 27
Joined: Mon Feb 16, 2015 9:27 pm

Re: Peaberry V2 and older/processor limited hardware

Postby smull » Fri Mar 27, 2015 12:32 am

I found I could getting quisk to stop skipping if I changed the mode from "DGT-U" to "USB". However, in "USB" mode, quisk does not send audio to the loopback device which Fldigi reads audio from and transmit from fldigi will not work either.

Here is what I think is happening: Quisk is sending audio to the speaker device as it processes the I/Q data. When the "DGT-U" mode is selected, it begins piping audio to the loopback device as well. When it does this my processor load maxes out and the audio skips. The audio going to FLDIGI has so many gaps it cannot decode.

Perhaps there is a way to send and receive audio from fldigi without using the "digital_input_name" "digital_output_name" options and without using "DGT-U".

I have included my quisk config file below. Surely someone else has already solved this.


from softrock import hardware_usb_new as quisk_hardware
from softrock import widgets_tx as quisk_widgets

si570_direct_control = True
si570_xtal_freq = 114211833

sample_rate = 48000
playback_rate = 48000
name_of_sound_capt = "plughw:SDR,0"
name_of_sound_play = "plughw:Intel,0"
channel_i = 0
channel_q = 1

# from http://quisk.973856.n3.nabble.com/Quisk ... 71689.html
#data_poll_usec = 1000 #default is 5000
#latency_millisec = 1 #default is 150

# Transmit Line
name_of_mic_play = "plughw:SDR,0"

# per directions at quisk help
# run modprobe snd-aloop first
digital_input_name = "plughw:Loopback,0"
digital_output_name = digital_input_name

usb_vendor_id = 0x16c0
usb_product_id = 0x05dc
smull
 
Posts: 27
Joined: Mon Feb 16, 2015 9:27 pm

Re: Peaberry V2 and older/processor limited hardware

Postby sternbal » Sat Mar 28, 2015 9:34 pm

Your analysis is correct, DGT-U adds another call to play_sound_interface, but I don't know how much extra overhead that adds. You can emulate this by using an alsa or pulse monitor device, or you can set name_of_sound_play="hw:Loopback,0" and not have audible signals. My atom netbook won't do it either. I can't wait to try an RPI2.
sternbal
 
Posts: 22
Joined: Thu Feb 13, 2014 3:18 pm

Previous

Return to Peaberry SDR V2

Who is online

Users browsing this forum: No registered users and 1 guest

cron