WS3085 Memory full causing error

[BrunswickWeather]

It appears that when the memory of WS3085 becomes full an error occurs. This error appears when Cumulus MX is stopped,restarted next morning and the memory has become full or has started to overwrite previous records (which is normal) during this time. It shows as a spike but does correct itself.
I also have a copy of Cumulus 1 which does not have this error, it does not show any spikes. I do not run both at the same time.
To fix the data in Cumulus MX I have copied from the correct records in the monthly log file from Cumulus 1 to Cumulus MX. And to fix the dayfile, I ran createmissing.exe then removed the error entry in mysql dayfile and used exportToMysql to add the correct entry.
Enclosed log files for both MX and Cumulus 1.
This has happened before.

[mcrossley]

As far as I know the 3085 memory doesn't actually become "full" it is a circular memory array.

But a couple of people have noted issues recently when downloading the historic data. The previous report looked like the data was being corrupted over the USB connection, but again Cumulus 1 did not have the issue. I cannot tell in your case unless you try again and run Cumulus MX using the -debug command line switch to turn on debug and data logging.

Nothing has changed on Cumulus side of how it handles FineOffset USB devices in a long time, so I'm not sure why these odd reports are happening now.

I have an old 1090 device that I use for testing and that does not show any problems, so diagnosing this will be difficult.

[BrunswickWeather]

Attached updated files with Debug and Data logging on. Included monthly files for March and April.
After closing down and restarting Cumulus MX the readings are correct in the new session but of course previous data is faulty..
At about line 650 in the debug file the error is shown.
Maybe at end of memory as it starts to record data at the start of the memory extra data is sent from the station console?
I know Steve is no longer involved but maybe he can shed light on this.

[BrunswickWeather]

It is not memory full error!

Error reading data WS3085 when resuming after station close down, when the roll over happens and the record address restarts at 0010
Causes "spikes" and the message "Read logger entry for 2021-04-23 6:46:49 PM" is the same for many record reads. This starts at record address 0024 downwards.

My calculations and theory may be wrong

My station is WS3085 with solar.

Is the address FFFFFFFC correct?

Max address FFEC as per FOSStation.cs.

When the program reads the records down, what should the record address be after 0010?

I feel it is reading the wrong bytes. When after a new restart Cumulus MX reads records correctly with the correct data but the damage has been done.
Cumulus 1 reads current pressure and the current record address from addresses at 00000 and 000020 as shown in the Cumulus 1 diag file.
This problem only happens when past records are read after the system has been stopped, a new day and record address goes below 0010 .
I did have the same problem with earlier versions of a Fine Offset stations with solar in MX, not sure if this happen in earlier versions ie 3043, so it is not just WS3085.
Does not happen in Cumulus 1.
My current solution with the error in MX is to copy Cumulus 1 data across to MX and then run Create Missing which fixes the dayfile for "feels like" info.

It does not matter if the logger is full or not. This last problem occurred when the logger was only about at 75%.

From FOStation.cs

hasSolar = cumulus.StationType == StationTypes.FineOffsetSolar;

if (hasSolar)
{
foEntrysize = 0x14;
foMaxAddr = 0xFFEC;
maxHistoryEntries = 3264;
}
else
{
foEntrysize = 0x10;
foMaxAddr = 0xFFF0;
maxHistoryEntries = 4080;
}


From MXDiags

21-04-24 09:00:59.378 Read logger entry for 2021-04-23 7:30:49 PM address 0038
2021-04-24 09:00:59.545 Read logger entry for 2021-04-23 6:46:49 PM address 0024
2021-04-24 09:00:59.710 Read logger entry for 2021-04-23 6:46:49 PM address 0010
2021-04-24 09:00:59.864 Read logger entry for 2021-04-23 6:36:49 PM address FFFFFFFC
2021-04-24 09:01:00.031 Read logger entry for 2021-04-23 6:36:49 PM address FFFFFFE8
2021-04-24 09:01:00.184 Read logger entry for 2021-04-23 6:36:49 PM address FFFFFFD4
2021-04-24 09:01:00.340 Read logger entry for 2021-04-23 6:36:49 PM address FFFFFFC0
2021-04-24 09:01:00.497 Read logger entry for 2021-04-23 6:36:49 PM address FFFFFFAC
2021-04-24 09:01:00.652 Read logger entry for 2021-04-23 6:36:49 PM address FFFFFF98
2021-04-24 09:01:00.815 Read logger entry for 2021-04-23 6:36:49 PM address FFFFFF84

Enclosed the full MXDiags file also a Cumulus 1 diags file (but not from the time of the error).

[BrunswickWeather]

From FOSStation.cs

if ((interval != 255) && (timestamp > cumulus.LastUpdateTime) && (datalist.Count < maxHistoryEntries - 2))
{
// Read previous data
addr -= foEntrysize;
if (addr == 0xF0) addr = foMaxAddr; // wrap around

ReadAddress(addr, data);

Is the wrap around statement correct?

2021-04-24 08:21:18.623 Read logger entry for 2021-04-23 6:47:09 PM address 0024
2021-04-24 08:21:18.790 Read logger entry for 2021-04-23 6:47:09 PM address 0010
2021-04-24 08:21:18.946 Read logger entry for 2021-04-23 6:37:09 PM address FFFFFFFC

[mcrossley]

I agree...

The issue is the test for the lowest address is wrong...

Code: Select all

if (addr == 0xF0) addr = foMaxAddr; // wrap around

This will never be hit. So MX carries on subtracting the log entry size, which reads down into the fixed memory area, then wraps around to the large number you see in the log file.

The lowest memory location used (for both station types) is 0x100, so the test (to work with both types) should be...

Code: Select all

if (addr < 0x100) addr = foMaxAddr; // wrap around

I'll fix this in the next release (and add a couple of bonus extras - checking the station logger interval matches MX, and only reading history entries up the number the station says it has recorded, rather than the max logger capacity as it does now)

[BrunswickWeather]

Thanks Mark,

I found this in a Diags file in Cumulus 1 from 2016 in an old backup disk, which confirms your post.

2016/03/08 11:22:35.310 : 11:22:35 AM EWUSB: Get history data
2016/03/08 11:22:35.311 : Request EW data block, addr = 000000
2016/03/08 11:22:35.329 : EWUSB: EW startup data line 01 55 AA 7B 80 00 6F 10 01
2016/03/08 11:22:35.336 : EWUSB: EW startup data line 02 01 12 00 10 01 01 12 00
2016/03/08 11:22:35.345 : EWUSB: EW startup data line 03 1E 20 02 21 09 00 00 00
2016/03/08 11:22:35.352 : EWUSB: EW startup data line 04 10 00 00 01 00 00 00 01
2016/03/08 11:22:35.353 : Request EW data block, addr = 000020
2016/03/08 11:22:35.369 : EWUSB: EW startup data line 05 C3 27 89 27 00 00 00 00
2016/03/08 11:22:35.369 : EWUSB: Read pressure values: rel=1017.9 abs=1012.1 offset =5.8
2016/03/08 11:22:35.376 : EWUSB: EW startup data line 06 00 00 00 16 03 08 11 20
2016/03/08 11:22:35.385 : EWUSB: EW startup data line 07 41 23 C8 00 00 00 46 2D
2016/03/08 11:22:35.393 : EWUSB: EW startup data line 08 2C 01 64 80 C8 00 00 00
2016/03/08 11:22:35.393 : UseDataLogger set, read current data
2016/03/08 11:22:35.394 : Request EW data block, addr = 000100
2016/03/08 11:22:35.408 : EWUSB: EW startup data line 09 02 4D FF 00 37 1D 01 89
2016/03/08 11:22:35.417 : EWUSB: EW startup data line 10 27 0A 14 00 0A CF 00 00
2016/03/08 11:22:35.425 : EWUSB: EW startup data line 11 7F 0D 0B 05 0F 3A D2 00
2016/03/08 11:22:35.432 : EWUSB: EW startup data line 12 42 98 00 C1 27 0A 18 00
2016/03/08 11:22:35.433 : Request EW data block, addr = 00FFEC
2016/03/08 11:22:35.448 : EWUSB: EW startup data line 13 0F 3A D2 00 41 98 00 C3
2016/03/08 11:22:35.457 : EWUSB: EW startup data line 14 27 07 11 00 0E CC 00 00
2016/03/08 11:22:35.457 : EWUSB: Data: 0F 3A D2 00 41 98 00 C3 27 07 11 00 0E CC 00 00
2016/03/08 11:22:35.464 : EWUSB: EW startup data line 15 00 00 00 00 55 AA 7B 80
2016/03/08 11:22:35.464 : Solar Data: 00 00 00 00
2016/03/08 11:22:35.473 : EWUSB: EW startup data line 16 00 6F 10 01 01 12 00 10
2016/03/08 11:22:35.473 : EWUSB: interval = 15
2016/03/08 11:22:35.473 : EWUSB: timestamp = 2016/03/08 11:20:35 AM
2016/03/08 11:22:35.473 : EWUSB: Lastupdatetime = 2016/03/07 8:39:00 PM

[davepaterson]

I have a post on the forms for the WS3085 missing data in the morning after an overnight shutdown an went back to Cumulus1 which was able to download all. After crazy UV and solar readings on the 7th May I went back to MX. I wanted to do a check on downloading a large number as I will be away for 7 days and copied MX to drive D on the 28th and left until the 30th for the next download. The download started at 21:15 but at 21:21 and it was still just showing 'Downloading Archive Data' D_MX20210530-211456.zip attached there is only 1163 entries but no log file were entered. Using the Cumulus1 files from the 7th I downloaded using Cumulus1 from my spare station, the 3250 entries started at 21:24 and completed by 21:24 cumulus_004.zip. MX on my main station had been off for 2:24 and I lost 33 entries from the download C_MX20210530-215456.zip attached.
note I change the name of the Cumulus folder in D whether it's MX or 1 and rename the other one.
As there is a new month coming Cumulus1 will be used again.
The station WS1093 that I had been using never gave me these problems using MX

C_MX20210530-215456.zip

C_MX20210530-215456.zip

C_MX20210530-215456.zip

[mcrossley]

It all looks OK to me.

The first run @21:15 on the 30th was still downloading the logger data when you stopped it after 6 minutes.

With your current settings it is reading ~3 log entries per second, you were off line for 2988 minutes, at 1 minute logging interval, that is also 2988 log entries.

A very rough calculation 2988 / 3 ~= 16 minutes to download the log data.

The USB read delay in advanced settings is set quite conservatively at 150ms, you can try reducing that, I'd try it at 50ms and see if that is OK, then try halving from there until it errors (or not, it may work at zero with your station). That will speed up the logger read if you can reduce it to a reliable value.

[davepaterson]

I have downloaded 14 days entries at 6 for the interval with MX and my old station and don't remember it taking a long time. One advantage cumulus1 has over MX it shows what it is doing during download and cumulus1 took only 3min to download 3252 entries. Will try MX again with the reduced value and put the result on here.

[mcrossley]

The .Net library used to read the USB HID devices does not seem to be as fast as whatever Cumulus 1 used. But 2988 * 150ms = nearly 8 minutes of extra "delay" being added.

The delay doesn't normally matter, but in your case when downloading a lot of data it adds up.

When I have added new stations to MX I have added a archive data progress to the console log, and I retro fitted to the Davis VP2, but that is it so far.

[davepaterson]

Thanks Mark.
Going to stick with C1 as it seems to be more efficient at handling the way I am doing things and possible I was still using an interval of 5 as a standard and only started using 1 towards the end of last year with the old stations and then with the WS3085 and ran into a whole load off problems