December
2005, Issue 185
Browser-Based
Telemetry System
DAQ
LESSONS
Lesson
number one: Log the raws. For testing, I had real-time
graphs sent to my laptop as I drove up hills in my van.
The assumptions I had made while programming proved
to be wrong about what would happen while I was in motion.
It seemed obvious after the fact, but you shouldn’t
process your data while collecting it. The raw data
should be logged for post-processing, something I didn’t
consider when I was testing everything on the bench.
I ended up editing out some of the erroneous data by
hand, but it was better to see those wrinkles than suppress
them with code.
I
had all kinds of averaging and filtering code that caused
lags that I could see in graphs. Initially, this batch
of data and graphs had me looking for problems in the
TAI8570 algorithm. But after removing the code and performing
additional tests on the same hill, it was clear that
the TAI8570 values were better than the eTrex Vista’s
values. (Remember that the GPS has an altimeter as well.)
By better I mean smoother, more continuous, more like
the road I was driving on. As you can see in Figure
6, all three lines settle on top of each other when
I stopped for a few minutes. But after I get started
moving again, the eTrex lines became jagged (certainly
rougher than any road I’d care to drive on) in comparison
to the others.
Figure
6 is proof enough that both the AAG TAI8570 sensor and
conversion algorithm were working well. But what was
causing these inconsistencies? Notice how the error—defined
as the signed difference between the AAG values—flipped
as I started coming down hill. The error is the eTrex’s
two values versus the AGG over time (sampled five times
per second). Hmm. It was kind of like when I was filtering
and averaging the AAG values, of course. A finished
commercial product, the eTrex Vista was surely doing
heavy filtering and averaging (even stricter than I
was enforcing). But why? These hand-held units were
designed for hikers who don’t move as fast as vehicles.
This is something to consider if you’re planning to
use your GPS for, say, paragliding or something similar.
|

(Click
here to enlarge)
|
Figure
6—Bad things happen as soon as you take your data
acquisition system off the bench. It took several
tries to get the data I needed to give me confidence
in the AAG altimeter. |
Take
a look at Figure 7. Why do the Garmin altimeter values
tend to pop (i.e., jump back to join the other two lines)?
The AAG sensor can’t get wet because it has a little
hole in the case. The eTrex Vista is IEC 529-IPX7-compliant
for waterproofing standards. Waterproofing makes it
difficult to measure the outside air pressure and thus
requires it to exceed a certain pressure in order to
register. This isn’t a huge problem, but it does go
to show that there are numerous causes of inaccuracy,
inconsistency, and plain old error.
|

(Click
here to enlarge)
|
Figure
7—Notice the ear popping in the eTrex’s pressure-derived
values. This must be due to the IEC 529-IPX7 weatherproof
protection. |
After
rigorous testing, the hardware and software were finally
in line, and I know the results were accurate. Never
blindly accept that your data acquisition system is
presenting you with the truth. The obvious rarely is.
Things are rarely ever that easy.