Hardware Troubleshooting

Devices that are connected to a hive send basic status information as part of the heartbeat driver. This driver can be configured to send periodic messages or, for low-power or low-comms devices, in response to an event (e.g. fault, alarm, or wake-up).

Out of reset, however, there are four actions that must complete successfully before a device can reach its hive. They are:

1) Connect to a network (ethernet, wifi, cellular).
2) Configure itself on the network (static or DHCP IP addressing).
3) Query the keeper to look up its hive's location.
4) Authenticate with its hive.

Many devices do not have rich display devices on which to indicate detailed fault or error conditions in the above steps, and many applications do not support the use of locally-connected devices (such as a laptop via a USB cable) to troubleshoot hardware. It is, however, common practice to use one or more visual indicators (e.g. LEDs) to display basic status information.

All drone firmware images include a driver for a single status LED. Firmware images for supported evaluation boards are pre-configured to use one of the evaluation board's LEDs as a status indicator (and hardware designers are encouraged to include a status LED as part of any design). Out of reset the visual indicator has the following behavior during the above four steps:

1) The status LED is on out of device reset / power-up. This demonstrates that the status LED is functional.

2) After the device connects to a network (ethernet, wifi, cellular) the status light blinks on and off once per second - a "slow blink".

3) After the device configures itself on the network (e.g. has a valid IP address, netmask, and default gateway on an IP network) the status light blinks on and off five times per second - a "fast blink".

4) After the device learns the location of its hive from the keeper the status LED turns off.

5) After the device authenticates with its hive it can send status information via the heartbeat message or via any other application specific messages.

TROUBLESHOOTING

A typical device should only require a few seconds between being reset / powered-up and being connected to its hive. If a device is not connected to the hive within a few seconds, look at the status LED. If the status LED is:

ON: The device is not able to connect to the network.

For "wired" network devices, check that network cables are fully inserted and that the network equipment on the other end of the cable from the device (usually a hub, switch, or access point) is powered up. Verify that the network equipment and the device have a common network speed (e.g. 10 Mbit, 100 Mbit, or 1 Gbit) capability. Try a different network cable. Try power-cycling the network equipment.

SLOW-BLINKING (1x per second): The device is not able to configure itself for the network.

Many devices use Dynamic Host Control Protocol (DHCP) to request network configuration settings from a server on the local network. On smaller networks this may be an access point or multi-function network device. On larger networks this may be a computer server. DHCP does not use "reliable transport" type messages - on a busy or noisy network device the occasional DHCP request may get lost - though the device will retry more than once before giving up. Try restarting the device. On smaller networks it is often possible to reset ("power cycle") the network appliance providing DHCP services. On larger networks IT policies may require that new devices be registered with the server before it will provide network configuration information - seek the help of your IT staff or department.

FAST-BLINKING (5x per second): The device is not able to communicate with the keeper service in order to look up its hive location. This suggests there is a connectivity problem between the local network and the keeper servers. Verify that any other devices on your local network are able to reach sites on the broader Internet (e.g. google.com). As with DHCP services above, communication with keeper services does not use "reliable transport" type messages. On a busy or noisy network the occasional keeper request may get lost - though the device will retry more than once before giving up. Try restarting the device. By default communication with keeper services happens over "UDP port 8000". On smaller networks it is unlikely that outbound UDP port 8000 traffic is blocked by your access point or other edge-of-network devices (such as a firewall) - advanced users can check their access point or other edge-of-network devices to confirm this. On larger networks IT policies may block traffic by default and require explicit authorization before passing it - seek the help of your IT staff or department.

OFF: If the status LED is off but the device is not communicating with its hive, the device is not able to authenticate with the hive server. Check the device's status in the portal - is the device listed as an Active instance? Check the hive status in the hive's portal - is the hive online? If the device has never successfully communicated with the hive, was the device provisioned?

1.0.0
Jason Dahlstrom

Navigation