A Sample Rate WARNING indicates that the rate got low, but the run is
still available. The program interpolates the missing data and for the
most part, the run will look fine. However, a Sample Rate FAILURE
indicates that the rate was lower than the program thought it should try
to interpolate. My real thought when I wrote the software was that if
ever the rate got that low, something went horribly wrong anyway. But
we have found over the years that's not necessarily the case.
There are two factors that contribute to Sample Rate problems. The
first is, as Alan points out, power. As the 9v fades, the sample rate
can slow down. On most machines, the LOW BATT message will come up
early enough that if you replace the batteries at the end of the first
day that you see LOW BATT, you'll probably never have a sample rate
problem of any consequence. However, the circuitry that sets the LOW
BATT signal itself is not exactly 100% consistent either. While the
vast majority of system will show LOW BATT when the loaded battery power
(meaning when the system is running) drops to about 6.5 volts or so. We
loose a little bit of voltage in the power conditioning chips that
regulate the power to 5 volts, and so the net result can be that around
6.2 volts in will result in less than 5 volts to the accelerometer and
microprocessor chips, which is what they are supposedly rated to use.
If the voltage is below that, for reasons that I don't pretend to
understand, the machine slows down. This confuses my feeble mind
because I thought the speed limit was essentially 186KMPS, pretty much
universally, regardless of the voltage, but hey, I ain't no electrical
engineer. So even though it confuses and annoys me for it to work this
way, it nonetheless does, and we've observed it many times.
The second factor for Sample Rate problems is the Palm itself. These
poor machines just aren't the fastest things on the planet. The program
we run in the Palm is an interpreted thing, which makes it slower than
we'd like, and so the net result is that we are working pretty much at
the limit of the abilities of the machine to sample as the rate that we
do. Once we discovered that the sample rate could and would vary from
machine to machine we had to write additional code into the algorhythm
to check and see what the sample rate was actually running at, and this
extra code became enough to further complicate the sample rate problem!
Without that code the majority of Palms would run reliably at 10hz (plus
the Cube itself doubles up and averages two readings into one, so it's
really 20hz native). But any Palm which dropped to even 9hz would just
fail entirely. So we had to put in the correction code, and that made
it to where all the machines need better battery power, AND even then,
some machines just have a hard time keeping up.
The machines that struggle are the early Palm III's, and IIIx's. The
M100's seem to be the best, and the M105's are right behind that. So
it's unusual to see a M105 show a Sample Rate Failure, but likely that a
new 9v battery will fix it.
Sorry to drone on like this. I've been programming on a major new
project (non-GEEZ related) for so long now that today it just seemed
like a treat to deal with a GEEZ thing for a change...
--Byron
/// Archives at http://www.team.net/archive
/// Check http://www.team.net/mailman/listinfo for other lists of interest.
|