Mark Posted April 12, 2016 Share Posted April 12, 2016 Has anyone seen this thread on AEVA... Coulomb writes: "Yes, but it's not clear to me whether sending such commands causes extra writes to the EEPROM chip that saves parameters. Certainly commands such as POP (setting Output source Priority) and PCP (setting Charger Priority) override settings read from the EEPROM. There is some evidence that settings are updated continuously, but it seems likely that if so the EEPROM device checks for whether changes have been made before actual flash writing. Most EEPROM or flash devices have a write limit; writing more than a certain number of times may wear the device out and eventually cause errors. " This may be a question that needs to be solved in the software discussion.. ie Don't "rewrite" to the settings if the setting doesn't need changing... or limit rewrites.... Interesting discussion here - I'm clueless from a coding perspective though... Chris Hobson 1 Quote Link to comment Share on other sites More sharing options...
___ Posted April 12, 2016 Share Posted April 12, 2016 The Microcare Charge Controllers had the same problem until recently. They updated the 24h average and total kwh counters every few seconds, killing the EEPROM in about two years. Their new software only updates it every 5 minutes, and spreads the writes over 3 memory locations. When mine broke (the first time, before it blew the internal DC-DC converter) it was because the location of the 24h average memory was worn out. I could tell, because that value was completely wrong :-) Quote Link to comment Share on other sites More sharing options...
Mark Posted April 12, 2016 Author Share Posted April 12, 2016 I wonder how the Axpert handles this... if at all... I expect changing from GRID to SOLAR and back twice a day isn't that much of an issue though... unless the software does many other changes more regularly... Quote Link to comment Share on other sites More sharing options...
Guest Posted April 12, 2016 Share Posted April 12, 2016 Now I NEVER would have thought of this potential issue. Thank you! Quote Link to comment Share on other sites More sharing options...
Guest Posted April 12, 2016 Share Posted April 12, 2016 100 000 writes = 136 years. Dont think it will be a problem as I wont be around to worry about it. Quote Link to comment Share on other sites More sharing options...
___ Posted April 12, 2016 Share Posted April 12, 2016 22 minutes ago, jdp said: 100 000 writes = 136 years. Dont think it will be a problem as I wont be around to worry about it. That reminds me of this issue we had with a bit of software. On one particular day in February 2012, the 29th to be exact, it failed to properly import data. Now being the male that I am (you know, we don't forget birthdays, we forget TODAY's date), I didn't suspect a thing until I found the bad code. It was a bit of code that tried to exclude impossibly old data, and it did so by subtracting ten years from today's date. Sadly it did so in a very naïve way, by splitting the date into components, subtracting ten from the year number, and reassembling the date. Unfortunately 29 February 2002 wasn't a valid date, and things fell over. This story isn't so much about that though. It is about how we decided to fix it. Given that all we really care about is ruling out very old data, the number we subtract doesn't have to be exactly ten years. There were two solutions on the table. First: We can use 8 years instead of ten. That way we are mostly assured that the new date would be valid. Or we could just subtract 3650 days, a function that is well supported by python's datetime module. We ended up going with the second option, and here is why: Because subtracting 8 years will fail in the year 2108. Though everyone agreed that we probably wouldn't be around by then, we still did the right thing. :-P Quote Link to comment Share on other sites More sharing options...
Chris Hobson Posted April 12, 2016 Share Posted April 12, 2016 Just an an aside - it is a leap year if it is exactly divisible by 4 except years that end in two zeros. So 1996 was a leap year 2000 wasn't and 2004 was and 2100 won't be a leap year. Quote Link to comment Share on other sites More sharing options...
___ Posted April 12, 2016 Share Posted April 12, 2016 34 minutes ago, Chris Hobson said: Just an an aside - it is a leap year if it is exactly divisible by 4 except years that end in two zeros. So 1996 was a leap year 2000 wasn't and 2004 was and 2100 won't be a leap year. 2000 actually was a leap year. The rules are that centuries that aren't divisible by 400 aren't leap years. So 2100 won't be a leap year. I have another funny story. They had these spreadsheets that they imported into the code and the dates were off by exactly 4 years and one day. Now you have to understand something about how spreadsheets store dates: They store a floating point number starting at a specific point in time. That point is 1900 for most implementations, but for some obscure reason the early Excel versions for the Macintosh used 1904 as the epoch. In addition, 1900 was deemed a leap year (incorrectly), so that if you loaded a spread sheet from an old Macintosh version of Excel on a PC, your dates would be off by exactly 4 years and one month :-) Quote Link to comment Share on other sites More sharing options...
Chris Hobson Posted April 12, 2016 Share Posted April 12, 2016 21 minutes ago, plonkster said: 2000 actually was a leap year. The rules are that centuries that aren't divisible by 400 aren't leap years. So 2100 won't be a leap year. That's correct. I had forgotten about the 400 rule. Complex! ___ 1 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.