Build your own LoRa-APRS dashboard

§What you'll build

If you run a LoRa-APRS iGate (for example the popular CA2RXU_LoRa_iGate ESP32 firmware), it can emit a syslog feed: one UDP line for every packet it hears, transmits, or forwards. That feed is a goldmine — it contains the heard callsign, signal strength, SNR, frequency offset, decoded position, digipeat path and more.

This guide captures that feed and builds a per-iGate analytics dashboard, similar in spirit to lora-aprs.live but entirely under your control. You'll get:

• Coverage & distance maps — every station you've heard, plotted, with reception lines back to your gateway colour-coded by SNR.
• Link quality — RSSI / SNR per station, packet rate, CRC error rate.
• DX records — your furthest direct and via-digipeater contacts.
• Telemetry — battery of heard mobiles, SNR-vs-distance scatter, a raw packet log.

Get the files

Three sanitised files power this build. Every credential, hostname and callsign in them is a placeholder — you'll replace them as you go.

⬇ parser.js — the Node-RED function ⬇ nodered-flow.json — importable flow ⬇ dashboard.json — the Grafana dashboard

§How it works

Four moving parts. Each does one job and hands off to the next:

Why this stack?

The data model (learn this — everything downstream depends on it)

InfluxDB stores points. Each point has a measurement, some tags (indexed labels you filter/group by), some fields (the actual values), and a timestamp. Our model:

A raw syslog line looks like this

…which the parser turns into this InfluxDB line

§Prerequisites

This guide picks up after the three services are installed. Each project has good install docs (Docker images exist for all three) — follow those, then come back. You need:

1InfluxDB — somewhere to put the data

We create an organisation, one bucket, and an API token Node-RED will use to write.

1.1 Create the organisation & bucket

In the InfluxDB UI:

1. If this is a fresh install, the setup wizard creates your first organisation and user. Name the org aprs (or anything — just be consistent).
2. Go to Load Data → Buckets → Create Bucket.
3. Name it after your iGate's callsign-SSID, e.g. N0CALL-10. Set retention to whatever you like — 30 days is a sensible start.

1.2 Create an API token

1. Go to Load Data → API Tokens → Generate API Token → Custom API Token.
2. Give it Read + Write on your N0CALL-10 bucket.
3. Copy the token now — InfluxDB shows it only once.

1.3 Confirm it works

From any machine on the LAN, write one test point. Substitute your host, bucket, org and token:

A 204 No Content response means success. You can delete the TEST-1 point later, or just let retention expire it.

2Node-RED — receive & parse the syslog

Node-RED listens on a UDP port, runs each line through a parser function, and POSTs the result to InfluxDB. You can import the ready-made flow, or build it node-by-node.

2.1 Point your iGate at Node-RED

In your iGate's web configuration, find the syslog settings and set the destination to your Node-RED host and a port of your choice (this guide uses 1234):

2.2 Import the flow

1. In Node-RED, top-right ☰ menu → Import.
2. Paste the contents of nodered-flow.json (or "select a file to import").
3. Click Import. You'll get a tab with four nodes: udp in → SYSLOG PARSER → InfluxDB write (+ two debug nodes).

The importable flow:

2.3 Edit the two things you must change

1. The parser function — double-click the SYSLOG PARSER node. At the very top are three values. Set them to your token, org and bucket:

const INFLUX_TOKEN = "YOUR_INFLUX_TOKEN";   // from Step 1.2
const ORG          = "aprs";                // your org name
const BUCKET       = "N0CALL-10";           // your gateway callsign = bucket name

2. The write node URL — double-click InfluxDB write and change INFLUX_HOST in the URL to your InfluxDB IP. Leave the {{org}} / {{bucket}} mustaches as-is — the parser fills them in per message.

2.4 The parser, explained

This is the heart of the system. It receives one raw syslog line in msg.payload and returns InfluxDB line protocol. Read the comments — every block earns its place:

The parts worth understanding

• Category & heard callsign — read from the line prefix (- RX /, - TX /, ,TCPIP,). This is who was heard and how.
• Coordinates are anchored to LATN / LONE.
  Why the " / " separator matters: APRS frames often relay other stations' or objects' positions. A loose "grab any number followed by N/E" regex will happily pin your fixed iGate wherever some passing relayed object happened to be. Real first-party positions in this firmware are wrapped as 52.34N / 0.12W; relayed ones lack that ` / ` structure, so anchoring to it skips them. This one detail is the difference between a clean map and your gateway scattered across the country.
• Everything numeric is written as a FLOAT (no i suffix in line protocol).
  Why: InfluxDB refuses to store an integer and a float in the same field — you'd get a "field type conflict" the first time a value happened to be whole. The Grafana queries also do float() maths on these. Keep them all floats and you never hit it.
• The gateway is the syslog HOSTNAME (3rd token of the RFC5424 line). We sanity-check it looks like CALLSIGN-SSID and return null otherwise — junk and obviously-spoofed lines never reach the database.

2.5 Verify data is flowing

1. In the parser flow, enable the line protocol debug node (click its green button) and open the debug sidebar (🐞 top-right).
2. Wait for your iGate to hear a packet (or beacon its own position). You should see aprs_syslog,... lines appear.
3. The write result debug should stay quiet (a 204 has no body). Now check InfluxDB: Data Explorer → your bucket → aprs_syslog — points should be arriving.

3Grafana — the dashboard

3.1 Add the InfluxDB datasource

Go to Connections → Add new connection → InfluxDB and configure it for Flux (not InfluxQL):

Click Save & test — Grafana should report it can reach the bucket.

3.2 Create a service-account token (for the API import)

This dashboard uses Grafana's newer dashboard schema, which is imported via the API rather than the classic "paste JSON" box. You need a short-lived token:

1. Administration → Users and access → Service accounts → Add service account.
2. Role: Editor. Then Add service account token and copy it.

3.3 Push the dashboard

From the folder containing dashboard.json, run (substitute host + token):

A 201 Created means it's in. Open Grafana — you'll find the LoRa-APRS iGate Monitor dashboard. If your datasource UID and bucket name match, panels populate immediately.

3.4 The one variable that matters: ${bucket}

The dashboard has a hidden variable called bucket, preset to N0CALL-10. Every panel reads from from(bucket: "${bucket}"), and the gateway's own identity is derived from it (so "my own beacons" filters target the right station automatically).

If your bucket isn't literally N0CALL-10, edit the variable: Dashboard settings → Variables → bucket.

§The dashboard, panel by panel

The dashboard is organised into sections — Maps & Coverage, Activity, Signal & RF, Telemetry, Logs. Here's what each panel tells you and the clever bits behind a few of them.

Counting packets correctly

Remember one packet writes ~13 field-rows. The activity query counts unique timestamps per callsign, not rows:

Finding "my own" position safely (the map cold-start guard)

Map panels need to know where your gateway is. Since the gateway's callsign equals the bucket name, that's callsign == "${bucket}". But on a brand-new bucket, before your iGate has beaconed its position, naïvely calling findRecord() on an empty table errors the whole panel red. The fix is to union in a harmless sentinel row so there's always something to find:

Defensive coordinate fixing

You'll notice fixLat/fixLon helpers in the map queries that convert a value to degrees if |lat| > 90.

§Troubleshooting

§Going further

• Keep your lora-aprs.live feed too. Many iGates only send syslog to one place. If yours points at a public aggregator and you don't want to lose that, add a second udp out node in Node-RED wired off the same udp in, forwarding the untouched packet to the aggregator's host:port. You then keep both feeds.
• Tune retention. Bump the bucket's retention in InfluxDB if you want longer history (storage permitting). 30–90 days is plenty for trend analysis.
• Add a second iGate. Give it its own bucket (named after its callsign), point its syslog at the same Node-RED, and clone the dashboard — changing only the ${bucket} variable. The same parser handles any number of gates, because it routes by the syslog hostname.
• Terrain profiles. A natural next project: feed gateway↔station great-circle paths through an elevation API (e.g. a self-hosted OpenTopoData) and plot the terrain cross-section to explain why some links work and others don't.