Protocol

Overview

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

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

- 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 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

- 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

- Arbitrary data, split to fit in frame's MTU then reconstructed

Footer

- 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

VERSION 1.0

TODO:

- make framer throw error if passed a z0 message
- make dac have special ways to beep out a preamble containing nulls
- make dac able to beep out a real callsign in morse so the fcc doesnt kill us after each message
- remmeber to zero-idex size (0000000 is a 1B message)

HEADER ========================================================================= left is start of stream, right is further into stream in time

Header
0000 0000         0000 0000
┌──────┐▲         ┌──┐ ┌──┐
└size B┘│         └──┘ └──┘
        parity    send recv
                  callsigns

This sets implict MTU of 128 bytes

size is zero indexed. We should never allow a 0B message

MESSAGE ======================================================================== - message - pad with zeros (just accept that as part of standard, will need to filter out later)

FOOTER ========================================================================= no footer for this version

Networking

Because we have so few nodes, we are not going to try to maintain a distributed copy of the shape of the network. Instead we will only store a list of neighbors.

This will likely be best done as a small list with space for callsign/id, and time last seen, then if we exceed the list just evict least recently seen.

Each node should broadcast it exists frequently, maybe every minute, and check in with a node once per five minutes or so, once it hasn't been seen for too long.