Devilbinder
commented
2 years ago For data acknowledgement. A message type data field will be required. To tell the device how interpret the data. A message ID will also be required. Some simple counter will do. You don't need "proof". All your device need to know is: I sent a message with ID x and have I gotten a response about that ID. Another approach is to have the final endpoint query the sensors but this does not scale to large networks.
CRC and checksum are used for data integrity checks not for data acknowledgement. They get appended at the end of a data frame,
CRC are superiors with the tradeoff being that is more computationally expensive unless you are using hardware accelerators.
Here is how to do a CRC. https://github.com/4-20ma/ModbusMaster/blob/3a05ff87677a9bdd8e027d6906dc05ca15ca8ade/src/util/crc16.h#L71
Here is how it is used. https://github.com/4-20ma/ModbusMaster/blob/3a05ff87677a9bdd8e027d6906dc05ca15ca8ade/src/ModbusMaster.cpp#L695
Your data structure will look like this.
typedef union __attribute__((packed)) DataReading_t {
__attribute__((packed)) struct{
float data;
uint16_t id;
uint8_t type;
uint16_t crc16;
}
__attribute__((packed)) struct{
uint8_t serial_data[7];
uint16_t crc;
}
__attribute__((packed)) struct{
uint8_t serial_payload[9];
}
} DataReading_t;Encryption and Security
Rule No.1: Don't roll your own crypto, bro.
Use AES128 or AES256 algorithms. MbedTLS is the defacto standard and is include with the ESP32.
Also requires true/secure random number generators witch kicks out 90% of the popular MCUs that are being used with Arduino.
timmbogner
thefeiter
Gulpman
GUVWAF
aviateur17
First off, I want to extend my deep appreciation to everyone who has helped me with this project. I'm so glad that everyone is having as much fun with FDRS as I am!
The first of the goals that Andreas mentioned for FDRS is packet confirmation.
Packet confirmation is already done within the ESP-NOW protocol to some degree, and you can use the send callback to confirm whether or not it was delivered. From what I read, the protocol actually does some quick retries if no confirmation is received. However, because we will want to keep our methods uniform with LoRa, which has no confirmation, I propose we create a new protocol for confirming packets on both LoRa and ESP-NOW.
Something I hold sacred in FDRS is that the messages are sent as either a single object or an array of objects (DataReadings). Because this is the only expected packet format, adding another packet type brings on the question: how does the gateway know which is which? My favorite solution: the system packets are smaller, and thus if LoRa or ESP-NOW receive a packet smaller than a DataReading, it knows that it is dealing with a system packet. This of course limits you to single system packets at a time. A DataReading is 7 bytes, thus I propose the new packet be either 6 or 4. The packet will already know its size and sender, so it doesn't need to convey either of those.
The system packet will be sent after a message is received by a device. It will send some kind of token back to the sender that proves it received the message correctly. The sending device will be waiting (non-blockingly) to receive that proof, and retrying at intervals if not.
So the main question: what is the proof? I'm hoping someone can just tell me whether to use CRC or checksum for the token.
This may also be a good time to have a discussion about encryption/security, which will be another use of the new packet. This will not be pertinent until two-way communication is ironed out, but it's good to keep in mind. The system packet will also be used by sensors for pinging and pairing with gateways, as well as perhaps get/setting configuration parameters.
All thoughts, ideas, and proposals are welcome and appreciated!