Manual & FAQ

Everything about the LoRa NextGEN Mapper β€” features, setup and frequently asked questions.

1 Β· What is the LoRa NextGEN Mapper?

The LoRa NextGEN Mapper is a self-hosted coverage map for The Things Network (TTN) / The Things Stack (TTS). It receives LoRaWAN uplinks with GPS coordinates (via webhook or MQTT) and displays the signal coverage on an interactive Leaflet map.

  • Public map lookup by DevEUI or Gateway ID β€” no login required.
  • Signal strength (RSSI), spreading factor and optional sensor values (temperature, humidity, pressure, battery) are stored per uplink and displayed colour-coded on the map.
  • Multiple users can connect their own TTS applications (after registration).

2 Β· Home page & Overview map

The home page shows three key metrics (gateways, devices, total uplinks) and an overview map of all gateways and devices active in the last 7 days.

  • ● Orange dots = Gateways (larger, fixed location).
  • ● Blue dots = Devices / trackers (smaller, mobile).
  • Clicking a dot opens a popup with name, ID, uplink count and last reception.
  • Clicking the popup link navigates to the device / gateway detail page.
  • The map automatically fits all visible points (auto-fit).

A DevEUI can be entered directly in the search box at the top (hexadecimal, 16 characters). Submitting navigates to the device page.

3 Β· Device lookup & Coverage map

URL pattern: /device/{DevEUI} β€” e.g. /device/0102030405060708.

Map

  • Every uplink with a GPS fix is plotted as a coloured circle.
  • Colour dropdown (top left): RSSI | Temperature | Humidity | Pressure. Options with no data are automatically disabled.
  • Heatmap toggle: Overlays a heat map based on RSSI values.
  • Time buttons (24 h / 7 d / 30 d / All): Filters the displayed uplinks by reception time β€” client-side, no page reload. The From/To date fields additionally let you pick a custom range (applies within the loaded uplinks).
  • Sensor filter (collapsible): Min/Max input fields for temperature, humidity, pressure and battery voltage. Shows how many uplinks pass the filter. Reset button clears all filters.
  • Popups show all available sensor values (🌑 Β°C, πŸ’§ %, 🌬 hPa, πŸ”‹ V).

Sensor history charts

Below the map, time-series charts are shown for temperature, humidity, pressure and battery voltage β€” provided the device sends these values.

Recent uplinks

A table of the latest 50 uplinks (timestamp, gateway, RSSI, SF, frequency).

4 Β· Gateway page

URL pattern: /gateway/{GatewayID}. Shows all uplinks received by this gateway.

  • Same map controls as the device page: colour mode (RSSI/Temp/Humi/Pressure), heatmap toggle, time filter (24h/7d/30d/All), sensor filter.
  • The gateway location is highlighted as a separate marker (πŸ“‘), if known.
  • Uplink table with DevEUI, RSSI, SF, timestamp.

The page /gateways lists all known gateways with uplink count and last reception.

5 Β· Compare map

URL: /compare. Multiple devices and/or gateways on a single map, each series in its own colour.

  • DevEUIs or gateway IDs can be added using the form at the bottom of the page.
  • Added entries appear as chips; clicking Γ— removes them.
  • Colour mode: Default = "Series" (each source its own colour). Alternatively, switch to a sensor mode (RSSI, Temp, Humi, Pressure) β€” the same colour scales as on the individual pages then apply.
  • Sensor filter applies to all series simultaneously β€” shows the total visible points across all sources.
  • The URL contains the selected entries as query parameters (?d=EUI1&d=EUI2&g=GWID) and can be shared directly.

6 Β· Statistics page

URL: /stats. System-wide statistics at a glance:

  • Uplinks per day (last 30 days) as a bar chart (Chart.js).
  • Top-10 gateways and top-10 devices by uplink count.
  • RSSI distribution (histogram) and spreading factor distribution (donut).
  • Longest active connection (device with the most uplinks over the longest period).

7 Β· Decoder library & Server-side fallback

URL: /decoders. Ready-made JavaScript payload formatters for common LoRaWAN devices that can be pasted directly into TTS.

Supported devices with ready-made formatters:

  • Dragino LGT-92 (GPS tracker)
  • Dragino LHT65 (temperature / humidity + external sensor)
  • RAK7200 / RAK7201 (WisTrio)
  • Seeed SenseCAP T1000 (A / B / C / E)
  • Browan TBHV110 (Healthy Home Sensor)
  • Adeunis FTD (Field Test Device, BCD-GPS)
  • ELSYS (ERS / ELT / EMS generic)
  • Cayenne LPP (generic)

Each decoder has a Copy button. Paste the copied code into TTS under Applications β†’ Payload Formatters β†’ Uplink β†’ Custom Javascript Formatter and save.

Server-side fallback decoder

If no payload formatter is configured in TTS, the mapper automatically attempts to decode the raw payload:

  1. Dragino LGT-92 heuristic (FPort 2, β‰₯10 bytes): lat/lon as int32 @ 1/1e6
  2. RAK7200 heuristic (FPort 8, marker 0x09): int32 lat/lon, v1/v2 firmware scaling
  3. Seeed SenseCAP T1000 heuristic (TLV format, Type 0x01 for GPS): int32 lat/lon @ 1/1e7
  4. Cayenne LPP (generic, searches for GPS field 0x88)

⚠️ Server-side decoders are conservative β€” they validate coordinates and reject false positives (like (0,0) or out-of-range values). A proper formatter in TTS is recommended for reliable results.

8 Β· Data export (CSV / GPX)

Two download formats are available for each device:

Format URL Content
CSV /api/device/{eui}/uplinks.csv All uplinks with timestamp, coordinates, RSSI, SF, frequency, sensor values
GPX /api/device/{eui}/track.gpx GPS track as GPX 1.1 β€” importable in OsmAnd, Garmin BaseCamp, QGIS and others.

Both endpoints are public and require no login.

9 Β· JSON API (v1)

All endpoints under /api/v1/ are public and return JSON. Base URL: https://ttnmapper.live/api/v1.

Endpoint Description
GET /api/v1 API index with all available endpoints
GET /api/v1/stats Overall statistics (gateways, devices, uplinks)
GET /api/v1/gateways List of all gateways (name, ID, last uplink)
GET /api/v1/gateways/{id} Gateway detail
GET /api/v1/gateways/{id}/uplinks Gateway uplinks (?limit= & ?offset=)
GET /api/v1/devices/{eui} Device detail
GET /api/v1/devices/{eui}/uplinks Device uplinks (?limit= & ?offset=)

GeoJSON endpoints (for map clients):

  • GET /api/activity.geojson?days=7 β€” active gateways + devices
  • GET /api/gateways.geojson β€” all gateways as GeoJSON
  • GET /api/device/{eui}/coverage.geojson β€” coverage points for a device
  • GET /api/gateway/{id}/coverage.geojson β€” coverage points for a gateway

10 Β· Account, Profile & Offline notifications

Registration

An account can be created with e-mail and password at /register. If an SMTP server is configured, the e-mail address must be confirmed before the first login (link via e-mail, valid for 24 h).

Login & sessions

After logging in at /login, a session is created (valid for 30 days). Active sessions are visible on the profile page and can be revoked individually.

Profile page (/profile)

  • Account details and last password change.
  • Your TTS applications with the timestamp of the last uplink.
  • Login history: Last 10 successful logins (time, browserΒ·OS, IP address) β€” helps identify suspicious access.
  • Active sessions (browser Β· OS Β· IP Β· login time) β€” current session highlighted in green. All or individual sessions can be revoked.
  • Device offline notifications: E-mail alerts when a monitored tracker stops sending uplinks.
    • Configurable per device (threshold: 15 min / 1 h / 6 h / 24 h / 7 days).
    • E-mails on online β†’ offline transition and back (with downtime shown).
    • Pause button to mute temporarily.
  • Change password (current password required).
  • Delete account (requires typing "DELETE" to confirm).

Forgot password

A password reset can be requested at /forgot-password. The reset link is valid for 1 hour and can only be used once.

11 Β· Connect TTS applications

TTS applications can be added at /applications (login required). Each application receives a unique webhook token and optionally MQTT credentials.

Webhook test

A test button (πŸ§ͺ Test) can be triggered for each application. This sends a synthetic uplink through the ingest pipeline and shows the result in a modal:

  • Loading state: Data is being processed (spinner)
  • Success: DevEUI, reception time, GPS coordinates (with altitude if available), decoded JSON payload (copyable), "View on map" link
  • Error: Error message from the server with option to retry

12 Β· My Coverage

At /coverage (login required), all GPS uplinks from all linked TTS applications are shown together on a single map. This gives a complete picture of your LoRaWAN range β€” regardless of how many gateways received a signal.

Best-of-gateway logic: Each uplink is plotted with the RSSI of the strongest receiving gateway. This shows the maximum achievable range, not the weakest link.

Map controls

  • Colour mode (dropdown): RSSI Β· Temperature Β· Humidity Β· Pressure Β· Per Device (each device gets a unique colour from a 10-colour palette; sidebar dots and legend update accordingly).
  • Heatmap toggle: Switch between dot view and RSSI heatmap.
  • Time-range buttons: 24 h / 7 days (default) / 30 days / All β€” filtered server-side, no page reload needed. The From/To date fields let you query any historical range (re-fetched server-side).
  • Sensor filter (collapsible): Min/Max inputs for temperature, humidity, pressure and battery. The header shows an "(active)" badge when a filter is set.
  • πŸ“‘ Receiving gateways (toggle): Shows all gateways that have received at least one uplink from your devices (lazy-loaded, orange πŸ“‘ icon, popup shows uplink count and last reception).

Device sidebar

  • Lists all devices with app name, uplink count, last timestamp and last RSSI (colour-coded).
  • Checkbox per device: show/hide on the map.
  • Clicking a device name zooms the map to that device's points.
  • In "Per Device" mode, a coloured ● dot next to each entry shows the assigned map colour.
  • "All" / "none" toggles all devices at once.

Stats strip

After loading, a line below the map automatically shows: X gateways heard Β· Best RSSI: βˆ’XX dBm β€” computed from the loaded data.

13 Β· Setting up webhook ingest

  1. Create an application at /applications and copy the webhook URL (https://ttnmapper.live/webhook/v3/{token}).
  2. In TTS: Applications β†’ Integrations β†’ Webhooks β†’ Add Webhook β†’ Custom Webhook.
  3. Paste the webhook URL, select format JSON, and enable only the event type Uplink message.
  4. Save β€” all GPS uplinks are now forwarded to the mapper immediately.
Requirement: The device must provide GPS coordinates in decoded_payload (fields latitude / longitude) or send a Cayenne-LPP payload. Without coordinates, uplinks are stored but not shown on the map.

14 Β· Setting up MQTT ingest

As an alternative to the webhook, the mapper can communicate directly with TTS via MQTT. This requires an API key with specific permissions.

Step 1: Create API Key in The Things Stack
  1. Go to The Things Stack Console β†’ your application β†’ "Collaborators"
  2. Click "Add Collaborator"
  3. Select "Create API Key"
  4. Set permissions: The following rights are required:
    βœ“ Required permissions:
    • application.traffic.read β€” Read uplinks (MQTT traffic)
    Optional, but recommended:
    • application:devices:read β€” Read device metadata
  5. Copy the generated API key (used as password later)
Step 2: MQTT Settings in Mapper

In your mapper application (Profile β†’ Applications) enter the following values:

  • Enable MQTT: Check the box
  • Broker Host: e.g. eu1.cloud.thethings.network
    Check your region: eu1, nam1, au1, etc.
  • Broker Port:
    • 1883 β€” unencrypted (TCP)
    • 8883 β€” encrypted (TLS, recommended)
  • Username: {app-id}@{tenant-id}
    Example: myapp@tenants.thethingsstack
  • Password: The API key you generated above
Step 3: Automatic Connection
  • The MQTT manager checks the settings every 30 seconds
  • Upon successful connection, uplinks are automatically ingested
  • Automatic reconnect on connection loss
  • In your profile (under "Applications") you'll see "Last active" β€” this shows the last webhook/MQTT uplink
Notes:
  • MQTT + Webhook simultaneously: Both can be active. Duplicate uplinks are deduplicated based on f_cnt + timestamp β€” no duplicates are stored.
  • Security: Use port 8883 (TLS) for encrypted connections. Limit the API key to the minimum required permissions.
  • Connection issues: Double-check host, port, username, and password in your mapper application. Check the server output for logs.

15 Β· Light / Dark theme

The theme can be toggled using the πŸŒ™/β˜€οΈ switch in the navigation bar.

  • For guests, the preference is stored in a cookie (1 year).
  • For logged-in users, the preference is saved permanently in the account.
  • Default: Light.

16 Β· Frequently asked questions

The most common causes:

  1. No payload formatter: TTS sends the raw payload as Base64. Without a suitable decoder, the mapper cannot extract GPS coordinates. Set up a formatter from the decoder library.
  2. No GPS fix: Device sends latitude: 0, longitude: 0 or no coordinate fields at all β€” in this case the uplink is stored but not shown on the map.
  3. Wrong field schema: The mapper expects decoded_payload.latitude and decoded_payload.longitude. Different field names must be normalised in the decoder.
  4. Webhook misconfigured: Enable only "Uplink message", format JSON, correct URL.

Any LoRaWAN device that sends GPS coordinates is supported β€” provided a suitable payload formatter is configured. Ready-made formatters are available in the decoder library for Dragino LGT-92, LHT65, RAK7200, SenseCAP T1000 and Cayenne LPP. For other devices, the Cayenne-LPP decoder or a custom formatter can be used.

Yes. If the device is received by a community gateway and the application is connected via webhook or MQTT, all uplinks are shown on the map β€” regardless of which gateway received them. The gateway location is taken from the TTN metadata.

Yes β€” the map data (DevEUI lookup, gateway lookup, coverage) is intentionally public, similar to ttnmapper.org. Anyone can look up the coverage of any device. Personal account data and application settings are only visible to the respective user.

RSSI (Received Signal Strength Indicator) is the received signal strength in dBm. Typical values:

  • βˆ’80 dBm and better: very good signal (green)
  • βˆ’100 dBm: acceptable signal (yellow)
  • βˆ’120 dBm and worse: weak signal (red)

Spreading Factor (SF) determines the trade-off between range and data rate. SF7 is fastest (short range), SF12 is slowest (greatest range, highest airtime consumption).

Currently all uplinks are stored indefinitely β€” there is no automatic deletion of older data. Sessions and e-mail tokens are automatically cleaned up after expiry (30 days and 24 hours respectively).

The map uses Carto Voyager tiles (basemaps.cartocdn.com). If they don't load, please check:
  • Is network access to external CDN domains available?
  • Are browser extensions (ad blockers) blocking cartocdn.com?
The map works completely without login and without an API key.

On the map pages (device, gateway, compare) there is a collapsible filter panel at the top. Min/Max values can be entered for temperature, humidity, pressure and battery voltage.
  • Filters work client-side β€” only visible uplinks are filtered, no page reload.
  • The counter shows how many uplinks meet the filter criteria.
  • Reset button clears all filters immediately.
  • Filters for which the device has no data are automatically disabled.

Offline notifications are e-mail alerts sent when a monitored tracker stops sending uplinks:
  • Setup: /profile β†’ section "Device notifications" β†’ select device + threshold (15 min / 1 h / 6 h / 24 h / 7 days) β†’ save.
  • Offline e-mail: When the device exceeds the threshold, the user receives an e-mail with the time of the last uplink.
  • Online e-mail: When the device sends an uplink again, a recovery e-mail with the downtime is sent.
  • Anti-spam: Exactly 1 e-mail per offline transition β€” resending the same data does not trigger again.
  • Pause: Alert status can be temporarily changed with the pause button (⏸) on the profile page.
Requirement: SMTP must be configured on the server.

On the /applications page, each application has a test button (πŸ§ͺ Test). Clicking shows a modal with three states:
  • Loading: Synthetic uplink is being sent through the pipeline (spinner)
  • Success: Modal shows DevEUI, reception time, GPS (if available), decoded JSON payload (copyable) and a link to the device map.
  • Error: Error message from the server β€” the modal can be retested.
Improvement over before: No more 302 redirect β€” result is shown inline in the modal.

Yes. If no payload formatter is configured in TTS, the mapper automatically attempts to decode known device formats:
  • Dragino LGT-92 (FPort 2, int32 lat/lon @ 1/1e6)
  • RAK7200 (FPort 8, int32 with v1/v2 scaling)
  • Seeed SenseCAP T1000 (TLV format, Type 0x01 GPS)
  • Cayenne LPP (generic, searches GPS field 0x88)
Limitation: Heuristic decoders are conservative and validate strictly (e.g. they reject (0,0)). For production environments, a proper formatter in TTS is strongly recommended.