Files by radio

Files by radio needs APRS Connect Pro.

Files sends a file from one station to another over a radio channel: a TNC or the audio modem, never the internet. The file goes out in small pieces. The other station asks again for any piece it missed, and checks the whole file before it shows it, so what arrives is an exact copy or nothing.

It is slow. At 1200 baud expect about 80 bytes a second on a clean channel:

Text, CSV and other files that compress go out compressed, often at half the size or less. Photos, PDFs and zips are compressed already and go as they are.

At 9600 baud, through a TNC that does 9600, it is about five times faster. The app does not need telling which: it measures the link from the air during a transfer, uses that for its timing, and remembers it for the next file on that radio. The line under the file says whether the speed is measured yet.

Before you send: leave 144.390

A file takes minutes of airtime, and 144.390 is shared by everyone's beacons and messages. Agree a packet frequency with the other operator (a message works: "Files on 145.050?"), both change your radios to it, and send there. The Files screen reminds you before you send.

Sending a file

Open Files in the drawer, or Send a file by radio in a conversation's menu.

1. Choose a file. Any file that comes to 1.44 MB or less once compressed: the limit is on airtime, so a large text file that packs small can go. The line under it says how long it will take, and what it comes to once compressed when that is smaller.
2. To: one station's callsign, or Everyone listening.
3. Radio: the channel to send on. Only radio channels that are connected are listed.
4. Press Send by radio.

The app sends a short offer first, and nothing else until the other station says yes. If nobody answers in two minutes, it stops and says No answer; Offer again tries once more. While the file goes out, the bar shows how much the other station has confirmed, and how much it asked for again. Pause stops between pieces; Resume carries on where it stopped.

Sent to everyone listening, the file starts as soon as one station accepts. A station that accepts later collects what is still going out and asks for the rest at the end.

Receiving a file

When a station offers you a file, it appears at the top of Files with its name, size and how long it will take, and the phone shows a notification. Accept starts it; Decline tells the sender no. Turn on Always accept files from a callsign to take that station's files without being asked.

A received file is listed under Received, with who sent it. Open shows a picture full screen, where you can zoom in, and a text file as text; anything else, a PDF say, opens in the phone's own app for it. From the picture or the text, Save to Photos puts a picture in the phone's photos, in an album called APRS Connect; Save to Downloads puts the file in the phone's Downloads (on an iPhone, Save to a folder, where you choose); Share hands it to another app. On a computer it is saved as a download. Files stay on this device: they are not synced or included in a backup.

Files sent to or from one station also show in your conversation with it, among the messages: an offer you can accept or decline there, a file on its way with its progress, and the file itself once it arrives, a picture shown in the conversation. Tap one to open it. A file sent to everyone listening shows only in Files.

If the signal goes for a while, the transfer waits and keeps what has arrived. When the sender carries on, only the missing pieces are sent.

What has arrived is also kept if the app closes. When it opens again the file is listed as waiting, and nothing is sent by itself, since you may have changed frequency. It carries on when the sender is heard again, or when you press Ask again. If the sender's app closed too and it sends the same file again, the transfer picks up where it stopped, and you are not asked to accept it a second time.

Which radios

Any channel that sends KISS frames can carry a file: a Bluetooth or USB TNC, a radio with a built-in TNC such as the TH-D74 and TH-D75, a KISS TNC over TCP, and the audio modem. An APRS-IS channel cannot: it is not the air. A LoRa link that carries APRS as text cannot either.

What is in a file is yours

The app does not look inside a file, and it does not refuse one. What you send is your responsibility as the control operator, under your licence's rules. In the United States, Part 97 does not allow messages encoded to hide their meaning (§97.113), so do not send a password-protected or encrypted file.

How it goes on the air

This section is the published description of the method, so anyone can receive these files with software of their own.

Files by radio uses the PACSAT Broadcast Protocol and the PACSAT File Header, published by Harold Price, NK6K, and Jeff Ward, K8KA, at the ARRL Computer Networking Conference in 1990, with the protocol's updates 1 and 2. They were written for amateur satellites; here two ground stations use them. Every frame is an AX.25 UI frame. All numbers are least significant byte first unless said otherwise.

The file. A file is a PACSAT File Header followed by the file's bytes. The header starts 0xAA 0x55, then items (a 16-bit ID, an 8-bit length, the data), and ends with ID 0 and length 0. APRS Connect writes every mandatory and extended item. destination is the receiving callsign, or ALL for everyone listening. file_type is 0x00 for plain text, otherwise 0xFF with the MIME type in file_description. user_file_name is the file's name. Three items in the experimental range (ID bit 15 set) are added: 0x8001, the SHA-256 of the body as sent (32 bytes); 0x8002, the file name in UTF-8 when it is not plain ASCII; and 0x8003, the file's size before compression (4 bytes), on a compressed file only. A receiver that does not know them steps over them.

Compression. A body that gzip (RFC 1952) shrinks by at least a twentieth and 64 bytes is sent as gzip, with compression_type 0xFF and compression_description gzip (RFC 1952), as the header definition provides for a method not in its list. The header's checksums and the SHA-256 are of the body as sent; the receiver inflates it afterwards, and refuses one that unpacks to more than 50 MB or to a size other than item 0x8003.

Broadcast frame (PID 0xBB, to QST-1): a piece of the file. Flags byte (0x02, or 0x22 on the frame holding the last byte), 4-byte file id, file_type, 24-bit byte offset into the whole file (header included), up to 245 bytes of the file, and the XMODEM CRC-16 of everything before it, high byte first.

Directory frame (PID 0xBD, to QST-1): the header on its own. Flags (0x60 on the last frame of a header), file id, 32-bit offset into the header, the upload time twice, the header bytes, the CRC. This is the offer, and later the sender's "anyone missing anything?".

Request frame (PID 0xBB, to the sending station): flags 0x10 "start sending", 0x11 "stop sending" or 0x12 "hole list", the file id, the largest piece wanted (16 bits), and for a hole list, pairs of a 24-bit offset and a 16-bit length.

What APRS Connect adds, inside the protocol:

• Nothing but the offer goes out until a station sends start. Stop is a no.
• A hole list with no holes means "I have every byte". A one-to-one transfer ends when the receiver says it; a broadcast ends when every station that accepted has said it, or when five offers in a row bring no request.
• The sender sends bursts of about fifteen seconds of air, two seconds apart. After about a minute of air it checks in: that burst ends with the header, and the sender listens. Every receiver answers a check-in with a hole list of everything it lacks so far, so the answer is never empty until the file is complete. Three check-ins in a row with no answer and the sender stops: nobody hears it. Receivers answer once the channel has been quiet for two seconds or one and a half frame times, whichever is longer, spread over three more seconds when the file is for everyone (and the sender listens that much longer). Every request waits for the quiet, and a sender holds its next burst for a second after hearing anyone.
• The header at each check-in is also how a station that tunes in partway hears the offer.
• A receiver that has every byte says so three times, fifteen seconds apart, so one lost answer does not leave the sender thinking nobody heard.
• Each station measures the link: a receiver from the spacing of a burst's frames, a sender from when the answers to its bursts arrive. The timings above are worked out from the measured rate, starting at 1200 baud or the rate the channel was last measured at.
• A receiver that has asked and heard nothing asks again every 20 seconds, six times. A station picking up where it left off sends its hole list instead of start.

The offer is repeated every 10 seconds, three times, and given up after two minutes. A file's body as sent, after any compression, is at most 1,474,560 bytes. A receiver shows a file only when the header checksum, the body checksum and the SHA-256 all match.

Last updated 5 November 2026