LPG2CV wrote: ↑
Fri Mar 27, 2020 12:21 pm
I'm sure you could easily calculate the speed, and mileage travelled. I suspect the issue is when, and where you store the value.
if i understand it correctly, the eeprom has a limited amount of writes. I'm not sure how many though but measured in 10s of thousands I think.
It would have to be written as ignition is on, because as soon as you turn off the ignition, you lose the ability to write it. So then it comes down to the frequency that you write it. To often, and you will eventually burn out the address in eeprom. Not often enough, and its inaccurate.
A button on the dash to manually write it.
Every time you stop ie, speed goes to zero. (great for main roads, but not town)
Any combination of above.
Just my 2 cylinders worth.
I am currently building a new digital dash to replace all of the analog clocks in my car. I have decided to do the whole thing, including indicators, warning lights etc. My car is just basic wiring (no modern kit, not even OBD nevermind stuff like canbus) so there is a bunch of work to do to integrate it all, and for that I'm adding a canbus to it.
One of the things I am doing is adding an odometer. You have correctly identified one of the key issues with a digital odo: You need to store the value somewhere, and do it regularly (whenever it changes). In my case I am storing it every 0.1 mile travelled as that is equivalent to what the analog gauge does (although the analog one effectively has infinite storage resolution in that respect).
I am using an arduino Nano for the odometer as it has plenty of eeprom space for that task (alongside some others that I will use it for). As you say, the write limit is around 100,000 write cycles for a given eeprom location. So storing at 0.1 mile resolution means only 10,000 miles before the write limit is breached.
My solution to this is to use more than one set of bytes (it's a 4 byte value for me) to store the value. If you allocate a range of memory locations instead of just the 4 bytes needed, and then each time you write the value you move it to a different eeprom address, then you can share the writes between multiple addresses. This increases the effective number of write cycles. All you need to do is to size the address space to get the longevity you need. It takes a bit more logic and a couple more bytes to be able to track the current location of the odo reading without falling into the same trap of constantly writing to the same eeprom address, but that is not too hard to do - you just precede the value with a recognisable signature and keep the unused bytes at zero all of the time, then the value can be found with a simple linear search across the allocated address range.
My system is still on the bench at the moment but once it is done I will have a digital odo that is properly updated and can be read by turning on the ignition key. I'm driving mine off the sensor on the diff input (also used for speedo) and will use that for speed (same canbus device) as well.