pureengineering / contiki Goto Github PK

The following procedure, after successfully connecting to three Canaries this morning, was persistently unable to connect to any of the three this afternoon.

1.) Boot laptop (Ubuntu 16.04.2 LTS)
2.) Insert CC2531 Dongle into USB port
3.) Insert batteries into Canaries
4.) Open terminal on laptop
5.) Type "sudo /etc/init.d/6lbr start" into terminal
6.) Type "sudo ip tuntap add dev eth0 mode tap" into terminal
7.) Type "sudo ip -6 addr add bbbb::101 dev br0" into terminal
8.) Type "mosquitto" into terminal

When connection was successfully achieved this morning, the dongle was flashing its green LED upon completion of (8), and possibly from (5) onward. This afternoon, the dongle began flashing red on (5), stopped flashing red and flashed green three times on (6), then stopped flashing after one or two more green blips. Checking "ip link show" indicates the presence of both an eth0 and a tap0 with master br0.
Repeating the procedure this afternoon with a second dongle resulted in identical behavior (failure).

Occasionally after battery removal, canaries enter an unresponsive state in which no user action (battery insertion, RST short- or long-press, ribbon cable connection, etc.) can activate the board. This has been most frequently observed following keyboard interrupt of the mosquitto message broker immediately prior to battery removal. The only way a canary has been observed to regain function is after it has been left unpowered for 12 hours; boards from an old batch require 60 hours. We suspect a capacitor is supplying sufficient charge to hold something in working memory that prevents the board from engaging its normal startup routine.

The subscriber client script subscribe.py will occasionally reach time out and stop logging data without fatal error. This has been observed to be preceded by the LED on the CC2531 USB dongle going through the same pattern of flashes as when the network is first being established. After interrupting subscribe.py via Ctrl+C in the terminal, it fails to reconnect to the network, throwing “Error 113: No Route To Host.” Any active canaries are able to reconnect. A reboot of the computer hosting the network is necessary to reconnect subscribe.py.

I updated the canaries to the most recent firmware, and while it seems some aspects of performance have improved in that we have been able to run 8 devices taking data at a time, there is still the timeout issue we had before. I don't know if the problem is how we are setting things up or if there is still something wrong in the firmware. I uploaded my notes, the computer logs, and the sql dump from the experiment yesterday to the canary repo.