-
Notifications
You must be signed in to change notification settings - Fork 0
SMS‐like Ham Radio Communication System
Below are notes, comments, ideas relating to the design of a system that will be used to allow a person to send and receive short messages over amateur radio frequencies. A sort of Ham SMS system.'' ''An Amateur Radio Safety Foundation project.'' '''''Internal Use Only'''''
===System Components=== * A. Server (Windows) * B. Gateway (Windows, Linux) * C. Client (Windows, Android, IOS, Linux) * D. ARDOP TNC (the RF protocol module)
===Server=== * accept connections from gateway gateway connection do not time out * accept connections from client (chat) client connections have a timeout * accepts beacon reports from Gateway (contain client and gateway information) adds client record to database keep client record for some number of days - then purge * maintains list of active gateways based on status reports from gateways gateways send status reports every few hours * complicated if multiple databases are involved (real-time sync issues) simpler if common (possibly cloud-based) database is used * accepts traffic from gateway or client if destination is direct-connected sends traffic bypassing the gateway (chat mode) looks up gateways for destination (if none, report delivery failure) * forwards traffic to a gateway that services destination starting with gateway closest to destination rotates through gateway list then pauses before next attempt server will hold and re-try delivery for some period of time * listens for delivery confirmation from gateway if no delivery in some period of time send failure report to source gateway/client * traffic addressed to multiple destinations are processed for each destination separately some or all traffic may succeed or fail
===Gateway=== * beacon to clients every x minutes (callsign, location, etc.) client will never need to wait more than x minutes to hear a gateway (assuming no collisions) * must always be connected to Server provide no internet mode — only serves "local" clients * report status to Server occasionally callsign, frequency, grid(8), * accepts beacon reports from client forwards beacon reports to server * accepts traffic from client forwards traffic to Server if destination is "local" or in "no internet mode" delivers traffic directly * accepts traffic from Server * attempts delivery of traffic to client use decaying retry algorithm * on successful delivery sends delivery confirmation to server * accepts delivery confirmation from server stops attempting to deliver traffic * on failure (exceeded retries) send failure report to server server will assume failure if timeout * shares a common ARDOP TNC interface with client
===Client=== * sends beacon reports to Gateway (callsign, location, etc.) * sends traffic to Gateway or direct to Server (chat mode) * accepts traffic from Gateway or Server (if connected) * accepts input of traffic from Client interface * presents received traffic to Client interface * may connect to server directly (chat) * allow sending to multiple destinations * clients can obtain a list of gateways from any gateway or server (callsign, grid, frequency, etc.) possibly reduce list size by retrieving only Gateways within a limit if Gateways beacon client can build list over a period of time (beacon interval) ** use Gateway location and value to determine connection probability * logs both sent and received traffic * shares a common ARDOP TNC interface with gateway * use netspell library for spell checker