BEESAT-1 not correctly decoded

[PistonMiner]

We've recently managed to recover BEESAT-1. As it turns out, gr-satellites apparently is not compatible with it currently unfortunately. It appears to be configured to use Mobitex-NX, however BEESAT-1 actually predates that and uses a slightly different form more alike the standard Mobitex protocol.

A Mobitex-NX frame looks like this:
bit sync: repeated aa
frame sync: 0ef0
control bytes: e.g. e.g. 3f00
control byte FEC: e.g. c0
callsign: e.g. 44503042454d
callsign checksum: e.g. 4df7
followed by a variable number of Mobitex blocks.

A BEESAT-1 frame looks like this:
callsign: 445030424545
reserved: 5252
bit sync: cccc
frame sync: 0ef0
control bytes: e.g. 1405
control byte FEC: e.g. ec
followed by 32 Mobitex blocks.

AFAIK gr-satellites does the deframing of Mobitex-NX via gr-tnc_nx, which actually has a separate flowgraph for BEESAT-1 as well which uses the tnc_b1 block instead of the nx_decoder block combined with the tnc_nx block. gr-satellites just uses the nx_decoder block always as far as I can tell, so this difference in framing related to the position of the callsign messes things up.

For reference, the header of a frame looks like this for BEESAT-1 (courtesy of this awesome SatNOGS observation from the Dwingeloo radiotelescope):

[daniestevez]

@PistonMiner thanks for the information. It doesn't look like the tnc_b1 block can be a drop-in replacement for the tnc_nx block used in mobitex_deframer.py. It seems to have additional ports.

Moreover, support for the BEESATs is not available in the main branch of gr-satellites, because of #238. Has anyone ported gr-tnc_nx to GNU Radio 3.10 yet?

If anyone wants to work on this I will happy to advise and get the pull request merged, but in principle I have no plans of bringing support to BEESAT-1 on my own, especially because without gr-tnc_nx in GNU Radio 3.10, the usefulness of this would be quite limited.