🏠 Home → Software → RTLV → Raw port — PAGING_USER (FPort 220)
🤖 Auto-generated from firmware (SSOT). Do not hand-edit — change the descriptor and regenerate. RTLV v3 ·
source_hash eb6b51128c1b
| Property | Value |
|---|---|
| Framing | raw (no [prefix][seq]/TLV) |
| Encoding | cp1251 (app-layer convention; firmware is raw passthrough BOTH directions — no charset transform) |
| Direction | bidirectional |
PAGING_USER (FPort 220) is the chat / paging passthrough — an opaque, bidirectional message channel between the LoRaWAN server and the BLE mobile app (via the nRF52). It carries application text, not RTLV: there is no [prefix][seq] and no [tag][len][value] — bytes are forwarded verbatim.
The app hands the firmware a UART TLV [0x60 TLV_PAGING_TX][len][text]; the firmware strips the 2-byte header and enqueues the raw text as a LoRaWAN uplink on FPort 220 (fragment_and_enqueue_tlv(CMD_PORT_PAGING_USER, &tlv[2], len, EVENT_TRIGGER_PAGING), main.c:8388). The 0xCA EVENT_TRIGGER_PAGING byte is archive metadata, not an on-wire prefix.
A downlink on FPort 220 is not command-parsed: lorawan_process_downlink early-returns for this port (lorawan_commands.c:1456). The raw payload was already forwarded to the nRF52/BLE app by uart_push_rx_data (lorawan_lmhandler_adapter.c:2108) before any command processing — so the text reaches the app verbatim, and a byte that happens to match a cmd_id is not mis-dispatched.
The firmware does no charset transform in either direction. The end-to-end convention is CP1251; the service / message-handler produces and consumes CP1251 bytes. Do not expect the firmware to transcode UTF-8.
The server gates its per-device paging queue by BLE presence: the device reports BLE connect/disconnect via the FPort-2 0x83 lorawan_event event_type=0x50 ble_state TLV (emit_ble_state_uplink, main.c:5633), and a periodic keepalive re-emits the connected state for a presence-TTL. Downlinks on FPort 220 are dispatched only while the device is BLE-connected. See the FPort-2 uplink tags.
Payload 31 32 33 = the text 123 (raw ASCII / CP1251). Decoding it as RTLV would mis-read [prefix 0x31][seq 0x32][len 0x33] → garbage.
Route FPort-220 frames to the message handler; do not TLV-decode them.