Waiting for data, from my Ground Station, who never arrive

Hello all,

I put this post here, because I don’t know where I have to post it.
If it disturbs I will delete it.

My question is the following:

I am a new SatNOGS user. And since the beginning of I built it.
In every record I did with the SatNOGS software I never send the data on the network.

Like today, three times I tried to do an observations but no data was send.
The last message with the access to the ground-station " IP:5000 " is :
" [INFO]: Tracking stopped. " or " [ERROR]: No waterfall data file found. "
Did I miss configure something or forget something to do ?

Thank you in advance for your advice and comments.

Montpellier, France

1 Like

Do you have access to IRC chat? There’s quite a few people #satnogs IRC Channel on freenode that can walk you through it.

It sounds like your ground station has authenticated with the network yet.


1 Like

No, I haven’t at the moment but I will get an access.
Ok, perfect I will check it.

I create an account, a GT and the GT is in the test mode at the moment.


Do you see your station listed in this list? (in orange)

If you look for #113, mine is in red. It’s currently offline.

I don’t think your ground station has authenticated with the network yet…

So you are about here:

Did you enter the API key correctly?
Is your Ground Station able to register with the SatNOGS Network?

Take a look at your logs.


@HugoCintas So has your groundstation registered with the network yet?


Hello @WA4OSH ,

Yes, the groundstation is in the list in Orange #125 “CSU test station v0”.
And I check the API, it is correct.
Yes, I can click on the “Schedule” button and after on the “Calculate” button too.
To every pass I watch it by the IP:5000 to understand the global process and the different step. But I don’t understand, and this is why I create this topic. Maybe I misconfigure something or I forgot something, I don’t know why but the data are never sent to the network.

Yes, it is registered.


1 Like

OK …It looks like you are scheduling passes, but all of your tests are failing. Are you marking them failed? Or are they not running?

Start with scheduling the satellites with the most signal and schedule only passes that are directly overhead. Schedule those that are green all the way across.

What I want to see next is if your RTL-SDR’s gain was properly set.


1 Like

Welcome @HugoCintas!!

Looking at one of your observations: https://network.satnogs.org/observations/166369/

In your metadata: rx_dexvice: "fcd"

I’m not sure if we have ever had success with the funcube dongle. :frowning: Give me a few days to test with mine and see what I can come up with.

1 Like


Yes, I think I will check it.
They are running but not uploaded the waterfall.


Hello kb9jhu,

Thank you.
Yes, that is right. I will wait for your result, with restlessness.


I poked around a bit today and remembered what the problem is with fcd: the sample rates are too low and fixed at a rate that is not compatible with our gnuradio scripts (in the way they are written today). The original funcube dongle is 96kHz and the pro+ is 192kHz… Our first decimation calculation divides the incoming sample_rate by 250k.

So… the funcube dongle is feasible but only after refactoring all of our gnuradio scripts and filters, which I can’t quite estimate when such a task would be done (or by whom).

Could you get an rtlsdr dongle? Something like the v3 from https://www.rtl-sdr.com/buy-rtl-sdr-dvb-t-dongles/


I think you’re mixing things up:
Our first stages decimates the input signal to match an output sampling rate of 250 k samples per second - with an rtlsdr sampling at 1 MHz the first stage decimation is set to 4.

I could offer you to make a testing script using an arbitrary resampler to resample the output of the fcd to match 250 k sps also.

This might be an easy way to enable them, but it is highly experimental and needs some testing. :wink:

P.S.: I don’t have an fcd so there’s limited debug capabilities…

1 Like