Highest Altitude I've ever been

I drove from work this early morning through some concrete jungle. APRS shows me that I was at 185,410 feet altitude My Mini can not climb that high. How the APRS makes such a mistake?

Wow! If your Mini does that, imagine what the -9 can do!

You sure you didn't take the SR-71 to work by mistake, and were descending?

Wow!

12 MPH in orbit! Are you sure your Mini wasn't impersonating space junk?

two theories:

1) The GPS screwed up for a moment
2) APRS is a pretty poorly designed protocol (though it does do the job). Its error checking scheme is weak, so there are fair odds of a misdecoded bit that is not detected.

Vlad said:

I drove from work this early morning through some concrete jungle. APRS shows me that I was at 185,410 feet altitude My Mini can not climb that high. How the APRS makes such a mistake?

Click to expand...

Hey Vlad - I knew I love that Mini Cooper of yours for a reason - it's a rocket ship!

Typically there are two obvious sources of such an error - GPS reflections deep in an urban jungle can cause a bad triangulation, although this would typically be accompanied by a lat/lon 'step out' as well (such 'marginal' GPS reports are usually filtered by a car sat nav)

Another possibility causing a single value stepping out like this is more typically a software error causing a bad encode or decode of the transmitted message - can happen in a number of places, prior to transmission, following receipt and prior to persisting the report in the database, or a valid value in the database but an error in the presentation layer (the web client).

Do you have any other client side tools, like a download-as-csv that could let you look at the raw data way (just by way of trouble shooting)?

chinch said:

Hey Vlad - I knew I love that Mini Cooper of yours for a reason - it's a rocket ship!

Typically there are two obvious sources of such an error - GPS reflections deep in an urban jungle can cause a bad triangulation, although this would typically be accompanied by a lat/lon 'step out' as well (such 'marginal' GPS reports are usually filtered by a car sat nav)

Another possibility causing a single value stepping out like this is more typically a software error causing a bad encode or decode of the transmitted message - can happen in a number of places, prior to transmission, following receipt and prior to persisting the report in the database, or a valid value in the database but an error in the presentation layer (the web client).

Do you have any other client side tools, like a download-as-csv that could let you look at the raw data way (just by way of trouble shooting)?

Click to expand...

What Kevin said. I can never say in a few words what I can say in a hundred.

Here's the RAW data...

Below is the raw data from Vlads excursion into the upper stratosphere. The first paragraph is the data chunk from 9/26/2010 at 11:53:43UTC (a good data point for reference). Second paragraph is the offending data chunk from 9/26/2010 at 11:56:15UTC (the high altitude data chunk).

The first part of the paragraph is the decoded info, the second part is the HEX code that is sent out from your APRS transmitter and recieved by an iGate.

The HEX code highlighted in BLUE is the altitude portion of the data chunk. Pulling those two HEX codes out and comparing them is interesting...
303030303439 ...good
313835343130 ...bad

Remove the "3" (In HEX code, all digits begin with a 3) and you get...
000049 ...good
185410 ...bad

After picking all this apart, I have no idea where the altitude got garbled. The rest of the data chunk was transmitted correctly, just the altitude was off by a couple of feet.


2010-09-26 11:53:43 UTC KC2TPD-1: 103 bytes
K C 2 T P D - 1 > A P B L 1 0 , K 2 M A K , W I D E 1 * , W I D E 2 - 1 , q A R , N 2 M H - 1 2 : ! 4 0 4 2 . 1 1 N / 0 7 4 0 0 5 8 W > 2 4 8 / 0 3 9 / A = 0 0 0 0 4 9 V l a d ' s M I N I C o o p e r

4b43325450442d313e4150424c31302c4b324d414b2c57494445312a2c574944 45322d312c7141522c4e324d482d31323a21343034322e31314e2f3037343030 2e3538573e3234382f3033392f413d303030303439566c61642773204d494e49 20436f6f706572

2010-09-26 11:56:15 UTC KC2TPD-1: 103 bytes
0x00 K C 2 T P D - 1 > A P B L 1 0 , K 2 M A K , W I D E 1 * , W I D E 2 - 1 , q A R , N 2 M H - 1 2 : ! 4 0 4 2 . 7 8 N / 0 7 4 0 0 9 5 W > 0 2 8 / 0 1 0 / A = 1 8 5 4 1 0 V l a d ' s M I N I C o o p e r
4b43325450442d313e4150424c31302c4b324d414b2c57494445312a2c574944 45322d312c7141522c4e324d482d31323a21343034322e37384e2f3037343030 2e3935573e3032382f3031302f413d313835343130566c61642773204d494e49 20436f6f706572

Vlad,

Everyone here is missing the obvious; things like this started happening when they began mixing alcohol in the fuel. The mini only THOUGHT it was that high

Bob Kelly

Thank you guys for looking into it. All valid points, from analysis to alcohol

Today I am down to 83,049 ft . Looks like errors are caused by obstructions.





I hope the glitch will not happen when flying at an altitude.

As a programmer, this looks like a classic "wrap-around" numeric conversion bug. Since you are driving at or around sea level your GPS receiver will occasionally register you at an altitude below sea level (a negative number).

Sounds like somewhere a poor conversion from a signed variable to an unsigned variable is happening. For example, if you take -20, convert it to an unsigned int/short, you will end up with a very large number.

This could just be a bug on the APRS.fi site. I briefly looked at your tracks and never saw a negative registered altitude. That would indicate to me that this is indeed the issue because with the inaccuracy of GPS altitude you would undoubtedly record a negative altitude at some point.

Whether GPS reflections or negative altitudes...

... either way it should not affect you at altitude. Unless you plan on doing some really low flying, in which case your APRS is going to be the least of your concerns