Mobitex performance issue on BEESAT

[kng]

While testing the new Mobitex fix PR on a BEESAT recording, I noticed a severe performance issue.

Fetch the attached file, decompress it and run with a gr_satellites-5.9.0 release:
time gr_satellites beesat-1 --iq --rawint16 iq_10185025_48000_cut.raw --samp_rate 48000 > beesat.log
or under docker:
time docker run --rm -it -v "$(pwd):/srv" librespace/gnuradio:3.10.5.1-satnogs gr_satellites beesat-1 --iq --rawint16 /srv/iq_10185025_48000_cut.raw --samp_rate 48000 > beesat.log
It should contain two valid frames in a 10s recording.

However, the logfile is mostly full of CRC errors, pointing to the original problem.
grep -ci "crc fail" beesat.log results in around 38000 lines in my case.

If my calculations is correct, 48ksps for 10s and resulting in 38k crc errors is one tagged frame each 12 samples, which is pretty unreasonable.

Running a longer ~14min recording on a Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz

real 5m47.972s
user 8m5.093s
sys 1m51.135s

Sending the process SIGTERM does not exit in a timely manner either but continues some thread that hogs one core. SIGKILL does terminate it promptly.
Others report their SatNOGS stations being frozen for 15 minutes when running this live.

iq_10185025_48000_cut.raw.gz

[daniestevez]

@kerel-fs FYI. It seems we have too many false frame detections in the MOBITEX deframer.

[kerel-fs]

When using the Mobitex deframer for Mobitex-NX (TUBIN, NanoFF etc),right after syncword detection the callsign is checked and thus invalid frames are discarded early (e.g. noise that passed the syncword detector by chance). This happens well before deinterleaving / scrambling / FEC / CRC check.

With BEESAT-1 here, the protocol is different: The callsign is located before the syncword. Thus, with the current architecture of the mobitex deframer it is stripped by the sync_to_pdu_packed block and not available to the subsequent mobitex_to_datablocks block.

As we can see here, the Mobitex deframer block is not optimized at all for BEESAT-1. This is why I left issue #670 open. The exact BEESAT-1 frame structure is described there.

Solution Idea

With a synword detection that can forward bytes located before the syncword to subsequent blocks, the callsign could be checked there.

[daniestevez]

Could we instead use the callsign + syncword as the syncword for BEESAT-1?

The syncword is supposed to be the sequence of bits preceding a frame. Having the need to forward something before the syncword downstream breaks this assumption, and the fixedlen_to_pdu block cannot easily look back in the symbol stream when it sees a tag marking a syncword detection (it would need to use history, probably).