Handling a data first golay

[dcia-dev]

Hello everyone!

I'm working on correctly receiving a TTC's packets as part of my master's thesis. The TTC in question is manufactured by a company in Spain and AFAIK hasn't been flight-tested yet. I've searched to see if someone has asked this before but found no answer. Apologies in advance if this is a duplicate, as I am relatively new to GNU Radio (about six months) and usually look at the code for answers.

After synchronizing with the access code, I want to decode the Golay field using the Variable Length Packet Tagger. However, this does not work because the Golay used by this modem is data-first instead of parity-first.

As a workaround, I have disabled Golay in this block. Since the length comes first, it works fine, but this is not ideal. I also tried flipping the first 24 bits with an ad-hoc Python block, but I’m having trouble dealing with tags.

My question is: Is there a better way to handle this?

Thanks!

P.S.: I'm happy to contribute my findings on this TTC if you find them relevant to the project.

[daniestevez]

I want to decode the Golay field using the Variable Length Packet Tagger. However, this does not work because the Golay used by this modem is data-first instead of parity-first.

I don't understand the difficulty here. Can't you just swap the parity and data parts of the uint32_t golay_field before calling decode_golay24() in the Variable Length Packet Tagger, and then swap them again after the call?. Not that I am too familiar with this particular block, since someone else wrote it, but if this is your only problem, then it seems to have a simple solution.