Axon Internal Clock

[Aberg098]

I am using an Axon to sent out some sensor data back through UART and I'm trying to get some time stamps to go with my data. So what I've done is read the Axon clock time using

Code: [Select]

Time = clockGetus();
I'e been hitting an obstacle in the form of the clock resetting after a while, which messes up the time stamps.

To make a long story short, what is the maximum value of the Axon clock? My current testing reveals that it resets back to zero around 3200 seconds (~53 minutes). Is there any way to extend the maximum to say 6 hours?

[Webbot]

Quick answer is 'no'. Most apps are interested in much smaller time differences - so I can only make the clock handle larger values by loosing the accuracy of the low level - which is a no go.
However: there is nothing to stop you defining your own variable and every time you read the clock then see if it is smaller than last time (ie it has wrapped around) in which case you increment your variable.
eg if the clock is providing the 0-53 minute time then your variable is tracking the whole number of 53 minutes.

[Admin]

The method Webbot suggests is what I'd do.

That said, the Axon clock has a small percentage error, I think it was 20 seconds off for every hour or something like that. It's a little different for every Axon.

So if accuracy is a concern, you can buy a RTC (real time clock) and use it to time stamp your data.

Here are two and I'm sure you can find more . . .

http://www.sparkfun.com/products/99
http://www.sparkfun.com/products/10160

[Aberg098]

Thanks for the input,

Unfortunately, I've looked into RTCs and none that I've found have resolution under a second: I need more than that.

I've now tried another approach. Instead of using the time stamps, I will have the Axon calculate the interval of time needed for each measurement sequence. I read the value of the Axon clock at the beginning of the measurement and once again at the end. Subtracting both values gives me a length of time, which I can output.

On the computer end I can then add up the intervals in order to get the measurement time.

This solution seems to work fine, except when the Axon clock resets back to zero, which screws up my subtractions. I would like to add an if statement of somekind to correct this, unfortunately, this brings me back to my original question of:

What is the maximal value of the Axon clock?

[madsci1016]

What is the maximal value of the Axon clock?

http://webbot.org.uk/WebbotLibDocs/object.jsp?id=27581

Though it seems it should be around 7 minutes, not the 50 something you are getting.

[Aberg098]

I'm getting conflicting statements about that particular link in the Webbotlib documentation.

Though it seems it should be around 7 minutes, not the 50 something you are getting.

The documentation shows  the length is either:
0xffffffff (I'm assuming this is hexadecimal)
429,4967,295 microseconds (this one has a comma that is misplaced, so I'm guessing this is 4,295 seconds or  roughly 72 minutes.)

Google calculator tells me that 0xffffffff is 268,435,455 microseconds, not the number indicated in the documentation. This would mean 4.47 minutes.

None of these numbers seem to match. So which one is the correct value?

[Webbot]

Its a 32bit number so in hex is 0xffffffff or in decimal is 4,294,967,295 uS
= 4294 seconds = 71.566666  minutes

In practice though you may see a different value - depending on the accuracy of your crystal, capacitors, temperature etc etc

[Aberg098]

So if you don't mind my asking, what is the difference you speak of? I know that the factors you have listed can affect the accuracy of the clock, but why would they affect it's limit? Shouldn't the actual number stay the same?

[madsci1016]

webbot, did you update that page? I swear it said something else at work.

[Aberg098]

I noticed the page update as well. I'm still dealing with a problem, which is a bit of a special case and only occurs when the clock resets. I will try to explain the special case and my solution for it in pseudo-code.

The special case:

Timer1 = ClockGetus (when the clock is near the it's maximal value)
Execute instructions (i.e. time is spent)
Timer 2 = ClockGetus (after the clock has reset)
Interval = Timer 2 - Timer 1 (becomes a large negative value)

The only way I can see around this is to add an if statement, to check if the clock has not reset. In the case that it has, the Interval value has to be adjusted. My proposed solution:

if Timer 2 > Timer 1
then Interval = Timer 2 - Timer 1
Else Interval = (ClockMaxValue - Timer 1) + Timer 2

And the correct ClockMaxValue is 4,294,967,295 microseconds.

[Webbot]

webbot, did you update that page? I swear it said something else at work.

Its called 'The Power of the Internet'  
When someone reports a documentation issue - it gets fixed !

I noticed the page update as well. I'm still dealing with a problem, which is a bit of a special case and only occurs when the clock resets. I will try to explain the special case and my solution for it in pseudo-code.

The special case:

Timer1 = ClockGetus (when the clock is near the it's maximal value)
Execute instructions (i.e. time is spent)
Timer 2 = ClockGetus (after the clock has reset)
Interval = Timer 2 - Timer 1 (becomes a large negative value)

The only way I can see around this is to add an if statement, to check if the clock has not reset. In the case that it has, the Interval value has to be adjusted. My proposed solution:

if Timer 2 > Timer 1
then Interval = Timer 2 - Timer 1
Else Interval = (ClockMaxValue - Timer 1) + Timer 2

And the correct ClockMaxValue is 4,294,967,295 microseconds.

It does NOT become "a large negative value". Since Timer1, Timer2 and Interval should be of type 'TICK_COUNT' then they don't understand negative values although its easy to understand why you think it will be negative.

If you're using windows then do the following with 'Calculator'. Launch it then click on 'View | Scientific' and then click the 'Hex' radio button.....
Assume Timer 1 = FFFFFFFF
and Timer 2 = 1
So Interval = 1 - FFFFFFFF
Type "1 - FFFFFFFF =' into Calculator and you will see the answer is 'FFFFFFFF00000002'.
But since Interval is only a 32 bit number then this is truncated to '00000002' ie its not negative, its 2. Which is correct.

So you don't need to add an 'IF' statement at all.

[Aberg098]

I think that I understand what you mean by the values being hexadecimal and the result of the subtraction being positive. That is fine, but how do I declare my variables. Currently, I've declared Timer1 and Timer2 as floats. I don't understand this TICK_COUNT variable type, nor can I find any reference to it.

[Webbot]

I think that I understand what you mean by the values being hexadecimal and the result of the subtraction being positive. That is fine, but how do I declare my variables. Currently, I've declared Timer1 and Timer2 as floats. I don't understand this TICK_COUNT variable type, nor can I find any reference to it.

C allows you to create your own datatypes. if you check my manual youll see the clock functions return a TICK_COUNT. So replace your float with TICK_COUNT eg

TICK_COUNT Timer1 = clockGetus();

I don't explain this in the manual because the manual is about the library rather than being a C primer

[madsci1016]

Its called 'The Power of the Internet'  
When someone reports a documentation issue - it gets fixed !

Lol, well next time let us know so we don't question or sanity or further confuse people.

[Admin]

Unfortunately, I've looked into RTCs and none that I've found have resolution under a second: I need more than that.

Well, no, you use the internal Axon clock for your high resolution, then reset the clock to zero when the RTC updates by a minute or so (whatever value you feel is appropriate). This way you have high resolution, your timer value never maxes out (at 71 minutes or whatever), and it stays near perfect accurate over long periods of time.

[Aberg098]

I've tried to declare my variables as TICK_COUNT, and this doesn't seem to work. Instead of getting a nice steady stream of data, as I used to get using floats, the output is jagged and irregular. It also seems to drop some messages on the UART, meaning I get partial numbers sometimes. Also, the marquee doesn't physically display the text properly, it just shows the d instead of the full dataacq3.

I've attached my code, maybe you guys can see where it's going wrong. I have edited some of the code out for clarity, mainly that related to reading my sensors. In any case, you can see that I'm using more than one variable, just to make sure I'm not missing out

Code: [Select]

#include "hardware.h"

//Declaring and initialising the timer variable
TICK_COUNT StartTimer = 0;

// Initialise the hardware
void appInitHardware(void) {
initHardware();
}

// Initialise the software
TICK_COUNT appInitSoftware(TICK_COUNT loopStart){
return 0;
}

// This is the main loop
TICK_COUNT appControl(LOOP_COUNT loopCount, TICK_COUNT loopStart) {

// -------- Start Switch/Button-------
if(SWITCH_pressed(&button)){
// pressed
}

// To test if it is released then
if(SWITCH_released(&button)){
// released
}
// -------- End   Switch/Button-------

// -------- Start Marquee-------

Writer old = rprintfInit(marqueeGetWriter(&marquee));
marqueeSetEndDelay(&marquee,0); // Make sure we are in one-shot mode
if(marqueeIsActive(&marquee)==FALSE){
     if(loopCount==1){
//Displays the name of the program on the 7-segment LCD
rprintf("DataAcq2\n");
     }else{
//rprintf("Loop=%u\n",(unsigned)loopCount); // Put the loop count
     }
}

// Restore rprintf back to its previous location
rprintfInit(old);
// -------- End   Marquee-------

//declaring interval variables
TICK_COUNT EndTimer;
TICK_COUNT NewTimer;
TICK_COUNT Interval;

//declaring accelerometer variables
float Ax;
float Ay;
float Az;

//Read all sensor values

//assign accelerometer values

//assign gyroscope values

        //Get timer final value in microseconds
EndTimer = clockGetus();

NewTimer = clockGetus();

//Calculate interval duration in seconds
Interval = (EndTimer - StartTimer)/1000000;

//Get initial timer value in microseconds
StartTimer = NewTimer;

//Output interval in seconds
rprintf(","); rprintfFloat(7,Interval); // I know this line is wrong.

return 0;

}


[Webbot]

Your problem is that you are using rprintfFloat to print out a number that is no longer a float. Its a TICK_COUNT. Try using:-

Code: [Select]

rprintf("%lu",Interval);
But you will need to add this line to the VERY top of your source code

Code: [Select]

#define RPRINTF_COMPLEXas described in the manual

You may well just get 0's coming out. The reason being that you have divided the interval by 1000000 so that it is in whole seconds. But since your main loop is not doing much then I'd be very surprised if it ever took 1 second. This is probably a left-over from when you were using floats.

As for the marquee issue then are you using the WebbotLib Version 1 code stream or the Version 2 code stream ?

[Aberg098]

Alright, I have done the rprintf with %lu, so I am doing that part correctly. I have also removed the division to keep results in microseconds(us). At least now I know that part works.

As it stands, when I was using floats, my intervals were somewhere around 15000-16000 microseconds (us). Now using TICK_COUNTS, I get the same results in terms of length. Except that every 10-20 loops or so, something goes wrong and I don't get a number output to the interval, I get 1 gibberish character.

Is it possible that it doesn't like doing the subtraction with TICK_COUNTS
Interval = (EndTimer - StartTimer)
I am hypothesising that a - operator is treated as a float or integer, but when the variables contain letters something goes wrong?

I used project designer with the Axon template to generate the source code. I'm unsure which version. Is there an easy way to check?

Edited for clarity!

[Admin]

I used project designer with the Axon template to generate the source code. I'm unsure which version. Is there an easy way to check?

In order to generate code with PD, it asks you where you saved the WebbotLib source code. In that sourcecode there is a version.h file.

[Aberg098]

Just to bring a bit of closure and an update, I've managed to debug things and now can get the TICK_COUNTs to work successfully. I've yet to run several tests to confirm, but it seems to solve the clock wraparound issue. Thanks all!