Basic HORS Satellites Support #722
Conversation
| self.slicer = digital.binary_slicer_fb() | ||
| self.deframer = sync_to_pdu_packed( | ||
| packlen=71, sync=_syncword, threshold=syncword_threshold) | ||
|
|
||
| self.connect(self, self.slicer, self.deframer) | ||
| self.msg_connect((self.deframer, 'out'), (self, 'out')) |
There was a problem hiding this comment.
Is there no CRC, no scrambling, no FEC, no nothing? Just a 64-bit syncword and 71 bytes of packet data?
Is there documentation publicly available about the transmission format used by these satellites?
There was a problem hiding this comment.
Based on the correlation, it has a 64-bit sync word and 71 bytes of data. There is a PN pattern in the data, but since I have absolutely no documentation on these satellites, I don't know the PN generation polynomials. Otherwise, it doesn't have much else.
There was a problem hiding this comment.
I don't know if this is enough to constitute a deframer, especially because there is no way to check for bad decodes without a CRC.
Let me see if I got this right: through reverse-engineering you managed to identify that all the packets start by the same 64-bit sequence (which you are using here as syncword) and following that they have 71 * 8 bits. Moreover, you say that there is a PN pattern, so there might not be any data in these packets, or the data would need to be despread for further processing.
There was a problem hiding this comment.
I hope will get at least some deeper info about packet structure, but it will be good to have ability to demodulate data from these sats
There was a problem hiding this comment.
Since there hasn't been a reply from @Foxiks in a few days, and just to be clear about my position:
Identifying that a 64-bit sequence at the beginning of some packets is always the same doesn't constitute enough reverse-engineering basis for a deframer. Probably this is a syncword (although the syncword could be shorter and some bits could be part of a header that is always the same), but it is quite easy to make a mistake of a few bits in delimiting what bits belong to the syncword (if there is a 01010101 training sequence before the syncword, it is difficult to tell if the last bits of this training sequence belong to the syncword or not). Mistakes here mess up byte alignment in the payload.
Furthermore, without a CRC or Reed-Solomon that can be used to check if the frames are correct, a deframer is potentially problematic, because it will happily output frames with bit errors. There are some rare exceptions, but most deframers in gr-satellites check some CRC or Reed-Solomon to ensure that the frame doesn't have bit errors.
So this PR is not mergeable as is.
|
IQ samples https://www.pe0sat.vgnet.nl/download/HORS/ |
This adds a deframer for HORS satellite data packets