Forum: Virtual Classroom - Linux Driver For SDR Dongle

Log In via ThumbSat
via Facebook
Not Registered? Register
Log In
2 + 9 =

Linux Driver For SDR Dongle

Are any of the rtl-sdr linux drivers fits to your dongle?Yuriy 28th Feb 2016
Hello Yuriy.

We've been successful using our ThumbNet dongles with GQRX on the default Debian image of Raspberry Pi as well as on the CHIP from Next Thing Company, using the standard RTL-SDR drivers from the boot image.

Using the Package Manager in both devices, we needed to load the additional package: "Pulse Audio Sound Server 5.0.13" to get GQRX to talk with the dongle, but it was a "Plug and Play" operation after that. (BTW, the dongles from other vendors didn't work either until the sound server was installed.)

There might be other sound devices that would work in addition to the specific one mentioned above, but we haven't had time to investigate other options yet.

Thanks for asking!


Wade 28th Feb 2016
Do you have specific instructions for using the PI from out-of-the-box to operating the unit for someone that has never used a PI or CHIP ?

I see hundreds of articles and videos, but most are dated and some just dont look realistic... I plan to purchase the latest PI next week and try to load the Debian image. I think I can do that, but dont want to make a major mistake and take days to 'fix' it.. my patience at troubleshooting has deteriorated...
Bobbie 5th Mar 2016

We don't quite have the ability to drive that station from a CHIP or Raspberry Pi ready yet. The support software, like GPredict or GQRX is working, but the details of talking with the physical hardware is still in work.

Some of the code has been completed and a little more is completed each day.

If anyone is a Python or other code programmer and wants to volunteer to help, that'd be amazing!!

At the same time, we are working very hard to get a complete and current procedure written.

All of the information will of course be posted to the Virtual Classroom when completed, and I'll try my best to remember to put a comment here as a notice.



Wade 6th Mar 2016
Well, I'm "python and other code" programmer.
Do you have any repository somewhere? Yuriy 7th Mar 2016

Somehow I missed this comment, and I apologize.

The particular task we have at the moment is porting the functioning Arduino code over to something that the C.H.I.P. or Raspberry Pi can use to control the GPIO pins to drive the A4988 board.

If you have time to take a look at it, the Arduino code is only about 300 lines long and is available in the Classroom at

I'm sure it is poorly written, but as I said, it is functional when using a laptop and the Arduino.

As always, any advice or help is most welcome.


Wade 12th Mar 2016
I have not programmed in more than 15 years, so I will not dare comment on your code. But my comment is about the hardware..

If we use CHIP or RPi in the mix, would it be wise to keep the Arduino Nano and the A4988 boards to isolate the CHIP/RPi from static discharges from the antenna and feed-line/power-line??

Seems that replacing a damaged Arduino/A4988 board would be much cheaper than replacing the main CPU.

Would this simplify the code for the CHIP/RPi?? Bobbie 19th Mar 2016
It's an interesting question Bobbie...

Firstly, we are looking at static and lightning protection. We just haven't created anything worth sharing yet.

To address your main question though:

The A4988 is required, regardless of the CHIP/RPI/Arduino question. One of the processors has to driver the A4988 regardless, since they will never be able to drive the steppers on their own.

So do we let the CHIP drive an Arduino to drive the A4988 or do we just let the CHIP drive the A4988 by itself?

Of course, at first glance, the answer is that for simplicity we remove the Arduino altogether and save components and cost.

However, I've just started working with the new Python script for the CHIP and RPi and there is some doubt in my mind about timing and control at the moment...

As I write this, I am only just beginning to get into the testing, but it *seems* as if GPredict and ROTCTLD is interfering with the Python script's ability to efficiently send commands to the GPIO pins for the motors. (And that is before we add the SDR software into the mix.)

I'm working with the programmer still, but it very well might turn out that we need to keep the Arduino in the chain anyway, simply to ease the load on the RPi.

Time and testing will tell....



Wade 21st Mar 2016