Solution to Timing Loops

[Steven Carmain]

I have found out how to time. Based of the information from Innovation First, a loop is every 26.2 ms, assuming your code does't lengthen it. Based off of that, there are 38.167938931297709923664122137405 loops per sec. So to do close timing without overloading the stamp, you do:

Time VAR byte
RealTime VAR byte

Time = Time + delta_t + 1
if Time > 38 then
Time = Time - 38
RealTime = RealTime + 1
EndIf

This way only uses 2 bytes insted of a byte and a word. I tryed the delta_t * 262 / 10 but it overloaded the stamp and was very inaccurate.

Based of of this formula, then the basic stamp will be 0.530431579 seconds fast at end of match.

You can check this information on this xls I inclosed.

[Anthony Kesich]

i must applaud you for your idea. I myself, being a rookie programmer on a rookie team, am just getting the hang of the language, but after reading the forum got this idea yesterday, but then flushed it out, on one basis. doesn't delta_t count the total number of packets missed since starting the program?

-Anthony

[Noah]

Originally posted by Anthony Kesich
[Bdoesn't delta_t count the total number of packets missed since starting the program? [/b]

No, delta_t counts the number of missed packets since your last serin. it gets reset to 0 with each serin.

[Anthony Kesich]

thats good to hear, you always want to check your bases. you know, play it safe.

-Anthony

[Steven Carmain]

Did you get the xls. If you guys didn't, then can I have a email address if you want a copy or to post it in the internet

[Noah]

You can attach it to your post as a file. That would probably be best. That way everyone can download it straight from here.

[Greg McCoy]

Originally posted by Steven Carmain
I have found out how to time. Based of the information from Innovation First, a loop is every 26.2 ms, assuming your code does't lengthen it.

How is this possible? Unless you use only the default code, this number will change, and you have to change the code if you are going to do anything automated.

It's really not that hard to just figure out the numbers by guess and check.

You can do a timer with 2 bytes too, only difference is that you can only count to 255, and when you reach this number you simply start a new step, as documented in my programming sample in the white papers.

[Steven Carmain]

If you do the research like I did, then you would see that a loop is 26.2 ms a loop. If your code is shorter then you wait at serin until you get the information and start the loop over. If you take too long in your code, then the delta_t comes in. It count the number of loops you missed as long as it is in the serin. If you miss 5 serins then you have the basic run error. So in theory, this should be accurate.

[Anthony Kesich]

all i know is this code works. I played with basic autonomous mode today (this isn't that sad, seeing as i am the only real programmer at my school, this is a rookie team, and i have taught myself almost all of the code) and this works like a charm. Since most people only use timing in auton mode, you will only be off by about .066 seconds, and that is extremely insignificant. (It was so little that i didn't notice at all)

-Anthony

[Ian W.]

one question. why the timing loops? why not just a counter?

i made a little program a few days ago, all it does is use a byte and a nibble, and based on the counter and nibble advances through a select case. all you do to control it is adjust the byte to how high to count, and always advance the nibble by one. you can get up to 18 operations in this way, actually more if you don't use the full 255 loops from one byte at a time.

if this doesn't make sense, i'll post the code tomorrow afternoon when i find it. it's very simple when you see it, and it works fine. no need to worry about time, because if the loop gets longer, even a timer would get screwed up.

[Greg McCoy]

Yeah, that's pretty much what I did. It seems to me that it does the exact same thing with less complexity and the exact same efficiency if done correctly.

[mjt902]

First, this thread starter knows what he's talking about. Second, a counter counts loops. The number of loops you get in one second changes. Don't believe me:

copy a simple statement 100 times, or use some calc in your program and see how slow the counter goes.

I can forsee that this years coding is that complex when compared to last years (all we needed were a few if statements). The delta_t is the only TRUE thing in your code, so it is imperative that you do the auton mode the way suggested, and do NOT use counters.

GUESS AND CHECK IS NOT HELPING US LEARN ANYTHING

[Ian W.]

uh, i can control how long it does something based on counting with cycles AND delta_t. it's the same as a timing loop, minus the extra memory and added difficulty. and i've seen no problems so far with my code. sure, it aint pretty, but it's dead reckoning, it's not supposed to be!

[rbayer]

There is no advantage to converting Stamp loops to "real" time. It is a 1-to-1 conversion, meaning that each "real" time value corresponds to some fixed number of loops and vice-versa. For example, the following code would do exactly the same thing:

loopCnt VAR byte
loopCntHigh VAR nib
loopCnt=0
loopCntHigh=0

SERIN...

if (loopCnt + 1 + delta_t > 255) then loopCntHigh=loopCntHigh + 1 : loopCnt=loopCnt+1+delta_t-255 else loopCnt=loopCnt+1+delta_t

SELECT (loopCntHigh<<8 + loopCnt)
CASE range1Low TO range2High
  'do stuff
CASE range2Low TO range2High
  'do other stuff
CASE ELSE
  'do even more stuff
ENDSELECT

SEROUT...

This will let you count up to 4096 loops, which is approx 1min 45s worth of autonomous time. Plus, it only uses 1.5 bytes!

Questions about the above stuff? Email or PM me and I'd be more than happy to explain.

[mjt902]

Once again you correct me!!! Oh, I'm lazy anyway but thanks for the free code. Only one question have I:
where'd you get the 8 from in SELECT(loopCntHigh<<8 + loopcnt)

i think you and i are on the same page (only i'm on a different plane) , and its great learning from you!!!