Decoding FUNcube-1 and similar satellites

Good day,

When trying to decode FUNcube-1 by replaying the audio I ran into the problem that not the whole bandwidth is available. We seem to miss the low tones.

Listen for example to this obs: https://network.satnogs.org/observations/2034874/

How can we changes this behaviour?

2 Likes

Hello,

I suspect you are correct, and any fudging to correct offset “drift” would be just that, “fudging.”
I had good results with your received audio (with low=0, High=3085 and Detected Frequency=551).
This is very close to my normal settings. A typical run is here:
https://network.satnogs.org/observations/2031646/
and the HackRF I’m playing with is here:
https://network.satnogs.org/observations/2041742/
The HackRF is a test, and the detected frequency is a little off at 850 Hz.

Good luck getting the word out. Use the offset only as a last resort. HI

73
-W6MSU
( .06 Hz. rating in 2019 ARRL Frequency Measurement Test - HI)
http://fmt.arrl.org/fmtdisplayresults.php?iid=649

1 Like

Thanks for the response, I have some problems with understanding what you are trying to explain with the “fudging” remark.

Where you able to decode my observation? I tried again, but the FUNcube-1 Dashboard is unable to decode both tones and therefor isn’t able to decode the data.

Then regarding the offset, I can’t find an option to make use of it.

The best thing would be to lower the receive frequency or widen the bandwidth but there is no option to do this as far as I know.

Any other support and or hints would be very much appreciated.

Jan PE0SAT

Hello,

I demodulated 65 TLMs from your audio (above).

Good luck.

73,

Guy - W6MSU
twitter.com/w6msu

How? The FUNcube-1 dashboard decoder can’t work with it.

Hello Jan,

Yes. I feel your pain. Some of these app (like FoxTelem) are comical. For those who don’t know
what we’re talking about, here’s the received audio from Jan’s recorded pass above:

(I am using Funcube-1 Dashboard v1.0.1044.1 (2017-03-01))
Just the indication of 551 Hz (center). on a 1200bps signal should be an indication that things are “close.” HI

So,

  1. Do not use “Auto Tune”
  2. The OGG formatted files for non-FM sources are very low (-30 dB nominal). That’s OK, just be prepared to deal with it.
  3. Shifting your entire system’s frequency is not recommended. I mentioned it half-heartedly. HI
    but, it’s
    sudo satnogs-setup > Advanced > Radio > SATNOGS_PPM_ERROR

Hope this helps. There are a million other variables, and I’ve only done about 40 or 50,000 TLMs from Funcube.

GL!

73,

Guy W6MSU

Thanks a lot, it is all in the details, I wasn’t able to move the centre freq slider.

But after some fiddling with the software I finally found a way and was able to decode the data.

Thanks Guy

1 Like

The main issues here are that:
a) The satellite is drifting, and so isn’t always on the correct centre frequency.
b) for the OGG output the BPSK flowgraph is only shifting the signal (assumed to be at 0 Hz), up to baud_rate Hz (in this case, 1200 Hz).

In the case of many observations, the funcube signals are a bit low, and so it ends up too low in frequency in the output OGG file.

I would suggest that instead of shifting the signal up just baud_rate Hz, it is shifted up to the centre of the available OGG file bandwidth - e.g. 12 kHz. The OGG sample rate is 48 kHz, so we can make use of everything up to 24 kHz. Why not do so?

This way even if the signal is off frequency by a few kHz, it will still end up in the output file and (hopefully) be decodable by Funcube Dashboard.

I should note that I don’t have these dashboard installed at the moment - can someone confirm that they will happily look at all the available bandwidth in a recording (e.g. 0-24 kHz), not just the bottom 3 kHz?

1 Like

Yes, I ran the Funcube Dashboard with a USRP N200, and (at one time) could cover 3 satellites (0-15kHz, one above and one below where AO-73 would track).

Was that with IQ input, or ‘real’ valued input (e.g. very wide USB)?

Hi, The N2xx project hit a very expensive wall when nothing supported the UBX (RF) daughter boards.
I ran IQ for (HF) DRM, but not the Funcube-1 Dashboard. Nice flat audio via a VAC.

Here a NAYIF-1 spectrum that I analysed with the help of Spectrogram.
One can clearly see that the on-board oscillator is stable and that this isn’t
influencing the signal.

Observation: https://network.satnogs.org/observations/2047865/

What can be done to make this decode much easier?

Jan PE0SAT

Bandwidth shouldn’t be an issue.

1 Like

Yes, it does look very much like Funcube dashboard will happily decode out to the nyquist frequency.

So I’ve gone and made a modification to the SatNOGS BPSK flow-graph where it outputs at an IF of 12 kHz instead of baud_rate. This will take effect for the next few observations on my station #232 - https://network.satnogs.org/observations/?station=232

This will hopefully result in some ogg output files with the sat frequency at 12 kHz, instead of 1200/9600 Hz. For the cases where the sat transmitter is off-frequency (due to drifting, or whatever), there will be a much higher chance for the signal to be present in the recording than with the current flowgraph settings.

I was able to get some decodes by replaying the ogg output from this observation through the JY1-Sat Funcube Dashboard: https://network.satnogs.org/observations/2056096/

This was a fairly low elevation pass, the next few should be better.

This shows the signals on top edge of the pass-band, shouldn’t it be possible to centre it?

The best explanation I have for the current BPSK flow-graph OGG output is that it’s like a upper-sideband receiver tuned 1200 Hz (or 9600 Hz in the case or a 9600 baud signal) below the transmitter frequency.

Because in your recording the sat frequency was just a little bit low (only a few hundred Hz!), the bottom bit of the signal was lost off the bottom end of that USB receiver’s passband.

Solutions are:

  • Fix the transmitter frequency so its properly centred (this should be done anyway, but will probably only work for a while as the transmit frequency will drift)
  • Track the centre of the BPSK signal and centre it properly (not sure if this works well for the low baud rate BPSK signals)
  • Move the signal somewhere higher up into the available bandwidth of the OGG recording. For a 48 kHz sample rate, we have 0-24 kHz to work with.

We’re not trying to listen to this signal by ear. For the 9600 baud BPSK signals, decoders like @EA4GPZ’s gr-satellites use a 12 kHz ‘IF’ - e.g. the BPSK signal is nominally centred on 12 kHz in the recording. This is right in the centre of the available bandwidth of the ogg file, and so gives the maximum amount of play if the transmitter is off-frequency.

While it would be nice if the 1200 baud signals could be heard by ear in the recording, it limits the amount of transmitter frequency drift that can occur before the signal falls outside the passband. May as well use a 12 kHz IF for them as well - the Funcube dashboards will decode them just fine at this frequency. This is what i’m trialing on my station right now.

Obs: https://network.satnogs.org/observations/2056097/ decode