Sometimes autonomous cycles at half rate (19 Hz instead of 38 Hz)

[gnormhurst]

Try printing out the packet number after every Getdata. It's rxdata.packet_num or rxdata.packetnum or something like that (you want the packet number in rxdata, not txdata). If your packet number keep incrementing by 2, you're missing packets.

Aha! Finally, a test I can do. Thanks, that's very helpful!

im not sure what your trackers are, but if they involve interrupts based on outside effects, then you may get varying amounts of interrupts thereby causing your code to take longer.

Yeah, that occured to me, too, but I don't know how to test for it.

Any chance your code is taking too long?

Always a chance. But I tested it way back in January with a scope and found the non-auton code taking less than 5 ms. I kind of think the auton code is not 5 times longer. I thought of taking my scope on the plane to Atlanta, but the thought passed (Tek 475 -- about the size of another carry on, but much more fragile than my socks). Besides, I think Kevin Watson's unmodified tracker.hex code had this same behavior, too. I think, but I might not swear to it.

do you have printf statements in your code?

Yes. Turning off printf is a good thing to try. I may write a dummyPrintf() function and #define printf dummyPrintf

void
dummyPrintf( char *s, ... )  // note the var arg "..."
{
  return;
}

// and later:
#define printf dummyPrintf

Do you think that will do what I want (shut down all printfs at once)?

I think printf's are always suspect since I found a strange behavior: I would upload the code, it would start running, flooding the screen with printf output, so much that when I stopped the RC the screen kept going for a second or so. Then the program would not run again after a reset. I had to download the code each time to run it once. I got rid of most of the printfs, and that self-destructive behavior went away. Beware printfs!

Thanks for all your inputs.

-norm