Built-in decoders
Decoding is the first phase in data processing in uplink communication. In this phase incoming data is normalized into SenML and additional (meta)data is enabled if applicable.
A regular data decoder transforms incoming payload into measurements in SenML, following the data protocol of the specific device.
ThingsML is a generic LoRa payload format, allowing you to send multiple measurements encoded in your payload in a compact way. Learn more about the ThingsML for Lora data protocol.
With additional data (decoders), metadata corresponding to the message received is enabled.
SenML record name | Content |
|---|---|
locOrigin | vs: "KPNLORA" Indicating that the location information in
the SenML record comes from the LoRa network. |
latitude | v The latitude of the location in decimal notation.u: "lat" |
longitude | v The longitude of the location in decimal notation.u: "lon" |
radius | v The theoretical inaccuracy of the calculated location. Can
be used to visualize a circle around the location on a map.u: "m" In meters. |
To extend the reach of our LoRa network on your location, we offer LoRa On Premise Gateways. A LoRa On Premise Gateway is an extension of our regular LoRa network. They have a smaller reach than our regular outdoor gateways, but you can position it for example in your warehouse to guarantee coverage for your LoRa devices.
Additionally, in KPN Things we have integrated the LoRa On Premises Gateway with our localisation service. When you enable Location by LoRa On Premises Gateway reception, KPN Things will detect when data from your device is received by one of your On Premise Gateways. Then KPN Things will add the administrative location of that gateway to the message. That way, the application can use that data to locate the device at the moment the message was sent.
To get this to work, you need to register your On Premise Gateways in your KPN Things account through the KPN Things API's by giving the gateway ID and the coordinates of the location you have positioned the gateway.
With no-decoders incoming data is not interpreted, it is only put into SenML.
SenML record name | Content |
|---|---|
payload | vs The received payload in hexadecimal notation
(example: 010203). |
port | v The application port the data was received on. |
In adition to the regular 'Raw LoRa payload' this extended decoder adds the lora network meta data to the SenML.
SenML record name | Content |
|---|---|
payload | vs The received payload in hexadecimal notation (example: 010203). |
port | v The application port the data was received on. |
FCntUp | v The uplink framecounter |
FCntDn | v The downlink framecounter |
LrrRSSI | vs Received Signal Strength Indicator |
LrrSNR | vs Signal to Noise Ratio |
LrrESP | vs Estimated Signal Power. |
DevLrrCnt | v Amount of gateways that received the message |
SpFact | v Spreading factor used |
SubBand | vs Lora band of the transmission |
Channel | vs Lora channel of the transmission |
ADRbit | v Adaptive Data Rate Bit |
This decoder will initially be available for 'own-Lora' device types. See payload example below:
LoRa Payload extended example
[
{"bn": "urn:dev:DEVEUI:7CC6C40900000104:", "bt": 1673939507.0},
{"n": "payload", "vs":"f105e43ed7aabda9337483c23a58ed33da"},
{"n": "port", "v": 1.0},
{"n": "FCntUp", "v": 3.0},
{"n": "FCntDn", "v": 3.0},
{"n": "LrrRSSI","vs": "-90.0"},
{"n": "LrrSNR", "vs": "-17.0"},
{"n": "LrrESP", "vs": "-107.0858"},
{"n": "DevLrrCnt", "v": 1.0},
{"n": "SpFact", "v": 12.0},
{"n": "SubBand", "vs": "G1"},
{"n": "Channel", "vs": "LC2"},
{"n": "ADRbit", "v": 1.0},
{"n": "TIME_ORIGIN", "vs": "THINGSENGINE"}
]
If your device uses the SenML data format to send data to KPN Things, the data will be accepted as is, without further decoding.
Last modified 8mo ago