the audio file is uploaded, but it has a size of only 4100 bytes
the waterfall png is not uploaded
In addition to this observation, I’ve noticed this problem already in observation 394463, 398768, 401000 and 401042. Such observation are related to either SARAL or METOP-A and what I found in common, is that all of them are configured with BPSK400 encoding, so I believe this is not a coincidence.
Is this a known issue, or it might be only peculiar to my setup?
This usually is related to a problem with the USB connection/driver of the rtl sdr. Try to run rtl_test to see if that responds correctly. If not, replug the rtl sdr or reboot the machine.
But in this case shouldn’t the problem persist also after each failed pass? In my case although such observations fail, subsequent scheduled ones are actually served properly, without me having to intervene in any way.
I still have not enough inside knowledge of the client to be able to support my suspect, but it is really too much of a coincidence that all such failed passes use BPSK400 encoding. I don’t want to say that the issue is the encoding itself, which might not make sense, but maybe with the part of the code that generates the audio and waterfall files, for such an encoding.
I failed to realize that this was a METOP-A observation. With gr-satnogs version 1.5 the BPSK demodulator has a known bug which means it can’t process the 400 baud signal. See here for the gitlab issue. This problem is fixed in the dev branch of gr-satnogs, which hopefully is rolled out soon.