Then don't run uncalibrated chips without crystals.

I hadn't thought about putting the Hall in the tube. That's good too but I thought rather on the post you slip the end of the tube over if it was a wrist rocket () or made -as- the end of the post. That kind of fitting doesn't pinch or otherwise deform the tube. You'd be measuring stretch at the end.

Oh, hang on. Wrist rockets aren't like they were in the 60's. These are:
http://www.amazon.com/Barnett-17018-Black-Widow-Slingshot/dp/B000PWBIKY/ref=pd_sxp_grid_pt_1_1

But if you were just going to pull the tube with your fingers then yeah that's good, put it inside! When the tube stretches the distance between the Hall and magnet widens, viola! But make sure there's enough extra untangled, sure to be free-moving wire going to the sensor so power and signal wires don't get 'stretched'. Maybe something with graphite powder?

A linear Hall sensor can measure very small fields and a small neodymium magnet should be good to inches at least and resolution 0-1023 (field drop off is inverse cube though, maybe you want mms at start).

You could watch a mark move and widen with a 1k linear photo-array.

If you put a stripe mark on it, the mark will move and get wider when the tube is stretched.
You can measure the tube diameter at a fixed distance from one end, it should get smaller with pull or at least my old wrist rocket tubes did.
If you attach one end to a spring and can find how much that stretches, you can know.
You can put a magnet in the tube and measure the field change at a stationary Hall sensor.
You can see if the air pressure inside the tube changes relative to outside.
You can have the pull compress a piezo and check the charge difference across the leads but that's far trickier than all the above.

Every conductor and semi-conductor I know of changes resistance when under stress (one of the many ways resistance can be changed), that's how at least some solid state scales work.

UNO clock is not 10%. Standalone chip running on factory default clock is 10%.

Serial is not the only thing that uses interrupts and I think it's been established that 1.0 does not use interrupts.

If an IRQ is running when the millis update IRQ is supposed to be running then how doesn't it miss the tick?

When you have a 1ppm crystal and a more than 1ppm RTC then the technical term to look up is 'tolerance'. And if your 1ppm is due to software correction then why can't the RTC which should be as regular as it gets be corrected in the same way?

What part of "easy way" is turning into "only way to be accurate"?
What part of hardware limitations really means nothing can be done to correct them?

The more I see about the dyno the less I think it's going to need 1ppm timing anyway, it's in the 99.99%.

I am really ever so sorry I brought up problems that others have related on UNO timing. Sue me.

[too long]

All they are saying is that if you disable interrupts (eg. by being in another ISR) for too long, then it might miss a tick. But since the timer fires every 1024 uS (roughly once a millisecond) you would have to disable interrupts for a long time for that to be a worry.

To miss a tick it's only got to be processing an IRQ during the 'tick'. But for 99.999% of use I don't think it's a problem. If you somehow got interrupts even partly synched to the millis though it might indicate a software problem.

IIRC micros() keep counting during IRQs.

See if one ball rolls down a ramp faster than the other. That's how old slug detectors work.

http://physics-animations.com/Physics/English/angl_txt.htm

   If two cylindrical bodies are rolling down on a inclined plane then body which has the smaller inertia moment will reach the end of the plane first.

The balls will have different trajectories after leaving the end of the ramp. You can literally put two buckets down and catch each type of ball in a different bucket.

Another way to tell that would take less space would be to use momentum transfer. The same momentum applied to each should make them move at different speeds. Put in a jump ramp with a block so the faster one goes over while the slower is blocked.

I'm not suggesting we change any hardware.  I'm talking about calibrating it in the code.
You're talking about 10%.
I'm talking about 10ppm.
We're not even in the same ballpark.
I have proven it works for my applications nearly 1ppm.

From Atmel I learned that uncalibrated internal clock accuracy in shipped chips has a tolerance of something like 10% but can be calibrated to within 1%. Add to that that Arduino boards don't run on the chips internal clocks. The 10%/1% applies to what standalone chips can supply.

And the millis() counter not being updated while interrupts are disabled (like during IRQs) is something I got (shown in docs) from Arduino. Why do you suppose that is?

Neither says you can't engineer around them. Step one: identify a need. Step two: indentify and quantize the parts. Etc till all the troubles are shot and it's done or proves impossible.
Please don't think that parts of step 2 are a statement that the task is impossible.

And again, the easy way that should be good is to use an RTC.

in my code above how do i replace the "Hello" with the actual serial string the sabertooth is seeing? so i can debug with my monitor?

You make a byte array to hold the incoming characters and then in loop() you watch for then serial data, get it (I find it best to get 1 character at a time, you may loop() many times between characters arriving. There's time to do other things between if you want/need.) and add it to the byte array (I use a byte variable to know what array index to fill next, starts with 0, and increment that each time I add a new character.) and when it's done (Aha! How to know when? Hang on!) add a 0 byte to terminate the string in the byte array. The byte array then holds the string to print.

------------------------------------------
How to know when to end the word or line? Lots of ways for lots of needs.

Worst case for end of line is if too much time has passed since the last character arrived then the line must be finished. That's terrible code though and really asking for trouble but hey you might get away with it for a long time. I actually did use that in code to read electric meter output but there are so many error checks on the data that I catch and handle errors... by dumping the data message as bad and getting the next one.

In Serial Monitor I set it up so that each line sent gets a carriage return added but you can go with new line, carriage return, both or the default which is nothing. It gives me an end stop.

If I expect multiple data items sent then I separate them with delimiters like space, comma, semi-colon, etc, and watch for those in my code... the delimiter is my end of word marker. Using different markers can give you extra error checking since serial transmission is not guaranteed.

When you see strings as arrays and serial data as 1 byte telegrams, simple approaches should become clear to you. Can you compare two strings in two arrays without using strcmp()? Certainly! The same way that strcmp() does! If the bytes at each array position are the same until both are zero (end of a C string is always 0) then the strings are equal. And look Ma, no library!

[With the internal oscillator calibrated you can be within 1%]

That's a crystal. Maybe not the best.

What I wrote:

With the internal oscillator calibrated you can be within 1% and with a crystal I think you can get closer but I dunno just how much -- and still the suckers won't stay in synch.

From ATMEL docs I see you can calibrate the internal oscillator which ships more like within 10%. I don't see a way to calibrate the external clock beyond changing the crystal.

Are you talking about using the 8 MHz Internal Oscillator or an External Crystal?

Are those cars using sensors and position information?

Here's AVR Libc Modules with a lot of particulars:
http://www.nongnu.org/avr-libc/user-manual/modules.html

That's on the home site for the C++ Arduino uses.

Just take it a step at a time and I hope you have time for this project to work out.
Haven't touched Fortran since 75 when we punched cards. That was my first programming course.

I've thought about this and maybe have a good one for laying useless search trails: internet scavenger hunts.

Then help the ones that read but don't understand.
The hard ones to help are the ones that don't understand but think they do.