Closed mkarliner closed 2 years ago
The short 100% CPU burst is fully legit, this is the decoder thread, starting after each acquisition. I will rollback the direct-sampling option, it could be the issue in this case.
Yep. It's legit, but I would have thought the thread should be launched at the end of the sequence at 50 seconds past the odd minute. The decode seems to be launched at the beginning of the even minute.
Hum ok. I will check this too. In the past, the decoding was started after 116 sec. Now the full sampling takes 120sec.
The new logic is in this loop: https://github.com/Guenael/rtlsdr-wsprd/blob/main/rtlsdr_wsprd.c#L972
while (!rx_state.exit_flag && !(rx_options.maxloop && (nLoop >= rx_options.maxloop))) {
/* Wait for time Sync on 2 mins */
gettimeofday(&lTime, NULL);
sec = lTime.tv_sec % 120;
usec = sec * 1000000 + lTime.tv_usec;
uwait = 120000000 - usec;
usleep(uwait);
/* Switch to the other buffer and trigger the decoder */
rx_state.bufferIndex = (rx_state.bufferIndex + 1) % 2;
rx_state.iqIndex = 0;
safe_cond_signal(&decState.ready_cond, &decState.ready_mutex);
nLoop++;
}
Basically:
I will put some printf("DBG...
and double check, but I made a dry test with these messages, and I was fine to me.
@mkarliner Additional note, the first decoding is dead, it start on an incomplete buffer, but I don't wanted to make a special case for it now. Please ignore the first decoding entry.
BTW, I fixed the direct sampling option: https://github.com/Guenael/rtlsdr-wsprd/pull/97
And made a new release to include this fix: https://github.com/Guenael/rtlsdr-wsprd/releases/tag/0.4.1
I was not able to reproduce this pattern on my PC, but I will test on a RPi too.
Patched with the latest release 0.4.2 https://github.com/Guenael/rtlsdr-wsprd/releases/tag/0.4.2
It seems we are not quite there yet...
I'm seeing 100% CPU usage at 1 or 2 seconds into the new cycle for a few seconds. That is at even minute + 1 to +10..
I suspect this is interfering with sampling enough that 1 in every 2 or three cycles does not get any spots.
No spot 2021-12-17 00:20z Spot : 2021-12-17 00:22:21 41.94 0.26 7.040106 1 EA6RD JM19 27 Spot : 2021-12-17 00:22:21 34.62 -0.89 7.040126 1 OE1RPW JN88 37 Spot : 2021-12-17 00:24:27 37.08 -0.55 7.040112 0 SO2O JO94 23 Spot : 2021-12-17 00:24:27 31.39 0.69 7.040149 1 EC7WR IM77 23 No spot 2021-12-17 00:26z
I'm getting this pattern quite a lot, with many spots and then none for a few cycles.
It seems to me that it's not running the decode at 10 seconds to the minute but after the minute. The no-spot reports are being printed at around 5-10 seconds after the minute.