Consistent failure of GS for particular satellites

SatNOGS
1

Hello everyone,

I have a young ground station (#930) and I’ve noticed something unusual with it. I get very consistent failures (no waterfall/audio is uploaded) when I am observing JY1Sat, LUSAT or NAYIF-1 . But I usually get almost all the other observations that are scheduled.

Here are all of my recent failed observations: https://network.satnogs.org/observations/?future=0&good=0&bad=0&unvetted=0&norad=&observer=&station=930&start=&end=

Do you have any ideas what could cause this?

Thanks.

2

I’m no expert but simple logic would indicate these 3 satellites may not be transmitting. Go to AMSAT and do some research on the health of those satellites. Start with their Status page. NAYIF-1 usually puts out a good BPSK signal and there is a dashboard available to decode the data.
Bob

3

Hi Bob,

Thanks for the reply, but actually, I mean that the ground station fails to perform the recording, not that it does a recording and nothing is seen transmitting.
It’s almost like something about those few satellites causes an error of some sort that prevents the ground station from finishing the recording. I suppose I need to get more troubleshooting info from the RPi… but I’m not at home to check in on it.

4

Failed satellite is BPSK, check if /usr/bin/satnogs_bpsk_demod.py, /usr/bin/satnogs_bpsk_decoder.py and /usr/bin/satnogs_bpsk_ax25.py are present.

2 Likes
5

Hi,

When I have this problem, I test separately the two large components (satnogs-client and gr-satnogs) by launching the gr-satnogs scripts by hand. For example, I launch the following gr-satnogs script:

/usr/bin/python2 /usr/local/bin/satnogs_bpsk_demod.py --rx-sdr-device=rtlsdr --rx-freq=145937000 --file-path=receiving_satnogs.out --waterfall-file-path=receiving_waterfall.dat --rf-gain=48 --decoded-data-file-path=data

(all arguments have to be adapted to your situation)

You will get extra debug info launching gr-satnogs scripts by hand like this. You will be able to confirm if the problem is coming from the client (which is the local scheduler from the GS perspective) or from the radio scripts (gr-satnogs). In your case, it seems the client is working. This method also speed up somewhat the testing cycle by not having to wait for a satellite to identify some issues.

73,

1 Like
6

Please follow the replies above and let us know any findings.

There is also new version of the client, you can try it by updating and let us know if the issue still exists.