How can i make satnogs client use an analog radio receiver?
Currently SatNOGS Client doesnât support analog radio receivers. There is an interest on supporting them, but its priority is very low. However any contribution to this direction would be more than welcome.
If anyone is interested on contribute, just make sure that you are in sync with the developers (and developments) on client part, as we are in process of critical architecture changes.
2 Likes
from Wiki,/build: " Alternately, any radio supported by rigctl should work."
The link is broken,
on documentation/projects: "The stack allows usage of other receivers too (like amateur radio transceivers) through the usage of rigctld "
The first to advanced radio settings in satnogs setup are SATNOGS_RIG_IP and SATNOGS_RIG_PORT preset with the default values of rigctld
As far as I understood things: Satnogs-client uses GNURadio to emulate an sdr receiver. For every demodulation type there is a flowchart. The Sdr part would have been to be bypassed, instead a wave source supplies the signals recieved by the radio. Gpredict is called by satnogs client for the doppler correction. In its standalone version it can be configured to use rigctld, so it should be possible to configure it somehow to do so when called from satnogs. Am I completely wrong?
A lot of the flowgraphs depend on having considerably wider bandwidth inputs than what is generally provided by an analog radio. Features like frequency offset correction would not work, and many wider-bandwidth signals (19k2 FSK, 9k6 BPSK, APT), may not even be decodable at all due to the available filter bandwidths present in many analog radios.
I see the work required to re-add analog radio support as being considerable, and overall not worthwhile. A properly designed SDR receive setup with correct pre-amplifiers and decent band-pass filtering can perform just as well as a legacy analog radio setup for these applications.
Thatâs my 5c+GST anyway⌠others may disagree.
2 Likes
TU, Mark.
âre-addâ indicates, that support for analog radios had been in place and was removed. But why was effort spend on that? What if I want to talk via an OSCAR transponder, I need my TRX controlled by GPRedict anyway.
âfrequency offset correctionâ - do you mean the doppler compensation? why should that be included in the band-width? It is a large but predictable shift, once accounted for, there is no need to give up sensitivity for the favour of bandwidth. Thatâs why I was asking in first place: I expect the signal quality of my radio transceiver simply superior to that of a dongle that costs 1/50.
Iâm still learning and most likely havenât got the point.
Not all transmitters are exactly on frequency. We do our best to update the DB to add correction factors, but often you still find transmitters that have drifted. Iâm talking about offsets which are still in place after doppler correction.
With a SDR that can capture a larger chunk of bandwidth at once (the default for many observations is 48 kHz), there is the opportunity to âfindâ the signal in that bandwidth, and still enable a decode. With an analog transceiver, most likely running a FM Demodulator, locked to whatever the nominal frequency is, that is less likely.
As for talking via a OSCAR transponder, there is plenty of other software to let you do that (GPredict is one example, as you mentioned). SatNOGS was not intended to control your radio to allow you to talk via a transponder sat. There is some code buried within SatNOGS that was designed for uplink commands to (some) cubesats, but I believe this was also performed using SDRs.
As for performance, it comes down a combination of system noise figure, intermodulation distortion, and how much local noise you have to deal with. Itâs very possible to take that dongle that costs 1/50th of your big rig, and put a decent front-end in front of it which makes it perform perfectly well for SatNOGS use.
I should note that I also own a IC-9700 - I use the same antenna and preamp system with that as I do with my SatNOGS receive system, and apart from a few extra IMD products out of the RTLSDR (which I could probably remove with some more selective filtering), receive sensitivity is about the same.
2 Likes