The main feature of this device is (lifetime) logging. But it would be not difficult to implement a software feature to beep out voltage like you sad, instead of using the digit method.
Since this device can keep track of you watt hours I think using this data can give you a way more accurate state of your battery / range.
If it was only about the voltage, no logging, nothing you could ditch the FRAM chip, therefore make it even smaller and a few Euros cheaper.
This is obviously not the case with this device.
For me personally as a data freak, I need that so much I even built a device for it haha. Btw, I also wear my fitness tracker 24/7…
There will be a tool to set up the device connected to the PC. To put in your motor data, wheel diameter etc. I can also make it possible here to choose what functionality goes to what gesture of the remote wheel.
Aaaaaand boom goes the dynamite. You just described the perfect version of what I am thinking. A beeper that learns the usable capacity (and maybe even discharge characteristics) of my battery and gives me a voltage reading based on that. Anything else and I would rather look at it, as I am a visual person.
haha if you own an Davega, it already does this Fairly certain it’s an averaging algorithm so not exactly full on AI but rather a self calibrating amperage/coulomb counter
@BenjaminF, why base a battery off of capacity though? Voltage would be much more accurate. Reason being is depending on how hard you run your battery, not all the energy will be converted to current. Some will be converted to heat. Voltage however will remain the same regardless in any situation
This is awesome! As a fellow data freak, this is awesome! Looking forward to hear more development. Let me know if you need any help with development or testing.
I don’t have any real circuit design/programming skills to speak of, so the answer to this is probably obvious, but the atmega328 seems to have a good amount of onboard flash/sram/eeprom, what are the advantages of offloading storage to the FM16W08?
With the persistent data, is the intention that you’d be able to export data/fault logs in some form?
The answer lies in the hardware implementation of the memory.
SRAM will lose all its contents when it is not powered on. So that one is out.
FLASH cannot be written by the processor itself only by a programmer, so that one is also out.
EEPROM is a possible solution. It can only be written 100,000 time though. That can seem like a lot but in this usecase it really is not. The controller checks the VESC’s data each second, and writes it to memory. This is done so that you can power the board off any time and there is no need to save data! 100,000/60s/60min = 27h of use and the device would be dead. So you would have to save each time before you power off, transferring date from SRAM to EEPROM.
Now FRAM (which is implemented in the FM16W08) can be rewritten infinite (10^14) times like SRAM and still keeps its contents after power loss. So there you have it!
I was aware of sram and eprom’s limitations, I think the original davega gets around that by reducing the write frequency to every .1km iirc.
The inability to write to save to flash, I wasn’t aware of, so I appreciate the enlightenment.
With 100 trillion read/write and 151 year retention, the chip seemed a little overkill
Would something like the FM25CL64B-GTR work similarly, or does the FM16W08 integrate a lot of components that would blow up the size of the pcb? The former seems to have super low power consumption.
Yes, in fact I am allready designing a version that uses this chip (but the 4kb version, fm24c04). It uses the I2C interface and therefore a lot less IO pins than the parallel FM16W08.
It just happened that I got those chips for free and so I used them for a first version.
edit: FM24CL04B-GTR, actually thanks for the recommandation, fm24c04 only works with 5V and I need 3.3!
Besides footprint, he other reason the FM24CL04B-GTR caught my eye is because it also has the advantage of being an order of magnitude cheaper if you ever wanted to scale production.