-
Notifications
You must be signed in to change notification settings - Fork 5
Operating Theory and Vision
LARPS expands on existing packet radio systems, such as APRS, and provides a variety of services.
These include:
- Weather and station positioning
- Messaging
- Emergency communications
- Coordinating a variety of radio resources
- BBS support
- Repeater directories
- Bulletin boards
- Ad-hoc mesh digipeting, dynamically creating coverage areas
LARPS is a protocol developed from the ground up for amateur radio. While AX.25 has been quite a workhorse over the years, it is almost 40 years old, and is based on an even older communication protocol (X.25) developed in the early 1970s.
Unlike AFSK, which requires significant power and signal-to-noise ratios to be useful, LARPS makes use of the LoRa spread spectrum protocol, allowing for very weak signal operation using low amounts of power. Consequently, data throughputs are 3 times as fast as 1200 bps AFSK! The barrier to entry is low and the cost/benefit is substantially higher than other amateur radio technologies. A 100mW radio transceiver, for example, has a retail price of under $15. The typical HopeRF RF95W "postage stamp" is about $4 wholesale, making it very attractive for amateurs and maker companies.
The LARPS topology allows for a highly meshed and smart digipeting, without introducing complications in doing so. This allows digipeting to take place in very small memory footprints, which is important to its viability as a reliable mode of communication.
- TTL is decremented after any digipete
- TTL of 0 is never digipeted
- Any digipete action is placed into a rolling buffer to avoid digipete broadcast storms
- Do Not Digipete flag is followed
The client can use one of the following techniques, depending on memory capabilities, to avoid broadcast storms. These techniques are ordered from highest to lowest memory and computational intensity. In each of the techniques, the fields Relay, TTL, and CRC should be zeroed out.
- Logging packets verbatim
- Logging call sign and sequence number
- 32 bit hash of packet digipeted
- Marking packet option as Do Not Digipete, while adhering to such packet types when received
While a study needs to be performed, it is expected that packet transit times should expire after a few seconds. Perhaps up to 1 minute to be safe.
A LARPS backbone are at least two digipeters interconnected via point-to-point connection. Typically, an alternate frequency is utilized for the backhaul. Optionally, the digipeters could be connected via IP connection. Care should be taken not to connect two dissimilar LARPS Domains with a backbone. If two dissimlar LARPS Domains are to be connected, only point-to-point traffic (IE: The "To" or "Destination" field not being wildcard) should be permitted.
A LARPS Domain is a contiguous area of common region, much like how a repeater services a similarly broad area. For example, two nearby cities of the same metropolitan area would likely be in the same LARPS Domain, while Seattle and Boston would not be. Each LARPS Domain provides visibility to all stations within an area and is fully meshed.
Internet gateways, reluctantly, are an integral part of the LARPS system. While any internet gateway is welcome to receive all LARPS packets and place them into the cloud, internet gateways should take extreme care before injecting LARPS packets onto the amateur radio bands. The following guidelines should be upheld:
- LARPS packets with non-wildcard destinations, which originate from the amateur radio band, should be transmitted
- LARPS packets in the same LARPS Domain can use the internet to interconnect multiple digipeters
- LARPS packets originating from the internet with non-wildcard destinations CAN be transmitted to amateur radio bands, assuming proper precautions are taken to prevent unlicensed usage or violation of third party rules
Similar to a calling frequency, any heavy traffic, regardless of type, should be moved off channel -- if possible.
While extremely experimental, LARPS can be used to dynamically allocate voice and data traffic. These resources must be specified by the local frequency coordinator.