Float Time from Offline Data being Erased with 1609/1608 Firmware

[Resthome]

Not sure what is happening but the Offline Data seems to be zeroing out Float Time data at the rate of one entry per day. In my case the lost FT data starts on 3/6/2013 and is continuing to ascend one day at a time. As of Feb 1, 2014 it has now erased 89 entries for FT between 3/6/2013 and 5/28/2013. On 3/6/2013 the Classic had the firmware updated to 1341. Although this just started showing up since the 1609/1608 firmware updates. There was a problem with the Classic and store FT being wrong a while back not sure when that got resolved.

I have only been going to the boat once a month since I updated the firmware on 10/22/2013 to 1609/1608 and installed the WB Jr at the same time. The local app was also update and the local app V 3.36 was use on Feb 1, 2014 when I first noticed the FT data being erased.

Attached are Offline data dumps from Nov 29, Dec 29, and Feb 1. The additional days of FT being erased are the number of days between these dumps. Which leads be to believe FT entry is being deleted per day.
Not sure what is happening but would like to see if anyone else is seeing this or if MN has any clues before it erases the entire stored FT for the last year.

[TomW]

Are you aware we are up to Classic FW rev 1755 which might be better than the older version?

Possibly your problem was fixed in one of the  updates since the version you are running?

EDIT: Added Firmware link:

http://www.fusion.midnitesolar.com/MidNiteSolarUpdate_1755_2-1-2014_v4.11.exe

Just my first thought.

Tom

[Resthome]

Are you aware we are up to Classic FW rev 1755 which might be better than the older version?

Possibly your problem was fixed in one of the  updates since the version you are running?

EDIT: Added Firmware link:

http://www.fusion.midnitesolar.com/MidNiteSolarUpdate_1755_2-1-2014_v4.11.exe

Just my first thought.

Tom

Thanks Tom, I'm aware of the updated firmware but since I'm only there for about an hour at a time once a month or so at this time of year. Any beta firmware will have to wait until the Spring when I can be there for a few days. Unless MN has a fix for this.

I wanted to get the WB Jr installed before the winter so I could control the charging when not using the boat. So I installed 1609/1608 the last week I was there back at the end of October. That part has seem to work great including the Skip Days.  Data logging has been a hit and miss for me. And with no internet ability for MyMidnite I only have the Local App to track what it is doing while I have been gone.

Just curious if anyone else is seeing this when downloading the Offline Data with the local app.

[Resthome]

Not sure what is happening but the Offline Data seems to be zeroing out Float Time data at the rate of one entry per day. In my case the lost FT data starts on 3/6/2013 and is continuing to ascend one day at a time. As of Feb 1, 2014 it has now erased 89 entries for FT between 3/6/2013 and 5/28/2013. On 3/6/2013 the Classic had the firmware updated to 1341. Although this just started showing up since the 1609/1608 firmware updates. There was a problem with the Classic and store FT being wrong a while back not sure when that got resolved.

I have only been going to the boat once a month since I updated the firmware on 10/22/2013 to 1609/1608 and installed the WB Jr at the same time. The local app was also update and the local app V 3.36 was use on Feb 1, 2014 when I first noticed the FT data being erased.

Attached are Offline data dumps from Nov 29, Dec 29, and Feb 1. The additional days of FT being erased are the number of days between these dumps. Which leads be to believe FT entry is being deleted per day.
Not sure what is happening but would like to see if anyone else is seeing this or if MN has any clues before it erases the entire stored FT for the last year.

Hum... no response  from the MidNite folks?

[boB]

Well, it looks like that float time data has actually been saved but shows up as 0 time when rolling through
the log index.  If you could check on 2 sequential days or maybe within 3 days of each other, I bet
you see  the split start on one particular day and roll back into view on the flip side of the dead spot.

Notice that 5-28-2013  and before is there and valid looking in some XLS files and just plain 0:0 in
other logs.  But it shows up again later.   Not sure what is happening there.  We'll take a look.

If anyone else has seen this, it would be good to know about it and what data is missing.

boB

[Halfcrazy]

So if I am following this the Float Time is getting erased one day at a time day by day. So is this happening on the Local App or on the Classic? Can you go back through the Classic logs and see if it has lost that data or if the local app is losing that data?

Ryan

[Resthome]

So if I am following this the Float Time is getting erased one day at a time day by day. So is this happening on the Local App or on the Classic? Can you go back through the Classic logs and see if it has lost that data or if the local app is losing that data?

Ryan

Ryan,

Didn't discover this until I got home and was reviewing the data. I was initially only looking at the Feb dump to see how the skip day setting was working that I had set December. When I spotted the missing FT data in the Feb dump I went back to look at older dumps taken and found the Nov and Dec with missing FT data also but with less days zeroed out. So I never got a chance to look at the Classic. Will do this in about 3 week when I return.

The Nov and the Feb dumps where with different versions of the Local app. Not sure which version was used in Nov but it would have been one without the WB Jr data. Local App V3.36 was used in Feb dump showing the additional missing data although the Classic has been on 1609/1608 since 10/22/2013 and has not been update to the latest firmware at this time.

My conclusion that it is zeroing out one day at a time is because the number of days between these three dumps equals the number of additional days being zeroed out on the next data dump. Note the Oct dump Is showing good FT data in the same spots that are now zeroed out. Why it started to zero float times on 3/6/2013 is a mystery to me except that my calendar shows on  3/6/2013 the Classic was updated to 1341.

Thanks for looking into this, may be something strange that is happening with only my set up. I do remember that the previous issue with Float Time was that the values recorded where just incorrect. That got resolved a while back. I'd have search the forums to see when that was but don't think that has any connection to this issue.

[Resthome]

Well, it looks like that float time data has actually been saved but shows up as 0 time when rolling through
the log index.  If you could check on 2 sequential days or maybe within 3 days of each other, I bet
you see  the split start on one particular day and roll back into view on the flip side of the dead spot.

Notice that 5-28-2013  and before is there and valid looking in some XLS files and just plain 0:0 in
other logs.  But it shows up again later.   Not sure what is happening there.  We'll take a look.

If anyone else has seen this, it would be good to know about it and what data is missing.

boB

Hi boB,

Yeah you have to scroll down to 3/6/2013 which appears to be the first day that the float times got zeroed.
I've highlighted it on the three different dumps. Nov, Dec, Feb. November is the first dump I have after the 10/22/2013 update to firmware 1609/1608. Each successive dump zeros more data. My conclusion that it is zeroing out one day at a time is because the number of days between these three dumps equals the number of additional days being zeroed out on the next data dump. Note the Oct 11 dump is showing good float time data in the same spots that are now zeroed out in the Nov, Dec, & Feb dumps.  Why it started to zero float times at the 3/6/2013 entry is a mystery to me except that my calendar shows on  3/6/2013 the Classic was updated to firmware 1341.

The Classic is set to reset at 23:59 every day.

[zoneblue]

As in auto reset? Is your button battery still good?

Maybe try it without the auto reset, see if that helps. Might help narrow the issue.

Whats your auto reset for??

[Resthome]

As in auto reset? Is your button battery still good?

Maybe try it without the auto reset, see if that helps. Might help narrow the issue.

Whats your auto reset for??

Zoneblue,

The button battery is good, I checked it recently. You can see the date and time of the data being log in the spreadsheets. So nothing seems to be wrong with the clock settings.

Doubt the A-RST tweaks setting being on would cause it but I can try turning it off next time I am there. Normally leave it set to on this time of year when I am not at the boat, so if something does go wrong at least it will reboot the Classic at 23:59 hrs. each day

Auto Restart is in the TWEAKS menus...  It is labelled A-RST. This tweak makes the Classic reset every night at midnight just after it saves the daily logging numbers.

[zoneblue]

Doubt the A-RST tweaks setting being on would cause it but I can try turning it off next time I am there. Normally leave it set to on this time of year when I am not at the boat, so if something does go wrong at least it will reboot the Classic at 23:59 hrs. each day

If "something goes wrong" the classic will always self reset, it has an independent "watchdog" circuit that if it hasnt heard from the cpu in x time, it gets rebooted. So i would only use it if you have a specific symptom, mostly these days of which are networking related.

The reason i ask is that on a lite at least auto reset has some odd side effects.

[Resthome]

Doubt the A-RST tweaks setting being on would cause it but I can try turning it off next time I am there. Normally leave it set to on this time of year when I am not at the boat, so if something does go wrong at least it will reboot the Classic at 23:59 hrs. each day

If "something goes wrong" the classic will always self reset, it has an independent "watchdog" circuit that if it hasnt heard from the cpu in x time, it gets rebooted. So i would only use it if you have a specific symptom, mostly these days of which are networking related.

The reason i ask is that on a lite at least auto reset has some odd side effects.

No Lite here. While anything is possible I would not suspect that A-RST would cause this kind of issue. The issue is only one field (Float Time) is being zeroed out and the rest of the record has valid data. In addition this record did have valid float time data at one time. Why when writing data to the log file at 23:59 for the existing days data (which it does fine) does it go back in the log approximately 8 months and pick the next record in ascending order from the last zeroed float time value and zero out one single field in the record (Float Time) and leave the other fields in the record alone. It has something to do with the programing logic for writing the day’s historical data to the EPROM. Since I only have the data from the Local App and do not know if the Classic itself shows this issue it could be a Local App issue. The Classic is suppose to hold 380 days of daily history.

  Ah just discovered another piece of data for boB and Ryan to think about. The number of entries (records) between the latest record (date of export of Offline Data) to the record before the record with the float time equal to zero is 256. Not sure but that number being 2 ^ 8 sure makes me think it could be a clue.

[boB]

  Ah just discovered another piece of data for boB and Ryan to think about. The number of entries (records) between the latest record (date of export of Offline Data) to the record before the record with the float time equal to zero is 256. Not sure but that number being 2 ^ 8 sure makes me think it could be a clue.

Interesting observation !!!

I wonder if maybe your EEprom is bad or something ?    BUT, the data does appear to still be there !  It's just that
it appears to be valid float time only when the index pointer into the data log is a certain distance away from that zero float time.

Maybe an EEprom test routine is in order.  But this just doesn't happen !  Well, maybe not until now ?

It is amazing what can go wrong.... go wrong.....   go wrong....  go wronggg...
boB

[Resthome]

  Ah just discovered another piece of data for boB and Ryan to think about. The number of entries (records) between the latest record (date of export of Offline Data) to the record before the record with the float time equal to zero is 256. Not sure but that number being 2 ^ 8 sure makes me think it could be a clue.

Interesting observation !!!

I wonder if maybe your EEprom is bad or something ?    BUT, the data does appear to still be there !  It's just that
it appears to be valid float time only when the index pointer into the data log is a certain distance away from that zero float time.

Maybe an EEprom test routine is in order.  But this just doesn't happen !  Well, maybe not until now ?

It is amazing what can go wrong.... go wrong.....   go wrong....  go wronggg...
boB

boB,

Another observation is the Float Time field is okay on the other side of 3/6/2013. It has been good all the way to the end of the logs which was around 12/2012 but those records are now being over written. And why is the pointer in two different locations, one for writing the current days historical records and 256 indexes away writing 0 in the Float Time field. Maybe a hardware issue, but some more investigation first. Of course I have no idea what the process for writing the historical data entries each night at 23:59 is.

I may make a trip up there this weekend, if I can stay for a few days I may consider updating to the latest firmware. Will look at the Classic historical data first. I'm sure more of the Float Times have been zeroed since my last visit on Feb 1st.

[Resthome]

So if I am following this the Float Time is getting erased one day at a time day by day. So is this happening on the Local App or on the Classic? Can you go back through the Classic logs and see if it has lost that data or if the local app is losing that data?

Ryan

Ryan,

I can now answer this question. And the answer is the FT data is being erased as explained in my original post on the Classic itself as well as in the Offline Export in the Local App. So it appears to be a problem with the Classic firmware or the hardware. But since no one else has reported seeing it in the forum who knows. The SN is CL2111 if that has any significance.

I also update to 1779 (2-20-2014) and the Float Time Data continues to change in one additional record per day after the writing of the Historical Daily data to the EEPROM.  The entry being changed is the record following the 256th. In other words we have 256 entries with good float time data. The 257 entry then has a float time of 00:00.

Again this appears to have started some time after 1609/1608. Prior to that time the data was good. My data from Oct 11, 2013 had 312 entries with good data for float time.