-
Notifications
You must be signed in to change notification settings - Fork 17
Using
Navigation: Home | Scenarios | Installing | Using | Future
First, get your system and your nodes set up.
Edit Makefile.avr-zigduino, and change the default avrdude port to match your local settings. This only needs to be done once ever.
AVRDUDE_PORT ?= /dev/tty.usbserial-A4009YFR
Each node needs a unique MAC address. The avr-zigduino platform expects to find the MAC address as the first 8 bytes in EEPROM.
There is a special program just to program the MAC address. It uses the same first 7 bytes, and lets you choose a different number for the last. From this point forward, we will refer to that last digit of the MAC address as the "Node number".
$ cd tools/set-eeprom $ make NODE=3 AVRDUDE_PORT=/dev/ttyUSB0
Second, make sure everything is working.
$ cd tests/hello-world $ make upload $ make login
Working correctly, you should see this:
connecting to /dev/ttyUSB0 (57600) [OK] Power-on reset. External reset! *******Booting Contiki 2.5******* MAC address 2:11:22:ff:fe:33:44:3 nullmac sicslowmac, channel 26 IP addresses [4 max] fdfd::3 fe80::11:22ff:fe33:4403 Hello, world
Now that we know the node itself is working and printing OK, we want to make sure two nodes can talk. The best way to do this is with a ping.
This requires two nodes. If you already have hello-world on one node, the easiest thing to do is to put ping-ipv6 on a second node, and ping the other. So for this example, say we already have hello-world working on node 3 on /dev/ttyUSB0.
$ cd tests/ping-ipv6 $ make upload AVRDUDE_PORT=/dev/ttyUSB1 NODE=3 $ make login AVRDUDE_PORT=/dev/ttyUSB1
Working correctly, you will see this:
connecting to /dev/ttyUSB1 (57600) [OK] Power-on reset. External reset! *******Booting Contiki 2.5******* MAC address 2:11:22:ff:fe:33:44:1 nullmac sicslowmac, channel 26 In Process PING6 Wait for DAD IP addresses [4 max] fdfd::1 fe80::11:22ff:fe33:4401 Sending Echo Request to fdfd:0000:0000:0000:0000:0000:0000:0003 from fdfd:0000:0000:0000:0000:0000:0000:0001 Echo reply received. Sending Echo Request to fdfd:0000:0000:0000:0000:0000:0000:0003 from fdfd:0000:0000:0000:0000:0000:0000:0001 Echo reply received. Sending Echo Request to fdfd:0000:0000:0000:0000:0000:0000:0003 from fdfd:0000:0000:0000:0000:0000:0000:0001 Echo reply received. Sending Echo Request to fdfd:0000:0000:0000:0000:0000:0000:0003 from fdfd:0000:0000:0000:0000:0000:0000:0001 Echo reply received. Sending Echo Request to fdfd:0000:0000:0000:0000:0000:0000:0003 from fdfd:0000:0000:0000:0000:0000:0000:0001 Echo reply received. END PING6
Finally, we will want to be sure that two nodes can exchange real application data between them. We can do so with the UDP client/server test. Again, this requires two nodes. One node contains the server program, the other contains the client. When making the client, we need to tell it where to find the server.
$ cd tests/udp-ipv6 $ make udp-server.avr-zigduino.u AVRDUDE_PORT=/dev/ttyUSB0 $ make udp-client.avr-zigduino.u AVRDUDE_PORT=/dev/ttyUSB1 NODE=3 $ make login AVRDUDE_PORT=/dev/ttyUSB0
Working correctly, you'll see something like the following. The exact numbers will depend on the timing of when you do the 'make login'.
connecting to /dev/ttyUSB0 (57600) [OK] Power-on reset. External reset! *******Booting Contiki 2.5******* MAC address 2:11:22:ff:fe:33:44:3 nullmac sicslowmac, channel 26 IP addresses [4 max] fdfd::3 fe80::11:22ff:fe33:4403 UDP server started Server IPv6 addresses: fdfd::3 fe80::11:22ff:fe33:4403 +READY Server received: 'Hello 2 from the client' from fdfd::1 Responding with message: Hello from the server! (1) Server received: 'Hello 3 from the client' from fdfd::1 Responding with message: Hello from the server! (2) Server received: 'Hello 4 from the client' from fdfd::1 Responding with message: Hello from the server! (3) Server received: 'Hello 5 from the client' from fdfd::1 Responding with message: Hello from the server! (4) Server received: 'Hello 6 from the client' from fdfd::1 Responding with message: Hello from the server! (5) Server received: 'Hello 7 from the client' from fdfd::1 +OK PASS
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.
$ cd tests/shell $ make upload $ make login
If successful, you'll see this:
connecting to /dev/ttyUSB1 (57600) [OK] Power-on reset. External reset! *******Booting Contiki 2.5******* MAC address 2:11:22:ff:fe:33:44:1 nullmac sicslowmac, channel 26 Contiki command shell Type '?' and return for help 2.17: Contiki> IP addresses [4 max] fdfd::1 fe80::11:22ff:fe33:4401
Now, try some of the commands, like 'help':
Available commands: ?: shows this help binprint: print binary data in decimal format blink [num]: blink LEDs ([num] times) echo <text>: print <text> exit: exit shell hd: print binary data in hexadecimal format help: shows this help kill <command>: stop a specific command killall: stop all running commands netstat: show UDP and TCP connections null: discard input ping <host>: ping an IP host ps: list all running processes quit: exit shell randwait <maxtime> <command>: wait for a random time before running a command repeat <num> <time> <command>: run a command every <time> seconds size: print the size of the input time [seconds]: output time in binary format, or set time in seconds since 1970 timestamp: prepend a timestamp to data 2.17: Contiki>
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.
Then type "kill blink" when you're done admiring your blinking lights.
We can also ping from within the shell!
2.17: Contiki> ping fdfd::3 SEND 13 bytes ping fdfd::3 Sending Echo Request to fdfd:0000:0000:0000:0000:0000:0000:0003 from fdfd:0000:0000:0000:0000:0000:0000:0001 Other ICMP6 message received. Echo reply received.
The most common thing to do with a sensor network is collect data, so that's just what we'll do. This first test is based on the rpl-collect example, but it should be noted that no actual RPL is being used. For now this can be thought of as "ipv6 collect".
This test needs to know which node is the 'sink', that is the node which is doing the collection. The sink node should get the udp-sink image, and the senders (all the other nodes) need the udp-sender image.
$ cd tests/rpl-collect $ make NODE=3 $ make udp.sink.avr-zigduino.u AVRDUDE_PORT=/dev/ttyUSB0 $ make udp.sender.avr-zigduino.u AVRDUDE_PORT=/dev/ttyUSB1 $ make login AVRDUDE_PORT=/dev/ttyUSB0
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 Node #1.
connecting to /dev/ttyUSB0 (57600) [OK] Power-on reset. External reset! *******Booting Contiki 2.5******* MAC address 2:11:22:ff:fe:33:44:3 nullmac sicslowmac, channel 26 I am sink! IP addresses [4 max] fdfd::3 fe80::11:22ff:fe33:4403 UDP server started Server IPv6 addresses: :: :: fdfd::3 fe80::11:22ff:fe33:4403 Created a server connection with remote address :: local/remote port 5688/8775 30 00000000 00000001 0 01 011 1 0 22 14622 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 30 00000000 00000007 0 01 012 1 0 22 15414 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 30 00000000 00000023 0 01 013 1 0 22 17311 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 30 00000000 00000024 0 01 014 1 0 22 17529 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 30 00000000 00000039 0 01 015 1 0 22 19330 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 30 00000000 00000052 0 01 016 1 0 22 21032 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 30 00000000 00000060 0 01 017 1 0 22 21934 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 30 00000000 00000067 0 01 018 1 0 22 22828 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
Contiki has a cool app to view sensor data being collected. I made a few modifications for Zigduino, so you'll have to build it anew.
$ cd ~/contiki/tools/collect-view $ ant $ cd dist $ java -jar collect-view.jar
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.
Next: Future. What's coming next.