circuitcellar.com
Magazine Support   Digital Library   Products & Services   Suppliers Directory 
 
 





 

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.