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

That's a great idea. The wiki gets added to once in a while, but I'm not really sure what's the best way to add something like this without the wiki becoming a disorganized mess. Any thoughts? Michael

First let's look at the tone settings. The best way to set min/max for any of these is to look at data from one of your previous jumps. This will give you an idea what range you cover. As Dan says, the easiest one to work with is vertical speed, since it doesn't depend at all on winds. If you look at a previous jump and see that you've been flying around 40 mph vertical speed, say, then you could set the FlySight for a range from 30 mph to 50 mph. You can use Google to do the necessary conversion. For example, to convert 30 mph: https://www.google.ca/#q=30+mph+in+cm/s Since 30 mph is 1341 cm/s, you want to set Min to 1341. Similarly, you would want to set Max to 2235. With glide ratio and horizontal speed, the situation is a bit more complex, since a tailwind will help you out and a headwind will hurt you. For a beginner, the default settings should give audible changes and unless you've got a smoking tailwind, you should fall somewhere inside the range. For more advanced use, you can look at several jumps in different wind conditions to get an idea what range you actually cover. I wouldn't usually adjust the rate settings. It's possible, e.g., to have the tone rate increase when your speed increases, but this isn't usually as easy to distinguish as a change in tone pitch. The speech settings are really easy to change, since you don't need to specify a range. Just choose what you want to hear dictated. If you're competing in a PPC competition, you won't get the best result just by optimizing your body position for one parameter--what I call steady state flying. Since the competition is judged through a finite window, the best strategy is generally to enter the window with lots of energy and exit the window "with nothing left in the tank". If you look at the records on the PPC website, you'll see some very dynamic flying. In terms of training, it's best to use the FlySight to get an idea what the effect of different body positions is, and then build a plan around that information. For example, if I'm flying for maximum time, I will dive down to a point just above the top of the competition window, plane out hard and "glide" through the window using that initial energy to float as much as possible. Ideally, when I hit the end of the window I should have used up most of the energy and I should be just about to fall out of the sky. The FlySight can help to minimize vertical speed in the "floating" section of the jump, but ultimately you've got to set yourself up properly in the dive and transition to make it work, and those parts are too dynamic for a single piece of information to be of much use. I hope this helps! Michael

Fixed! The new beta is available in the usual place: http://flysight.ca/wiki/index.php?title=Latest_firmware This one should handle any timezone offset without problems. Michael

I've uploaded a new version of the beta firmware here: http://flysight.ca/wiki/index.php?title=Latest_firmware This version fixes the issues we had with folder naming. Michael

There appears to be an issue with the latest beta firmware which causes the date folders to be named incorrectly. I'm working on a solution, but wanted to let you all know right away to avoid some frustration. I'll let you know as soon as an updated firmware is available. Michael

That's not a bad idea... For now I could add plot options to the preferences page, including (for each plot) the option to scale automatically or use a fixed range. We can look at in-plot adjustments after that, I think. Michael

The scales automatically adjust to whatever data is currently in the plot view. Quite often this means the glide ratio scale will be huge if you're looking at the whole log because it includes, e.g., a short time when you're standing on the ground. Once you zoom in a bit, the minimum and maximum glide ratio are more sensible, and so are the scales. I'm hesitant to add manual adjustment because it increases the complexity of the interface. However, if you have an idea of how this might be done without cluttering things, I'm all ears. Michael

Yep... I'm working on a simplified update utility, but for the time being there is an ironic difficulty to updating on a Mac. Shoot me an email and I'll help you get up and running: michael at flysight dot ca. I use "Audacity" to generate the files. The sample rate is 7812 Hz and they are uncompressed 8-bit WAV files. If there's significant interest, I can probably put together a page for the wiki describing how it's done. Michael

You'll need to configure it first. By default the beta firmware will only produce tones. Configuration information is here: http://flysight.ca/wiki/index.php?title=Configuring_FlySight#Speech_Settings Also, you can test the speech on the ground by changing "V_Thresh" in the configuration file to 0 instead of 1000. This will make it so the FlySight always produces tones--not just when you're in freefall. If you make this change and then turn the FlySight on, you should immediately hear tones and speech. You'll want to change the setting back to 1000 before your next jump, or it will be a long climb to altitude. Michael

The speech modes should work on all FlySights. The only limitation with the older units is that they will only be able to record 5 Hz data rather than 10 Hz. Michael