@NeverDie Yes, you are correct - it is based on ATMega1284P. So not relevant
My point is that I'd rather stick to the datasheet rather than overclock, but that's just me. And yes I realise that Moteino is overclocking, but the size, voltage and flash are really appealing to me.
@scalz said in HALO : ESP32 multi transport GW/Bridge for Mysensors:
the webapp was great, but I converted it to native crossplatform app for better versatility&perf, so I can use one app for my devices, like Ethernet for HALO etc, or Serial for my other Janus gw dongle, bluetooth..
To be honest, I've not updated anything yet for a few reasons, like very little spare time for a public release + support for such "big" project. (easier to handle local projects).
Sorry, still no eta for the moment..
It is clear that there is not enough time. But this project can become popular. That's what's missing MySensors. ...This void must be filled.
@fets So far, I have only built the 5x5 board (but the others should be schematically identical). The only issue I have found so far is that I cannot get the ISP port to work. But I have checked and I have an identical setup on the 1.0 board and that worked, so I suspect the programmer is too weak to drive the net on this one. So it is not a board-issue per se, and might only be an issue on the 5x5 board as routing is the most complex on that one due to the size.
@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.
@4994james or just use internal vcc measurement as described on the same page. That saves you the voltage divider.
I wrote a convenient library to measure vcc internally : https://github.com/Yveaux/Arduino_Vcc
