Time stamp in data file?

[WetAndWindy]

I'm trying to use an old fine offset station WH1081 that doesnt work with the external sensor, for recording underfloor heating response times. Its working ok except that while testing just now I noticed that the times in the data file seem to be determined by the time that the download occurs rather than the time that the fine offset would have recorded the data.

FYI - While testing I've set it to 5 minutes but in use it will be 30 minutes.

Data file with a few records in is attached where the inconsistency can be spotted.

Is there an explanation or am I doing something wrong or making a wrong assumption please?

Thanks.

WnW

[steve]

It's not obvious from the file what you think the problem is. The entries are 5 minutes apart, why do you think they are timestamped with the time they were downloaded rather than the time they were recorded?

Note that Cumulus has to calculate the timestamps for data downloaded from the logger, as the entries are not timestamped. It does this by working backwards from the current time, using the interval in each entry. So the most recent entry downloaded will have the current time as its timestamp (because the most recent entry will always have been written within the last minute).

[WetAndWindy]

Thanks Steve, your second paragraph answers the question and is verified by that data file I posted.

If you look again at the data file the first seven records were downloaded at 17:53, the next set at 18:14, you can see the discontinuity where the data sets meet at records 7 and 8.

I have to say that i hadn't realised that the data logger did not record the time, surely this can introduce significant timing errors if larger time intervals are used.

Thank you for your answer.

[steve]

The interval shouldn't make a difference, the calculated timestamp should always be within a minute or so of the actual time the data was recorded, assuming the PC clock is correct. If you leave Cumulus running, then it's not an issue anyway, and the timestamps will always be correct.

[WetAndWindy]

I'm sure that this is me misunderstanding but surely if the time stamp is determined by working backwards from the time of the download then it can be anything up to the time interval out.

[steve]

Each logger entry has the interval for that entry in it, including the entry currently in use. So working backwards from the current time involves subtracting the intervals in each entry. It doesn't matter what the interval is set to, the result has the same accuracy.

[WetAndWindy]

But what if the last entry was 20 minutes before the download. I'm assuming two things here which relate to how I use it:-

1. That the time interval is 30 minutes
2. That the logger is no always connected

[steve]

The last entry is always the current entry and will always have been written to within the last minute. The station doesn't have separate memory for archive data and live data, it is all treated the same. Live data is written to the latest logger entry. Cumulus downloads all of the recent logger entries, including the one that is still being used.

[WetAndWindy]

I don't get it. How can the last reading have always been made in the last minute? Doesn't a 30 minute interval mean that each record is written 30 minutes apart, so how can there always be one written in the last minute?

[steve]

The station writes to the current logger memory location every 48 seconds, regardless of the logger interval you have configured. At the configured logger interval, it moves on to the next logger memory location, leaving the previous location with its final contents as archive data.

[WetAndWindy]

>>The station writes to the current logger memory location every 48 seconds, regardless of the logger interval you have configured.

Hah, I see. I was thinking that by configuring a longer time I would get more days from the memory.

Thanks for sticking with me.

[steve]

Hah, I see. I was thinking that by configuring a longer time I would get more days from the memory.

Yes, you would. I'm clearly not explaining it very well. Let me start from the beginning...

The station has an area of memory of which conceptually consists of 4080 16-byte locations (this is for non-solar sensor models). At any given time it is using just one of those locations, and it keeps the address of that 'current location' elsewhere in memory. Every 48 seconds, it writes the current set of sensor readings to the current location, overwriting the previous set of readings. As well as the sensor data, the memory location holds a byte which contains the 'age' of the location in minutes - the length of time that it has been using that entry.

Once a minute, it increments the 'age' of the location. If the age is equal to the configured logger interval (e.g. 10 minutes), it advances the 'current location' address to the next location, so that when it next writes sensor data to memory, it writes it to a new location, and the previous readings are left behind as archive data, no longer being overwritten. So at any give time, you have (potentially) lots of older entries with their age set to the logger interval, and one location - the current one - with an age of anything up to the logger interval.

So a longer logger interval doesn't affect how often the current location is overwritten with new data, that's fixed at 48 seconds, but it affects how frequently it moves on to the next location, and hence how long it takes for it to get from the start of memory to the end (at which point it 'wraps around' and starts using the first location again).