Doomtenna Update

The Doomtenna has been on the roof of our office for about two months now, so it is time for an update!

We’ve had a change of Heart

For solar-powered devices, the use of an nRF52-based device is preferred over an ESP32-based device, as this would give a 90-95% reduction in power consumption. Therefore, we changed the heart of the Doomtenna from a LILYGO® TTGO T-Beam to a RAK5005-O + RAK4631-based setup. As an additional benefit, the RAK5005-O board includes a solar charging controller.

Solar Panel Performance

The device was configured to report battery levels twice a day (around 6 AM and 6 PM). The plot of the battery level clearly shows that the current solar panel provides insufficient power to keep the battery charged.
After the device runs out of power and gets charged again, the device starts running, but it seems to lose some crucial configuration (radio region/frequency).
So, after the 6th day, the device needed reconfiguration to continue functioning.

Plotting Signal Strength

Our earlier connectivity experiment was performed by hand and could only be performed on safe parking locations. Now, we have automated the process. Two devices have been configured to relay all broadcast packets that they receive, and the Signal-to-noise- ratio (SNR) of the signal reception, to MQTT. A script running in the cloud stores all these packets in an ElasticSearch cluster, using Kibana we can easily visualize the received information.

A simple query aggregates (median) the SNR values of received position information packets per geographical area. The following two plots show the result of these queries around the office and my home (many more data points).

Position Broadcast Tweaks

By default, Meshtastic sends very few position updates. This is good behaviour for the intended purpose, it saves battery power and airtime (percentage of available time a radio channel that is used for transmissions). If we want to have much more data points for our signal strength plot, we would like to increase the frequency of position broadcasts.

Increased Position Packet Priority

Meshtastic maintains a queue of packets that need to be transmitted. Each packet in the queue has a priority. When Meshtastic is sending packets from the queue, it only sends a packet if its priority is high enough for the current airtime of the radio channel. (When there are many transmissions on the radio channel, low priority packets are not sent but remain in the queue.) Therefore, we have tweaked the firmware to increase the priority of position packets.

Decreased Node Information Packet Frequency

Meshtastic sends (puts a position packet in the outgoing queue, possibly replacing an old packet in the queue if it was not sent yet) position packets at the same frequency as node information (user name/device type) packets. So, if we increase the frequency at which we transmit position information, we also increase the frequency at which we transmit node information, wasting airtime. Therefore, we have tweaked the firmware to send node information only every -th (configurable) position packet.

Increased position update frequency

The frequency at which the device updates its position is independent of the frequency at which the device sends its position packets. We want the position the device broadcasts to match the actual position of the device as close as possible. Therefore, we have increased the frequency at which the device updates its position from the GPS.

Future Plans

Soon, we would like to:

• add or replace a solar panel (to keep the battery charged),
• hardcode configuration in the firmware,
• perform range tests for the office’s Doomtenna,
• experiment with the new 1.3 version of Meshtastic.