The goal of this project is to create a low-power wireless mesh network which can localize nodes in
3D space. Goals of the mesh network:

1. Nodes should be able to route packets amongst themselves. Nodes should not require a central hub or central server.
2. Minimize power. Nodes with limited power should be able to participate in the mesh network. Nodes may be powered using energy harvesting (e.g. indoor solar cells).
3. IPv6 based. Standard internet protocols allow interoperability both with nodes in the mesh and with devices outside the mesh.
4. Provide 3D location. Nodes should be able to measure their location and automatically configure themselves based on their location. Location services should not require central processing.

Todo

1. Tests.
2. Add NTP to nodes and border router.
3. Power optimization.
4. Encryption / Security.
5. Switch to NRF52840 and DW3000 which will help reduce power and shorten the time required for a location beacon slot (because of the 32 MHz SPI interface).
6. Live updates of data displayed in the iOS app.
7. Scripting on the nodes and on the border router. The end goal is for interactions between nodes in the mesh to be programmed in the nodes themselves. The border router needs to enable the user to set and update the various interactions between nodes.
8. Notifications
9. Location services. Some means need to be implemented to so that interactions and configurations can be linked to location. Then, nodes need some way to automatically download and configure themselves based on location. One possibility would be for all nodes in the network to store a copy of all configurations/interactions. Then, nodes simply select the appropriate configuration based on node type and location.
10. Implement IPv6 Router Advertisements directly into border-router to remove the dependency on radvd.
11. Custom url for the border-router home page.
12. https.
13. QR codes or some other printed AR tag.
14. Debug sources of error in the AR app.

Motivation

There are a number of problems with present-day smart home devices. First, present-day smart devices typically require a central hub which contains the processing for the interactions between the smart devices. Typically the hub will also require internet access to enable the smart functionality. For example, suppose one has a present-day smart light switch which is programmed to turn on a present-day smart light bulb. The switch, when activated, sends a packet to the hub which processes the packet, recognizes that the light bulb needs to be turned on, and sends a new packet to the light bulb to turn on. The problem with this approach is that the smart devices are effectively bricked if the hub loses power.

Furthermore, some present-day smart devices require an internet connection for some functionality. For example, suppose the user wants to view and change the settings on a present-day smart thermostat from their smart phone. Functionally, both the app on the smart phone and the smart thermostat itself connect to the company’s remote server even if both the phone and the thermostat are on the user’s WIFI network. This means that the thermostat is partially disabled if the company shuts down the server or if internet connectivity is lost.

The brittleness inherent in a central point of failure can be overcome by using a wireless mesh network. A mesh network allows devices to communicate with each other without the need for a central hub. In this scheme the smart switch can send a packet directly to the smart light bulb. Functionality is not lost if the hub loses power or if the internet goes down. In essence, the hub becomes just a dumb portal to the internet.

The second problem is that present-day smart devices require some form of pairing procedure to join the network, which is a degradation of user experience. Compare:

1. The user needs to replace a dumb light bulb in the kitchen. The user goes to the store, buys a new light bulb and screws it in. The light bulb just works.

2. The user needs to replace a smart light bulb in the kitchen. The user goes to the store, buys a new light bulb and screws it in. The user then needs to identify the light bulb to the central hub and program the interactions for the smart bulb. A location-based wireless mesh network can solve this problem. Smart devices could configure themselves based on their 3D location. Consider the following:

3. The user needs to replace a location-based smart light bulb in the kitchen. The user goes to the store, buys a new light bulb, and screws it in. The light bulb performs the localization procedure and determines that it is located in the kitchen. The light bulb then downloads the relevant interactions for a light bulb in the kitchen.
   The benefits of this mesh network are many. First, it allows rich interactions. Any smart switch can be reprogrammed to control light bulbs, outlets, appliances, etc. With existing infrastructure, the user would need to rewire a room in order to put in another switch. However, with smart switches, the user could put in a 3-way or 4-way switch with no extra cost except for the cost of the switch itself and the time required to program the new interaction in the switch.

Introduction

This project consists of the following elements:

1. border-router: Software running on a Raspberry Pi. The border router acts as a bridge between nodes in the UWB mesh and computers in the user’s LAN or WIFI network. The border router also runs a web server so that the user can monitor and interact nodes in the network.
   
2. hypertun: Linux TUN device which bridges the border-router and mesh-root.
3. mesh-root: Firmware running on the device that is connected to the border router. There is no theoretical difference between mesh-root and mesh-beacon, but for development mesh-root enables the slave SPI interface while mesh-beacon doesn’t. The board is a Decawave MDEK1001 UWB development boards. Note: SPI was used instead of UART because there wasn’t a free UART from the MDEK1001 dev kit. I wanted to use the UART from the dev kit to output serial logs to the development computer. The SPI slave is incredibly simple and only transmits/receives IPv6 packets as an array of bytes (no registers to read to and write from. If data needs to be requested from the mesh-root, it needs to be done through IP networking). One downside to the NRF52832 is that the SPI interface is limited to transfers of a maximum of 255 bytes. This means that packets larger than this amount will not be transmitted/received correctly. I intentionally have not fixed this issue as I will switch to the NRF52840 at some point which does not have this limitation.
4. mesh-beacon: Firmware running on devices deployed in the mesh. This firmware allows nodes to become location beacons. The board is a Decawave MDEK1001.
5. mesh-nonbeacon: Exactly the same as mesh-beacon except that location beacons are disabled; mesh-nonbeacon will only perform TDOA.
6. app-ios: App running on a user’s iPhone. The app utilizes Apple’s RealityKit to scan and upload the user’s home to the border-router. The app also initially calibrates the nodes’ reported location to their actual location in the home. Finally, the app overlays nodes’ information in the virtual scene (WIP).

Topics

1. Wireless Connectivity describes how nodes communicate.
2. 3D Location describes how nodes cooperate to measure their location.
3. Mesh Routing describes how packets are routed in the mesh network.
4. Error Handling

Getting Started

Development was done using the Decawave MDEK1001 dev kit and a Raspberry Pi. When setting up a new board, first build and flash the bootloader with CONFIG_BOOT_SIGNATURE_TYPE_ED25519=y (this is automated when starting the “Launch bootloader” Run and Debug task in vscode). Then, the signed hex firmware can be flashed to the board (flashing the hex file does not erase the bootloader). The build tasks and debug tasks in vscode take care of setting up a terminal’s environment, building the firmware, and then signing the firmware (see build-and-sign.cmd). As a custom step for signing firmware, I append an MCUBoot TLV header that describes the manufacturer, board, and firmware version. This “manuf,board,fwver” string is generated by fw_version.h. As part of the signing stage of the build script, fw_version.cmd extracts the “manuf,board,fwver” string from fw_version.h and passes this string to west sign. For now, the private key is the default ED25519 key distributed by mcuboot.

When starting up the system from scratch, I first ssh into the Raspberry Pi and set up a tun device and start radvd (see Setup radvd for creating a tun device and starting radvd).

Next, I start debugging border-router. In a web browser, I navigate to http://raspberrypi.local:5000/ to verify that the web page is up.

Then, I start debugging mesh-root and the mesh-beacon. One MDEK1001 has a header soldered to it and sits atop a Raspberry Pi. This MDEK1001 hat has the mesh-root firmware flashed to it and acts as a bridge between the mesh network and the Raspberry Pi. The Raspberry Pi communicates with the mesh-root, and the rest of the network, using hypertun, a tun device integrated with the border-router software running on the Pi, which has an IPv6 subnet assigned to it (see Setup radvd below).

IPv6 Router Advertisements need to be manually sent from the Raspberry Pi over hypertun so that the mesh-root can learn the mesh’s IPv6 prefix. The mesh-root and mesh-beacons will randomly send advertisements as well so that joining nodes can learn the network’s prefix. IPv6 addresses in the mesh are currently assumed to be unique. Currently no Duplicate Address Detection is performed. The nodes’ IPv6 address is assigned directly from the NRF52832 DEVICEID register, which is also used as the link-layer address for IEEE 802.15.4.

In my test network I have 6 beacons: 1 beacon attached to the Raspberry Pi as the mesh-root, and 5 other mesh-beacon