Timestamps and Data Logging on XmegaA3BU

Go To Last Post
14 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

 

I'd like to add a timestamping and data logging section to my data acquisition code. It would be great to have anyone's input.

 

I was thinking that, for polled or interrupted ADC readings, I'd use an RTC to stamp the time along with the data at, say, channel 2. Something like: [time] [16-bit data] [channel #].

My goal is to see the real sampling frequency of the ADC. Funny thing is I know that just by testing it, it'll slow it down, but I'd still like to observe it.

 

From there I'm planning to write the data to the chip's EEPROM, or an external EEPROM, for later reading. My roadblock here is that it would be great to be able to easily plot the data into Excel, but with the format that EEPROM records the data in, I think this would be fairly challenging. Converting the data from hex, and then separating the points from one another, that seems like it would be a huge pain. Then again, I'll do it if I have to.

 

Are there better ways of doing these things?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well, Excel knows nothing about EEPROM nor AVRs - so something in the AVR is going to have to read the EEPROM, and then send to the PC for Excel.

 

The most obvious way would be to send it to the serial port - so you just read a (time, data, channel number) triplet from EEPROM, then

printf( "%d,%d,%d", time, data, channel_number );

 

Capture that to a text file, and Excel can read it as CSV.

 

QEF.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

On-chip EEPROM is not very big and not very fast.
You can fit the channel # into the 16-bit data. The ADC is only 12-bits.
You can either store Unix time_t in 32-bits or use a 16-bit offset from a special Start time_t
.
Having filled up the EEPROM, you can process the stored info into a human readable form or an Excel readable form.
.
If you end up with an external I2C or SPI Eeprom chip, they have reasonable page sizes. As you do the logging, store a page's worth in SRAM before writing to the chip.
This should allow you to log at a reasonable speed while the previous page is being written.
.
David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

daisy148 wrote:
with the format that EEPROM records the data in

Surely, the EEPROM records the data in whatever format >>you<< tell it.

 

daisy148 wrote:
My goal is to see the real sampling frequency of the ADC. Funny thing is I know that just by testing it, it'll slow it down, but I'd still like to observe it.
Interesting goal, if you intend to log the values that result from each conversion, plus a timestamp.

 

As you are posting in the Xmega forum, let's use 1Msps as a start -- one conversion result each microsecond.

 

Any EEPROM operation (internal? external?) operation is going to be an order of magnitude or more slower.  So what is the point?

 

You could set up twin DMA buffers, one for the results and corresponding for some timer ticks.  Have the RTC reading be a "base" with ticks offset.  Then you could record maybe 1000 samples.

 

I fail to see the utility of fast sampling and a full RTC stamp.

 

Excel uses its own date/time format.  I have a conversion routine I use to go from "unixtime" to "exceltime".  I convert the logs from my AVR apps to comma-separated .CSV.

 

Does your RTC really have a resolution finer than one second?  Fast enough to distinguish the single microsecond between conversions, and take no overhed to get it?

 

 

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

My goal is to see the real sampling frequency of the ADC.

 

Two additional thoughts to those mentioned above:

 

Be sure to look at the number of Write cycles the EEPROM will allow, it is limited.

 

If you really want to do this, then have a look at a FRAM chip, or other option.

It will be, IIRC, both faster for a Write operation, and essentially unlimited in its lifespan.

 

That said, if the above is really the goal, then I think you are approaching it from the wrong angle.

If you have an O'scope, simply pulse a pin with each ADC operation.

On some of the micros you can Toggle a pin's state, one operation.

Just know then that each High pulse represents two ADC readings...

 

The time to configure a time stamp, and the time to save or upload it, will be far far longer than the ADC processing time.

 

Don't have an O'scope handy, then write a loop to take 1000 or 10,000 ADC readings, (or whatever), and turn an LED On at the start, Off at the end, and time that, either by eye for a rough count, or using another micro for a better count.

 

JC

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for the great responses.

 

I like the idea of using DMA for recording data, and using an o'scope for sampling frequency.

I'm a lowly mechanical engineer so I'm not familiar with DMA. Does setting up a DMA buffer mean initialising a DMA channel, writing the code to transfer the data from readout, through the DMA channel, into an array in RAM?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

DocJC wrote:
If you really want to do this, then have a look at a FRAM chip, or other option.

Let's say OP does indeed add or use some fast storage.  To what end?

DocJC wrote:
My goal is to see the real sampling frequency of the ADC.

How would adding such storage tell the real sampling frequency of the ADC?

 

1)  The desired sampling frequency is "low" -- say, 1ksps.  Why does it need to be verified? 

 

2)  But perhaps there is a language barrier, and OP is really saying "I want to take a number of samples of a signal at a reasonable rate, and create a 'log record' for each for later analysis".  That certainly would make sense.  A full RTC timestamp for each is a bit of overkill; one can have the "session" have a start timestamp, and each sample an offset.  That said, Unix time stamp is 32 bits, and gets you down to a second resolution.

 

2a)  So before further speculation,  what >>is<< the max frequency of these samples?  How many are in a session?

 

3)  If the question is indeed the way I read it, "What is the fastest sampling rate I can get from an Xmega ADC?" then logging each, even to fast storage, will never answer that question, will it?  At 1Msps, that gives one microsecond for each sample to fetch the result and park it, along with fetching the timestamp and parking that.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

How would adding such storage tell the real sampling frequency of the ADC?

It wouldn't, which was the second 1/2 of my post.

 

Toggle a pin and look at the sample rate on an O'scope.

 

Easy.

 

JC 

Last Edited: Thu. Aug 10, 2017 - 08:57 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Why do you need to measure the ADC sampling frequency? Do you suspect that the datasheet is wrong?

 

The datasheet has precise timing information. A very easy way to verify it is to simply record the number of samples taken in one second.

 

Or do you mean the bandwidth of the ADC in your circuit? In that case you probably only need a small number of samples, and can cache them in RAM for later writing to EEPROM or USART.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The reason for checking the sampling frequency is more to 'check a box' for a project. I just want to see what a lower-limit might be for the frequency to see if it will be enough ADC feedback to update motor speeds. Probably unnecessary, so I totally get what's being said, but someone on my team for a school project wants to know, so I'm just going to do it.

 

I like the o'scope idea, or caching in RAM - I'll give that a try

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Is there anything else in the datasheet you don't trust? I mean it says that PC (without BOOTRST) will default to 0x0000 at power on but can we really believe that?

 

The fact is that synchronously clocked electronics is going to be fairly deterministic. If the datasheet says the ADC will be clocked at F_CPU divided by the ADPS prescaler and that it will take 13 such ADC clocks to make a conversion then, on the whole you can be pretty sure that is exactly how long it will take. It's not like some of the time it pops outside to have a fag or something like that!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That's true. Yah, you guys are right, I think I'm not going to do much when it comes to the sampling frequency if at all. 

 

For the data logging though what do you think? Planning on.. status pin -> event -> ADC -> DMA -> FRAM for writing

Only thing though is for reading I'm trying to think what would be an easy way to have the data copy-and-pastable, so I was thinking FRAM-> EEPROM

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It will be far easier to analyze, post-experiment, if you output in csv format with lines terminated by a CR. Then, you can open it directly in almost any spreadsheet.

 

From painful experience, I can also tell you that the analysis is a LOT easier if you have the time stamp and ADC data in a single line (record). Dealing with alternate lines, one ADC and one timestamp, is challenging in a spreadsheet. Single line is dead easy.

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That's what I was concerned about. Thanks for the advice.

I'm getting to that point soon, so I'm taking note