crwper

Some of the advanced analysis features in FlySight Viewer use the full 3D velocity vector. For example, you can use this to estimate lift and drag forces. The N/E components are also used to determine wind speed/direction using data from the climb to altitude.

As @platypii points out, in general deriving velocity from changes in position is a bad idea. This is known as the method of "finite differences" and is a notoriously error-prone way to calculate derivatives. That said, you may find this works better than expected with FlySight data (or GoPro data if they are using a similar chipset), since both the position and velocity are outputs of the same Kalman filter--so the smoothing @platypii refers to may already have been done inside the GNSS module.

Looking at the JSON file, it does seem to be a direct dump of the GPMF data embedded in the MP4. Here's a collapsed view of what's in the file which shows the headers but not the data itself: Looking at the "GPS5" key, it seems to include only 5 values: latitude longitude altitude 2D speed 3D speed In addition, nested in the GPS5 data, it occasionally includes two more pieces of information: "fix" - This seems to be the GNSS fix type (3 for 3D, 2 for 2D, etc.). "precision" - If I had to guess, I'd say this is position accuracy in cm. That's not too bad. There are a couple of things missing compared to FlySight's data: Components of 3D velocity. In principle you can recover the vertical component from 3D speed and 2D speed, but there's no way to get north and east speed directly from this data. You would have to go through latitude and longitude, which will likely result in some additional error. Components of accuracy. FlySight includes horizontal and vertical position accuracy as well as speed accuracy. Number of satellites used in the fix. This can be a useful diagnostic, but there is arguably some overlap with the position accuracy figure reported in the GPMF data. I suspect at 18 Hz this is GPS only, for the reasons given above, but it may be that if you drop down to 10 Hz the unit will automatically switch over to GPS + GLONASS. Here's the relevant table from the u-blox M8 datasheet: Assuming their velocity is coming from the same place FlySight's is, I feel like the GoPro data would be just fine for most uses.

It sounds like you might be looking at the <sat> field in the GPX file, which actually gives the fix time--i.e., 2D or 3D--so it typically has a value of 2 or 3. The minimum number of satellites required for a GNSS fix is 4, so if you're seeing a value of 3, it's definitely not the number of satellites used in the fix. Can you post an example of the GPX data produced by the GoPro? It looks like the <sat> field in the GPX file would give the number of satellites used in the fix.

It's been a while since I checked the forums, but I came across this post and thought I'd add a little more information. The latest FlySight hardware uses the NEO-M8Q module, which supports 10 Hz update while tracking both GPS and GLONASS satellites, or 18 Hz while tracking a single GNSS constellation. There's nothing magical about 18 Hz, so I think the GoPro is probably also using a u-blox M8 chip. The main limitation with the latest FlySight hardware is processor speed. I haven't checked to see if we can run at 18 Hz, but it might be possible, especially if we disable audio output. However, I would say that we've seen some really good results with GPS + GLONASS tracking. Roughly speaking, this doubles the number of satellites in view, which makes the fix a little more accurate and a lot more robust. If I had to choose, I would probably go with 10 Hz and two constellations as opposed to 18 Hz and GPS only. My guess is that the GoPro is using GPS only at 18 Hz. This could be confirmed by looking at the number of satellites used in the fix (assuming this is reported). If you see a number around 8-12, it's likely GPS only. If you see a number more like 12-18, it's probably tracking GPS and GLONASS. There is one other thing I would pay close attention to. One of the things I like most about the u-blox module inside the FlySight is that it reports 3D velocity, so there is no need to calculate velocity from differences in position (which is notoriously error prone). This may very well be the same interface that the GoPro uses, but it's very common for consumer GPS units to use the NMEA interface instead. This is an old interface which doesn't have native support for 3D velocity, which means vertical speed needs to be calculated from differences in elevation. You can probably tell which method GoPro is using by looking specifically at vertical speed. How clean are the measurements? If you hold the GoPro in your hand and wave it over your head, up and down, etc., do you see clean velocity measurements on all three axes (even though position may not reflect that motion)?

Hi Craig! The first thing I would do is to look at the log file for that jump to see if the FlySight logged data from exit. If you have data but not audio, there may be an issue with your configuration or a physical issue with the headphones. If the FlySight doesn't log for the first part of the jump, the most likely cause is either incorrect warm-up procedures or an issue with the FlySight itself. Shoot me an email at "michael at flysight dot ca" if you haven't been able to resolve the issue and I'll help you get it sorted out. Michael

Is there anything in particular you're looking for advice on? When you plug the FlySight into a computer, it will come up as a USB disk. In the root folder of that disk is a file called "config.txt" which can be edited to change the FlySight's behaviour. You can find basic FlySight configuration information here: http://flysight.ca/wiki/index.php/Configuring_FlySight If you're using selectable configuration files, it's a little different. You can find basic information on using selectable configuration files here: http://flysight.ca/wiki/index.php/Configuring_FlySight#Selectable_configurations Michael

If the conditions are similar, you should get a consistent fit between the jumps. This is the great thing about consistency between jumps. Ideally, you want to fit the drag polar using a jump where you explore the full range of the suit. Once you've fit the curve, you can apply it a jump with more limited range. One thing to note... There is a big assumption here--that the airfoil itself doesn't change from one jump to the next. For me this has been a bit of an experiment. I wasn't sure if we would see a lot of change in the airfoil within a single jump--e.g., if we de-arch quite a bit more to generate lift. The quality of the fit that I've seen on many competition jumps makes me think that we get most of our range by changing the angle of attack, rather than the shape of the airfoil itself. I believe so. Ideally, the lift and drag coefficients depend only on the design of the airfoil--i.e., the cross-sectional shape of the wing. One of the things I'd like to do in the long run is to explore the relationship between performance and jumper height, weight and suit type. For example, we might ask, "For a 5'6" 115 lb woman, what suit will give optimal performance in speed?" I think there are a couple of things we need to do to lay the groundwork for that project: We will probably need to compensate for wind. While the tool is useful right now in consistent conditions, quantitatively its usefulness is limited by the small amount of error the wind introduces. We've got a wind measurement tool in the FlySight Viewer right now, which I will be doing a little bit more work on in the coming weeks. Ultimately, we should be able to take a track from take-off to landing and use the climb to altitude to determine winds, then use that to correct the freefall measurements. We will also need to do a lot of testing with different jumpers flying the same suit design, to determine if it's true that a single wingsuit design has consistent aerodynamic parameters. For the moment, the drag polar feels "exploratory" to me--it's something we need to play with a bit to figure out what we can learn from it. I'm excited to see where this all goes, though. Michael

That's normal. This stems from the fact that a pure tone has a lot more energy for a given amplitude compared to speech. Because of this, I'll often use, e.g., a volume of 6 for tones and 8 for speech. Michael

I see you've already found a solution, but I thought I would add a suggestion in case someone finds this thread later on. When the FlySight is "dead" after updating, this usually means that the erase step has completed successfully, but programming has not. When using Flip (Windows) to update, this usually means that the firmware was either not selected or was selected, but then the chip type was changed afterward--this clears the firmware selection. To check this, look at the bottom middle in Flip, where it says "HEX File". This should not be blank--it should give you a firmware name and size. When using dfu-programmer (Mac) to update, this usually means that the first command--"erase"--was run but not the second command--"flash". Note that both commands need to be run one after the other for the firmware to be updated successfully. Michael

Thanks, Daniel. I'm not sure why this is happening, but it seems to be sporadic. If you repeat the click, does the download eventually work? Michael

The hardware has been capable of 10 Hz logging since serial number 1247 (shipped at the end of 2013). However, some units may need a firmware update in order to use the higher rate, since the original firmware doesn't support rates higher than 5 Hz. The firwmare update procedure can be found here: http://flysight.ca/wiki/index.php/Firmware_upgrade I'm hoping to have an update utility available soon which will make the process a lot easier, but in the meantime it's easiest on a Windows XP/7 machine and possible (but harder) on a Mac. Michael

As you mention, the side of the helmet is not a great place to mount the FlySight. There are a couple of major problems with this mounting location: If you're in a normal flying position, the FlySight won't be able to see half of the sky. The FlySight usually sees more satellites than it needs, so often you won't notice that this is a problem, but trouble is that it makes the fix "less robust", so when something else interrupts the signal, you lose the fix entirely rather than just losing a few satellites.Normal head motions like turning your head sideways or just turning your body onto a different flight line can change which satellites the FlySight sees. This doesn't seem like a problem, but making this kind of change in freefall can be challenging. The FlySight may not be able to get a lock on the new satellites, of you may simply wind up with "glitches" in your data. I may be able to get a better idea of where your troubles are coming from if you send the following files to "michael at flysight dot ca": Your "config.txt" file and "flysight.txt" file (if present--this one won't be there for older firmwares);The 15-minute warm-up file from the start of the weekend;The 1-minute warm-up file from before the jump;A jump which shows the problem you're seeing. Hope this helps! Michael

This is a great position to mount for swooping, but less great for wingsuiting since the FlySight will be slightly on its side in flight. The FlySight's fix is usually pretty robust, so you'll probably still get good data, but in marginal situations it might have an impact. Michael

Another firmware update is available here: http://flysight.ca/wiki/index.php?title=Latest_firmware This one adds "speech alarms". This is an altitude alarm that plays a sound file when it's triggered. There is some discussion of how to configure speech alarms here: http://flysight.ca/wiki/index.php?title=Configuring_FlySight#Speech_alarms I'm hoping this update will help performance competitors identify the top and bottom of the competition window more accurately. The usual cautions apply--these alarms should never be used for life-saving purposes, e.g., to indicate break-off or deployment altitude. Michael