Sensebender Micro
-
A general question regarding these types of boards that are generally designed to be used on battery power. Is there a reason to not power the ATSH204A and Si7021 from AVR pins? The pins can source far more than what these devices can sink (even when using the heating on the Si7021), and it would allow squeezing a tiny bit more out of the battery life by selectively powering down the devices.
Eg., if I'm not using the ATSHA204A at all, I can save 150nA continuous current. The power saving from disabling the Si7021 is less at about 60nA, so that might just be eaten up by having to wait up to 80ms before a full conversion.I'm aware that we're talking about saving a tiny ~200nA here, but over the span of two years that adds up to about 350mAh.
So what I'm wondering is simply, is there a technical reason saying that this really isn't a Good Idea (tm)? Should I avoid doing so if I design my own similar device?
@ximinez said:
A general question regarding these types of boards that are generally designed to be used on battery power. Is there a reason to not power the ATSH204A and Si7021 from AVR pins? The pins can source far more than what these devices can sink (even when using the heating on the Si7021), and it would allow squeezing a tiny bit more out of the battery life by selectively powering down the devices.
Eg., if I'm not using the ATSHA204A at all, I can save 150nA continuous current. The power saving from disabling the Si7021 is less at about 60nA, so that might just be eaten up by having to wait up to 80ms before a full conversion.I'm aware that we're talking about saving a tiny ~200nA here, but over the span of two years that adds up to about 350mAh.
So what I'm wondering is simply, is there a technical reason saying that this really isn't a Good Idea (tm)? Should I avoid doing so if I design my own similar device?
I second that question. I was just thinking about a similar idea.
-
A general question regarding these types of boards that are generally designed to be used on battery power. Is there a reason to not power the ATSH204A and Si7021 from AVR pins? The pins can source far more than what these devices can sink (even when using the heating on the Si7021), and it would allow squeezing a tiny bit more out of the battery life by selectively powering down the devices.
Eg., if I'm not using the ATSHA204A at all, I can save 150nA continuous current. The power saving from disabling the Si7021 is less at about 60nA, so that might just be eaten up by having to wait up to 80ms before a full conversion.I'm aware that we're talking about saving a tiny ~200nA here, but over the span of two years that adds up to about 350mAh.
So what I'm wondering is simply, is there a technical reason saying that this really isn't a Good Idea (tm)? Should I avoid doing so if I design my own similar device?
That is indeed a good question. The straight answer is that I didn't think about that when I designed the board.
In theory you could also power the radio from a digital pin on the avr, and power that down completely.
BTW. If you turn on the heating element in the si7021 at full power, I think the power drain exceeds what the avr can deliver on a digital pin. But one could just avoid that.
-
I have been thinking about this as well. But I discarded parts of the idea because I needed the IO for other stuff (MYSX in my case). Instead I designed a switched rail where one could attach sensor power sinks. It's not io powered but it is io controlled.
Though I did not attach the si or atsha to this switch function as I decided to make it an optional feature but wanted to make sure authentication and temp/hum would always be available. -
That is indeed a good question. The straight answer is that I didn't think about that when I designed the board.
In theory you could also power the radio from a digital pin on the avr, and power that down completely.
BTW. If you turn on the heating element in the si7021 at full power, I think the power drain exceeds what the avr can deliver on a digital pin. But one could just avoid that.
That is indeed a good question. The straight answer is that I didn't think about that when I designed the board.
Oh, I thought it was a design decision :)
In theory you could also power the radio from a digital pin on the avr, and power that down completely.
I've been wondering about the radio in particular. Does the radio keep any state locally, and will it have to be reinitialized upon powerup?
BTW. If you turn on the heating element in the si7021 at full power, I think the power drain exceeds what the avr can deliver on a digital pin. But one could just avoid that.
The heating element eats a measly 3.1mA according to the datasheet, so even that would be well within the limits for a single in on a 328p.
Now, I don't have Eagle installed on this laptop, and my bandwidth is limited right now. Is there a picture of the PCB traces available? Wondering if atleast some of this can be hacked on by cutting traces.
-
Nope, there are only the eagle design files.. (Or gerbers, you could use a gerber viewer)
I have 4 sensors operating for almost a year on two AA batteries, they all report around 73% battery left. So in my opinion, it's not that necessary to do extra optimization on the power drain..
-
Nope, there are only the eagle design files.. (Or gerbers, you could use a gerber viewer)
I have 4 sensors operating for almost a year on two AA batteries, they all report around 73% battery left. So in my opinion, it's not that necessary to do extra optimization on the power drain..
@tbowmo
While 73% after one year is good, it doesn't mean that it can't get better. The ATSHA204a and Si7021 draw about 350mAh from the battery over two years from idling alone. The NRF24L01+ draws around 1500mAh.
Remember, you will never get close to emptying out the battery before the voltage drops below working voltage. Using alkaline batteries, you'll get around 2000mAh before the batteries reach 2v (which, if you're using battery voltage as a pure percentage, is 66%), at which point the voltage curve drops sharply - and your sensors die. The radio and sensors have drawn more than 900mAh from your battery during the year you have run the device (and that's just idling) - close to half your battery life.Assuming your battery percentage is correct, and you started at 100% one year ago, I'm betting your sensors will die sometime during this summer. While you may think that extra optimization isn't worth it, I do. The nanoAmp draws may not seem like much, but drawn out on a timescale like this, it is a major power draw.
-
@tbowmo
While 73% after one year is good, it doesn't mean that it can't get better. The ATSHA204a and Si7021 draw about 350mAh from the battery over two years from idling alone. The NRF24L01+ draws around 1500mAh.
Remember, you will never get close to emptying out the battery before the voltage drops below working voltage. Using alkaline batteries, you'll get around 2000mAh before the batteries reach 2v (which, if you're using battery voltage as a pure percentage, is 66%), at which point the voltage curve drops sharply - and your sensors die. The radio and sensors have drawn more than 900mAh from your battery during the year you have run the device (and that's just idling) - close to half your battery life.Assuming your battery percentage is correct, and you started at 100% one year ago, I'm betting your sensors will die sometime during this summer. While you may think that extra optimization isn't worth it, I do. The nanoAmp draws may not seem like much, but drawn out on a timescale like this, it is a major power draw.
@ximinez That depend on how you define battery percentage. I have chosen to adjust my measurements to let 0% mean when voltage drops below the highest requirements of the onboard devices. Since that particular device will fail when voltage goes lower, it serves no purpose to provide a false battery percentage. 0% is when the node no longer operates according to specs. But this is of course hw/sketch-dependent.
Do you feel secure today? No? Start requiring some signatures and feel better tomorrow ;)
-
@ximinez That depend on how you define battery percentage. I have chosen to adjust my measurements to let 0% mean when voltage drops below the highest requirements of the onboard devices. Since that particular device will fail when voltage goes lower, it serves no purpose to provide a false battery percentage. 0% is when the node no longer operates according to specs. But this is of course hw/sketch-dependent.
@Anticimex The point still stands however. The discharge graph is far from linear, and your sensors and radio have already drawn close to half of your battery life by idling alone. A colleague of mine has had to replace the batteries in his two sensors already.
-
@Anticimex The point still stands however. The discharge graph is far from linear, and your sensors and radio have already drawn close to half of your battery life by idling alone. A colleague of mine has had to replace the batteries in his two sensors already.
-
-
@Anticimex Ah, yes. sed /your/@tbowmo's/g. I blame lack of caffeine.
@ximinez makes sense. I'm sure you can cut down on power consumption by cutting power to those peripherals. I do not know how signing would be affected by this though, as I have not tested it with switching the atsha on and off between calls. I would like to hear from you on that topic if you choose to try it though :)
Do you feel secure today? No? Start requiring some signatures and feel better tomorrow ;)
-
@ximinez makes sense. I'm sure you can cut down on power consumption by cutting power to those peripherals. I do not know how signing would be affected by this though, as I have not tested it with switching the atsha on and off between calls. I would like to hear from you on that topic if you choose to try it though :)
Ok, I've been looking at the image and my spare sensor. It looks like:
Power to the NRF can be cut between C3 and VCC pin.
ATSHA204a power can be cut on the trace that goes from the atsha and beneath the flash.
Si7021 power can be cut at the trace that goes from C4.I just might have to dig out my scalpel and iron for this. If the components magically work without any extra initialization on powerup, modifying the code looks easy.
I'll report back with my findings
-
Well that went south pretty fast. Was wondering why my sensebender was acting up. Took a while to see that I had plugged in an ESP8266 module instead of one of my NRF24 modules. Those modules look far too much alike :rage:
Serial output now looks like this: "Sånsebåndåò Micro FW 1.3" with random characters corrupted. I think I've killed it ;)
I can still flash firmware to it via serial, so it's not completely dead.I can however confirm that both the SHA204A and SI7021 self-tests OK being powered on in-sketch:
(Flash seems to randomly fail or test OK, not sure why yet)þSånseâånder Micòo F× 1.3 - TesôÍoäe
Tåstiîg påòipheraló!
-> ÓÉ7021 : ok!
-> Æìasè : æailed!
-> SÈA204 : Ïk (seòéal : 01234ÂBAÅ259E8AÄÅE)
Tåót fiîésheä
----> Óelftest æaiìåä! -
Well that went south pretty fast. Was wondering why my sensebender was acting up. Took a while to see that I had plugged in an ESP8266 module instead of one of my NRF24 modules. Those modules look far too much alike :rage:
Serial output now looks like this: "Sånsebåndåò Micro FW 1.3" with random characters corrupted. I think I've killed it ;)
I can still flash firmware to it via serial, so it's not completely dead.I can however confirm that both the SHA204A and SI7021 self-tests OK being powered on in-sketch:
(Flash seems to randomly fail or test OK, not sure why yet)þSånseâånder Micòo F× 1.3 - TesôÍoäe
Tåstiîg påòipheraló!
-> ÓÉ7021 : ok!
-> Æìasè : æailed!
-> SÈA204 : Ïk (seòéal : 01234ÂBAÅ259E8AÄÅE)
Tåót fiîésheä
----> Óelftest æaiìåä!@ximinez If possible, try to check if signing and verification of signatures work as well. I have tried to implement the use of the ATSHA to be atomic in nature, but it could be that some state is retained which is cleared on power down which might break the calculations.
-
What is the easiest and fastest way to sign and verify? I don't have a gateway set up quite yet.
(And, is any part of setting this up dependent on serial integrity? If so I might have to adjust baud quite a bit) -
Yes, you have to personalize it. What is failing? I don't have an Uno myself, but according to Jenkins the personalizer compiles ok for Uno on both master and development. You don't have any local changes?
-
The personalization fails to compile for my sensebender micro. There's a few undeclared:
Personalizer:225: error: 'EEPROM_SIGNING_SOFT_HMAC_KEY_ADDRESS' was not declared in this scope
Personalizer:225: error: 'hwReadConfigBlock' was not declared in this scope
Personalizer:236: error: 'EEPROM_SIGNING_SOFT_SERIAL_ADDRESS' was not declared in this scope
Personalizer:247: error: 'EEPROM_RF_ENCRYPTION_AES_KEY_ADDRESS' was not declared in this scope
Personalizer:697: error: 'hwMillis' was not declared in this scopeI'm trying to compile this against master however. Do I have to have dev branch to compile that sketch?
