Author Topic: Both ends of a link in low power mode.  (Read 1673 times)

galah

  • NewMember
  • *
  • Posts: 9
Both ends of a link in low power mode.
« on: November 28, 2018, 07:22:07 PM »
Hi
I have recently started using a few  moteinos around the farm to monitor and control things.  I found one configuration harder than I expected.

I have a relaying moteino on the roof of the house which lets the house server log stuff. The server has a moteino-usb on it the relay logs to.  Both of those are based on Felix's 'gateway' code.   Both of those are always on. The rooftop 'relay' node has a solar cell as the house got struck by lightning earlier in the year,  so air gaps are attractive. The old wired sensors got fried.

I had a case where I wanted to automate filling a water tank. The tap is ~80m away from the house. The tank is ~160m away. Neither remote sites have power, so pure battery operation without fiddling with solar cells was attractive. So both ends mostly sleep.

I ended up modifying the relay node (always on) to allow the low power nodes to post and read an addressed byte flag, so the mostly-sleeping nodes could communicate with each other.  At least at their 8 minute sleep rate per message.   Plenty for a 'tank is nearly full' message to turn off the tap.  That seems to work well.

Sorting out how to get the sleepy node to hear a response to its question proved harder than I expected. In retrospect it seems like it would be a good library function.     I ended up implementing a loop on radio.receive_done()    bracketed by a timeout  based on millis() and flags to exit as soon as a response had been seen.   

In retrospect I suspect this is a problem that's probably been solved better prior. Anyone got any useful pointers?
   

Felix

  • Administrator
  • Hero Member
  • *****
  • Posts: 6866
  • Country: us
    • LowPowerLab
Re: Both ends of a link in low power mode.
« Reply #1 on: November 28, 2018, 08:23:54 PM »
Since native LISTEN_MODE has been found to not be stable long term (locks up), I think the best approach is either to implement a watchdog + LISTEN_MODE,
Or find a way for the 2 ends to synchronize. Using LISTEN_MODE timer for a precise waking up, can help achieve that, but I haven't done it myself, I know of others who use it very successfully.
Sorry for the vagueness, I'm hoping those folks can chime in and add more than my 1 cent here.

TomWS

  • Hero Member
  • *****
  • Posts: 1930
Re: Both ends of a link in low power mode.
« Reply #2 on: November 28, 2018, 08:44:19 PM »
Sorting out how to get the sleepy node to hear a response to its question proved harder than I expected. In retrospect it seems like it would be a good library function.     I ended up implementing a loop on radio.receive_done()    bracketed by a timeout  based on millis() and flags to exit as soon as a response had been seen.   

In retrospect I suspect this is a problem that's probably been solved better prior. Anyone got any useful pointers?
 
I think this is fairly easily addressed if your 'gateway' is able to respond immediately to the 'sleepy' node.  If this is the case, then the easiest implementation is to simply respond with a message contained in the Ack back to the 'sleepy nodes' posting.   In this case, anything you want to send to a sleepy node gets queued by the gateway and, when the gateway 'sees' the posting from the 'sleepy' node, add a message in the Ack to the posting. 

The message could be a short one byte message - "Yes, I have something for you so come back to me and request it"  or it could be the complete message itself.  I'm inclined to choose the first method because the 'thing' the gateway has for the node might be a complete code update - can't send that in an Ack response!  Once the 'sleepy node' sees that the gateway has something for it, the node can temporarily switch to a more interactive mode until the entire message is received by the node.



galah

  • NewMember
  • *
  • Posts: 9
Re: Both ends of a link in low power mode.
« Reply #3 on: November 28, 2018, 10:31:03 PM »
Thanks Tom. I wasn't aware I could add information to the ack packet.  But as I gather the ack-ness is just a set bit so seems reasonable.

Mostly I just want to send/get a byte flag - so that seems a good solution. I'll dive in to radio.sendWithRetry() and radio.sendACK() to see how to do that at each end.

And your comment about a code update certainly sheds light on how I would go about doing a SW update to a sleeping node.