I'm working on some projects that I have for my military M939 truck. OEM made it completely analog, which is perfectly fine, however the gauges are not in an ideal location. Since I want to move them to a more user friendly location, I thought that I would upgrade them. Some because of necessity, and others just because I have to do the necessary ones anyways.
I have a big laundry list of projects to attack, however...one that I'm not 100% sure is feasible is how to make an odometer that can keep it's data while the vehicle is not powered on, or that is dependent on the vehicles power to sustain the data.
I've only what I would call simple projects with the couple Arduinos that I have and I'm not sure if they can store data that is anything other than written code. If there is/isn't a way I would appreciate someone just letting me know in advance before I get too far down that rabbit-hole.
I'm not tampering with the OEM equipment, it's mechanical anyways so why bother?? I'm just trying to move the "speedometer" to where it is close to the line of sight while driving vs having to nearly look at the floor all the time. OEM will stay where it is, I'll just look at the GPS one instead so that the eyes are off the road for as little time as possible. I just figured, if I'm doing that I might as well add an odometer to it as well. Over time there will be difference between the two regardless since the OEM tires were a little larger. Technically, for some reason most states won't recognize any GPS speedo as being legitimate anyways.
So what's the point of all this? You're telling us you will look at the GPS, which sounds reasonable, and it should tell you more than any odo will. There is no suggestion that the original odo doesn't work, so I guess its there when you feel it might be time for an oil change.
One of the reasons I want to add an ODO, besides the challenge, is because the current tires (395/85R20) have ~446 revolutions per (rated for 68mph) , where the old sized tires (14.00R20) were ~427 (rated for 55mph). Besides the noticeable difference in speed when compared to the radar speed checkers, I know that it makes a difference to the oil changes as well, ~4.5% actually. Granted, I could just adjust my oil changes accordingly, which would turn then from 5K to 4775, but which one is easier to remember? Another thing to think about with this specific vehicle is that the tread depth on these tires are nearly 1.25" and that is a rather large difference to accommodate for mechanically speaking. However, if I incorporate an ODO into the GPS speedo i'm trying to do, then any difference in tires should be null since it's not measuring speed based on many times the tires are rotating in a given amount of time, especially if I changed tire sizes again.
But yeah, I guess when it boils down I just want to try to do it lol
read() and write() are used to retrieve & store a single byte. get() & put() are used for multi byte data types (such as float). You don't really need the clear function as write/put will overwrite the current contents.
The EEPROM generally has a limited number of write cycles (~100,000 per address), so there is benefit in considering some kind of wear levelling. The built in update() function only writes if the value has changed, and there are techniques for writing to a different address after x writes, as the 100,000 limit is per address slot.
Well there is no code to post, I was only asking if it was viable with the Arduino. I also don't see how the actual vehicle is relevant since the project is only code and hardware related to GPS at best and in no way would it be interfacing with any OEM equipment, but yes that is the correct vehicle. However, I'll still go take a gander at the that post you referred to.
thanks redcar for that info, I didn't know that there was a "life"d to the EEPROMs addresses. If they are 100,000, then I'll only be able to drive less than 10,000 miles before I have to change that address if I want to keep the tenths decimal. Sounds like I'd be better off using an SD card for storage instead then.
Mick, there is no such thing as "cant" lol, unless we're talking about pianos, in that case I definitely can't play pianos. lmao
Right now I'm just trying to get this stinkin screen to work on my Mega, as it will be completely useless on the UNO since every pin is covered. I got a general GUI working on the UNO so that is nice, it just means that I'm going to have to spend some more time going over the differences in the code for the Mega to see what is different between the examples that do work and the code for my GUI.
But you can do that programmatically by storing a pointer to the EEPROM address in EEPROM. There is of course a lifetime to the EEPROM and for an AVR it is guaranteed 100.000 .
Yeah right, that can probably last a lot longer ? I have some doubts about that, but product specification might be conclusive evidence in either direction.
And it works on an UNO okay ?
Covered probably yes, not every pin is used probably, though the shields i have use pretty much all but 3 pins.
SPI shields probably don't uses as many though.
Keep in mind that on a Mega the SPI is on different pins than on an UNO
It's pretty easy in your case to implement a solution... consider something like this...
// Initialise the EEPROM - only needs to run once.
uint16_t mileage_address = 2;
uint32_t mileage = 0;
EEPROM.put(0, mileage_address);
EEPROM.put(mileage_address, mileage);
// To get the current mileage from the EEPROM.
EEPROM.get(0, mileage_address);
EEPROM.get(mileage_address, mileage);
// To update the mileage in the EEPROM.
if(mileage % 100000 == 0) // Max write cycles every 10,000 miles
{
mileage_address = mileage_address + 4; // 4 bytes for uint32_t
EEPROM.put(0, mileage_address);
}
EEPROM.put(mileage_address, mileage);
Assumes you store the mileage as a 32 bit integer value (including the tenths), and you update the EEPROM every 10th of mile. Should last longer than your car
I wouldn't expect an SD card to be any more reliable.
I was actually wondering the same thing as I was typing that lol
yes, but i'll leave that for another post specific to that issue if I can't figure it out.
Most definitely covered, but like you said I doubt it uses every single pin. Problem was that when I tried disconnecting pins, more than what are shown in the code are actually being used. So I thought it would be a better idea to try to get it to work on the Mega instead.
Doesn't every time I change said mileage count as an address rewrite and thus use up some of the "life" that's why I was was concerned about using it because it would only yield 10K miles....unless I'm not fully understanding this. 100,000 = 10,000.0 ...Right?
For me 10K miles is just two trips across the country (this vehicle will be an RV when finished) so at the quickest I'd have to change addresses every 3-4 months, just like an oil change.
However, while typing this out, I thought of something. What if we use a few addresses for the updates while we drive and then have a power down portion of code that will write only the last updated mileage to the original address. I hope that makes sense to you guys.
Welcome mos68x, Many states require you to keep the OEM speedometer connected. If it is an off road vehicle I believe there are different requirements, you might check into that. Disconnecting it is considered tampering with the milage. You may want to check into what is involved using a replacement speedometer. There is an easy to keep the data, use FRAM, it is cheap, unlimited reads, millions of writes, and it works at memory speed no delays waiting on it to program. You could update every tenth of a mile or less if you like. Keep the data in three sections of memory and checksum each one. Then you can determine if one fails. When you do this module protect from reverse battery and load dump. Information on that can be readily found on line. Have Fun!
I also realized today that I would have to do the same thing for the hour meter as well. And considering that I can bench test that a whole lot easier, I might start with the hour meter to pactice using the EEPROM stuff.
I need to go look at the EEPROM function a little closer to see if there is a number for how many addresses there are.
