Important changes to forums and questions
All forums and questions are now archived. To start a new conversation or read the latest updates go to forums.mbed.com.
8 years, 10 months ago.
API: Ticker/Timer bugfix with constness in MBED lib release 100
Hello all,
I have STM32F401RE MB1136 rev C-01 nucleo board for development. I am planning to use interrupted analogical readings based on LowPower Ticker or Timer functions.
My aim is:
1 - Send analogical readings every N seconds with ticker (for example every 30 secs); 2 - Get analogical samplings and average it every N / X second (for N = 30 secs and X = 3 secs total 30 or 29? analogical sampling will be made and averaged and will be send every 30 secs with ticker or timer???) 3 - Can both approach solved by interrupts?
So, Firstly I decided to check a small code which sends a ASCII character over USB (with printf) to Comm Operator serial program every 10 seconds with Ticker. I set up the comm operator so that can also show the milliseconds of the received ASCII.
I realize that, in every 10 secs there is about 45 - 50 milliseconds slipping/deviation from interrupt timing. Also in showing passed seconds by time function in another code, sometimes i see the same passed seconds such as...
16 17 18 19 19 20 . .
I know that i can use RTC such as DS1307, and i did, but solving the problem just with ticker or timer will be good for me.
I wonder, bugfix in API: Ticker/Timer bugfix with constness in mbed release 100 has any solution to these problems?
Thanks for support,
Regards
1 Answer
8 years, 10 months ago.
The ticker should be as accurate as the clock on the board, typically for boards with a crystal you should see an error of around 20 ppm (20us per second) but it could be up to 100ppm. On boards without a crystal ( all of the Nucleo series ) the error will be a lot bigger. The same goes for the RTC, it'll be as accurate as its reference source, but that is always a crystal so in this situation it will be more accurate if you can use it.
You can fix the main clock error either fitting X3 on the board and changing the libraries to use the external source or by using an mbed that comes with a better clock source.
If you need better than 20ppm then you need to go with something like a GPS module with a configurable rate PPS output that you can use as an interrupt source. That will give you a very stable clock as long as you have a GPS signal.
Good posts, only for specifically the Nucleo boards the clocks are bit different. If you include the programming part, that will deliver a crystal based 8MHz (or 12, but I believe 8) clock to the MCU if I remember correctly, so thats relative accurate (of course with the normal accuracy of a random crystal). However since no RTC crystal is fitted it uses an internal oscillator for that, which is not accurate at all.
@Kamil, I can check later on what accuracy I see for ticker, but in general I don't think a serial terminal's timestamp is the most accurate measurement. Do you see a fixed error (lets sat always 10.05 seconds), or does it vary? (So sometimes 10.05, sometimes 9.95). In the last case I would expect it to be the serial terminal.
posted by 27 May 2015Sorry for late reply due to heavy work.
@Andy thx for the reply. I will try external crystal. I think nucleo auto recognise the external crystal?
@Erik I will try to determine the error as soon as possible and give the results.
Do you have any other suggestions for 3 issues in my first posts, i.e. 1 - Send analogical readings every N seconds with ticker (for example every 30 secs);
2 - Get analogical samplings and average it every N / X second (for N = 30 secs and X = 3 secs total 30 or 29? analogical sampling will be made and averaged and will be send every 30 secs with ticker or timer???)
3 - Can both approach solved by interrupts?
Regards
posted by 27 May 2015First results with 10 second Ticker interrupt, printing Hello to Comm Operator's screen:
Rec:(12:24:05.424)Hello
Rec:(12:24:15.299)Hello
Rec:(12:24:25.173)Hello
Rec:(12:24:35.033)Hello
Rec:(12:24:44.907)Hello
Rec:(12:24:54.782)Hello
Rec:(12:25:04.657)Hello
Rec:(12:25:14.532)Hello
Rec:(12:25:24.391)Hello
Rec:(12:25:34.266)Hello
Rec:(12:25:44.141)Hello
Rec:(12:25:54.031)Hello
Rec:(12:26:03.906)Hello
Rec:(12:26:13.781)Hello
Rec:(12:26:23.656)Hello
Rec:(12:26:33.530)Hello
Rec:(12:26:43.405)Hello
Rec:(12:26:53.280)Hello
Rec:(12:27:03.155)Hello
Rec:(12:27:13.030)Hello
posted by 27 May 201530 seconds Ticker interrupt:
Rec:(12:30:18.935)Hello
Rec:(12:30:48.528)Hello
Rec:(12:31:18.137)Hello
Rec:(12:31:47.746)Hello
Rec:(12:32:17.355)Hello
Rec:(12:32:46.964)Hello
Rec:(12:33:16.573)Hello
Rec:(12:33:46.197)Hello
Rec:(12:34:15.822)Hello
Rec:(12:34:45.446)Hello
Rec:(12:35:15.071)Hello
Rec:(12:35:44.679)Hello
Rec:(12:36:14.304)Hello
Rec:(12:36:43.928)Hello
Rec:(12:37:13.553)Hello
Rec:(12:37:43.177)Hello
Rec:(12:38:12.786)Hello
posted by 27 May 2015...and lastly 5 mins (300 secs) Ticker interrupt :
Rec:(12:45:05.579)Hello
Rec:(12:50:01.746)Hello
Rec:(12:54:57.912)Hello
Rec:(12:59:54.017)Hello
Rec:(01:04:50.262)Hello
Rec:(01:09:46.460)Hello
posted by 27 May 2015May be someone can think about the dependability of the comm operator's time... I think (in fact sure) it checks operating systems time (in that case Windows 7).
The ratio of the actual DeltaT to Configured DeltaT is around 0.986 - 0.987 but it is really a matter if u are planning to log data starting minimum from 5 mins... Even for 1 days period, too much data I miss or skip for my application...
In my first application which I prepared in Arduino Due by using DS1307, data retrival was almost perfect... But since the utilisation of interrupts for me are much more easy in embed, I thought I can use Ticker, Timer, Timeout etc., but I think I should re-consider the RTC solution again?
If you have an external 32k osc, can you perform this test and share the results?
Do you have any other idea or suggestions?
Thanks..
posted by 27 May 2015I wouldn't trust anything on windows 7 to give exact times, the interrupt time in windows is neither constant or predictable. However that would add random error to the time measured, you see a nice constant period so that shouldn't be a problem. The PC timing will also have a constant error related to the error on it's clock, that should be well under 100ppm so a far smaller error than you are seeing.
Also I hope you are using puts not printf for the output, printf could also add some random noise on the timing if you were to change the string you output but should be constant for a constant string. Also you should never use printf within an interrupt.
It looks like it is purely an issue with the clock source for your CPU, I don't have any neucleo boards to play with to verify this or try solutions.
When I needed accurate timings on mbed (better than than the few us per second that a crystal should give) over a long time period I used a GPS module with a configurable PPS signal. I used ublox but anything with a PPS (pulse per second) output where you can configure the rate will do.
After giving it 20-30 seconds to sync up to GPS that will give you a very stable interrupt source at whatever rate you want. If you need exact UTC time stamps on data faster than about 10Hz the clock synchronization gets a bit messy but is possible.
I've a couple of mbed based data loggers that run at up to 1kHz and record the exact UTC time of each sample by using this method.
posted by 28 May 2015
the bugfix is not relevant for your questions
posted by Martin Kojtal 27 May 2015