Serial gateway running on coin cells. Needs to sleep
-
@Jason-Rennie I see. Thanks for explaining.
Id 0 is reserved for the gateway. Therefore any node will refuse to initialize if the node has id 0.
From the log parser: Assigned id 0 is invalid
Use a different id.
@mfalkvidd I think both sides are attempting to ping node 0 and not getting a response. So they never get into loop()
I think I will give the lowpowerlab library a try. I've also found that I am running low on resources (RAM + program space).
I think it would be better if the mysensors gateways could establish a time schedule with their nodes to allow both sides to sleep.
Something like this... If nodes only need to talk once every minute and I have 10 nodes, then the gateway can tell each node when they should transmit. So once every minute the gateway wakes up and listens for each node to talk. 10 nodes require 10 time windows, one after another. Node 1 talks in the first time window. The 5th node wakes up and talks in the 5th time window. I hope you see what I am suggesting. This way the nodes are not trying to talk over each other and the gateway is asleep for almost the whole time window. If you want to support n retries on transmissions then the gateway needs to listen for up-to n retry attempts. Or until it has heard from all nodes.
This is overkill for me because my system has only 1 node. But its something you might find easy to implement. I'm not sure how your system is structured.
-
@mfalkvidd I think both sides are attempting to ping node 0 and not getting a response. So they never get into loop()
I think I will give the lowpowerlab library a try. I've also found that I am running low on resources (RAM + program space).
I think it would be better if the mysensors gateways could establish a time schedule with their nodes to allow both sides to sleep.
Something like this... If nodes only need to talk once every minute and I have 10 nodes, then the gateway can tell each node when they should transmit. So once every minute the gateway wakes up and listens for each node to talk. 10 nodes require 10 time windows, one after another. Node 1 talks in the first time window. The 5th node wakes up and talks in the 5th time window. I hope you see what I am suggesting. This way the nodes are not trying to talk over each other and the gateway is asleep for almost the whole time window. If you want to support n retries on transmissions then the gateway needs to listen for up-to n retry attempts. Or until it has heard from all nodes.
This is overkill for me because my system has only 1 node. But its something you might find easy to implement. I'm not sure how your system is structured.
@Jason-Rennie said in Serial gateway running on coin cells. Needs to sleep:
I think it would be better if the mysensors gateways could establish a time schedule with their nodes to allow both sides to sleep.
This is overkill for me because my system has only 1 node. But its something you might find easy to implement. I'm not sure how your system is structured.
I started to take a look at this a while ago (I wanted to try freq hop etc), but it was just tests and unfinished work, too busy to get back on this even if it's very interesting and challenge to do.. I think you don't get the implications of this. Of course it's "easy" to imagine timeslots :)
for a few nodes, it's not really hard, but for a whole network there are lot of things to take care.
- hardware: this needs precise clock on all devices. That's something most of MySensors users do not have, for example some use unprecise internal rtc (just an example about hw). If no precise clock, then when using lot of nodes, there will be drift in time, packets collision etc and packet delivery will become unreliable, unresponsive network.
- software. retrocompatibility is just another example. also using a better mcu (than 328p) + rtos can help managing stuff.
- etc
without retrocompatibility in mind, and by starting from scratch, it's for sure "easier" but you might hit some rocks as network grows. And, still, you will need to sync your nodes, even more important if not using a precise clock, as the wider the listening timeslot is, the more energy you'll use.
MySensors archi is gw/concentrator always ON (like many others commercial stacks though), only ONE channel communication, where availability of channel is checked with CSMA+random time+retries for preventing collisions.
there are lot of researchs about different methods like TDMA etc on internet, you'll see it's not that easy if you want more than just a few nodes ;)
-
@Jason-Rennie said in Serial gateway running on coin cells. Needs to sleep:
I think it would be better if the mysensors gateways could establish a time schedule with their nodes to allow both sides to sleep.
This is overkill for me because my system has only 1 node. But its something you might find easy to implement. I'm not sure how your system is structured.
I started to take a look at this a while ago (I wanted to try freq hop etc), but it was just tests and unfinished work, too busy to get back on this even if it's very interesting and challenge to do.. I think you don't get the implications of this. Of course it's "easy" to imagine timeslots :)
for a few nodes, it's not really hard, but for a whole network there are lot of things to take care.
- hardware: this needs precise clock on all devices. That's something most of MySensors users do not have, for example some use unprecise internal rtc (just an example about hw). If no precise clock, then when using lot of nodes, there will be drift in time, packets collision etc and packet delivery will become unreliable, unresponsive network.
- software. retrocompatibility is just another example. also using a better mcu (than 328p) + rtos can help managing stuff.
- etc
without retrocompatibility in mind, and by starting from scratch, it's for sure "easier" but you might hit some rocks as network grows. And, still, you will need to sync your nodes, even more important if not using a precise clock, as the wider the listening timeslot is, the more energy you'll use.
MySensors archi is gw/concentrator always ON (like many others commercial stacks though), only ONE channel communication, where availability of channel is checked with CSMA+random time+retries for preventing collisions.
there are lot of researchs about different methods like TDMA etc on internet, you'll see it's not that easy if you want more than just a few nodes ;)
@scalz I appreciate what you are saying. It was just a suggestion for an implementation since I will need something akin to this.
-
@Jason-Rennie maybe if you give us more info on your usecase/project archi, we could help you. I think a sleeping gw is not very common.
-
@Jason-Rennie maybe if you give us more info on your usecase/project archi, we could help you. I think a sleeping gw is not very common.
@scalz Its a watch sized receiver taking signals from a transmitter.
The transmitter is sealed in a protective silicone blob and the watch is preferably coin cell powered to avoid the need for a MSDS/SDS for shipping lithium batteries. The whole thing needs to pass FCC for sale in the US and it has to meet EU RED regulations to sell in Europe.
The transmitter only needs to send a signal to assure the watch that it is in range. Once every 2 minutes is fine. It should send an alert signal when an alert condition is detected by it's sensors.
There's normally only 1 or maybe 2 senders and 1 or maybe 2 receivers.
-
@Jason-Rennie unfortunately as you guessed MySensors is not really tailored for this task, so
as you don't have lot of nodes involved, perhaps it's easier to start your sw from scratch with a more simple lib+rtc, or some true mesh framework with low power capabilities if there is one available (MySensors is star network).
I guess BLE 5 long range+beacon doesn't fit your project??
imho, I think I would do my own sw, if it's just for 2-3 nodes, and sync them, perhaps easier for sw maintenance. For MySensors, we need to take care of a lot more usecases..
Long time ago, I tested rfm69 listenmode from lowpowerlab, maybe it can help you getting started.
cr2032 can be tricky, don't forget capa buffering, but that's another topic :) -
@Jason-Rennie unfortunately as you guessed MySensors is not really tailored for this task, so
as you don't have lot of nodes involved, perhaps it's easier to start your sw from scratch with a more simple lib+rtc, or some true mesh framework with low power capabilities if there is one available (MySensors is star network).
I guess BLE 5 long range+beacon doesn't fit your project??
imho, I think I would do my own sw, if it's just for 2-3 nodes, and sync them, perhaps easier for sw maintenance. For MySensors, we need to take care of a lot more usecases..
Long time ago, I tested rfm69 listenmode from lowpowerlab, maybe it can help you getting started.
cr2032 can be tricky, don't forget capa buffering, but that's another topic :)@scalz I tried BLE first but the sender is in close body contact and the signal from an NRF52840 was almost completely absorbed by the body. They claim upto 800m range but the truth is that indoors the range is miserable. In close body contact the range was barely 1m or zero depending on how much body it passes through. Bluetooth depends on walls to reflect signals so this is even worse outdoors.
To extend the range I made an android app that could also act as a gateway to send the live signals over wifi or mobile to Google Cloud Firestore. So any other instances of the app could see the live values. But Android and iOS are so determined to reduce battery usage that they make it very hard to maintain a Bluetooth connection. The ble connection timeout for iOS is 4 seconds for instance. Its also difficult to keep long running background tasks because the OS will stop them, it's also difficult to guarantee that Bluetooth scans are performed to reestablish connections. The whole thing would require a ton of coding to maintain.
This is why I chose the RFM69HCW.
-
@Jason-Rennie unfortunately as you guessed MySensors is not really tailored for this task, so
as you don't have lot of nodes involved, perhaps it's easier to start your sw from scratch with a more simple lib+rtc, or some true mesh framework with low power capabilities if there is one available (MySensors is star network).
I guess BLE 5 long range+beacon doesn't fit your project??
imho, I think I would do my own sw, if it's just for 2-3 nodes, and sync them, perhaps easier for sw maintenance. For MySensors, we need to take care of a lot more usecases..
Long time ago, I tested rfm69 listenmode from lowpowerlab, maybe it can help you getting started.
cr2032 can be tricky, don't forget capa buffering, but that's another topic :)@scalz said in Serial gateway running on coin cells. Needs to sleep:
capa buffering,
What is capa buffering? Google is not helping me
-
@Jason-Rennie unfortunately as you guessed MySensors is not really tailored for this task, so
as you don't have lot of nodes involved, perhaps it's easier to start your sw from scratch with a more simple lib+rtc, or some true mesh framework with low power capabilities if there is one available (MySensors is star network).
I guess BLE 5 long range+beacon doesn't fit your project??
imho, I think I would do my own sw, if it's just for 2-3 nodes, and sync them, perhaps easier for sw maintenance. For MySensors, we need to take care of a lot more usecases..
Long time ago, I tested rfm69 listenmode from lowpowerlab, maybe it can help you getting started.
cr2032 can be tricky, don't forget capa buffering, but that's another topic :)@scalz said in Serial gateway running on coin cells. Needs to sleep:
rfm69 listenmode from lowpowerlab,
listenmode. Interesting....
Unfortunately I found this comment (and linked discussion) here
https://github.com/LowPowerLab/RFM69/blob/master/RFM69.h
//Native hardware ListenMode is experimental
//It was determined to be buggy and unreliable, see https://lowpowerlab.com/forum/low-power-techniques/ultra-low-power-listening-mode-for-battery-nodes/msg20261/#msg20261
//uncomment to try ListenMode, adds ~1K to compiled size
//FYI - 10bit addressing is not supported in ListenMode
//#define RF69_LISTENMODE_ENABLE -
@scalz said in Serial gateway running on coin cells. Needs to sleep:
capa buffering,
What is capa buffering? Google is not helping me
@Jason-Rennie said in Serial gateway running on coin cells. Needs to sleep:
@scalz said in Serial gateway running on coin cells. Needs to sleep:
capa buffering,
What is capa buffering? Google is not helping me
I think he means adding capacitor(s). Cr2032 will not be able to deliver its rated capacity if more than a few mA is drawn. See https://electronics.stackexchange.com/questions/234901/lithium-coin-cell-cr2032-battery-specifications for one data point.
-
@Jason-Rennie
sure, but you didn't mention the whole thing, I also prefer subghz :)
cr2032 is limited, so without extras capacitors = possible brownouts + you won't get full lifetime because of its internal resistance (when power consumption >5ma generally) . even a short burst can reset your mcu (brownout)
like 100-300uf to handle H version of rfm modules, I usually place a few close to batt and rf module
also forget bad coincell brands, not good at all for lifetime.
for a commercial product, I wouldn't recommend to remove brownout protection, nor watchdog too, for saving power.I didn't know about listenmode. when I tried it worked, but this was experimental, never used it in prod.
-> custom fw with rtc and sync. simple :) -
@Jason-Rennie said in Serial gateway running on coin cells. Needs to sleep:
@scalz said in Serial gateway running on coin cells. Needs to sleep:
capa buffering,
What is capa buffering? Google is not helping me
I think he means adding capacitor(s). Cr2032 will not be able to deliver its rated capacity if more than a few mA is drawn. See https://electronics.stackexchange.com/questions/234901/lithium-coin-cell-cr2032-battery-specifications for one data point.
@mfalkvidd Yes, I need the right capacitors. I'm now designing boards for the watch and sender device using KiCAD based on moteino and easysensors but with a few differences.
-
@Jason-Rennie
sure, but you didn't mention the whole thing, I also prefer subghz :)
cr2032 is limited, so without extras capacitors = possible brownouts + you won't get full lifetime because of its internal resistance (when power consumption >5ma generally) . even a short burst can reset your mcu (brownout)
like 100-300uf to handle H version of rfm modules, I usually place a few close to batt and rf module
also forget bad coincell brands, not good at all for lifetime.
for a commercial product, I wouldn't recommend to remove brownout protection, nor watchdog too, for saving power.I didn't know about listenmode. when I tried it worked, but this was experimental, never used it in prod.
-> custom fw with rtc and sync. simple :)@scalz said in Serial gateway running on coin cells. Needs to sleep:
also forget bad coincell brands, not good at all for lifetime.
This is my biggest concern at the moment. With the watch device I can resort to Lipo and recharge if needed, but the sender is best encased in silicone to protect it so its crucial that I get a long reliable battery life from it. My only option there is to use inductive charging. Which might be easy but I've not looked at the details.
I would also need to do shipping safety sheets if I use lipo but I think that it's probably just an expense. Not a project risk.
