Timebase stability

[ngkdc]

I've created a once-per-second machine using the code provided here, and after constructing a simple elapsed timer for my product, I found that it was running slow. No problem, lower the "every x cycles" number. Problem is, I have to keep readjusting this number, based on room temperature. Right now, I'm adjusted to 48942 cycles; on Friday I was keeping time within 8 seconds per hour ... right now I'm slow by 12 seconds (in only 27 minutes).
Just how accurate is the processor timebase supposed to be? If I'm seeing errors in this simple task, just how accurate will the timers and any other code be? The board is mounted as-received on the development kit motherboard with the processor up.

I'd rather not have to impliment an off-board timebase, but I do need accurate timing for some of my calculations. Any suggestions?

Thanks,

Rick

[g_jilek]

Hi Rick

I haven’t observed any time base variations on the Pod, but I haven’t looked for them as of yet either. O couple of things I can think of doing for starters would be to start collecting data i.e. speed vs. temp. If the time-base is indeed wandering based on temp you should get a nice clean looking data set that directly correlates to temperature. Keep your temp probe as close to the Pod as possible; 6 inches on the bench can make a difference.

If the time-base is temp sensitive the next question would be is “How stable will the temp be in the actual application?” Can you stabilize the enclosure temperature, or will it be stable by nature? i.e. Will the system as a whole come up to an operating temp and stabilize?

Food for thought.

Good luck,

Gerard

[nmitech]

The accuracy of the timebase is limited by the processor crystal. That's probably about 0.01% (100 ppm), which should be less than 0.16 seconds in 27 minutes.

However, when using EVERY x CYCLES to run a periodic task, it is possible for clock ticks to be missed...depending on the complexity of the periodic task and other load on the processor. This is described in the documentation on "IsoMax Performance Monitoring." For short durations you can monitor the
variable TCFTICKS, which will remain accurate regardless of load (unless your application turns off interrupts, which it shouldn't do). For longer measurements you can either use TCFTICKS to update a 32-bit counter, or watch the variable TCFOVFLO to adjust your EVERY n CYCLES counter.

[ngkdc]

Thanks for the reply. I am intending this to run in an industrial application, thus temperature stability is really important. Based on what I've measured thus far, I'm seeing about 1045 ppm at 76°F (air conditioning on). Last week, I was working with the window open, so the humidity was higher (from about 45% to 85%, and temperature was a little higher (82-84°F).

Yes, I COULD measure, calculate and correct, but I'm looking at having to fine tune LOTS of these little puppies ... a thought that doesn't sit well right now. If I've identified the crystal manufacturer correctly, the crystal used should be ± 30 ppm tolerance, and ± 50 ppm stability over a -10 to + 70°C range (14 to 158°F). Tolerance now appears to be - 1045 ppm, and the stability is questionable, because I don't have my precision measurement equipment available right now.

My initial suspicion is the crystal is not up to snuff; but with a sample size of one, I can draw pretty much any conclusion I want; the reliability, however, is suspect! :)

I've already changed the mounting orientation to allow the heat to escape easier rather than soaking the processor and crystal; this doesn't seem to have made much difference in my timing issues ... but you can touch the processor without getting burned!

Right now I'm running 25 seconds slow (at 15 minutes) ... which makes my mechanical wall clock much more accurate (it only loses about 3 seconds a day).

Again, while I can (and have) calculated the offset to insert into my program, the fact that I have to recompute it almost constantly is a major concern. I'll work out alternative solutions if this is not easily resolved (things like installing an off-board TCXO (temperature controlled crystal oscillator), or a real-time clock with a 1-second pulse output. I can then take the 1-second pulse to an input and use that to trigger my counter events, rather than counting tics.


Regards,

Rick

[ngkdc]

_________________________________________________
The accuracy of the timebase is limited by the processor crystal. That's probably about 0.01% (100 ppm), which should be less than 0.16 seconds in 27 minutes.
__________________________________________________

Concur
__________________________________________________
However, when using EVERY x CYCLES to run a periodic task, it is possible for clock ticks to be missed...depending on the complexity of the periodic task and other load on the processor. This is described in the documentation on "IsoMax Performance Monitoring." For short durations you can monitor the
variable TCFTICKS, which will remain accurate regardless of load (unless your application turns off interrupts, which it shouldn't do). For longer measurements you can either use TCFTICKS to update a 32-bit counter, or watch the variable TCFOVFLO to adjust your EVERY n CYCLES counter.
___________________________________________________

I'll look at TCFTICKS and see what happens.

Thanks,

Rick

[ngkdc]

NMI to the rescue once again!!!

Checked TCFOVFLO, and sure enough it was clocking up. I am sending serial data out the second serial port to a Noritake VFD ... and I had earlier created a CTS loop that looked at the busy line from the Noritake.

It appears that the Noritake does not have any character buffering ... and when I execute my CTS loop, I'm hogging cycles instead of coming back later.

To prove this, I sent the data out SCI0 instead of SCI1, and the clock is running correct (well, it's about 2 seconds fast in an hour, but I've gotten a fix for that as well). I suspect the Noritake is temperature sensitive and that is why my timing changed with temperature.

Short answer is to modify the CTS routine to skip transmitting a character if the line is high, rather than sitting in an idle loop waiting for the display to clear.

Long term solution is to get a better display, one that does have a character buffer, so I don't have to babysit a busy line.

Thanks again NMI ! ! ! ! :cool:

Rick

[RMDumse]

If this delay due to the display is really your problem (sounds like you've got it figured, though) it's a good time to point out how badly backwards branching loops can consume your processor time. The language works if you avoid them. But if you choose to use a Program Counter Capture Loop, you have to be aware it may break the paradigm, and form its own system stopping "Wait State", while everything else just has to slip.

[ngkdc]

Yes ... it appears that the display is the issue. I should have switched displays when I first ran into the lack of buffer, but since the boss really liked the look ...

The clues were everywhere ... the program wouldn't start if the display was not powered up ... and I completely ignored them.

You do have the right answer ... don't tie up the processor doing nothing but waiting. I'm not sure how to do that ... but that's part of my learning process (help IS welcome!).

I've several projects waiting ... and the Isopod will fit all of them nicely. They all require a user display as well, so the time invested getting the hardware combination working is not lost.

*****

I'm wondering if I shouldn't be looking at a 4 or 8 bit wide parallel LCD instead ... though I'm still unsure how I'll deal with the lack of a buffer in the display.

Thanks,

Rick

[RMDumse]

When you run into a situation where you are tempted to use a backwards branch, such as a BEGIN... ...UNTIL, BEGIN... WHILE ...REPEAT, or even sometimes a DO... ...LOOP, you really have to stop, and realize you're wanting to make a Wait State. A State has to go into a machine, and if you don't want to hold up the machine or program section you're currently in, then you know... I must need a new machine!

So your example is a good one. You know you want to send serial characters. But you can't send them as fast as you want to, because of external hardware conditions. So... what you need is another machine. Maybe the whole purpose of this machine is just to buffer and dole out serial characters to the display when it can take them.

It might even have only a single state in a machine. The transition might be conditional on CTS low and character in Buffer and the action is take the char out of the buffer, move the buffer pointer, put the char in the serial, and go back to the same state.

While it may seem alot of work for a little delay, it's "the right thing to do and the right way to do it".