LeafLabs Garden » Topic: Time stamp for analogRead() Accuracy

LeafLabs Garden » Topic: Time stamp for analogRead() Accuracy http://forums.leaflabs.com/topic.php?id=717 A place to share, learn, and grow... en-US Fri, 22 Jan 2016 00:23:03 +0000 http://bbpress.org/?v=1.0.2 <![CDATA[Search]]> q http://forums.leaflabs.com/search.php gbulmer on "Time stamp for analogRead() Accuracy" http://forums.leaflabs.com/topic.php?id=717#post-4175 Wed, 06 Apr 2011 11:57:43 +0000 gbulmer 4175@http://forums.leaflabs.com/ StephenFromNYC - <blockquote> <blockquote> 16 MHz Arduino boards (e.g. Duemilanove and Nano), this function has a resolution of four microseconds (i.e. the value returned is always a multiple of four) </blockquote> I do not know how the Arduino resolution was determined for micros(). </blockquote> The Arduino millis() timer is driven by the ATmega's Timer/Counter0 peripheral, with is an 8bit timer. It is set up to count with a frequency of 16MHz/64, and hence counts at 4 microseconds. Timer/Counter0 generates an 'overflow' interrupt which is used to update a millis-count variable used by millis(). It isn't updated by software. Once it is initialised, it just counts from 0 to 255 in hardware. micros() uses the millis-count variable and the actual value of the hardware counter in Timer/Counter0 to give a time stamp with 4 microsecond precision. The time on the Maple, uses a STM32F hardware timer called <code>sysclock</code>, intended for timestamps. Like the Arduino's Timer/Counter0, it isn't normally updated in software; once initialised the timer keeps itself going in hardware. I just read the code, and it is counting at 72MHz, so the jitter on it is way smaller than 1 microsecond. (I was mistaken about the precision of this time source. The ST documentation suggests counting at a much lower frequency than 72MHz, so I had assumed maplelib did that, but it doesn't.) The nice thing about using timers is they don't 'jitter' because they count in hardware, and aren't effected by interrupts. The Arduino delayMicroseconds uses a similar 'busy wait' technique to the one in maplelib. Neither Arduino nor Maple use the underlying timers, but instead run some instructions a calculated number of times, so do have jitter caused by interrupts. (NB - <code>sysclock</code> isn't available as a source of triggers to the ADC.) (full disclosure: I am not a member of the LeafLabs staff) StephenFromNYC on "Time stamp for analogRead() Accuracy" http://forums.leaflabs.com/topic.php?id=717#post-4173 Wed, 06 Apr 2011 10:15:48 +0000 StephenFromNYC 4173@http://forums.leaflabs.com/ Here is an apples:oranges comparison. From the arduino web site: <a href="http://www.arduino.cc/en/Reference/Micros" rel="nofollow">http://www.arduino.cc/en/Reference/Micros</a> <blockquote> 16 MHz Arduino boards (e.g. Duemilanove and Nano), this function has a resolution of four microseconds (i.e. the value returned is always a multiple of four) </blockquote> I do not know how the Arduino resolution was determined for micros(). Enjoy! <a href="http://forums.leaflabs.com/profile.php?id=843">Stephen from NYC</a> (full disclosure: I am not a member of the LeafLabs staff) gbulmer on "Time stamp for analogRead() Accuracy" http://forums.leaflabs.com/topic.php?id=717#post-4163 Tue, 05 Apr 2011 20:41:56 +0000 gbulmer 4163@http://forums.leaflabs.com/ Brian - a DMA solution is a good solution, but if you are willing and able to 'get your hands dirty', a timer channel could be used to trigger the ADC conversion. This is slightly intricate code, but I guess less difficult than writing the DMA code. Even then, you might want to avoid it, but it would give very regular samples. You might find that their are several sources of delays: 1. analogRead takes about 6-7 microseconds; that is set in the source code of analogRead to ensure signals with a relatively high output impedance (eg. a few K ohms) are sampled reasonably faithfully 2. USB generates interrupts when the host PC polls the Maple, so sometimes those interrupts may happen after the delay(50), and before the analogRead, causing 'jitter' or variability 3. micros() might not have microsecond precision (I think its precision was a couple of usecs) 4. delayMicroseconds may suffer a bit from USB interrupts causing some variability too (for full disclosure: I am not a member of LeafLabs staff) bhclowers on "Time stamp for analogRead() Accuracy" http://forums.leaflabs.com/topic.php?id=717#post-4152 Tue, 05 Apr 2011 10:00:35 +0000 bhclowers 4152@http://forums.leaflabs.com/ Thanks Stephen, If your assessment is correct that I'll be happy to wait. Having explicit control over the acquisition rate would be fantastic. I'm looking at reads on the order of 50us to fill an array--well within the range of the processor speed. As for transferring data via USB, that was only used a way to look at the data after it was acquired. That function should have no bearing on the actual read times. I'll stayed tuned for that next release. Any ideas on a date? Cheers, Brian StephenFromNYC on "Time stamp for analogRead() Accuracy" http://forums.leaflabs.com/topic.php?id=717#post-4150 Tue, 05 Apr 2011 08:52:22 +0000 StephenFromNYC 4150@http://forums.leaflabs.com/ Hello- Brian, this may not be the quick answer you want, but I am waiting for the DMA functions which will be included with the next software release. With DMA the ARM Cortex M3 chip will perform analog reads (ADC) without using the processor (no need to call <code>analogRead()</code>). Just set up the required ADC timing and the DMA circuits should do the rest. I do not know how quickly or how much data can be sent via <code>SerialUSB</code>. I do not know how data acquisition by the Maple board and transmitting the data from the Maple board to the host is coordinated if you need high speed data acquisition via ADC. Thanks! <a href="http://forums.leaflabs.com/profile.php?id=843">Stephen from NYC</a> (full disclosure: I am not a member of the LeafLabs staff) bhclowers on "Time stamp for analogRead() Accuracy" http://forums.leaflabs.com/topic.php?id=717#post-4148 Mon, 04 Apr 2011 23:14:32 +0000 bhclowers 4148@http://forums.leaflabs.com/ I'm hoping this is a very easy fix. To start, I'm using Maple IDE 0.0.9 and the maple r5 board. The sketch I have at present attempts to fill an array with both a time stamp of when the data was acquired and the actual analogRead. The problem of the output can been seen below. Despite having a delayMicroseconds(50) there seems to be some sort of variable delay that takes approximately 7-8 microseconds. While livable, it would be nice to have a reproducible time stamp for the analog reads placed into an array--or any process for that matter. I tried introducing the noInterrupt() call but that still produced the same result. Any ideas would be appreciated. Cheers. Brian SerialUSB Output: #################################### Micros DeltaT AnalogIn 6152400 , , 2370 6152457 , 57 , 2266 6152515 , 58 , 2186 6152573 , 58 , 2129 6152631 , 58 , 2089 6152688 , 57 , 2056 6152746 , 58 , 2033 6152804 , 58 , 2167 6152862 , 58 , 2115 6152920 , 58 , 2076 6152977 , 57 , 2047 6153036 , 59 , 2178 6153093 , 57 , 2120 6153151 , 58 , 2077 6153211 , 60 , 2048 6153268 , 57 , 2027 6153326 , 58 , 2156 6153384 , 58 , 2107 6153442 , 58 , 2074 6153500 , 58 , 2045 6153557 , 57 , 2177 6153615 , 58 , 2119 6153673 , 58 , 2075 6153731 , 58 , 2050 6153788 , 57 , 2029 ################################# int analogPin = 0; // our array size int size=25; uint32 time[25]; uint32 rawdata[25]; void setup() { pinMode(analogPin, INPUT_ANALOG); SerialUSB.begin(); } void loop() { //noInterrupts(); for (int i=0;i<size;i++) { time[i]=micros(); rawdata[i]=analogRead(analogPin); delayMicroseconds(50); } for (int i=0;i<size;i++) { SerialUSB.print(time[i]); SerialUSB.print(" , "); if (i > 0) { SerialUSB.print((time[i]-time[(i-1)])); SerialUSB.print(" , "); } else{ SerialUSB.print(" "); SerialUSB.print(" , "); } SerialUSB.println(rawdata[i]); } SerialUSB.println(""); delay(3000); }