Smart Mesh Part 6
This SerialMesh product works quite differently. Basically, all serial data communications received on the DB9 connector is broadcasted into the smart mesh. No connection or a peer is required to allow transmitting of serial data. All mesh packets are encrypted, only if you know the network key, the serial data can be understood. This product is designed for industrial sensor market.
Each SerialMesh product choses its own device id. This identifies the product. A device id is between 0x8001 and 0xFFFE. The top bit is set to follow the standardization attempt of the SIG. See here. When serial data is detected, the SerialMesh waits for a timeout of 50ms or until the mesh packet's payload of 9 bytes it full. It will then send that serial data packet to a virtual channel with the same network id, top bit cleared (device id & 0x7FFF). Any one listening on this particular channel will be able to receive the serial data, as long as it has the same network key for decryption.
Receive serial data from other devices (or applications) works the same way. A mesh packet sent to the device id or the virtual channel the device represents will result in printing the content on the serial port at the configured baud rate.
In order to "pair" two SerialMesh devices together, meaning we are making a "wireless cable", we allow the device to be part of one group. The group is part of the configuration, as is the baud rate etc.
Now configure one SerialMesh to be in a group that is the virtual channel of the other SerialMesh product. E.g. SerialMesh_1 has device id of 0xC0C0 and SerialMesh_2 has device_id 0xF123. SerialMesh_1 sends serial data to channel 0x40C0 and SerialMesh_2 sends serial data to channel 0x7123. To pair SerialMesh_1 to SerialMesh_2, configure the group of SerialMesh_1 to 0x7123.
When SerialMesh_2 sends data, SerialMesh_1 is able to receive these data, because it belongs to the group and prints the data on its serial port. Do the same on the other side and you have a nice 1:1 pairing.
But this concept is more powerful. Multiple SerialMesh devices can belong to the same group. This means that one SerialMesh can send data to multiple SerialMesh receivers. This is still a great feature, a 1:N type connection, Bluetooth never had before. It's still not the other way around.
So far, the serial communication is completely transparent. The bytes to go into the DB9 on the RS232 are coming out on the other end, unaltered. No information is available on where did it come from, or if the data was relayed or what the signal strength was.
There is a tradeoff between reliability and performance. We chose performance, but added additional measures for reliability. As it goes with broadcast messages, collisions over air or other problems will cause a loss of packets. Even though, each packet is sent twice on each of the 3 advertisement channels at a certain repeat time, it does happen that packets are lost. A good way to deal with it would be to acknowledge each packet and have the transmitter repeat it until the ack is received. That is very slow.
In our implementation, we have a relative large receive buffer that matches the sequence number of each serial packet. The SerialMesh prints the packet with the next serial number. If all goes well and everything is received, no acks or no repeats are happening and we reach the maximum performance of the smart mesh data throughput.
If a packet is missing, indicating that we have a missing serial number, the SerialMesh sends are repeat request message to the group it is configured to receive serial data from. If the group is not configured, it will not send request messages. The other end, that sent the serial data also has a transmit buffer mapped to serial numbers and will repeat the missing packet. If it still is of no avail, the timeout is set to 250ms, meaning we take the loss and keep on printing of what we have.
We implemented N:1 and N:M type connections as well. It get a bit confusing when you think about multiple SerialMesh devices sending data to one SerialMesh. There is no guarantee on the order of arrival or it is impossible to see where this data came from. To solve the problem we allow the SerialMesh to interpret the data. Instead of transparently printing serial data, we print the origin, the rssi, the relay count, the serial number and of course, the data itself, for each packet.
This mode can be enabled by using virtual groups 0x0001 to 0x00FF. Configured to that group, the receiver will each serial mesh packet in readable form, all hex, e.g. "-51 0d 4123 06 32333534320d0a", this means "23542<CR><LF>" from 0x4123, twice relayed, -51dBm last signal strength.
Config and Status
The AIRcable SmartMesh send out status messages every 20 seconds and config packets every 1 minute. Those packets contain
product id, a unique number identifying the AIRcable SerialMesh, 0x105C
vendor id, the USB-IF id, ours is 0x16CA
epoch time, the number of seconds the device has been running since the firmware was installed.
This is the standard status packet for all our products. The SerialMesh does not have any more status. The config packet contains
name of the device (configurable 9 char length string)
density (number of packets to be sent per serial communication, set to 2)
duty cycle (set to 100% listening time)
behavior (this determines if the device only sends to group or to both, virtual and group)
groups (max 3, but the SerialMesh can only use one group)
baud rate (9,600-115,200 baud, with 2,400 baud special)
For details see the description of the Smart Mesh Controller application.
The new AIRcable MiniMesh product is based on our AIRcable BLE module with the CSR1010, programmed with the smart mesh firmware. It only implements the smart mesh communication protocol, no standard BLE GATT, bridge mode or other is implemented. The SerialMesh is powered through pin 9 of the DB9, 5-25V input is allowed. The RS232 has no hardware handshake, just TX and RX, but fully RS232 voltage conform.