Consumption strage behavior #209
Comments
|
Hey @azgael, that battery consumption is indeed very strange. My first though is that either there is a short, or the boards are stuck in a rebooting loop, draining the battery. It's difficult to debug hardware issues from far, specially since you modified the pcb yourself from what I understood. First step would be to get some logs from the working boards and see if they tell you something. If that doesn't work, please send a picture of the the boards you soldered the components on. It's a long shot, but maybe we can spot something. |
|
Hi @rbaron from the logs i don't find anything relevant, also when i plug the debugger i end up always resting the board so any previous log is gone. the log is the following: SEGGER J-Link V7.96h - Real time terminal output seams normal So I have compiled the firmware once again with the debug log flag and reprogram it: ''' '# prstlib config - ser all options in prstlib/Kconfig. the log now is the following: ''' [00:00:00.000,488] adc: prst_adc_init: Dry coeff 1: 110000 [00:00:00.000,518] adc: prst_adc_init: Dry coeff 2: -15300 [00:00:00.000,518] adc: prst_adc_init: Wet coeff 0: 299000 [00:00:00.000,549] adc: prst_adc_init: Wet coeff 1: -83100 [00:00:00.000,579] adc: prst_adc_init: Wet coeff 2: 11200 [00:00:00.000,823] bt_sdc_hci_driver: SoftDevice Controller build revision: Regarding the soldering on the boards, please find the picture attached, looks quite clean for me.
About the redesign of the board, I have just change a bit track wide and via and component position very minor changes, i believe it does not come from there since some boards seam to work fine as a couple of the previous lot made by your design. Going back to the Logs: is there a way of enable more information besides that flag. Thanks again |
Now the logs with the refresh at 30 sec instead of 10 min :|*** Booting nRF Connect SDK v2.5.2 *** [00:00:00.000,457] adc: prst_adc_init: Dry coeff 1: 110000 [00:00:00.000,488] adc: prst_adc_init: Dry coeff 2: -15300 [00:00:00.000,488] adc: prst_adc_init: Wet coeff 0: 299000 [00:00:00.000,518] adc: prst_adc_init: Wet coeff 1: -83100 [00:00:00.000,549] adc: prst_adc_init: Wet coeff 2: 11200 [00:00:00.000,762] bt_sdc_hci_driver: SoftDevice Controller build revision: [00:00:31.901,275] adc: get_soil_moisture_percent: Read soil moisture 2: -2.27 | Raw 535 | Batt: 3.01 | Dry: 526.46 | Wet: 150.36 looks quite clean! |
|
I can't see anything immediately wrong from the logs or the pics. I compared the components orientations with a board I have here and they look correct. I assume you already did some of these steps, but I would:
From your first post, I understood you ordered two batches, and you got 2 working from the first one, correct? Does it mean these 2 display correct low power consumption? |
|
Hi, I have a source measurement unit, hopefully I'l find the time to do some current consumption measurements and give you an update soon. As it is my first post a big thank you to rbaron for the awesome project! 
|
|
Here are a few measurements for the sensor which gave me the weird battery voltage. Current consumption over 10 minutes, including two send periods of 1 s each. Sampled at 1000 Hz. Current consumption during startup. Including 1 send period. Sampled at 100kHz. And lastly the sleep current consumption. Sampled at 100kHz. In my opinion they all seem pretty good? |
|
@Thomas-514 I'm glad to hear you managed to build some boards. Yes, I'd say those values look okay. Pretty close to nominal. If you punch those numbers in a battery life calculator, you'll get well over a year. Assuming 150 mAh batt, a conservative 10uA average current, I get 20 months. Years ago I had something similar happen, where a single board discharged super fast. It turned out to be water shorting the battery clip. |
|
@rbaron unfortunately by now a lot of the boards I built show the same behavior. They seem normal under operation with the source measurement unit so my culprit is the battery and it's internal resistance. I assume the battery voltage is read roughly at the same time when data is transmitted. If we assume a high internal resistance of 30 Ohms (I read it typically is in the order of 15-20 Ohm for CR2032) and a current of 16 mA (during transmission) this would result in a voltage drop of 480 mV, maybe enough to shut down the MCU if the battery voltage is already a bit low? A clue might be the weird recovery of battery voltage once the MCU shuts down. It somehow recovers again and manages to send data again (for a few hours to days) before it dies completely. The batteries of the devices which are no longer working still show an OCV of 2.82 V. I'll experiment some more. |
|
If I try to use one of the "faulty" boards with the "faulty" batteries the LED blinks from time to time, I think the board is in a reboot cycle. The voltage over the battery during this looks like this:
If we match that up with the current consumption during reboot (earlier post, here again for reference): 
we can see that the battery voltage drops below 2 V when it tries to send data and the reboot cycle starts again. The voltage drop of more than 1 V for the 16 mA seems very large, no idea why that is. I don't have a load (or various resistors) to test these small currents to get an understanding of the iR of the batteries. (But this will be my personal next project). Edit:
|
|
Indeed the voltage drop seems rather high during the BLE TX. I'd expect this sort of voltage drop after a year of use -- not with a new battery. I just checked the usual current consumption for the zigbee sample, and it goes even higher up to 20mA at peak. It seems to still be okay for me and for other users. Out of curiosity, have you tried different batteries batches/manufactures? Have you observed a situation in which it does not occur with some of your boards? What if you swap the batteries between working/faulty boards? Otherwise I don't have a lot of ideas :( Larger caps across the power rails can definitely help, but I'd be curious to measure the leakage current it introduces, if appreciable. For the current design, the module we use just uses the caps as suggested by Nordic (datasheet). There's one extra thing I'd be curious about: we currently set the TX power to the maximum +8dB here. These are the sharp peaks we see in the current chart. You could you try lowering it to |
|
I have 2 boards that work fine and if I remember correctly I had two batteries to start with and bought some more. It could well be that all the non-working boards are powered by the newer batteries (Energizer brand), which are probably from the same batch. I can swap the two "good batteries" into other boards and they will work fine. I can try to measure the leakage current tomorrow. Electrolytic capacitors are generally known to be worse than MLCC. It would be interesting to test different types if I can get around to it. I can also try lowering the TX power while I'm at it. In conclusion, I strongly suspect that I was unlucky with the batteries and got a bad batch. I'll buy some other ones and see what happens. |
Dear rbaron
Thank you again for this excellent project.
Still I have been having serious trouble to have a stable long term b-parasite.
I have ordered from jbl pcb 2 set of boards, the first one (10units) I fully populated it using the radio Nrf52833 module, I got only 2 working at the end, I have reviewed all soldering and process and have no idea why this was happening (i have experience soldering delicate stuff, the humidity and temperature sensors is hard but I can manage it with good equipment). my first idea was that i was having problems with the pcb vias (never use pcb vias on pads!!!), so I have redesigned the boards only to move out the vias from the pads, i managed well, so I order the second lot but to be on the safe side i order also the population of the boards, so I only need to solder the rf modules and the battery holder. with the second lot i built 10units using the nrf52840 since I had so much trouble with the first ones i just wanted to make sure using the best radio also.
the problem now is that ou of this last 10 units built i got only 7 working out (others the programed the led does not blink on one, and the other 2 blinks constantly, I guess high consumption resets the board constantly) but still the power consumption seams extreme on some of the boards, further more i got very strange behavior regarding the voltage reading,
seams that only 3 out of 7 are minimally usable (still high voltage drop for the time frame)
to be frank I am a bit lost here, so I just wonder is others are having similar trouble?
would you be so kind to let me know a feasible debug strategy that i could make and share here?
with my bast regards,
azgael
The text was updated successfully, but these errors were encountered: