Audio data much shorter than waterfall length when trying Ops-Sat S-Band

I’m currently starting experimenting with some S-Band observation using a LimeSDR-Mini.

Scheduling Ops-Sat i got some results but i don’t know if it is correct. But i noticed that the audio file is much shorter than the waterfall. The waterfall usually covers around 300 seconds but the audio data is only around 30 seconds.
Here the observations:

The station is running on a raspberry pi 3 with a limesdr-mini receiver.

Is it normal that the audio data is truncated ?

1 Like

Forgot to mention, it was running satnogs-client 1.1, in the meantime i just upgraded to 1.1.2

if this persist can you please open an issue in

Thank you!

1 Like

Ok, opened an issue as it persists after upgrade to 1.1.2

Hello Martin,
I would try to receive Ops-Sat in S-Band but I have 2 questions / issues :

  1. Ops-Sat always send a beacon on this frequency or it emits just when the ground station communicate with it
  2. I am using a 40 turns helix antenna with a down converter, is it possible to configure Satnogs client to take into account the frequency conversion ?
    Best 73, Nicolas

Hello Nicolas,

  1. I don’t know for sure but all my recent observations showed a consistent signal, as it would be always transmitting. I can’t be sure if it is really OpsSat so comparing the results with someone else would be very interesting.
  2. I expect the SATNOGS_LO_OFFSET parameter under Advanced/Radio to serve this purpose. Haven’t tested it.

Do you have a reference to your helix antenna ? Could be interested in a similar one.

I currently use a wideband LTE antenna with 8-9dB gain and an angular -3dB width of almost 90°, no rotator. In fact the antenna is meant to be used as a feed for a dish but i use it reversed without dish. Looking for a little more narrow antenna but still usable without a rotator.

73s de Martin HB9FXX


The support for downconvers is tracked in gr-satnogs#129 and might already be realized by using some soapy arguments according to @surligas.

SATNOGS_LO_OFFSET changes the small frequency offset applied to the LO to avoid the SDR carrier at DC (source: satnogs-flowgraphs:[…]/afsk1200_ax25.grc#L524-535) so this is not what you are searching for.

Best wishes,
Fabian / kerel


Thanks @kerel

Yes that makes also perfectly sense and is a distinct feature from a transverter. I’m new to SatNOGS and happily learning all these options and the inner working of this great project.

Best regards,

Martin HB9FXX


The 40 turns helix is 1.25m length and 16db gain. I don’t know the aperture angle but I should use a rotator … I will make some tests listening Ops-Sat next week. I will give you some news.

Kerel, thank you for your answer, I will ask to @surligas if he found a solution. I must remove 1833 Mhz to tune the sdr on the correct frequency.

Hello Nicolas,

Took a closer look at my OpsSat and LQSat observation that consistently return an almost straight line as it is strange so see the same signal independently of the antenna orientation regarding the orbit. In fact the line looks slightly like a tangent. This can be seen nicely here:
The frequency scale for these observations is 4MHz wide, compared to the 60kHz of for example this is a lot and would explain why they look almost straight.
So my signal on all my OpsSat and LQSat observations is probably just some terrestrial signal :frowning: I still have a lot to learn on satellite observation.

Thanks for your antenna info. Building or buying a helix antenna is planned, but for building i first need an analyzer capable of handling this frequency band. And then i’d also need a rotator. Maybe i should start a SatNOGS v3.

On the other hand i try to improve my setup for S-Band so i wonder if i should go the downconverter way thus opening more options for the SDR receiver (like the AirSpy family) or stay with a LimeSDR mini as there is not much inexpensive alternative.

It is an issue of the flow-graphs. I did not had in mind such large data rates. As a workaround I would suggest to increase the sampling rate to something higher. At least 5x the baud rate of your obs. Can you raise an issue for that so I can fix it in some point?