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?
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
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
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,
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
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?
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: SatNOGS Network - Observation 2047865
What can be done to make this decode much easier?
Jan PE0SAT
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:
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.
