@nekitoss
I used 3.3V pro mini with regulator removed and powered by Vin pin. Also removed leds from the pro mini.
I used minicore bootloader.
I used the small pir sensors and again removed the regulator to power directly from the pro mini outputs.
After that sleep the node and trigger on interrupt.
Send battery level once a day.
Use inbuilt battery level monitor and not external components that constantly drain power to get battery level.
1.8V is 0% on the graph (not visible yet!) but I have had nodes working below 1.7V It's a matter of luck with that it seems.
Hope this helps you on the right track. I'll try and help if you want.
This is the latest image and still going strong after 18 months. Voltage is at 2.903V
Here is photo of the test example - I need to make a case and produce more of them over winter.....
Here is the same build/code of a window sensor. Similar time frame but hardly triggered.....
@NeverDie Thx for appreciating the work done. There will also be an open source part in the future. When and how extensive the open source part will be, remains to be seen. The release of certain information (block diagram, ..., in this post) is related to those open source parts.
There are some OBD solutions, however most of them (in my experience) give back low frequency data put by the car manufacturer on the OBD-bus (CAN, ...). Therefore transients evolving directly from the battery could only be recorded if the manufacturer sends those data accordingly on the bus. Due to the small bandwidth(also because of other car data that have to be sent, ...), such battery data are sent more often once per second or less. Fast battery events (i.e. cranking events, ...) are therefore imperceptible. Unless the manufacturer processes the fast events and then sends them (once per second or less), which is very unlikely if the manufacturer does not market this feature itself. Third parties devices for high frequency sensing costs several hundreds dollars.
In my experience, important battery states (especially the fast ones) are recorded by measuring and processing corresponding data directly on the battery.
I agree with you about the limits related to the communication over Bluetooth. But i think Bluetooth 5.0 will improve a lot. However, WiFi will always remain an important option due to the high data throughput. The combination of both (BLE & WiFi), especially with regard to energy consumption, will gain in importance.
You can put 100uf on each even 200uf would not be able to handle only one tx, so..
but you need them at least for coin cells.
you would need more capa to handle tx..but the more capa the more time they take for recharging, and the recharging if big, increase internal res of the coin cell and that's not so good too; to prevent this that would need a current resistor limiter..etc a whole balance!
On mine for instance, I have 100uF for coincell, 100uF for PIR and 86uf on radio. Fresh varta coincell 3.02V, after multiple presentation tx 2.85V if I remember, not so bad. but that's an homemade pcb.
Another notes, it's better to use ceramic capacitor (because of leakage, if you want to optimize), and better smd, but that's not your case I think.
@hek The capacitor addition seems to be helping. So far 9 hours and all the values are updating as they should YAY!
I'll continue to monitor but i'm hopeful that this is the solution.
Does this help:
http://forum.mysensors.org/topic/748/manual-assigning-node-id-s-for-network-with-repeaters
I agree with you that the serial messages are not perfectly documented, but realise that this site has been made (as far as I know) by a bunch of people that share their 'love' for home automation.....
boozz
@NeverDie Perhaps but the design is a bit too simple and unoriginal. I'd have to clean up the files a bit and I haven't touched Eagle since I made this board several years ago.
