Loose Thoughts About Time

 In the last post I mentioned feeling that the phones were good to plus or minus a few milliseconds on a 50 millisecond loop.  I don't have any hard data on that, and I'm not really in the mood to go play alien autopsy on the robotics innards with a probe and a scope.

But ... I've been playing around with Python and a Raspberry Pi a little, and thought it might be interesting.  Yeah, I know, it isn't the same thing.  Python is interpreted yada yada yada...   But I'm doing this for fun so it's an experiment worth pursuing just a little bit.  

The first picture shows the basic setup.  Using a cobbler from Adafruit (This is NOT an endorsement, but it works and here's the link : https://www.adafruit.com/product/2028) and some generic LED circuit from I don't remember where,  I added the following Python code.

On a side note, there's a gyro or a BMP280 or something, a potentiometer, and a humidity sensor also on that breakout board.  We'll get to those some other day. :-D 

Anyway, it's crude and ugly, but sometimes you just gotta let your hair down - metaphorically of course - and beyond here be pythons, or at least a screenshot of the useful part.  I put it in as a screenshot because I like the darker theme for IDLE.  I think I used this one, but it's my own hardware so I didn't document it.  Link to dark theme: https://gist.github.com/dsosby/1122904 .

The fun thing here is the millis and stopmillis ... we're basically timing the precision of the "sleep" command.  Now, I think we _all_ can think of better ways to look at time, but for a really crude idea of what's going on, this will get us started.   Here's what we see right off the bat.  When I ran it 50 times at 0.05 seconds each, I was seeing some reports of 51ms, but mostly 50's.  Roundoff error maybe?  Well,run it with blinks of 10 seconds duration instead of 50 milliseconds ... and the very first one comes back at 10010 milliseconds.  This seems plausible to me. 

Remember, the Pi and our Phones are roughly comparable - typically an ARM processor running a Linux derivative at around 1GHZ.   

Yeah, I'm not actually satisfied with the experiment either, and yeah it's going to bother me. 

The "righter" way, of course, is to do what we have in our robotics code and let it lounge around in a do-nothing state until 50 milliseconds elapses then set a physical output and watch it jump around on an oscilloscope.  Then keep shrinking the time until the error is large enough to be a pain.  This might be a fun thing to do with our students in between seasons, but even with what we have, I'm a little more comfortable believing we shouldn't really trust our hardware to be both accurate and precise down to 1-2 milliseconds.