Using:Sensors
Navigation: Home | Scenarios | Installing | Using | Future
Using:Setup | Using:Troubleshooting | Using:Shell | Using:Sensors | Using:Actuation | Using:SLIP | Using:Webserver | Using:HTTP | Using:RPL
The most common thing to do with a sensor network is collect data, so that's just what we'll do. Contiki includes a rich toolset for collecting and viewing sensor data. This section will take a close look at each piece.
Contiki's sensor collection and display system, collect-view, has five major components:
- Sensors
- Message-builder
- Sender nodes
- SINK nodes
- Collect-view java app
Contiki defines macros to provide a standard interface to sensors. Each sensor gets its own module under platform/avr-zigduino/dev e.g. temperature-sensor.c. This module is responsible for interfacing with the hardware to collect the actual sensor value. Each sensor module produces one value each time it's requested.
The message builder collects sensor readings from all known sensors into a sensor message. This work is done by the node-side 'app' in "apps/collect-view". Obviously the message built here needs to correspond to the message expected in the java app.
The sender code in examples/ipv6/rpl-collect/udp-sender.c is responsible for putting a sender node on the network, and packaging a message and putting it on the wireless network. It also adds some additional information about the sender node itself. Each of potentially very many sender nodes runs this firmware.
The single sink node listens to all the senders in the system, receives their messages, adds some information about the sender's network connection, and puts the results on the serial line.
The java collect-view app listens to the sink on the serial line, and displays the results for our enjoyment. Each message from the sender is relayed out on the serial line for the java app to pick up and add to its graph.
Build the rpl-collect example. This brings together all the client-side components, and creates two firmware images. One for the senders, and one for the sink. Note that the avr-zidguino platform now uses RPL by default, so this image will automatically and invisibly create a mesh-tree network to find the optimum path for each sensor message back to the sink.
The 'PERIOD' below is the maximum number of seconds between transmissions from each node. For testing, it's useful to have a small number like 15. For production use, you'd want something much higher like 120.
$ cd examples/ipv6/rpl-collect<br/> $ make TARGET=avr-zigduino savetarget<br/> $ make PERIOD=15 -j10<br/> $ make udp-sender.avr-zigduino.u AVRDUDE_PORT=/dev/ttyUSB0<br/> $ make udp-sink.avr-zigduino.u AVRDUDE_PORT=/dev/ttyUSB1<br/> $ make login AVRDUDE_PORT=/dev/ttyUSB1<br/>
If all is well, you'll see data being collected. The 5th entry on the line is the node # doing the sending, in this case it's '836' which is 0x0344, or node #3.
connecting to /dev/ttyUSB0 (57600) [OK]<br/> *******Booting Contiki-2.5-1364-g613783c*******<br/> MAC address 2:11:22:ff:fe:33:44:2<br/> nullmac sicslowmac, channel 26<br/> Routing Enabled<br/> Autostart other processes<br/> I am sink!<br/> <br/> IP addresses [4 max]<br/> fdfd::2<br/> fe80::11:22ff:fe33:4402<br/> UDP server started<br/> created a new RPL dag<br/> Server IPv6 addresses: ::<br/> aaaa::1<br/> fdfd::2<br/> fe80::11:22ff:fe33:4402<br/> Created a server connection with remote address :: local/remote port 5688/8775<br/> 30 0 4 0 836 5 1 0 22 6666 0 0 0 0 0 580 8 512 1 65 2708 0 0 0 6738 0 0 0 0 0<br/> 30 0 41 0 836 1 1 0 22 2108 0 0 0 0 0 580 8 512 1 8 2708 0 0 0 6738 0 0 0 0 0<br/> 30 0 48 0 836 2 1 0 22 2954 0 0 0 0 0 580 8 512 1 16 2708 0 0 0 6738 0 0 0 0 0<br/> 30 0 58 0 836 3 1 0 22 4192 0 0 0 0 0 580 8 512 1 32 2708 0 0 0 6738 0 0 0 0 0<br/> 30 0 68 0 836 4 1 0 22 5410 0 0 0 0 0 580 8 512 1 32 2708 0 0 0 6738 0 0 0 0 0<br/> 30 0 78 0 836 5 1 0 22 6666 0 0 0 0 0 580 8 512 1 65 2708 0 0 0 6851 0 0 0 0 0<br/> 30 0 93 0 836 6 1 0 22 8563 0 0 0 0 0 580 8 512 1 65 2712 0 0 0 6851 0 0 0 0 0<br/> 30 0 95 0 836 7 1 0 22 8781 0 0 0 0 0 580 8 512 1 65 2708 0 0 0 6851 0 0 0 0 0<br/> 30 0 113 0 836 8 1 0 22 11034 0 0 0 0 0 580 8 512 1 131 2712 0 0 0 6738 0 0 0 0 0<br/>
Now you'll want to watch your data coming through, which is what the collect-view java app does for us. Note that I made a few modifications for Zigduino, so be sure to build a fresh copy. When running it, send in the device where the sink node is connected.
$ cd tools/collect-view<br/> $ ant<br/> $ cd dist<br/> $ java -jar collect-view.jar /dev/ttyUSB1<br/>
Launch the node info page, and you'll see stats on all of the nodes connected. The 'Received' counter should be steadily increasing for this one node that's connected.
Contiki designates one button to be the 'button sensor', and hooks it up into the sensor framework. It just tells us whether the button is being pressed. The avr-zigduino platform expects a button connected to ground on Pin 7. This will show up as the 'button sensor'. The rpl-collect example for avr-zigduino puts the button sensor data on the 'battery indicator' page of the Collect View app.
The Atmega129RFA1 has an internal temperature sensor, so the avr-zigduino platform exposes a temperature sensor to read it, and collect-view will pick it up accordingly.
It's interesting to know how the battery is doing. While there is a "battery monitor" feature of the chip, it's not useful in the Zigduino case, because it only monitors the power coming into the chip. The Zigduino has a regulator, so there is always a steady 3.3V coming in.
What we do instead is hook up the battery voltage to analog pin A1, and read that. The chip uses an internal reference voltage of 1.6, so we first have to divide down the battery voltage into a measurable range. I am using a voltage divider circuit with a 1M and 470k resistors, so when the ADC pin reads 1.6V, there is actually 5.0V coming in through the battery. Here is a simple schematic to explain:
Here's what it looks like in collect-view. Not a lot of battery surprises in only a few short samples.
We can dig into details about the message being transmitted to see what's going on under the covers. In tools/collect-view/src/se/sics/contiki/collect/SensorInfo.java, we can see the exact breakdown of the message expected by the Java app.
Values 0-7 are added by the sender after it receives the message from the sink, before it sends it up to the java app. DATA_LEN refers to the final length of the data which the sink is printing for the java app.
public static final int DATA_LEN = 0;<br/> public static final int TIMESTAMP1 = 1;<br/> public static final int TIMESTAMP2 = 2;<br/> public static final int TIMESYNCTIMESTAMP = 3;<br/> public static final int NODE_ID = 4;<br/> public static final int SEQNO = 5;<br/> public static final int HOPS = 6;<br/> public static final int LATENCY = 7;<br/>
Values 8-19 are added by the sender to give information about the sender node and its position on the network. "DATA_LEN2" refers to the length of what the sender sent to the sink.
public static final int DATA_LEN2 = 8;<br/> public static final int CLOCK = 9;<br/> public static final int TIMESYNCHTIME = 10;<br/> public static final int TIME_CPU = 11;<br/> public static final int TIME_LPM = 12;<br/> public static final int TIME_TRANSMIT = 13;<br/> public static final int TIME_LISTEN = 14;<br/> public static final int BEST_NEIGHBOR = 15;<br/> public static final int BEST_NEIGHBOR_ETX = 16;<br/> public static final int RTMETRIC = 17;<br/> public static final int NUM_NEIGHBORS = 18;<br/> public static final int BEACON_INTERVAL = 19;<br/>
Values 20-26 are the actual sensor values measured by the sensor modules and collected by the message builder.
public static final int BATTERY_VOLTAGE = 20;<br/> public static final int BATTERY_INDICATOR = 21;<br/> public static final int LIGHT1 = 22;<br/> public static final int LIGHT2 = 23;<br/> public static final int TEMPERATURE = 24;<br/> public static final int HUMIDITY = 25;<br/> public static final int RSSI = 26;<br/>
And some more clues on how to interpret these from SensorData.java
this.nodeTime = ((values[TIMESTAMP1] << 16) + values[TIMESTAMP2]) * 1000L;<br/> <br/> public static String mapNodeID(int nodeID) {<br/> return "" + (nodeID & 0xff) + '.' + ((nodeID >> 8) & 0xff);<br/> }<br/> <br/> public double getTemperature() {<br/> return -39.6 + 0.01 * values[TEMPERATURE];<br/> }<br/> <br/> public double getBatteryVoltage() {<br/> return values[BATTERY_VOLTAGE] * 2 * 2.5 / 4096.0;<br/> }<br/> <br/> public double getRadioIntensity() {<br/> return values[RSSI];<br/> }<br/> <br/> public double getLatency() {<br/> return values[LATENCY] / 32678.0;<br/> }<br/> <br/> public double getHumidity() {<br/> double v = -4.0 + 405.0 * values[HUMIDITY] / 10000.0;<br/> if(v > 100) {<br/> return 100;<br/> }<br/> return v;<br/> }<br/> <br/> public double getLight1() {<br/> return 10.0 * values[LIGHT1] / 7.0;<br/> }<br/> <br/> public double getLight2() {<br/> return 46.0 * values[LIGHT2] / 10.0;<br/> }<br/>