In order to set up a basic endpoint reference, at least for the common configuration options, any SWAP device should provide support for the following endpoints:
Product code (8 bytes): Each type of device is defined by a unique product identifier. This endpoint may be queried by other wireless nodes as a way to discover the device capabilities. A central repository containing XML definitions for each product ID may be also maintained, allowing the creation of automatic mechanisms on internet-enabled controllers.
Each product code is composed by a manufacturer id and a product id. No need to produce then unique device id's (MAC), just a unique product code for each product type.
Figure 1: Product code
Hardware version (4 bytes): Hardware version of the device.
Firmware version (4 bytes): Firmware version of the device.
System state (1 byte): Working state of the device. This endpoint can be queried or controlled so that different working modes can be entered wirelessly, including reseting the remote node.
Carrier Frequency (1 byte): This endpoint will be used to switch between the different carrier frequencies available on the device (basically between 868 MHz and 915 MHz). Modulation type will be always GFSK for SWAP.
Frequency channel (1 byte): RF channel.
Security option (1 byte): Type of encryption algorithm applied on each data packet. It should be equal to 0 if security is disabled.
Security nonce (1 byte): Current value of the cyclic nonce. If security is enabled, this endpoint should be queried before sending a command to the device. The reported nonce value would then be used in the subsequent command in order for the command to pass the protection against playback transmissions.
Network identifier (2 bytes): Custom 2-byte code used as synchronization word in a common network. In order to communicate with each other, all devices in the same wireless network must use the same network id.
Device address (1 byte): Unique device address within the network. This address must be comprised between 1 and 255, being 0 reserved as broadcast address.
These fixed endpoints will have to be defined and indexed following the above order. Any custom endpoint would be added at the end of that table.
The advantage of this solution is that any endpoint, including configuration parameters and regular endpoints would be queried and modified in the same way. This said, a proper endpoint management layer would free the protocol stack from having to address configuration operations, reducing the size of the resulting code and simplifying the work on future extensions. Almost anything in a device can be treated as an endpoint: IO's, configuration registers, setpoints, special programmings, diagnosis flags, etc. Then it's just an issue of making those endpoints readable only or modifiable.
Figure 2: architecture of the panStamp library
The final panStamp library will provide all the necessary functions to develop SWAP-enabled devices, battery-operated or not, capable to handle commands, queries and information packets, without having to deal with the protocol details. The following piece of code implements a battery-operated sensor device that sends an ADC value (epTable[10]) every eight seconds, sleeping the rest of the time:
#include "eptable.h"#include "panstamp.h"
void setup(){panstamp.init();}
void loop(){epTable[10]->getData();panstamp.sleepFor(WDTO_8S);}
Example 1: Arduino sketch of a simple battery-operated transmitter
For those wanting to directly interface with the CC1101 driver, the panStamp library will also provide lower-level methods like “CC1101::sendData” or “CC1101::receiveData”, allowing the creation of custom proprietary protocols and avoiding the use of the current endpoint management system.
No comments:
Post a Comment