Im a little stuck on the software side, but so close…
This is the Raspberry Pi 3 with Funcube Pro Plus Dongle and Dual Axis Rotor Controller sitting on my desk while I experiment with the software load and configuration.
4 Likes
Hello N7IPY,
May I know in a bit detail the kind of help you are looking for?
Regards,
Sudip Kar
Thanks for the contact.
Here is where I am at: I am at step 14 of the ‘raspberry-client-setup-guide.text’ document where it states to make changes to the ‘satnogsclient/settings.py’ file as needed. From looking through the file I think the only thing that needs editing is the Rigctld settings. I am not sure what fields to edit; RIG_MODEL = “” would be set to RIG_MODEL = “2518” for the Funcube Pro+ with no other changes?
Likewise, for rotctld, is there a settings file or do I include the specifics in the same command line when starting it as a deamon? The Rotor system communicates using the GS-232 protocol at 9600 baud. I can see the active USB port for the Rotor System using ‘lsusb’ but I do not know how to relate that information to a serial port number for rotctld?
Thanks for any advice… Will - N7IPY
For RIG_MODEL unfortunately there isn’t support for Funccube Pro+, I’ve just opened an issue for that https://github.com/satnogs/gr-satnogs/issues/64
Hopefully it will be resolved in the next days, I have sent you a private message with more details.
For rotctld you just add all the needed parameters when you start the daemon.
Fredy,
Surprised this is not a supported SDR device. The FC Pro+ is a popular device as it has much better receiver capabilities over the low end SDR RTL dongle and it is about the same size.The Raspberry Pi 3 supports it without drivers in the default distribution of Raspbian as seen in an earlier capture I posted. I went to the FunCube site and grabbed the specifications posted there:
Guaranteed frequency range: 150kHz to 240MHz and 420MHz to 1.9GHz
Typical frequency coverage: 150kHz to 260MHz and 410MHz to 2.05GHz
TCXO specified at 0.5ppm (in practice about 1.5ppm)
192kHz sampling rate
Standard SMA female antenna port
USB 1.x type A male connection
Eleven discrete hardware front end filters including:
6MHz 3dB bandwidth (10MHz at -40dB) SAW filter for the 2m band.
20MHz 3dB bandwidth (42MHz at -40dB) SAW filter for the 70cm band
Third- and fifth-order LC bandpass filters for other bands
Front end LNA OIP3 30dB
Typical noise figures:
50MHz 2.5dB
145MHz 3.5dB
435MHz 3.5dB
1296MHz 5.5dB
Typical NFM 12dB SINAD measurements:
145MHz 0.15uV
435MHz 0.15uV
I think using a better receiver would allow for overall better system performance. The only negative is that the FunCube Pro+ costs much more than the simple SDR RTL device.
Hello Will @N7IPY
The Funcube Dongle Pro+ is readily supported at the hardware interfacing layer. However, having it work in a SatNOGS setup requires that somebody familiar with the device and SatNOGS finds and tests the correct configuration. This has not happened yet and therefore it is not officially supported yet.
Also note that the FCD Pro+ does not “just work” without drivers. While that the dongle is recognized as a HID and an audio device by the OS, applications still need to know which commands to send if they want to control the gain, frequency, etc. This requires installation of a driver library before the SatNOGS client software can control it. This again requires testing and updating the installation guides.
So, it should theoretically work but some setup and tests are needed before we can claim “officially supported”
I totally understand. This level of code work is way above my pay grade, though I have been lead to believe the FCD P+ is working in a few SDR Apps on a Pi under Raspbian. I just write low level microcontroller code to move motors and read sensors 
It would be nice to be able to use other SDR radios in this project. I also have a SDR-Play sitting on the shelf, but I assume getting it into the the software stack would be just as much work and I think the SDR-Play is more expensive than the FunCube Pro+.
On a positive note, I made a 1 line change in the Rotor Controller firmware so it reports GS232A position data in the way ‘rotctl’ expects to see when using the rotor model #601 and I am able to command the rotor system via rotctl on the Pi 3. Still have some testing to do to be 100% satisfied.
If nothing else, I am learning a lot about poking around in linux.
1 Like
With client version 0.3 (just around the corner) we switch to gnuradio which allows for a lot more SDR flexibility than what rtl_fm allowed for.
This release will support most rtl-sdr sticks, usrp, hackrf, and airspy (with the latter 2 not working well with the raspberry pi and needs more powerful hw).
However, with that the script we came up with needs a sample rate multiple of 250k out of the gr-osmosdr block. Discussing the funcube dongles earlier today neither reach that point.
So, we will need some more re-engineering to make that happen. Until then if you can swing the $20 I would really recommend this rtl-sdr with a txco for low ppm drift: https://www.amazon.com/dp/B0129EBDS2/linkId=9806dfa291f74f7cdb49e2cfbe3d34eb
I’ve used that same model in some of my satnogs testing with GREAT success (better than some of the high end SDR devices even). Decoded data packets up to 19.2k (so far).
As for v3, we should have a release and docs in the next couple of weeks… Huge difference from what we have in release today, with a lot of improvements!
Message received. Ill have a couple of the rtl-sdrs here on Friday (Amazon Prime).