How data frames are generated

Data frame types used by the PCS

As you know, the programs generated by the PCS consist on 3 basic steps:

• Read sensor data

• Send sensor data

• Sleep mode

The Waspmote Frame was designed in order to create sensor data frames with a specific format. This data protocol is supported by Meshlium (Meshlium can decode these data frames), so this is the format used by the PCS in order to transmit data. For more information, refer to the Data Frame Guide.

The PCS creates "binary frames" because this type of frame permits to add more sensor data within the same frame buffer. Each sensor value defines a sensor field which is added to the frame structure. All sensor fields can be found in the Data Frame Guide.

Figure: Binary frame format

Besides, a special frame format was designed in order to send sensor data via low bit-rate protocols with short payload size. This frame type is called "tiny frame". The user must keep in mind that this protocol is not integrated into Meshlium (in fact, this frame type is mainly designed for constrained radios like Sigfox or LoRaWAN, and when operating with these protocols the receiver is not Meshlium but a Sigfox or LoRaWAN base station). In this case, the Programming Cloud Service chops the whole "binary" frame payload into a number of "tiny frames" as explained in the Data Frame Guide.

Figure: Tiny frame format for LoRaWAN and Sigfox

Also, payload encryption feature (AES-256) can only be applied to radios using the binary frame format. If this feature is enabled, encrypted binary frames will be used. The format of the encrypted frames is explained in detail in the Data Frame Guide. In case of enabling the payload encryption feature, the user must define whether "Device to Cloud" or "Device to Gateway" is used. The only difference between both encryption options is the frame type identifier. Also, Meshlium will manage the frames differently. On one hand, the "Device to Cloud" packet will be stored in the Meshlium\'s database as it is received. On the other hand, the "Device to Gateway" packet will be decrypted and then stored in the Meshlium\'s database as any other unencrypted frame.

Figure: Encrypted frame format

To sum up, depending on the radio protocol a specific frame format is used:

Radio	Frame type	Payload encryption (AES-256) feature?
XBee-PRO 802.15.4	Binary	Yes
XBee-PRO 900HP	Binary	Yes
XBee 868LP	Binary	Yes
XBee ZigBee	Binary	No
4G	Binary	Yes
WiFi	Binary	Yes
Sigfox	Tiny	No
LoRaWAN	Tiny	No

Sensor fields definition

Normally, each sensor data consists on:

• Sensor identifier: this is the first byte to identify the sensor. For instance, the temperature sensor.

• Sensor value: the rest of the sensor data (one or more bytes) are dedicated to define the value of the sensor data.

Sensor data
Sensor ID	Sensor value (one or more fields)

Figure: Sensor data structure

In the Data Frame Guide you can find the explanation for the binary frames payload. There are different sensor data types depending on the meaning of the data which integrates the sensor value. In the mentioned guide you will find 3 binary sensor data types:

• Simple data: sensor ID + one sensor field. For instance, the temperature sensor value.

• Complex data: sensor ID + several sensor fields. For instance, the GPS (latitude and longitude).

• String data: sensor ID + string length + string message.

For more information, refer to the Data Frame Guide.

Modbus sensor data

The Modbus sensor data is a special case. The PCS features the “read input register” Modbus function. Each reading defines a new SENSOR_MODBUS_INPUT_REGS sensor data. This is a complex sensor data of three different uint16_t fields. The first field is divided into 2 bytes for the device address and the register address respectively. As the PCS can read up to 2 registers per action, the second field will be the first register and the third field will be the second register.

Example:

• Industrial protocol: Modbus (over RS-232)

• Baudrate: 9600

• Device address: 0x11 (Decimal 17)

• Register address: 0x00

• Number of registers to read: 2

In the form you should enter the next settings:

Figure: Industrial protocol settings

Imagine the first register read from the RS-232 module is 0x0192 and the second register is 0x0115. In that case, the final sensor data inserted within the payload would be:

Sensor data
Sensor ID	Sensor field 1	Sensor field 1	Sensor field 2	Sensor field 2	Sensor field 3	Sensor field 3
Byte 0	Byte 1	Byte 2	Byte 3	Byte 4	Byte 5	Byte 6
0xB7	0x11	0x00	0x92	0x11	0x15	0x01

Figure: Sensor data structure