Frame-Check Sequence implementation about ax25 HOT 7 CLOSED

Added - thank you very much, you really helped me a lot. Now RadioLib can send AX.25 via most of the supported radio modules. Onwards to APRS then I guess ;)

from ax25.

It's pretty hard to find the low-level implementation details for AX.25. I got most of the info from the two pdfs in the docs folder of the repo. I tested it against the AX.25 decoder in GQRX. You can find their decoder code here. Happy to help out since I'd love to have a library like yours with AX.25 support. BTW, have you considered a CircuitPython port?

from ax25.

Thanks for the response, I'll definitely give GQRX a shot (once I get it running on VM, as I'm working on Windows).

I haven't considered CircuitPython port - to be honest, I never used it (and it's been a few years since I did anything in Python). I'm not sure it would be easy, as RadioLib is using some C++ features that might not be available in Python, like pure virtual methods, or converting constructors.

from ax25.

Hi again, I managed to decode AX.25 frames using SDR Console (to get the AFSK output) + SoundModem (to decode the audio) on Windows, since GQRX on VM was far too slow.

I noticed that the frames are quite long, the following seems to be cause:

If my understanding of your implementation is correct, that loop will add the 0x7E flag 64 times. Was there a particular reason for this? I tried it with only one flag and SoundModem decodes it just fine.

from ax25.

That's the preamble. Most decoders expect some minimum number of 0x7E bytes, but it varies by implementation. You can definitely use fewer than 64, but one is probably risky as some decoders may fail.

from ax25.

Can't seem to find any recommended number of preamble bytes in the specification... Will leave it up to the user then ;)

Thank you very much for the help, support for AX.25 will be added to RadioLib shortly. Is it OK to use your CCITT CRC implementation (appropriately licensed, of course)?

from ax25.

Yup, of course. If you're curious what's up with the preamble thing, it's there to give the receiver PLL lots of edges to synchronize on at the beginning of the packet.

from ax25.