Differences

This shows you the differences between two versions of the page.

--- lab9 [2016/01/05 16:47]
dan.tudose [Sensor Message]
+++ lab9 [2018/01/25 19:00] (current)
narcisa_ana.vasile [Voltage]
@@ Line 10: / Line 10: @@
 $ cd tests/udp-ipv6
 $ make NODE=3 -j10
-$ make udp-client.avr-zigduino.u AVRDUDE_PORT=/dev/ttyUSB1 NODE=3
+$ make udp-client.sparrow.u AVRDUDE_PORT=/dev/ttyUSB1 NODE=3
-$ make udp-server.avr-zigduino.u login AVRDUDE_PORT=/dev/ttyUSB0
+$ make udp-server.sparrow.u login AVRDUDE_PORT=/dev/ttyUSB0
 </code>
@@ Line 32: / Line 32: @@
 ===== Shell =====
-The shell is a very powerful feature of Contiki. Within this OS lies a fully-featured command shell. The shell in the avr-zigduino platform is a subset of the full Contiki shell, including only the shell modules which have been proven to work on this platform.
+The shell is a very powerful feature of Contiki. Within this OS lies a fully-featured command shell. The shell in the sparrow platform is a subset of the full Contiki shell, including only the shell modules which have been proven to work on this platform.
 ==== Building ====
@@ Line 85: / Line 85: @@
 ==== blink & kill ====
-Try "blink 100 &" to start blinking the LED's for 100 times. Notice the '&' at the end of that! You should now see all 3 LED's on Zigduino flash on and off repeatedly.
+Try "blink 100 &" to start blinking the LED's for 100 times. Notice the '&' at the end of that! You should now see Sparrow's LED flash on and off repeatedly.
 Then type "kill blink" when you're done admiring your blinking lights.
@@ Line 114: / Line 114: @@
 Individual Sensors
-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.
+Contiki defines macros to provide a standard interface to sensors. Each sensor gets its own module under platform/sparrow/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.
 ==== Message Builder ====
@@ Line 134: / Line 134: @@
 ==== Node Images: rpl-collect ====
-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.
+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 sparrow 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.
 ==== Building ====
@@ Line 142: / Line 142: @@
 <code>
 $ cd examples/ipv6/rpl-collect
-$ make TARGET=avr-zigduino savetarget
+$ make TARGET=sparrow savetarget
 $ make PERIOD=15 NODE=3 -j10
-$ make udp-sender.avr-zigduino.u AVRDUDE_PORT=/dev/ttyUSB0
+$ make udp-sender.sparrow.u AVRDUDE_PORT=/dev/ttyUSB0
-$ make udp-sink.avr-zigduino.u AVRDUDE_PORT=/dev/ttyUSB1
+$ make udp-sink.sparrow.u AVRDUDE_PORT=/dev/ttyUSB1
 $ make login AVRDUDE_PORT=/dev/ttyUSB1
 </code>
@@ Line 159: / Line 159: @@
 ==== Host PC: collect-view ====
-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.
+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 Sparrow, so be sure to build a fresh copy. When running it, send in the device where the sink node is connected.
 <code>
 $ cd tools/collect-view
@@ Line 172: / Line 172: @@
 ==== Button ====
-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.
+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 rpl-collect example for sparrow puts the button sensor data on the 'battery indicator' page of the Collect View app.
 {{ ::687474703a2f2f6661726d372e7374617469632e666c69636b722e636f6d2f363133392f363033353538363838325f333266643331653865312e6a7067.jpg |}}
 ==== Temperature ====
-The Atmega128RFA1 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.
+The Atmega128RFA1 has an internal temperature sensor, so the sparrow platform exposes a temperature sensor to read it, and collect-view will pick it up accordingly.
 {{ ::687474703a2f2f6661726d372e7374617469632e666c69636b722e636f6d2f363132352f363033373135333030315f303438666535336465342e6a7067.jpg |}}
@@ Line 183: / Line 183: @@
 ==== Voltage ====
-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.
+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 Sparrow case, because it only monitors the power coming into the chip. The Sparrow 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:
@@ Line 247: / Line 247: @@
 And some more clues on how to interpret these from SensorData.java
-<code C>
+<code Java>
- this.nodeTime = ((values[TIMESTAMP1] << 16) + values[TIMESTAMP2]) * 1000L; public static String mapNodeID(int nodeID) { return "" + (nodeID & 0xff) + '.' + ((nodeID >> 8) & 0xff); } public double getTemperature() { return -39.6 + 0.01 * values[TEMPERATURE]; } public double getBatteryVoltage() { return values[BATTERY_VOLTAGE] * 2 * 2.5 / 4096.0; } public double getRadioIntensity() { return values[RSSI]; } public double getLatency() { return values[LATENCY] / 32678.0; } public double getHumidity() { double v = -4.0 + 405.0 * values[HUMIDITY] / 10000.0; if(v > 100) { return 100; } return v; } public double getLight1() { return 10.0 * values[LIGHT1] / 7.0; } public double getLight2() { return 46.0 * values[LIGHT2] / 10.0; }
+this.nodeTime = ((values[TIMESTAMP1] << 16) + values[TIMESTAMP2]) * 1000L;
+public static String mapNodeID(int nodeID) {
+return "" + (nodeID & 0xff) + '.' + ((nodeID >> 8) & 0xff);
+}
+public double getTemperature() {
+return -39.6 + 0.01 * values[TEMPERATURE];
+}
+public double getBatteryVoltage() {
+return values[BATTERY_VOLTAGE] * 2 * 2.5 / 4096.0;
+}
+public double getRadioIntensity() {
+return values[RSSI];
+}
+public double getLatency() {
+return values[LATENCY] / 32678.0;
+}
+public double getHumidity() {
+double v = -4.0 + 405.0 * values[HUMIDITY] / 10000.0;
+if(v > 100) {
+    return 100;
+    }
+return v;
+}
+public double getLight1() {
+return 10.0 * values[LIGHT1] / 7.0;
+}
+public double getLight2() {
+return 46.0 * values[LIGHT2] / 10.0;
+}
 </code>

WSN Wiki

User Tools

Site Tools

Differences

Page Tools