tag:blogger.com,1999:blog-1564958057737541664.post3582081071662711445..comments2024-02-14T17:11:22.168-08:00Comments on On Bicycles, and.... what else is there?: combining GPS and barometric altimetry: generating random altitude datadjconnelhttp://www.blogger.com/profile/01484858820878605035noreply@blogger.comBlogger9125tag:blogger.com,1999:blog-1564958057737541664.post-41278207761852375062010-02-02T17:39:09.994-08:002010-02-02T17:39:09.994-08:00Well...if the intent is to use this for any sort o...Well...if the intent is to use this for any sort of VE testing (i.e. as an "actual" elevation for AeroLab), then I'd HIGHLY recommend a separate ANT+ wheel speed sensor to be added into the mix. After all, the largest potential source of error in the VE calculation is error in the speed measurement :-)<br /><br />I like where you're going with this...if there's one thing that bugs the crap out of me is the HORRIBLE estimate of altitude that the 705 outputs, even though it has GPS AND barometric pressure.Tom Anhalthttps://www.blogger.com/profile/08175472546482777614noreply@blogger.comtag:blogger.com,1999:blog-1564958057737541664.post-13065865061300845772010-02-02T17:24:18.248-08:002010-02-02T17:24:18.248-08:00Well, I'm not sure about Kalman filters, but ...Well, I'm not sure about <a href="http://en.wikipedia.org/wiki/Kalman_filter" rel="nofollow">Kalman filters</a>, but I am intrigued by the intro on<br />Wikipedia:<br /><br /><i>The Kalman filter uses a system's dynamics model (i.e. physical laws of motion)...</i><br /><br />The broader message is "don't analyze data without exploiting knowledge of the underlying physics". With that in mind a simple approach to the stagnation problem would be to evaluate a correlation between altitude difference (between GPS and barometer) and speed-squared (the functional form of <a href="http://en.wikipedia.org/wiki/Dynamic_pressure" rel="nofollow">dynamic pressure</a>. Since the goal of this is archived data, not real-time display, this could be done globally on the entire ride file. This correlation could then be subtracted from the data, point-by-point, IF a speed number was available, which GPS should provide (at least when the signal's available). GoldenEmbed is primarily an ANT+ sniffer, so there may be another trusted ANT+ speed signal available when GPS is unavailable.<br /><br />So there are possibilities. More chance to hack my script.djconnelhttps://www.blogger.com/profile/01484858820878605035noreply@blogger.comtag:blogger.com,1999:blog-1564958057737541664.post-68816986106940603622010-02-02T17:03:18.823-08:002010-02-02T17:03:18.823-08:00In a previous job, I was exposed to a bunch of rea...In a previous job, I was exposed to a bunch of really smart guys who where working on inertial nav systems. It seemed that in situations like this, they tended to rely on a Kalman filter to make good estimates of system's state from a bunch of noisy measurements...I'm not smart enough to know if something like that would be of use in this application, with the measurements being GPS altitude, barometric pressure, and speed?Tom Anhalthttps://www.blogger.com/profile/08175472546482777614noreply@blogger.comtag:blogger.com,1999:blog-1564958057737541664.post-28762708086049240832010-02-02T16:53:10.776-08:002010-02-02T16:53:10.776-08:00That is really cool! Okay, so I can tell right o...That is really cool! Okay, so I can tell right off the effect of this. It depends on how speed fluctuates. Since my solution is to smooth the barometric and GPS signals with a cosine-squared convolution function with full-width-half-maximum (FWHM) = 100 seconds, if speed fluctuates over significantly less than this time, the error will leak through. My time constant was based on the assumption the primary source of variability is uncompensated atmospheric pressure variations (static pressure), and these typically occur over more than 100 seconds, a time suitably long to smooth out the noise from the GPS signal. However, if speed varies more quickly than this, you're sort of stuck. My speed in the model is a strong function of road grade: I assume no motivational noise :).<br /><br />A nicer combination, I feel, is a GPS with a "smart" gradiometer, for example iBike. Maybe iBike will be GPS enabled this year.djconnelhttps://www.blogger.com/profile/01484858820878605035noreply@blogger.comtag:blogger.com,1999:blog-1564958057737541664.post-11424681704440980382010-02-02T16:43:13.149-08:002010-02-02T16:43:13.149-08:00Yeah...it might be mount specific. Both of my exa...Yeah...it might be mount specific. Both of my examples were with the unit mounted on the handlebars. As I chose to do in the example I link to below, you might want to allow the user to specify a % of free stream velocity that's converted to static pressure. Just a thought...<br /><br />http://biketechreview.com/forum/viewtopic.php?f=1&t=1826Tom Anhalthttps://www.blogger.com/profile/08175472546482777614noreply@blogger.comtag:blogger.com,1999:blog-1564958057737541664.post-39429736238920298432010-02-02T15:37:22.357-08:002010-02-02T15:37:22.357-08:00Do you have a model for this? It's an interes...Do you have a model for this? It's an interesting idea! It seems it would be very sensitive to mount location. <br /><br />For example, you wouldn't want to mount your altimeter on the top of a wing, where the occupants of the vessel are relying on reduced pressure for their survival! Yet even airplanes manage to measure altitude barometrically.<br /><br />In the case of the present application, I think GoldenEmbed is typically going into water bottles. However, the goal is to make a mount which can be tucked someplace unobtrusive.djconnelhttps://www.blogger.com/profile/01484858820878605035noreply@blogger.comtag:blogger.com,1999:blog-1564958057737541664.post-38936708857164922312010-02-02T15:12:26.529-08:002010-02-02T15:12:26.529-08:00You should think about adding a term that accounts...You should think about adding a term that accounts for stagnation pressure effects at the barometric sensor that's proportional to the speed. I've found that most bike mounted barometric altimeters suffer from this problem, where the altitude reported is offset lower than reality the faster you go...I've seen this with both Polar and Garmin bike units.Tom Anhalthttps://www.blogger.com/profile/08175472546482777614noreply@blogger.comtag:blogger.com,1999:blog-1564958057737541664.post-5308778187297804962010-02-02T11:54:11.447-08:002010-02-02T11:54:11.447-08:00Okay -- I fixed the non-physical acceleration. It...Okay -- I fixed the non-physical acceleration. It was bugging me the whole time I was in the dentist chair this morning getting a cleaning. Totally immaterial to the subject of altitude analysis :).djconnelhttps://www.blogger.com/profile/01484858820878605035noreply@blogger.comtag:blogger.com,1999:blog-1564958057737541664.post-33698441014630263342010-02-02T05:13:56.814-08:002010-02-02T05:13:56.814-08:00My initial plot of altitude was in error (max clim...My initial plot of altitude was in error (max climbing rate was 1 m/sec instead of the desired 0.35 m/sec). I fixed this.<br /><br />BTW, sharp-eyed observers will note the equation of motion is not constant power: the acceleration is wrong, the max speed is too low given the climbing rate. However, the intent was an equation describing typical behavior. I intentionally boosted the power when climbing because that's what a lot of riders do (more payback from higher power on climbs), and the acceleration was intentionally heuristic to avoid the zero-speed singularity of a constant power assumption (not based on constant power).djconnelhttps://www.blogger.com/profile/01484858820878605035noreply@blogger.com