Here's my problem: over a worm cycle, I cannot get the measured rotational speed to match 86164 seconds. It varies with every run, e.g. 86300, 85950, 86000... about 1000ppm difference.;}long calc_full_angle (long theta, long tcnv) { // calculate the full encoder angle (in DECI-arcseconds!) _current_encoder_angle = (long) (get_quadrature_count() * 648) + (theta % 648); if (_cal) { _current_encoder_angle -= _origin_encoder_angle; // don't use seconds directly as angles here are in DECI-arcseconds double tElapsed = ((double) (tcnv - _tstart)) / 100; _theoretical_encoder_angle = (long) (_trackingRate * tElapsed) + 0.5; } else { _theoretical_encoder_angle = _current_encoder_angle; } return ( _current_encoder_angle );}
Quote from: orly_andico on Apr 18, 2013, 08:20 am2).No, I'm saying that the SOFTWARE won't lose time. Everyone knows the resonator is only accurate to 0.5%, which could be up to be seven minutes over a day or 18 seconds per hour or 6 seconds per 1200 second period (twice what you measured)
2).
The ceramic resonator is accurate to .5% (5000ppm). At room temperature, no device should be this much off. Being 5000ppm in error is worst case due to temp, age etc....
@Afremont:QuoteThe ceramic resonator is accurate to .5% (5000ppm). At room temperature, no device should be this much off. Being 5000ppm in error is worst case due to temp, age etc....Problem's in the software and we don't see all the code so it's like an Easter Egg hunt without the back yard.
All the code is in the Dropbox link, the code is in tabs so it's an entire folder worth of files.I got 1063/1064 with the random atan.But the extra 63/64 is not the problem - that is the amount of time taken to run the atan loop. I know that will cause the loop time to be greater than delay(1000). I don't care about that and can budget for it.I don't expect or want every iteration of my loop to run in exactly 1000 milliseconds. I do care that the millis() count falls behind wall clock time.
unsigned long previousRollTime = millis(); // some place to startvoid loop() { while(millis() - previousRollTime < 1000) { // burn up the rest of the previous second // do some repetitive stuff that you want to get done while waiting out the second tick // like accumulating serial data in a buffer, or checking for user input, or whatever } // end while previousRollTime += 1000; // adjust next roll time // do a bunch more stuff that you want done once per second // you have to be able to get it all done in enough time to catch the next roll minus // how much time you want to spend in the wait loop doing the repetitive things} // end loop
I don't care or need for the routines to execute in fixed time. It doesn't matter how much time atan takes.I need to just know the current time. Accurately. Doesn't matter how long my routine takes to execute, it's irrelevant, because knowing the correct time will let me calculate my values correctly.Let me try another analogy.At time T1 I measure the position of the encoder. Say it's X.At time T2 (some indeterminate time later) I measure the value again. It is Y.So I can calculate the velocity = ( Y - X ) / ( T2 - T1 ).Regardless of how much time has passed between T2 and T1.But if T2 and T1 are not accurate then my computed value is meaningless. But the amount of time elapsed between T2 and T1 is irrelevant.What I meant by "budget" was, if millis() is consistently inaccurate, I can budget for that, e.g. if it's always 1000ppm slow.
Please enter a valid email to subscribe
We need to confirm your email address.
To complete the subscription, please click the link in the
Thank you for subscribing!
Arduino
via Egeo 16
Torino, 10131
Italy