Cheap SDR Dongle PPM, RPi Batteries, and other Ramblings

[lwvmobile]

Didn't want to make a separate thread for each of these, since this is more of a discussion than it is a set of precise questions, but what would you consider to be acceptable PPM error on a cheap Blue/Black RTL-SDR Dongle? Currently, I have 4 of them, three from one vendor, and one from another vendor. On the outside, they look the same, but come with a different package set. For context, this is the 'package' I ordered and received over the weekend from eBay.



My other 3 dongles that look like this, albeit black, have a PPM error of around 2PPM. This blue one up above, is 50, FIFTY, PPM off from hitting the frequency you really want to land on. I was just wondering if this is something I should treat as acceptable, or not. Knowing that its 50 PPM, and when using that one specifically making sure to give it the correct values, it seems to operate fine, and I haven't noticed any sort of significant problems with it otherwise(yet). I was just wondering if anybody else has encountered this sort of thing on these cheap knock off of knock off dongles or not.

My second rambling, does anybody use a Raspberry Pi 3B+ or similar SBC with a battery for SDR activities? If so, what size battery pack do you use, and what kind of battery life do you typically see when using say, 2 SDR Dongles and decoding software like OP25 or similar? I was pondering making some sort of setup in my truck to use or at least test the waters a bit. I originally was considering just using my piddly dual core celeron ultrabook for this task, but to be honest, just running two rtl_fm instances and DSD maxes that thing out. Its still a viable option for some tasks, has a build in screen, keyboard, and battery that can run for a couple hours under load, but I seem to remember the quad core ARM on the 3B+ handling the same tasks much better, so thought perhaps that's the way to go if anybody has any experiences they want to share using a Pi and a battery pack with dongles and SDR software, I'd love to hear how it went for you and also what kind of run time you get on a full battery pack and what size pack you used.

 

[goldmyne99]

I have been running 'cheaper' sdr dongle for 3 years with a ppm of 43 with SDRTrunk. No issues. It tracks freq as well as a 2nd with ppm of 0.3. YMMV.

 

[lwvmobile]

I have been running 'cheaper' sdr dongle for 3 years with a ppm of 43 with SDRTrunk. No issues. It tracks freq as well as a 2nd with ppm of 0.3. YMMV.

Aye, that's about what I figured, just as long as it doesn't deviate wildly or anything, I can live with 50, just need to remember to make sure that that particular dongle is set up for that value.

 

[lwvmobile]

Rambling Continued: Just tossing these two things out there to see if anybody has any experience or bumped into the same little issues I've had.

Making a simple radio in GNU Radio Companion. I've attached a shot of the flow graph for reference. GNU Radio Companion version 3.9.2.0. I'm not an expert on this sort of thing, but I followed a few tutorials and got a little radio set up, but for some reason the audio output from the radio, while I'm pretty sure the sampling rate is all set up just fine, I have issues getting DSD to 'hear' it and properly decode it. Sometimes it works, most times it doesn't. By contrast, I can send the audio out through the UDP sink, pick it up with socat, pass it through sox, play it with aplay, and then DSD can pick it up just fine. So, audio coming out of the regular audio sink not picked up with DSD when routed correctly using pavucontrol, same audio out the UDP sink through sox and aplay decodes just fine using this command. Disregard that the flow graph has the audio sink disabled currently.

socat stdio udp-listen:2001 | tee >(sox -t raw -b 16 -e signed-integer -r 48000 -c 1 - -t raw - vol 2 sinc 0.2k-4.5k -a 110 rate 48000 | aplay -t raw -f S16_LE -r 48000 -c 1) | ./dot-detector

padsp -m provoice -- ./dsd -fp -i pa:3 -o /dev/dsp -d ./MBE/PV

Continuing on, I have a version of the same setup but using a few Qt controls and widgets, and when I attempt to import and run said setup in a separate python script, I end up with a error:

QWidget: Must construct a QApplication before a QWidget

I realize this error is due to me needing to import Qt and set up a window, but since this is RR, I was wondering if anybody had an example just laying around on how they imported their GNU Radio Companion script with Qt widgets into another script and how they got it to run, or if its even possible to simply import that script generated by GNU Radio Companion with Qt widgets, that way I can have a nice little interface so I can see the FFT on signals, see if they are strong or weak, and also sliders for gain and little nice odds and ends.