Sensebender Micro
-
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?
-
@ximinez and you are certain you have no local changes to the code? Jenkins builds both master and development branches every night for both the SenseBender and the uno and it builds all examples, including the personalizer without issues.
-
If memory serves me, some of the errors you get seem to originate from code on development branch. The eeprom addresses are to my knowledge not yet available on master.
