I'm very interested by your setup. It has been a shame to have some low voltage power in order to measure power consumption
I hope you can display something soon.
Regards,
@YuryPol as far as I know, all licenses require some form of documentation. In all cases I know of, this is documented with the license or on the licenses official site.
Hello,
I'm thinking about upgrading this board to include pinout for LIS3DH breakout board, like this one :
https://www.aliexpress.com/item/LIS3DH-Three-Converters-Motion-Accelerometer-Triaxial-Acceleration-Temperature-Sensor-Module-Development-Board-Replace-ADXL345/32840326778.html
and ditch the ADXL shield as it's not a good solution, it has either the ADXL345 which uses too much power, or the ADXL362 which is ultra low power but lacks advanced functionality like tap/double tap detection.
I would like to have feedback of users on this (do it sound useful ?), and also know if anyone uses the SMD footprints on the board, for leds and for reserve capacitors, as it could be a cleaner board without those footprints.
I would make the following changes :
put footprint for LIS3DH accelerometer along the "NModule connector" as it has too many pins to put elsewhere
keep only one I2C footprint on the side, for "GY-49" MAX44009 light sensor breakout board: https://www.aliexpress.com/item/GY-49-MAX44009-Ambient-Light-Sensor-Module-for-Arduino-with-4P-Pin-Header-Module/32828654450.html
temperature/humidity would be via the existing "SMD" footprint, it's not through hole but very easy to solder as it's 2.54mm pad spacing
remove SMD footprints for LED, add footprint for through hole reserve capacitor, keep SMD footprints for reserve capacitors only if I have space for them
shield would be a bit extended to go over the 2 M2 holes in the "power" part of the NModule, so it could be fitted with spacers and nylon screws and have stable/reliable mechanical connection between NModule and Shield. Basically this would be the footprint of the shield :
So in the end it would make one shield to have Temperature/Humidity/Light/Acceleration or Temperature/Humidity/Light/Door.
@mr_red
I have a zipped snapshot of all the 3d step/wrl models that I used to build my projects so far. It was quite some work to gather them all and align with the footprints using the kicad stepup tools. It's not complete - still needs some more work:simple_smile: but it should help you or anyone else to get started into MCAD integration using FreeCAD and kicad stepup tools. Maybe it's not very easy to start when using free tools but hey they are "FREE" so we cannot ask for more. But the nice thing is that once you get used it will be really easy to do your stuff and to go forward. Oh and FreeCAD can be so powerful after you learn it - I was really amazed what you can do with it(it has it's quirks and downsides but once you master it - oh, well...).
There's also: https://www.onshape.com/ - pretty powerful this one too and it has more advanced features than FreeCAD but the downside is that it's a cloud based solution: it's free for public documents but you never know when they will go to paid accounts only so yeah...I don't really like the idea to depend on something that it's hosted and the application is not on my PC along with the documents that I create with it. Cloud solutions have their flexibility but you're locked and you depend entirely on that hosted service.
Ok, enough talking...I uploaded the zip file here: http://www.mediafire.com/file/kzh1l9uo40cpj1u/kicad_stepup_packages.zip
@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.
