Timestamping data

Thanks for the reply.

I was thinking for storing the data in an external EEPROM. For the first reading, I would save the time,obtained from an RTC or the uC itself.Then when the EEPROM is being read ,(to transfer the data to the PC),the subsequent times would be calculated,either by the uC and the data along with the time ,transferred to the Pc,or the time calculation would be done in the Pc itself. After a memory read,for the next reading,time would be saved again.i.e. time will be saved in the EEPROM only after a download takes place. Downloading would be done every few hours.Logging every few seconds.

I need the data and the real time when viewing the past data on the PC,either as a chart or a tabular.

Is the above thing a bad idea?What would be a good way of doing this?

What should I do during power downs?Have a battery running for the RTC?I havent decided on the RTC chip yet.Any suggestions?

I hope what I have said is clear.

Thanks.

How it is stored doesn't matter to the user. What matters is that the data output be correctly labeled with the time.

This can be done if the time between samples is fixed and not based on some external event such as an object passing the sensor.

If you use it in the wrong situation or have a bug in your software, you can mess up the timing.

No, not really. A micro running from a crystal can often keep track of the time well enough. Processors like the 8051 series can be set up to get an interrupt every 1mS or so. The can keep time in terms of the number of interrupts that happen.

I guess that may well be depending on the application case. You'd finally want to have the data together with the time information. What medium are you writing to ? At what speed in what intervalls ? How about a power down ? Is the media to be changed during a measurement ? Do you need absolute time or would incremental be sufficient ?

Rene

I don't think there is one generally accepted method.

It depends on how accurate the time needs to be and many other things.

If the time source you use at the beginning of the acquisition is accurate, and the sample clock is not accurate, frequency-wise, then your time will slowly drift. This may be OK. (You have to tell us, not the other way around. ;-) )

If this is the case, you may need to periodically refresh the time, somehow. But this could make your data collection more tricky.

If the sample clock is locked to the master clock, then I don't see any drawback to just recording the time once when you first start sampling.

--Mac

I'd suggest a Compactflash/MMC as storage. They cost in the order of 50$ for 256MByte. Since they are sector oriented, I'd have a FerroRAM as sector buffer which survives a powerdown without loosing the data. When the aquisition is as slow as yours, I'd just write the time & date of powerup and then the equally spaced data. All samples can be calculated forward in time then. Yes, the RTC has to run from a battery when the absolute time is necessary.

Rene

One method I know is used is counting the seconds since a "datum time" - I think one may be 1 Jan 1980. Others more knowledgeable would knwo what the options are - I think there are two standard datum times used, I think there are also some standard fucntions for converting this "tick" count back into a date/time.

When you connect to the logger, download the current count (of seconds elapsed since the datum time). The logger sleeps incrementing the tick cound every second (or portion/multiple etc). When a log is done the tick count is saved with the data. When the logger is unloaded the tick count is "post processed" back to the time/date. I hope this helps, it might suit your needs. rob