Protocol: Difference between revisions
Create protocol page to reflect protocol as decided in 2026_06_24 Meeting (and mostly my whims) |
|||
| (2 intermediate revisions by the same user not shown) | |||
| Line 6: | Line 6: | ||
The idea is that by splitting and framing packets, we are able to reduce the amount of continuous air time in use, and reduce issues caused by drift in the bit detection | The idea is that by splitting and framing packets, we are able to reduce the amount of continuous air time in use, and reduce issues caused by drift in the bit detection | ||
Some transmissions are framed, others are not to save space. See the Transaction | Some transmissions are framed, others are not to save space. See the [[Protocol#Transaction Format|Transaction Format]] below | ||
== Transaction Format == | |||
A ____ | Unframed, Occasionally broadcast ping to say ready to transmit, maybe once every two minutes or something | A ____ | Unframed, Occasionally broadcast ping to say ready to transmit, maybe once every two minutes or something | ||
A <- B | Unframed, Reply to A's broadcast, just different(?) preamble then A's callsign, then B's callsign | A <- B | Unframed, Reply to A's broadcast, just different(?) preamble then A's callsign, then B's callsign | ||
| Line 20: | Line 18: | ||
A <- B | Framed packet, Message data for all requested packets A is missing | A <- B | Framed packet, Message data for all requested packets A is missing | ||
== Packet Framing == | |||
- One frame contains a preamble, header, packet/packet part, footer | - One frame contains a preamble, header, packet/packet part, footer | ||
=== Preamble === | |||
- | - More than a standard bit string, could just stop transmitting within the block. This will allow the reciever to calibrate their bit width offset | ||
- All messages start this way | - All messages start this way in some fashion | ||
- Used to detect if this is a transmission for us, or another mode like someone just talking we can ignore | - Used to detect if this is a transmission for us, or another mode like someone just talking we can ignore | ||
- It could be worth having a distinct preamble for framed packets vs freeform want-to-talk/reply-to-want-to-talk packets | - It could be worth having a distinct preamble for framed packets vs freeform want-to-talk/reply-to-want-to-talk packets | ||
- Something like 11110000110011001010 could be cool, the goal is that it can be listening periodically, then have enough time to spool up the math, and set the timing for where bit edges are | - Something like 11110000110011001010 could be cool, the goal is that it can be listening periodically, then have enough time to spool up the math, and set the timing for where bit edges are | ||
=== Header === | |||
- Contains meta information about the packet/packet part | - Contains meta information about the packet/packet part | ||
- Size of data block in bits/bytes (TBD) | - Size of data block in bits/bytes (TBD) | ||
| Line 39: | Line 36: | ||
- Section to say if we are a part of a split packet, and if so, what number out of how many we are, maybe just reserve two bytes for me/total | - Section to say if we are a part of a split packet, and if so, what number out of how many we are, maybe just reserve two bytes for me/total | ||
=== Packet === | |||
- Arbitrary data, | - Arbitrary data, split to fit in frame's MTU then reconstructed | ||
=== Footer === | |||
- Like header but less | - Like header but less | ||
- parity/checksum again(?) | - parity/checksum again(?) | ||
- Callsign of sender in standard format again -- I think this should be the end of the message so if someone doesn't know the format they can do it | - Callsign of sender in standard format again -- I think this should be the end of the message so if someone doesn't know the format they can do it | ||
- Maybe beep it out in morse code using more standard fm ptt also | - Maybe beep it out in morse code using more standard fm ptt also | ||
Latest revision as of 21:25, 24 June 2026
Overview[edit]
When data should be sent, a packet is generated, this is an arbitrary bit string of arbitrary length. If the packet gets above a threshold, call it an MTU for Max Transfer Unit, then the packet can be split into multiple frames. Each frame is one transmission, containing part or all of a packet, and meta information about itself.
The idea is that by splitting and framing packets, we are able to reduce the amount of continuous air time in use, and reduce issues caused by drift in the bit detection
Some transmissions are framed, others are not to save space. See the Transaction Format below
Transaction Format[edit]
A ____ | Unframed, Occasionally broadcast ping to say ready to transmit, maybe once every two minutes or something A <- B | Unframed, Reply to A's broadcast, just different(?) preamble then A's callsign, then B's callsign A -> B | Framed packet, containing list of message hashes A <- B | Framed packet, containing list of message hashes A -> B | Framed packet, List of hashes A does hot have A <- B | Framed packet, List of hashes B does hot have A -> B | Framed packet, Message data for all requested packets B is missing A <- B | Framed packet, Message data for all requested packets A is missing
Packet Framing[edit]
- One frame contains a preamble, header, packet/packet part, footer
Preamble[edit]
- More than a standard bit string, could just stop transmitting within the block. This will allow the reciever to calibrate their bit width offset - All messages start this way in some fashion - Used to detect if this is a transmission for us, or another mode like someone just talking we can ignore - It could be worth having a distinct preamble for framed packets vs freeform want-to-talk/reply-to-want-to-talk packets - Something like 11110000110011001010 could be cool, the goal is that it can be listening periodically, then have enough time to spool up the math, and set the timing for where bit edges are
Header[edit]
- Contains meta information about the packet/packet part - Size of data block in bits/bytes (TBD) - Hash/Checksum/Parity to verify message integrity (TBD, I vote start with single parity bit, then get more complicated once we're good at this) - Callsign of sender, need to decide on format. It may be worth finding a standard already in place for amateur radio - Callsign of intended recipient (Do we want this?) - Section to say if we are a part of a split packet, and if so, what number out of how many we are, maybe just reserve two bytes for me/total
Packet[edit]
- Arbitrary data, split to fit in frame's MTU then reconstructed
[edit]
- Like header but less
- parity/checksum again(?)
- Callsign of sender in standard format again -- I think this should be the end of the message so if someone doesn't know the format they can do it
- Maybe beep it out in morse code using more standard fm ptt also