Category: Arden’s Status Reports

This week I worked on the RX/TX schedule distribution phase of the protocol stack. Once the gateway router has a complete view of the sensor network topology (i.e after the LSA phase is complete), it calculates a node transmission schedule based on this topology. At the moment, the gateway is being run on an STM32, so an objective for next week is to port the code over from the STM to the RPI, using an external UART library to interface with the LoRa transceivers. Once the gateway router has calculated the schedule, it iteratively sends the schedule out to its children. Unfortunately, due to materials constraints, we have only been able to test these three out of four protocol phases on a network of 4 nodes, and more complications may arise when testing with 8 nodes. We are slightly behind schedule, and using slack-time. For this next week, I will work on:

• implementing ACKs for the schedule distribution phase of the routing protocol, in order to avoid packet collisions (which will arise in an 8-node topology)
• porting the code for the GW node from the STM32 platform to the RPI

Two out of four  protocols on the networking stack have been successfully implemented, and were demonstrated on Monday. Furthermore, I changed the packet format (we were using inefficient strings to encode packet information before), therefore increasing the scalability of the code substantially. We are slightly behind schedule, as I had expected to have written the RX/TX schedule last week after the demo on Monday. Nevertheless, I am now much more confident in the robustness of the code, and am sure that we will be able to accomplish at least the schedule-distribution phase of the protocol at the end of next week. I have also been working on making the network robust to node failure: essentially detecting if neighboring nodes are unresponsive during the STP phase (phase 1) of the protocol, and ignoring these nodes during the LSA phase (phase 2). Right now, the gateway node is informed of the overall topology. We have split up the work of the next phase into three items:

• Creating the schedule based on the WSN tree-topology (via an adjacency list). 
• Distributing the schedule to all nodes across the spanning tree
• Synchronizing nodes using a pre-computed fixed delay

We plan on accomplishing these three items in the coming week, after which we will be much more on track (as according to our Gantt chart).

This week I worked on implementing the spanning tree protocol and the link state advertisement protocol. These comprise the first and second phase of the overall routing protocol, and are run every 15minutes in order to detect node failures. In our preliminary tests, we tested two four-node topologies: a line topology and a fully-connected topology. After running STP, the line topology did not change, and the fully-connected topology was reduced to a star topology centered at the gateway node (address 1). The image below shows 4 nodes running the spanning tree protocol (one of the nodes is transmitting). Once a tree has been created, link state requests are sent from the gateway node to each of its neighbors iteratively, however link-state aggregation has not yet been implemented or tested. I am now closer to the initial schedule, and next week I will be testing more topologies with more nodes and will work on the sensor-node scheduler.

This week I established a communication channel between two nodes. This was a multi-step process involving programming the nodes to use UART communication from the MCU to the LoRa transceiver. Unfortunately two of our transceivers were broken, and will have to be replaced before we can conduct a test of our 8 node and gateway topology. My progress is slightly behind schedule, however, now that nodes can send and receive data the development of the STP and LSA protocols can begin. I plan on getting a topology of 3 or four nodes either establishing a tree topology or gathering link-state and sending it to the gateway. I will be working with Ankita to develop the border gateway side of the routing algorithms.

This week I focused on calculating the power consumption for the design presentation. I used Semtek’s LoRa calculator to estimate the current draw of running the routing algorithm. After getting some feedback on the previous TX-schedule distribution algorithm, we decided to pivot to another approach which was both more power efficient and took less time to run. The final numbers calculated for the design presentation considered primarily a 30min sensor sampling rate, and tree-reforming period. I also spent some time working on the design document, consolidating the various aspects of the routing algorithm, and parsing through essential details. Next week I will begin developing the TDM STP protocol on the dev boards themselves, and will finalize the design document.

This week I focused on narrowing down the design of the wireless sensor network. After having spoken to Prof. Mukherjee, we pivoted to a time-division multiplexing approach rather than an asynchronous medium access control method to optimize power consumption even further. Furthermore, to reduce maintenance cost, we want our network to be resilient to link failures (e.g. if multipath effects caused by inclement weather degrades the quality of the channel between two nodes). Since a forest fire is not a frequent occurrence, and since the time before spreading to an open fire is 60 minutes, we would like to detect node failures (or critical link failure) within a timeframe of 15-30 minutes of the actual event. After having read a paper on TDM MAC for wireless sensor networks by Koutsonikolas and Salonidis, I decided to base our forest fire WSN’s MAC algorithm off their approach. Now, we have a good method for ensuring that sensor data can be transmitted and forwarded across the network from any node in the mesh network to the gateway. The clock synchronization method described in the paper enables each node to correct their clock drift in regular intervals, and to match up to a global transmission and reception schedule. I also soldered pin headers to the gas sensor and plan to test whether it can detect a match being lit next to it by interfacing it with an STM32 via SPI by Monday.

Due to the pivot to a new project idea, we have only had a few days to plan out the design of this new idea: WSN for early wildfire detection. Nevertheless, I have been researching medium-access protocols that we could use to minimize power in the WSN. The most promising one would be an asynchronous B-MAC protocol where the sender would have some notion of the designated receiver’s wakeup period, allowing it to send a much slower preamble. The preamble would ensure that the receiver and the transmitter are in the “awake” state before the actual sensor data is sent. However, this would mean that the sensor node cannot be fully turned off during the off state, as it would still need to receive the preamble. Fortunately, the STM32 has a low-power mode where UART is still enabled, so the board could still receive data from the LoRa transceiver in this lower power state. Conversely, we could implement a synchronous MAC protocol (much like TDMA) which would allow the STM32 to go into an even lower power state mode, but this requires regular beacons to account for RTC clock drift among the sensor nodes, which sounds much trickier to implement. I do believe we are behind because we chose an idea so late, but I believe we can catchup promptly by the end of next week with other teams. My goal is to get LoRa communication up and running between a pair of STM nodes, and finalize the MAC protocol design.