richonguzman / LoRa_APRS_iGate

LoRa APRS iGATE for ESP32 Based Board with Rx + Tx capabilities
MIT License
247 stars 73 forks source link

Question: which format/encoding is used for sending data on LoRA? #188

Open bettio opened 1 month ago

bettio commented 1 month ago

It is not clear how data is encoded before being sent over LoRa. Is any document format used? What 0x3C, 0xFF, 0x1 / 0x3C, 0xFF, 0x17 strings mean, and what is the meaning of what follows after?

richonguzman commented 1 month ago

from the first LoRa APRS firmware they uses 3 identification bytes to recognize a valid APRS LoRa packet

bettio commented 1 month ago

@richonguzman thanks, still I'm not understanding how is encoded all the following bytes. Do you have any link to any protocol / format documentation that you've been implementing?

richonguzman commented 1 month ago

all of the lora packets is the APRS protocol written in plain text (or as TNC2)

do you know APRS101.pdf

wb2osz commented 1 month ago

APRS101.pdf was written in 2000. It is missing all of the corrections, clarifications, and new features since that time. You can find newer information here: https://github.com/wb2osz/aprsspec APRS12b.pdf is version 1.2 draft b. Look for draft c soon. A much gentler introduction can be found in "Understanding APRS Packets."

73, John WB2OSZ

richonguzman commented 1 month ago

APRS101.pdf was written in 2000. It is missing all of the corrections, clarifications, and new features since that time. You can find newer information here: https://github.com/wb2osz/aprsspec APRS12b.pdf is version 1.2 draft b. Look for draft c soon. A much gentler introduction can be found in "Understanding APRS Packets."

73, John WB2OSZ

you are right @wb2osz I will forward all to this 1.2b version you have from now. :)

bettio commented 1 month ago

I'm pretty confused: the following 3 bytes after the identification header have decimal values 73, 65, 219 (so the captured packet starts with 0x3c, 0xff, 0x01, 0x49, 0x41, 0xdb, ...), and there are more and more characters that are out of the plain text range. Should I assume the packet is corrupted? or am I missing some decoding step? For instance what I'm trying to decode is a beacon packet.

Furthermore, can anyone provide here a sample correct beacon packet?

richonguzman commented 1 month ago

I guess you should explain what are you decoding and how to understand how you should read it

bettio commented 1 month ago

I did a LoRa packet capture nearby a device running LoRa_APRS_iGate and I was trying to understand the packet format, but I wasn't understanding how to manually decode it.

So my plan right now is just to understand the format, and being able to manually decode it.

What I captured while the device was sending a beacon is:

    0x3c, 0xff, 0x01, 0x49,
    0x41, 0xdb,
[... ommited ...]
    0x91, 0x94, 0x35

It doesn't look plain text, and I'm not understanding the used format.

richonguzman commented 1 month ago

are you printing them (each byte) as HEX??? (try it printing as they are... just text)

bettio commented 1 month ago

As text there are several unprintable bytes: Screenshot_20241027_222551

Should I assume this is corrupt?

richonguzman commented 1 month ago

i have now more questions than answers for this:

where did you read/hear this? is it really APRS LORA or another lora message (maybe even encrypted)? what is the program you use to hear/decode? what are the settings you are using for decoding/listening. (lora settings?)

bettio commented 1 month ago

where did you read/hear this?

I captured this placing a lilygo device close to a friend lora transmitter running LoRa_APRS_iGate.

is it really APRS LORA or another lora message (maybe even encrypted)?

The device transmitting this is running LoRa_APRS_iGate.

what is the program you use to hear/decode?

A custom firmware I did that prints to terminal lora packets

what are the settings you are using for decoding/listening. (lora settings?)

Just printing bytes in decimal as soon as a packet is received. Settings are:

      tx_power: 21,
      frequency: 433_775_000,
      bandwidth: :bw_125khz,
      spreading_factor: 12,
      coding_rate: :cr_4_8,
      preamble_length: 8,
      sync_word: 0x12,
      header_mode: :explicit,
      invert_iq: false,
      enable_crc: true
richonguzman commented 1 month ago

try codingRate4: 5 instead of 8 (as this is the one used in 433.775 / 12 /125.000 / 5

i dont know about the sync word too, I remember it was 0x34 as the typical default sync word but you would need to dig a little on google to make sure of it