Currently we have different applications that can decode telemetry from different satellites and submit the frames to the SatNOGS DB. These are, at least, UZ7HO Soundmodem + DK3WN Telemetry Forwarder, gr-satellites, and SatNOGS itself.
For satellites using AX.25, the common practice when submitting to the DB is to send the full AX.25 frame, without 0x7e HDLC flags and without CRC-16. However, for other satellites it is not so clear what constitutes a “frame”, and there can be different reasonable choices of what to send to the DB.
In some cases, the different applications follow slightly different conventions in their definition of “frame” when sending to the DB. This is causing entries with slightly different formats in the DB, which is undesirable.
To improve the compatibility of all these applications, and have consistent information in the DB, we should have an open technical discussion to agree on a common definition of the format of the frames that should be sent to the DB for each satellite/modem/protocol.
I have already done some preliminary discussion with Mike DK3WN, Jan PE0SAT and Andy UZ7HO, and we have identified the following points for discussion:
A. Whether the 4 byte CSP header should be swapped in frames transmitted by a GOMSpace AX100 or U482C transceiver.
B. Apparently, the optional CRC-32 in CSP packets transmitted with a GOMspace radio is missing in some SatNOGS frames. Andy and I consider that the CRC-32 is part of the frame and should be included in the DB.
C. Apparently there are some differences in frames from AAUSAT-4. The difference might have to do with the Frame Sync Marker that comes before the convolutionally-encoded data. Check differences between Soundmodem, gr-satellites and SatNOGS and decide whether to keep or drop the Frame Sync Marker.
D. Andy has noted that some of the MOBITEX satellites have seemingly erroneous decodes in SatNOGS. Check whether the SatNOGS MOBITEX decoder works at all and decide if we should include “errorcodes” in the frames sent to the DB (the errorcodes are not transmited over the air but included by the BEESAT GNU Radio decoder at the end of the frame to indicate which blocks were correctly FEC-decoded).
Please add any other topics that you think should be treated. The goal is to discuss these (and perhaps other) points and iron out all the small differences between the applications in order to have a consistent format in the DB entries.
I’ll put more information and opinion in a second post in this thread.