richonguzman / LoRa_APRS_iGate

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

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

Open bettio opened 4 days ago

bettio commented 4 days 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 4 days ago

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

bettio commented 4 days 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 3 days ago

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

do you know APRS101.pdf

wb2osz commented 3 days 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 3 days 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 3 days 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 3 days ago

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

bettio commented 3 days 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 3 days ago

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

bettio commented 3 days ago

As text there are several unprintable bytes: Screenshot_20241027_222551

Should I assume this is corrupt?

richonguzman commented 3 days 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 3 days 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 3 days 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