Monthly Archives: February 2014

Hardware update – new sensor board

We finally assembled a couple of sensor boards this week. This board has pads for a bunch of sensors (listed below).

  • MPL3115A2 – Pressure / Temperature / Altitude (Freescale)
  • CC2D33S   – Humidity and temperature (GE Sensing)
  • LM75B – Temperature (NXP)
  • TSL45315 – Ambient light (AMS-TAOS)
  • MMA7660FCR1 –  3-Axis Orientation/Motion Detection Sensor (Freescale)
  • MP34DB01TR – Microphone (ST)
  • DS1822-PAR – Temperature sensor 1-wire (Maxim)
  • MP3V5050GP – Ported liquid pressure sensor (Freescale)

You can select one or more sensors. We  will mount the selected sensors and test them before delivery.

The sensor board can be plugged into a WiSense node. Note that WiSense boards can be plugged in any order. Pads for two sensors (LM75B and TSL45315) are also present on the RF host board. You can choose two have these two sensors mounted on either of these two boards.

The first five sensors in the list (above) are I2C capable. The DS1822-PAR  communicates over a 1-Wire bus. MP3V5050GP has an analog output. The MP34DB01TR is a microphone with PDM interface.

The pads for the first six sensors in the list (above) are on the top side of the board. The last two sensors are mounted on the bottom side.

The pictures below show a sensor board populated with five of the sensors in the list.

sb1.

.

.

.

.

.

.

sb2

Advertisements

WiSense gateway interface message format

In this post, I am going to explain the format of messages sent/received to/from WiSense coordinator/gateway nodes. Each instance of a WiSense network has exactly one coordinator/gateway node which is responsible for bringing up and maintaining the sensor network. It also acts as the gateway between the sensor nodes and the external world. In the simplest case, a WiSense network consists of one coordinator/gateway node connected to a PC through a USB/serial bridge and just one sensor node. Let us assume that the app layer on the sensor node samples one or more on-board sensors every 10 seconds and sends the sensor data in a message to the coordinator. The coordinator simply forwards all received application layer messages over the serial connection to the PC. The coordinator does not interpret application layer messages received from any node in the network.

The serial port configuration is 9600 bps / 8-n-1 (8 bits, no parity bit, 1 stop bit).

For each application layer message received from a WiSense sensor node, the coordinator prefixes a header whose format is given below –

  • Byte Offset       Length            Description
  • ——————————————————————————————————————————-
  • 0                               2                     Message Type (16 bit value in network byte order)
  • 1                                1                     Flags
  • 2                               1                      Message sequence number (Monotonically increasing 8 bit value)
  • 4                               2                     Message payload length field
  • 6                               2                     Header CRC (covers the previous 6 bytes)
  • 8                               2                     Payload CRC (covers the complete payload)

When the message type is  0x0006 (LPWMN_GW_MSG_TYPE_RELAY_FROM_NODE), the format of the payload is given below –

  • Byte Offset       Length          Description
  • ——————————————————————————————————————————-
  • 0                                2                   16 bit short address of the sensor node which has sent this app layer message
  • 2                                1                   RSSI (received signal strength) of the message as reported by the PHY layer on the coordinator
  • 3                                1                   Correlation factor of the message as reported by the PHY layer on the coordinator
  • 4                               N                  N byte app layer message received from sensor node.

Allowed message types are defined within the WiSense application layer. You can look up the file “gw/inc/gw.h”.

An application running on the PC can also send messages to any sensor node via the coordinator.  Such messages are sent using the message type 0x0005 (LPWMN_GW_MSG_TYPE_RELAY_TO_NODE).

Messages sent over the serial link to the coordinator/gateway node are sent in two phases. In the first phase, only the header portion (10 bytes) is sent. When the coordinator/gateway receives this header, it will use the payload length field in the header to allocate a buffer for the payload portion. If this buffer is allocated successfully, the coordinator/gateway will send an acknowledgement  to the PC. The ack message only has the header (no payload). The message type in the header will be 0x0 (UART_MSG_TYPE_ACK) and the flags field will be set to 0x81  indicating that the sender can now send the payload portion.

Note that messages sent by the coordinator/gateway to the PC are sent in one shot.

The coordinator uses the message type 0x00b0 (LPWMN_GW_MSG_TYPE_EVENT) to send network events to the application running on the PC. For example, the coordinator sends event with id 0x1 (LPWMN_GW_EVT_TYPE_NODE_REG) whenever a sensor node joins the WiSense sensor network managed by this coordinator. The event message contains the 64 bit extended address of the node (which has just joined) and the 16 bit short address allocated to this node.

You can get more info on the different message types from the WiSense gateway message specification.

WiSense Sensor data format

In this post, I am going to go over the format in which WiSense sensor nodes send sensor data. The format utilizes TLV objects. Each TLV object  comprises a fixed length type field, a fixed length field and a variable length value field. For example, a node uses the “sensor-id” TLV to convey the specific sensor to which the associated data belongs. The TLV looks like this –

  •     Type field:  0x14
  •     Length field:  0x1
  •     Value field:  0x9

The TLV occupies 3 bytes within a message. The value of the type field is ox14 which identifies this as “sensor id” TLV. The length field of this TLV has a value of 1 and the value field of this TLV is 0x9 which implies that this an LM75B sensor.

The value of the length field indicates the length of the subsequent TLV value field. The total length of a TLV object is the sum of the length of it’s three fields (1 byte (type field) + 1 byte (length field) + N bytes (value field) = (2 + N) bytes). Since the size of the length field is only 1 byte, N can be at most 255 bytes.

The length of the type field is also 1 byte. This restricts the max number of TLV types to 256. In OOP terminology, the maximum number of classes possible is 256. We could increase the TLV type field to 2 bytes but this would increase the overhead.

Let us look at another TLV (the sensor data value TLV) below.

  •     Type field:  0x2
  •     Length field:  0x2
  •     Value field:  0x001a

This TLV above is used to convey sensor output. In this example, the length field is 2 bytes which means the value field of the TLV is a 16 bit number. The value field in this example is 26 (0x1a). The type field value is 0x2 which identifies this as a “sensor output” TLV.

All TLV objects sent/received by WiSense nodes always have a 1 byte TLV type field and 1 byte TLV length field. The TLV value field is variable and it’s length is indicated by the value of the TLV length field.

You can think of the TLV type field as a class identifier. You can instantiate multiple instances of a TLV within a message.

TLV’s can encapsulate TLVs. A TLV which contains one more more TLVs is called a compound TLV. A TLV which does not contain any TLVs is called a simple TLV.

Let us take a look at an actual message sent by a sensor node to the coordinator which forwards this message to an app running on a PC connected to the coordinator over the serial interface.

The message byte sequence is –

0x3 0x10 0xf 0x11 0xd 0x14 0x1 0x9 0x2 0x2 0x00 0x1a 0x3 0x1 0x7 0x4 0x1 0x6

0x3 (DIS_MSG_TYPE_SENSOR_OUTPUT)

  • 1 byte type: 0x10 (DIS_TLV_TYPE_SENSOR_OUTPUT_LIST)
  • 1 byte length:  0x1e (30)
  • 30 bytes long value field:
    •     1 byte type: 0x11 (DIS_TLV_TYPE_SENSOR_OUTPUT)
    •     1 byte length: 0xd (13) 
    •     13 bytes long value field: 
      •          1 byte type: 0x14 (DIS_TLV_TYPE_SENSOR_ID)
      •          1 byte length: 0x1
      •          1 byte value: 0x9 (LM75B sensor #1)
      •          1 byte type: 0x2 (DIS_TLV_TYPE_VALUE)
      •          1 byte length: 0x2 
      •          2 byte value: 0x001a (26 deg Celcius)
      •          1 byte type: 0x3 (DIS_TLV_TYPE_DATA_UNIT)
      •          1 byte length: 0x1
      •          1 byte value: 0x7 ( DIS_DATA_UNIT_CELCIUS)
      •          1 byte type: 0x4 (DIS_TLV_TYPE_DATA_SCALE_FACTOR)
      •          1 byte length: 0x1
      •          1 byte value: 0x6 (DIS_DATA_SCALE_NONE)
    •    1 byte type: 0x11 (DIS_TLV_TYPE_SENSOR_OUTPUT)
    •    1 byte length: 0xd (13)  
    •    13 bytes long value field:
      •          1 byte type: 0x14 (DIS_TLV_TYPE_SENSOR_ID)
      •          1 byte length: 0x1
      •          1 byte value: 0x12 (TSL45315 light sensor #1)
      •          1 byte type: 0x2 (DIS_TLV_TYPE_VALUE)
      •          1 byte length: 0x4 
      •          2 byte value: 0x0000c350 (50000 Lux)
      •          1 byte type: 0x3 (DIS_TLV_TYPE_DATA_UNIT)
      •          1 byte length: 0x1
      •          1 byte value: 0xd ( DIS_DATA_UNIT_LUX)
      •          1 byte type: 0x4 (DIS_TLV_TYPE_DATA_SCALE_FACTOR)
      •          1 byte length: 0x1
      •          1 byte value: 0x6 (DIS_DATA_SCALE_NONE)

In this message, the first byte is 0x3 which indicates that this message conveys the output of one or more sensors located on the sending node.

The second byte is the start of the “DIS_TLV_TYPE_SENSOR_OUTPUT_LIST” TLV. This is a compound TLV. It can contains one or more TLVs of type “DIS_TLV_TYPE_SENSOR_OUTPUT“. In this example, the node is sending the output of two sensors, as a result the “DIS_TLV_TYPE_SENSOR_OUTPUT_LIST” TLV contains two TLVs of type “DIS_TLV_TYPE_SENSOR_OUTPUT”, one for each sensor.  The first DIS_TLV_TYPE_SENSOR_OUTPUT” TLV conveys information about the LM75B temperature sensor and the second DIS_TLV_TYPE_SENSOR_OUTPUT” TLV conveys information about the TSL45315 ambient light sensor. You can see four sub TLVs in both theDIS_TLV_TYPE_SENSOR_OUTPUT” TLVs. One TLV conveys the sensor id, another TLV conveys the sensor output value, another TLV conveys the data unit and finally a TLV to convey the scale factor of the data value. In the firstDIS_TLV_TYPE_SENSOR_OUTPUT” TLV, the unit is “degree Celcius” and in the second TLV, the unit is “Lux”.

The TLV format does not have to be static. Each message of a specific type need not contain all the TLVs. For example, another node can send the same message type (DIS_MSG_TYPE_SENSOR_OUTPUT) with different number of DIS_TLV_TYPE_SENSOR_OUTPUT” TLVs. Further, some “DIS_MSG_TYPE_SENSOR_OUTPUT” instances may be missing some optional TLVs such as the DIS_TLV_TYPE_DATA_SCALE_FACTOR” TLV or may have additional TLVs. The parser (on the receiving node) will only flag an error when a mandatory TLV is missing. For example, if the “DIS_TLV_TYPE_SENSOR_ID” TLV is missing, the receiver cannot determine the sensor instance to which the associated information belongs and this is an error (an invalid TLV).

The length field of the top level TLV is set to 0x1e (30). This is because it’s value field consists of two TLVs each of which is 15 bytes long.

Multi byte numbers sent in a TLV value field are sent in network byte order. For example, the output of the LM75B sensor is sent as a 16 bit signed value in network byte order. In the above example, the value field is (0x00 , 0x1a) which is 26 deg Celcius.

The TLV types are defined as part of the WiSense sensor node application layer. You can look up the file “dis.h” in the directory “dis/inc/dis.h” where “dis” refers to “device interface specification”.

A minor hardware update

We have a separate PCB which hosts the RF board, a coin cell retainer as well as a couple of sensors (temperature and light). The chip antenna  PCB is only 0.4 mm. Compare this to a normal FR-4 PCB whch is 1.6 mm thick. We cannot mount board to board connectors on the chip antenna PCB since it is really thin. As a result we had to build a “host” board to host the radio, sensors and a coin cell retainer. In the latest version we have added a slide switch to the “host” board. This allows the user to turn off the node when not in use.

Host board

Host board

.

.

.

.

.

.

.

.

 

.

Host board (bottom side)

Host board (bottom side)

Yet another hardware update

We have now added a UART to USB interface to the controller board using a chip from FTDI. This interface has two functions –

  • Provide serial connectivity using a USB cable (USB Mini-B plug)
  • Provide power to a sensor node

The UART to USB interface is more suitable for gateway nodes which need to be connected to a PC or an SBC such as the Raspberry Pi. This interface is not required on battery powered RFDs (reduced function devices). We will give you the option to include/exclude this interface on any nodes you purchase.  We are using a FT234XD UART/USB bridge chip from FTDI.  We are using the 3.3 volt output from this chip to power the sensor node. Note that there is a separate SPY-BY-WIRE for programming and debugging the microcontroller. The SPY-BY-WIRE interface also powers the sensor node during programming/debugging. You can use the SPY-BY-WIRE interface as well as the UART/USB interface at the same time. When both interfaces are in use, the SPY-BY-WIRE powers the board (in addition to programming/debugging) and the  UART/USB interface provides only the serial connectivity.

We also added a tiny reset button to the controller board. Press this button to (hardware) reset the MSP430.

Now some pics –

usb_uart

.

.

.

.

.

.

.

.

node_with_usb_cable