Meshcore-sensor-net
| Project meshcore-sensor-net | |
|---|---|
| File:Yunopicture.png | |
| Status | Initializing |
| Contact | bertrik |
| Last Update | 2026-02-22 |
Introduction
This project is an investigation for using meshcore as a transport layer for citizen science data.
Meshcore is basically a network of radio repeaters for lora messages with a specific radio setting. The idea is to use a citizen science sensor with a LoRa radio to uplink citizen science data through this repeater network, get the data repeated, then pick it up using a special kind of node is connected to the internet (e.g. MQTT) that forwards the data to a collection server for further processing.
The LoRa setting used almost universally in the Netherlands now is the EU/UK setting:
869.618 / SF8 / BW62.5 / CR8 header enabled sync word XXXX Description of the on-the-air message: https://gist.github.com/recrof/ca7ccff28c43d1b6bf7e55ce5159100b Dissection code: https://github.com/folkertvanheusden/meshcore-store/blob/master/utils/dissect.py
Meshcore repeaters a relatively "dumb", they just forward anything that resembles a packet (they can't inspect the encrypted part).
The idea is basically:
Sensor first starts up, sends a kind of discovery packet in "flood" mode. This kind of packet is flooded over the entire network. At some point the discovery packets reaches a special internet-connected gateway that forwards it to the backend software. The backend software processes the data payload and sends back an acknowledgement packet back over the (best) path that it received the message on. When this reaches the sensor node, the sensor node knows the most efficient way to reach the gateway node and uses a "direct" packet. Every now and then it expects a kind of acknowledgement packet back from the server, to know that messages are still coming through. This is actually a bit similar to how LoRaWAN works.
Investigation
Design
The plan is to use payload type "RawCustom".
Meshcore packet structure from sensor:
- Header: 1 byte = payload type RawCustom + (flood or direct)
- Path: length + path bytes (0 in case of flood)
- Payload: citizen science payload structure
Citizen science payload structure:
- 4 bytes device address
- 4 bytes counter
- x bytes citizen science data
- 4 bytes MAC
Security:
- The citizen science payload is not secret, so it is not encrypted, but we do add a cryptographic checksum to prove authenticity
- The checksum is calculated using the blake2s algorithm, calculated as follows:
- Keyed hash mode with a 32-byte key
- Source device, 4-bytes
- Message counter, 4 bytes
- Message payload, x bytes
- Retain 4 bytes of the hash
- The secret hash key is also calculated using blake2s:
- Initial step: calculate key as blake2s(salt || deviceid || passphrase)
- Repeat this 10000 times: calculate key as blake2s(salt || deviceid || key)
- The salt used is actually the "application name", and the passphrase is the "application secret"
- The application name is part of the program image, the deviceid is read from some unique hardware id, the application secret is entered only during key generation (never stored on device). The resulting key is written to non-volatile storage.
