Spis treści

APRS TNC2 text protocol
Bluetooth terminal applications
Lora-APRS compatibility

This file contains ambiguous Unicode characters that may be confused with others in your current locale. If your use case is intentional and legitimate, you can safely ignore this warning. Use the Escape button to highlight these characters.

Protocol compatibility

Make sure LoRa sync word and other LoRa parameters match
Normal/Client mode should be interoperable with other clients, which transmit raw text APRS messages if KISS client sends them in this format to the modem
- NB! For interoperability with other APRS LoRa implementations, which do not use AX.25 frames, but use text based messages, need to use TNC (plaintext TNC2) APRSDroid connection protocol and set cfg.EnableTextPackets/CFG_TEXT_PACKETS to true, this way KISS will be disabled and TNC2 compatible mode will be activated. This option should also be activated if you want to use modem with Bluetooth terminal applications.
- For interoperability with lora-aprs project need set cfg.EnableTextPackets3/CFG_TEXT_PACKETS_3 to true in addition to cfg.EnableTextPackets/CFG_TEXT_PACKETS, as lora-aprs uses 3 byte prefix for packets ('<', 0xff, 0x01).
Server iGate by default supports only classical AX25 frames over LoRa (as defined in http://www.aprs.org/doc/APRS101.PDF page 12, see section below). It should enable interoperability with classical Linux APRS software, such as Xastir with kissattach.
- NB! Some popular LoRa ARPS implementations transfer plain text APRS messages over LoRa, for this mode operation need to set cfg.EnableTextPackets/CFG_TEXT_PACKETS to true, in this case iGate will transmit, receive and digirepeat text based APRS messages instead of classical AX25 frames.

APRS protocol

APRS AX.25 UI packet format

At the link level, APRS uses the AX.25 protocol, as defined in AmateurPacket-Radio Link-Layer Protocol, utilizing Unnumbered Information (UI) frames exclusively. This means that APRS runs in connection less mode, whereby AX.25 frames are transmitted without expecting any response, and reception at the other end is not guaranteed.At a higher level, APRS supports a messaging protocol that allows users tos end short messages (one line of text) to nominated stations, and expects to receive acknowledgements from those stations.

Flag — The flag field at each end of the frame is the bit sequence 0x7e that separates each frame.
Destination Address — This field can contain an APRS destination callsign or APRS data. APRS data is encoded to ensure that the field conforms to the standard AX.25 call sign format (i.e. 6 alphanumeric characters plus SSID). If the SSID is non-zero, it specifies a generic APRS digipeater path.
Source Address — This field contains the callsign and SSID of the transmitting station. In some cases, if the SSID is non-zero, the SSID may specify an APRS display Symbol Code.
Digipeater Addresses — From zero to 8 digipeater call signs may be included in this field. Note: These digipeater addresses may be overridden by a generic APRS digipeater path (specified in the Destination Address SSID)
Control Field — This field is set to 0x03 (UI-frame).
Protocol ID — This field is set to 0xf0 (no layer 3 protocol).
Information Field — This field contains more APRS data. The first character of this field is the APRS Data Type Identifier that specifies the nature of the data that follows.
Frame Check Sequence — The FCS is a sequence of 16 bits used for checking the integrity of a received frame.

APRS data in AX.25 information field

APRS position packet

APRS compressed packets

In compressed data format, the Information field contains the station’s latitude and longitude, together with course and speed or pre-calculated radio range or altitude. This information is compressed to minimize the length of the transmitted packet (and therefore improve its chances of being received correctly under less than ideal conditions). The Information field also contains a display Symbol Code, and there may optionally be a plain text comment (uncompressed) as well.

APRS compressed packets generation

Arduino code to generate compressed coordinates from degrees.

/*
**  Convert degrees in long format to APRS compressed format
**  http://www.aprs.org/doc/APRS101.PDF, page 36
*/
static char conv_buf[5];
char* deg_to_compressed(long deg, boolean is_lat) {
  long tmp;
  if (is_lat) {
    tmp = ((90000000LL - (long long)deg)) * 1000000LL / 2625182LL;
  }
  else {
    tmp = ((180000000LL + (long long)deg)) * 1000000LL / 5250364LL;
  }
  conv_buf[0] = 33 + tmp / (91L * 91L * 91L);
  tmp = tmp % (91L * 91L * 91L);
  conv_buf[1] = 33 + tmp / (91L * 91L);
  tmp = tmp % (91L * 91L);
  conv_buf[2] = 33 + tmp / 91L;
  tmp = tmp % 91L;
  conv_buf[3] = 33 + tmp;
  conv_buf[4] = '\0';
  return conv_buf;
}

APRS TNC2 text protocol

TNC2 protocol does not use KISS, it sends text based APRS messages, multiple messages are separated by using new line character \n. This is quite inefficient protocol for LoRa, because packet lengths are much longer compared to AX25, which causes longer TOA (time on the air).

Bluetooth terminal applications

Set cfg.EnableTextPackets/CFG_TEXT_PACKETS to true to use modem for sending text based messages through Bluetooth terminal applications.

Lora-APRS compatibility

Set cfg.EnableTextPackets/CFG_TEXT_PACKETS to true AND cfg.EnableTextPackets3/CFG_TEXT_PACKETS_3 to true.