Observation 18721: NOAA 18 (28654)

Regarding Observation 18721 … I have seen splitting of my decoded NOAA images lately, loss of alignment even for good passes.
Any ideas whats wrong?

It could be that the SNR is not high enough? @Sleepwalker ^ ?

I have manually set the gain, I do not know if that has any effect on decoding.

I manually decoded using the online ogg file with wxtoimg. Here is the output, without much processing.

Then most probably it was a CPU issue… Can you check the levels of CPU using htop next time you have a NOAA pass?

Sure, I will make a script to log these

Seems that is a CPU issue. What SDR do you use? Maybe increasing the SDR buffering may prevent samples to be lost. eg RTL has an option for setting the number of the available buffers and their size.

I am using RTL-SDR Blog R820T2 RTL2832U 1PPM TCXO SMA Software Defined Radio v.3 dongle running on Fedora. What setting could be adjusted. Is there something I could add to .env file? Running rtl_test does not give me any packets lost besides the initial ones. I think packets lost shows as OOOOOO 's in log files, which I do not see.

I will try htop later when I get hold of my setup.

You can change either this rtl,buffers=32,buflen=16384 on the hw_settings.py located on gr-satnogs/python/ or passing it using the --dev-args.

Eg: --dev-args=rtl,buffers=64,buflen=16384

rtl_test does not stress the CPU so it is normal that you do not see overflow messages. When logging, note that overflow messages are printed in the stderr not stdout, so adapt your redirection properly.

Just out of curiosity @pierros @cshields,
are the NOAA images written to the tmpfs randisk or directly to the SD file system? It may not a CPU problem but the slow write speeds of the SD.

I did some testing with htop during a noaa capture, during the duration of capture all figures were normal. Just after completing of pass, CPU figures for each core randomly hit 100%(only one core at 100% at a time). Memory figures were lower than 75%. When all the files were uploaded, CPU figures went back to normal.

Hope this helps.

After the pass is the gnuplot script that saturates a single core. Do you have an estimation of the CPU usage during the pass?

@surligas I am certain it was less then 65% max in a core during the actual pass.

Ok, let me check if something else is going on then. Meanwhile, can you schedule more NOAA passes to check if the problem persists?

I have scheduled more passes. Others till now also seem to show split up images.

Okay so I noticed files in the data folder. Each file corresponds to a NOAA pass. Decoded image was successfully uploaded, so I am not sure what these would mean. Each of the files had a odd png1 extension.

receiving_data_18718_2017-10-09T10-19-20.png1
receiving_data_18966_2017-10-10T10-07-46.png1
receiving_data_18967_2017-10-10T12-48-49.png1
receiving_data_18968_2017-10-10T13-12-37.png1