sudomesh / LoRaLayer2

Layer 2 routing protocol for LoRa connected devices

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Low Power

robgil opened this issue · comments

Hey Folks

I have been working on getting LoRaLayer2 working for the purposes of sending sensor data. I'm very excited to have a mesh solution that will have the ability to resolve the line to sight issues of other technologies. As a result, I'm trying to get my sensors to go in to deep sleep. One issue that I keep running in to is that messages that are in the buffer when it goes to sleep are not sent.

Pseudo code

void setup() {
  esp_sleep_enable_timer_wakeup(5 * 10000); //microseconds to seconds
  // Do all the other LoRaLayer2 setup
}

void loop() {
  LL2->daemon();
  // send packets blah blah sensor data blah
  // Ok, done prepping and adding packets to the buffer to send, now time for sleeping
  esp_deep_sleep_start();
}

Whenever I have esp_deep_sleep_start() set, it seems to immediately stop whatever the LL2->daemon() is doing. I'm thinking this is doing a hard stop and not letting LL2 flush the packets.

I'm thinking we need 2 things.

  • A way to check how many messages are in the packet buffer. c++ is not my first language (:laughing:), but it doesn't seem like I can access the struct to see how many packets are queued.
  • A way to flush the queue which will block until complete. This isn't as necessary as the first thing since we can just tell it to wait until its empty and not enqueue anything else.

Note, that this is specific for sensors. I'm thinking relay nodes will need to be active almost all the time, or at some sort of regular interval that both sender and receiver are both active at the same time.

Curious to hear your thoughts. I know this is outside of what LoRaLayer2 was originally designed for, but conceptually its awesome! (and can be applied to other problems)

One thing I noticed while testing is that when delay() is removed, the power usage is much higher. I'm wondering whether it might be worth having a helper that might be tuned just for sensor data.

For example

Generate sensor data
Add sensor data to packetbuffer
Start daemon
Broadcast
Find peers
flush packet buffer
sleep

@robgil I'm in full support of developing a low power mode, There is actually another individual who was working on a similar fork stored here, https://gitlab.com/thefinn93/LoRaLayer2/-/tree/sleepable. Maybe there are some useful insight in some of their commits. From what I recall they also had to fork arduino-LoRa (something to do with not resetting the LoRa chip). They actually merged their modifications to my fork (which I want to start using for this repo)

In addition to the flushing of packets which you identified, we will also need to make sure that the routing table persists between sleeps. I've believe this is mostly what @thefinn93 was working on.

And you are half correct about the ability to check how many messages are in the packet buffer. While there isn't a function written explicitly for this purpose, the packetBuffer::write() function does return the number of packets currently in the buffer being written to? Maybe this could be used?

Or maybe the packetBuffer::read() function needs to be rewritten to use the same syntax as write(), like so
int read(BufferEntry *entry),
where it takes a pointer to where you want to store the read out packet and returns the number of packets remaining in the buffer.

I'm not sure what will be the best way to ensure that all the buffer's have been flushed, I would have to think about it more deeply (or maybe I just need to sleep on it 😝 )