Altitude

[Mirko Buholzer]

I was playing around with the Firmware and found some interesting GPS data: 

typedef struct

{

uint32_t iTOW;     // GPS time of week             (ms)

int32_t  lon;      // Longitude                    (deg)

int32_t  lat;      // Latitude                     (deg)

int32_t  height;   // Height above ellipsoid       (mm)

int32_t  hMSL;     // Height above mean sea level  (mm)

uint32_t hAcc;     // Horizontal accuracy estimate (mm)

uint32_t vAcc;     // Vertical accuracy estimate   (mm)

}

UBX_nav_posllh;

I can see the "height above mean sea level", but no reference to actual altitude (kind of makes sense). Is there a way to get or calculate the actual altitude during the jump? How is Paralog calculating the altitude? Is it just using the final altitude on the ground as a reference?

Thanks, Mirko  

[Tom van Dijck]

There is no reference point in the GPS data no...

Paralog basically just takes the lowest point in the data as it's reference point.

I've played with that before, but the only thing I managed to get working, is by having the device turned on on the ground, and let it calibrate.. basically just like you would with a ditter. In the end I found it too unreliable, so I'm hoping that we can add a barometer, accelerometer and compass to the "version 2" of the flysight when it comes, if it ever comes.

Tom.

[Michael Cooper]

Any thoughts on what the accelerometer/compass would be used for? The geek in me wants to throw every sensor I can into FlySight, but I think that’s driven more by an insatiable appetite for information, and less by actual utility.

 

Michael

[Tom van Dijck]

Well, the the compass is most useful, or at least the way the "sensor" in the Wii controller works, it gives you 6 values, 3 of which can be used for acceleration, and the other 3 for orientation...

Orientation is useful to measure drift... for example GPS tells us we're heading 240 degrees, while our compass heading is 230 degrees, thus we have a difference of 10 degrees caused by external factors (such as wind, odd body position, etc). You do need to keep your head pretty stable though, although with the accelerometer added to it, it is pretty easy to filter for "noise" by head movement (when you look around for example), as long as the average head position is "down" and "straight"... but mounting the device on the body/shoulder/rig would be more stable..

In addition with the horizontal orientation you can actually play with glide ration versus inclination of the body.. for this you would have to put the flysight on your body, and not on the helmet... it becomes a pretty 'accurate' device with adding all those sensors, so positioning the device becomes an important part of the analysis of the jump... which may make the device less attractive for general use...

The barometer is useful towards getting a more accurate reading of altitude... certainly if we have 2 modes for the device where we can independently enable/disable the other sensors to safe battery life, but still have a proper ground base measurement, so basically you turn on the device in the morning like you would with a ditter/protrack, but this only enable the barometer, then once at altitude you press a button to enable the GPS logger and other sensors..

tom.

[Mirko Buholzer]

There are wingsuit performance competitions, which usually as below mentioned for the contest in Elsinor will happen in a competition window. 

USA Performance Cup (Lake Elsinor)

Contestants enter the competition window at 9850’ (3km) and exit the competition window at 6550’. (2km)

Since FlySight is used as measuring device anyway, I wanted to add a audible marker when you enter and exit the competition window. This would help you in choosing your heading as well as having an effective body position. 

I thought about reading the lowest altitude of the last log entry as a reference. This could be a hack for the current FlySight until we have a barometer. 

-Mirko

[Michael Cooper]

A couple other ideas about how the altitude could be picked out:

 

1.       First fix of the day. The unit should be turned on for 15 minutes at the start of the day anyway, so if you can recognize this, it might be a good time to pick out the altitude. You could potentially store the time of the last fix, and check if it’s been, say, more than 8 hours since then. If yes, then update the ground elevation.

 

2.       When the FlySight is standing still. If the speed error is lower than 1.5 m/s or so, and the speed itself is less than 1.5 m/s, it’s a pretty safe bet that the FlySight is sitting on the ground. The advantage of using this method is that you don’t need to store previous information—just look at what’s being returned from the GPS right now.

 

Both of these have issues which make me reluctant to include them in the production firmware—e.g., they can both be fooled by someone turning on the FlySight first thing in the morning at home, and then heading to the DZ. However, within the scope of a competition, something like this might be useful, as you say.

 

Michael

 

From: flysig...@googlegroups.com [mailto:flysig...@googlegroups.com] On Behalf Of Mirko Buholzer

Sent: September-17-11 1:07 AM
To: flysig...@googlegroups.com

[Mirko Buholzer]

Thanks for the great ideas! 

1. I like this method, but it definitely has the drawback you are describing, starting the device in the morning at a different elevation and not having the option to correct the fact without hooking up the device to a computer. We could also implement a reset and re-read when the device is powered on and off twice.
   
2. This method seems more problematic, since if we look at a usual pattern (at least based on my personal experience) where the device is turned on before exiting and switched off on the ground the first valid (speed error is lower than 1.5 m/s or speed itself is less than 1.5 m/s) information sent from the GPS would be after landing. 

Still thinking about the drawback of my initial suggested method which would take the last log (either last lock on the ground or last jump) and get either lowest hMSL or as you suggested hMSL where speed error is lower than 1.5 m/s or speed itself is less than 1.5 m/s. The drawback would be to have this calculated each time the device is put on. Have to make a test and see how much time it takes to do this analysis.

Mirko