Topic: Erroneous Monthly High Rain Rate

[tinplate]

I've shied away from providing an interface for writing into the EEPROM data because it would not be hard for someone to really hose their system poking values into the EEPROM, and I'd rather not be blamed for that. But it would be an interesting tool to have! Even if I were to do it, I'm so busy right now, that I would not be able to get to it in a time frame that would be useful to you for the problem you have right now.

As someone mentioned, you can do it through the Terminal program that comes with Windows. You just connect the terminal program to the console's COM port, and you can type in a command, hit "Enter", and the console will act on the command and respond. There are commands to read and write to EEPROM locations without needing to calculate CRC checksums. There are a few places where your bad rain rate will be. But I think the ones you're propably most interested in is the yearly highs and monthly highs as displayed on the console graph. I'm not sure if the graph history memory in EEPROM is the only place where the hi/low values are stored. It may not. There is a separate command for reading hi/lows, and a command for clearing hi/low data. Whether that access the same EEPROM values as the ones I describe below, I'm not sure.

If you want to access the rain rate graph data, the different periods store 24 2-byte values, or in the case of monthly and yearly data, 25 2-byte values. Here are the starting addresses in hex (the commands expect hex values), that I calculated from the Davis docs for the VP2. Don't take this as gospel though. The VP1 is different, I may have calculated the address wrong, and it's always possible that this may have changed with the most recent firmware version.
A2B -rain rate 1 minute (24 values)
A5B -rain rate hourly (24 values)
A8B -rain rate daily highs (24 values)
ABB -rain rate daily high times (24 values)
AEB -rain rate monthly highs (25 values)
B1D -rain rate yearly highs (25 values)

So, if you wanted to see the raw values for the 24 monthly highs, you'd enter this command if you were in the terminal program:

EERD AEB 32

This reads 50 bytes (32 in hex) starting at position AEB. The values the console spits back are the contents of that chunk of EEPROM, displayed in hex. Normally, for two byte values, the console sends the least significant byte first. So, 10 00 would be 16, and 00 10 would be 4096. If you could see from the resulting values which one you wanted to change, then you can use the EEWR command to poke a new value in. For example, if you determine that the the 6th pair returned from EERD is the bad one, you would calculate the position by adding 5*2 to AEB, which = AF5

AEB, AED, AEF, AF1, AF3, AF5, AF7, ... would be the addresses of the monthly high rain rate values. It's easy to point to the wrong place, so you have to be careful.  The rain rate monthly highs for example is START + 2470 (decimal). For the VP2, START = 325. The VP1 is different. My numbers above assume you're talking VP2.

So, to poke 0 into the 6th monthly high rain rate, you'd send

EEWR AF5 00
EEWR AF6 00

Rain rate is most likely stored as the count of rain tips per hour. So if you have the .01 inch per tip rain gauge, it will be 100ths of inches per hour.

Steve
SoftWx

[Ray Proudfoot]

Hi Steve,

Thanks very much for that excellent write-up. I have read it through a few times and have also printed the Davis Reference manual linked in an earlier message. I have the USB type connection but VirtualVP recognises the console on COM6 I think.

I've never used Hyperterminal before but it seems relatively straight-forward. Page 5 on the reference manual advises a carriage return should be sent to the console to "wake" it up and to wait until a response is received. After that, it stays active for 2 minutes. Page 9 advises to send TEST to confirm connection with the console. Would you recommend both steps?

Fortunately there are only 5 months of data stored in the console starting in late April so it shouldn't be difficult to identify the bad value for July. Looking through the Davis document I'm wondering if the bad value might be stored in both RAIN_RATE_MONTH_HIGHS and RAIN_RATE_YEAR_HIGHS. I'll peek both addresses and see what's there.

The All Time High Rain Rate used on the History_Vantage_Pro.htm doesn't appear to be listed in the reference manual so I'm guessing it is derived from either RAIN_RATE_MONTH_HIGHS or RAIN_RATE_YEAR_HIGHS. The latter probably.

I'll proceed with extreme caution. Once I've read the values I'll report them back here and perhaps you can confirm which address / addresses I need to change. The current bad rate of 52.68" needs to read 9.76".

More later when I'm home.

[tinplate]

an easy way to convert back and forth between hexadecimal and decimal is to use the Calculator program that comes with windows. Put it into Scientific mode and there are some extra radio buttons for switching between different bases.

[d_l]

I just shut down WL to my console.  It is on COM9 and I opened Hyperterminal to COM9 at 19200 bps and left the other settings at defaults.  When I type TEST (in caps) there is no echo of it, but after hitting enter, the console sends back TEST.

All I can think of to check is if COM6 is your correct comm port after the software shutdown?  It isn't a virtual port set up to run WL and Cumulus simultaneously, is it?

[Ray Proudfoot]

Thanks for replying. I deleted the message as I found what I needed to do. There's an option in Settings to echo what you type.

I do have a virtual port (using VPP) but have terminated it (and the weather programs) as HL needed exclusive access.

I have some data to decypher. I'll be back after I've had some dinner.

[Ray Proudfoot]

Hi Steve,

Okay, I think I've analysed the data correctly. Attached are two text files containing the data from the console for the following commands -

EERD AEB 32

EERD B1D 32

I've included extra information against the entries in question including the new values that have to be written to the console.

If I'm correct in my understanding those commands should be -

EEWR AF1 D0
EEWR AF2 03

to update July High Rain Rate to 9.76"

and to correct the current year value...

EEWR B4D D0
EEWR B4E 03

Look forward to hearing from you. 

[tinplate]

If 52.36 was the bad value you're trying to get rid of, then it looks like you've got the right commands for poking the correct values in. You might try just doing the monthly one first, and see if the console display looks good for that value after that. Then do the yearly. I'll be curious if it fixes the hi/low values the console sends down to programs like weatherlink.

Steve

[Ray Proudfoot]

If 52.36 was the bad value you're trying to get rid of, then it looks like you've got the right commands for poking the correct values in. You might try just doing the monthly one first, and see if the console display looks good for that value after that. Then do the yearly. I'll be curious if it fixes the hi/low values the console sends down to programs like weatherlink.

Okay, I've just performed the updates. First I updated the monthly high rain rate and this was successful when viewing the console in Graph mode.

Next I updated the yearly high rain rate to the same value. The commands were accepted but on checking the console the old value is still present. I checked History_Vantage_Pro.htm and that still shows the incorrect value. If you look at that Davis reference document the yearly highs for rain rate start at 325 + 2520 = 2845 or B1D but that address only contains FF. The address containing the current year is B4D and B4E and those are the addresses I updated. I wonder if that area might be read-only? Any thoughts? Perhaps on Jan 1 2010 things will sort themselves out.

Anyway, it's been an interesting exercise and I've learned something and maybe this will help others correct bad data.

One thing I noticed in that document is the ability to update the console time. I know you don't have the time (and perhaps inclination) at present Steve but it would be very useful to be able to keep the console and PC time syncronised. Food for thought perhaps. 

Thanks once again for your help without which none of this would have been possible. 

[d_l]

I wonder if this note from the Serial Protocol Docs might be in some way related to why your yearly rates weren't updated immediately:

Please note that some of the pointer values stored in the EEPROM may not be updated
immediately, such as NEXT_10MIN_PTR and NEXT_15MIN_PTR. This is done to save
EEPROM write cycles, since the EEPROM is good for 100,000 times of write. Those data will
only be saved into the EEPROM at the beginning of each new month or when the console goes
into setup mode.

Perhaps there is some delay to the actual EEPROM write and the yearly data you "poked" is stored in SRAM until the next EEPROM update cycle for that value. ... but this explanation doesn't seem correct when the monthly rates were updated immediately. Maybe a better explanation is that your poke didn't take for some reason.

[Ray Proudfoot]

The thought crossed my mind that there might be a delay to the update for the year value. There was no indication it hadn't accepted the command and I was very careful when typing it in.

I suspect either a change of month or change of year will cause something to happen. If not I'm hopeful that I will be able to amend the 2009 value once it's been written to by the console on Jan 1 2010.

[tinplate]

I added time sync to VPLive some time back, after receiving some requests on this forum.

[Ray Proudfoot]

I added time sync to VPLive some time back, after receiving some requests on this forum.

I don't have that so I shall download it tonight. Thanks.

[Ray Proudfoot]

I've received a reply from Davis Support. This is what they recommended...

Display your HIGH RAIN RATE (for the year, month, or day, as required) on your console's display using the HI/LOW button.
 
Then, wherever required, do a CLEAR command (2nd-HI/LOW) to clear that value from that register.
 
This way, the next highest rain rate will succeed the erroneous value living there now.

When I navigate to Year High the rain rate is not visible, only the annual rain. Can anyone else with a VP2 check if they can see a year high rain rate please? I'm wondering if I don't see it because I've only been running it since April.

[johnd]

I suspect that what you might need to do is to:

1. Navigate to the Monthly high rainfall (amount)

2. Press RAINyr which should toggle that particular display field to rain rate

3. Then using the left/right cursor keys go to the month with the erroneous rate and clear it.

This obviously isn't exactly what you're seeking to do in that the error month is going to get a zero rain rate rather than an edited value. I don't know whether this will trigger an automatic update of the yearly max rate (either now or at midnight or 1st Sept (next month) or 1st Jan (next year)??) And there's obviously a certain data risk to playing with the console values in this way.

Edit: But this is just a comment on the Davis email about clearing an erroneous value. If you've already amended the relevant monthly max value then you obviously won't want to clear it again. Maybe what they're saying is that clearing the relevant yearly value (ie as above but with yearly in step [1]) forces a recalculation of the yearly max rate but this doesn't sound too plausible.

[Ray Proudfoot]

Thanks John. The bad monthly high rain rate value was corrected yesterday using HyperTerminal. But I navigated to Year High and pressed Rainyr and the bad annual value (52.86") appeared. I pressed 2nd then Hi/Low for a couple of seconds and it reset to zero.

I'm guessing it will change to the highest monthly rain rate at a future time. Maybe midnight tonight or possibly midnight Aug 31. The risk to data integrity seems low given this is official Davis advice.

So I'm now almost there. The bad monthly and annual values have gone. I have a valid monthly value and hopefully in the next few days I'll have a valid yearly value.

[Ray Proudfoot]

An update to my last post...

After clearing the (bad) annual high rain rate last week I was hoping it would then show the next highest annual rain rate value as advised by Davis support. It didn't change at midnight that day but I was hopeful it would change at midnight last night. Unfortunately it didn't and still only shows the highest rain rate since I cleared that setting.

It looks like I'll have to write to Davis support again to see how this value can be updated. I'm reasonably confident that once midnight 31 Dec 2009 passes the value will be stored in a different place and will become editable.

For whatever reason it doesn't look like the current year's high rain rate can be changed - only cleared.

[Cienega32]

For whatever reason it doesn't look like the current year's high rain rate can be changed - only cleared.

I can't swear to it but I THINK that was what I ended up being faced with and just living with the bad rain rate but I was apprehensive about diddling my data and chickened out of anything more than quickly deciding to live with it.

You've changed the Monthly and Yearly data but isn't there a Daily rain rate value available in the console edit mode?

[Ray Proudfoot]

I can't swear to it but I THINK that was what I ended up being faced with and just living with the bad rain rate but I was apprehensive about diddling my data and chickened out of anything more than quickly deciding to live with it.

You've changed the Monthly and Yearly data but isn't there a Daily rain rate value available in the console edit mode?

The console can only store a finite amount of data and 7th July is no longer available. If I'd spotted the problem earlier then yes, I would had to change that too. I think the console can only store the last 28 days of complete data but I'll need to check that when I get home.

I was apprehensive about editing this bad data but having read the documentation and using tinplate's excellent guidance notes I felt confident enough to do it.

I'm still confident this bad annual rain rate value can be altered. I think the current year's high rain rate is stored in a different location and is not editable. Once 1 Jan 2010 arrives I believe that value will be written to a different location - the first of the annual locations - and the current year will be cleared down ready for the new current year. At that point I'm sure I will be able to alter the bad value for 2009.

Things are definitely better now than before. I have a good monthly high rain rate and a lower than required all-time high rain rate but not the ridiculous earlier value.

[Ray Proudfoot]

An update on the annual high rain rate problem...

I received a reply from Davis support and they suggested I had used the wrong address to update the RAIN_RATE_YEAR_HIGHS for the current year.

So this morning I entered these commands

EEWR B1D D0
EEWR B1E 03

And equivalent EERD commands confirmed that 976 was now stored in those addresses. 9.76" is my high rain rate for 2009.

However, if I enter Graph mode and press v (down arrow) to go to the annual mode I still don't see 9.76" for 2009 even though in the ticker tape area it states Min 0.00 Max 9.76. The value it is displaying is the high rain rate for the current month. This doesn't seem right.

Can anyone else report what their VP2 is showing please? I want to ascertain if it's just my VP2 or if it affects them all.

[Ray Proudfoot]

I've done some more digging.

If I enter Graph mode on my VP2 and press the v arrow until I'm in Year mode the earliest year is 1985 and the latest 2009.

So by entering EEWR B1D D0 and EEWR B1E 03 I was effectively updating the 1985 value. I confirmed this by viewing 1985 High_Rain_Rate and 9.76 was stored there.

So 2009 appears to be the last address in the range B1D-B4E. So I entered:-

EEWR B4D D0
EEWR B4E 03

and OK was shown after each entry. However, when I read those addresses with EERD they still show the old values of 0D 01 (269).

So it looks to me as though something is not allowing the current year address to be updated. If anyone has the answer to this I'd really appreciate hearing from them.

[Ray Proudfoot]

I had high hopes that on 1 January 2010 my erroneous annual high rain rate value would be corrected. Unfortunately it wasn't.

I used the Terminal program to read what values were in addresses B1D and B1E and these showed D0 and 03 respectively which equate to 269 - 2.69" was the high rain rate in October when I last tried to correct the bad entry.

The correct value for 2009 should be 9.76" - 03D0 but despite entering EERW B1D D0 and EERW B1E 03 they were not accepted. I think I'll just have to give up on this now. I've had instructions from Davis on how to correct the problem but despite following those to the letter they also didn't work.

Maybe I have a female VP2 that just won't accept certain instructions. 

[killwilly]

Now now Ray, there are a lot of ladies on this forum. 

Alan.