crwper

I think this point bears a little elaboration. It's easy to get lazy about keeping the arms/legs completely closed for a second or two. It's important to focus on pushing the wings completely closed on exit for a full second at least. If this is done properly, then it shouldn't really matter how he exits--he should be no nearer to the tail than any other jumper would be. Michael

It looks like I misinterpreted the jumps in the data. What's actually happened here is that the speed accuracy fell below the threshold specified in the configuration file, so the FlySight stopped logging. Looking at the raw data, a few seconds are lost inside each break, but because of the way I was plotting the data, this showed up as a sudden jump instead of a break in the plot. So, all of the data for these two jumps seems to be valid. To avoid the problem in the future, the speed accuracy threshold could be increased in the configuration file. However, this would result in more erroneous points being logged, e.g., just before exit. The speed accuracy threshold was introduced to prevent false "exits" when importing data into Paralog. Considering that data could be lost irretrievably because of a low threshold, I wonder if it might be better to handle this filtering when the data is imported into Paralog, rather than preventing the data from being logged at all. Looking at Helmut's track again, the elevation appears to go up, but the size of the error bars, combined with the fact that the velocity never quite makes it to zero, make me think he was close, but not quite there. Looking at Oliver's jump, again we see the rising elevation--still with fairly large error bars. However, the vertical speed drops below zero by an amount larger than the estimated speed error. Ideally, I'd like to see a little more room above the error bar, just to be sure, but I would say based on this data that Oliver flew upward for about one second. Michael Edit: I've attached updated plots showing the gaps in logging more clearly.

Ideally, the FlySight should be mounted so that its top surface points toward the sky. For wingsuiters, the back of the helmet is common. There are a few mounting methods. FlySight ships without a mount, but a machined aluminum mount is available: http://www.dropzone.com/cgi-bin/forum/gforum.cgi?post=4155977#4155977 There are many homebrew mounting options available, as well. In the past, I have simply use gaffer's tape to tape the FlySight to the back of my helmet. Others have posted their mounting solutions in this thread. The FlySight is about 2" x 2" x 0.5", and weighs less than 50 g. A few people have commented that it is a lot smaller/lighter than they had expected. Earphones are required. FlySight won't work with a "mono" plug, but works fine with the kind of earphones most people have lying around. Just put one earphone in your ear, and tuck the other one away in your helmet. Alternatively, some people have used motorcycle helmet speakers similar to these: http://www.ebay.ca/itm/3-5mm-Motorbike-Helmet-Speakers-MP3-Motorcycle-Bike-/150653724660 Someone even had good results just placing a regular pair of earbuds in the audible altimeter pocket. Hope this helps!

I would have guessed the same as you. I'll send an email to u-blox to inquire. Michael

I've attached the analysis of Helmut's track. Alas, it has similar discontinuities. I would be very interested to see the same test repeated with the units set to the 2 G model, to confirm that the 1 G model is the cause. Perhaps. I haven't done this yet because using a more inclusive model (i.e., using the 2 G model instead of the 1 G model) will result in increased noise in the data. Provided you're flying within its parameters, you should get more accurate data using the 1 G model. That said, it's possible that the difference in noise is negligible, in which case the 2 G model might be a better default. If you're still flying, I'd love to see a track using the 2 G model for comparison. Michael

I've attached another plot focussing on Oliver's flare. The vertical speed here comes directly from the CSV file, so it is largely independent of the elevation. The error bars for speed and elevation come from the speed accuracy and vertical accuracy, respectively, reported by the GPS receiver. The discontinuity just before point #330 caught my attention, and I think there may be an explanation that will be helpful for others trying to get this kind of data. Most GPS receivers rely on an internal model in order to reduce the noise inherent in their measurements. This model describes the kind of motion the unit is expecting. Anything that doesn't fit the model is essentially written off as noise. The more restrictive this model is, the lower the noise becomes. However, if you choose a model that is too restrictive, then some of your actual motion may wind up in the "noise" pile. By default, FlySight uses a model called "Airborne with < 1 G acceleration". In most cases, this works beautifully for wingsuit flight. However, it doesn't work quite as well, e.g., for swoopers. We noticed at one point that swoop tracks were consistently going below the ground, then recovering upward. While planing out, they were experiencing more than 1 G acceleration, but the model had "smoothed" the track to keep acceleration within the expected limits. Changing the model to "Airborne with < 2 G acceleration" corrected the problem. In the attached plot, it looks to me like acceleration was nearing the 1 G limit just before the discontinuity, which makes me think the discontinuity itself may be a sort of correction, and makes it harder to say exactly what's going on with the data just after it. For anyone using a FlySight to log this sort of jump, where an aggressive flare is used: Be sure to change your model at least to "Airborne with < 2 G acceleration". This way, you'll stay clear of the limits of the model, and avoid glitches. Michael

It depends on the unit. Some of Garmin's receivers use a barometric altimeter to augment elevation measurements; other receivers, e.g., the FlySight, do not. A position track alone probably wouldn't convince me that someone was flying up. The published specs for GPS receivers give position accuracy on the order of 2 metres, but this cannot necessarily be achieved in dynamic conditions. One thing in particular that caught my eye is the "lift" immediately after exit. This is probably best explained by the fact that the GPS receiver suddenly loses half the satellites it had been using. This results in a bit of a discontinuity in measurements, and it wouldn't be too surprising to see a sudden jump up at that point. One piece of information comes to mind that could corroborate a claim of lift... In addition to calculating position based on the travel time of satellite signals, a GPS also keeps track of shifts in the signal due to Doppler effects. This information can be used by the GPS to calculate your 3D speed, with no need to take differences on inaccurate position readings. Not all consumer units record this, but a few do. Published specs give a speed accuracy of about 0.1 m/s, but, again, in dynamic conditions this could be as bad as 1 m/s or so. The GPS receiver can use its internal model to estimate the accuracy of speed measurements, which gives us some idea how big the "error bars" are on any speed measurement. So... Putting it all together... First, the data should occur in a place where there is not a sudden change in visible satellites. Second, the position track should show an upward trend. Finally, the vertical speed measurement derived from Doppler data should show upward motion greater than the reported speed accuracy. Michael

The updated firmware is available here (links in the "Beta" row have been updated): http://flysight.ca/wiki/index.php?title=Latest_firmware Two major changes have been made: In the "Tone Settings" section, I've added a "Chirp" option. When this is set to "1", the FlySight will chirp up when the value is below the minimum, and down when it's above the maximum. An up-chirp sounds like "bweep", while a down-chirp sounds like "beeoop". This should make it a lot easier to use the FlySight to bracket, e.g., your vertical speed. To improve FlySight's accuracy when indicating vertical speed, I've also added a "Use_SAS" option in the new "Miscellaneous" section at the bottom of the config file. When this is set to "1", the FlySight will compensate for the expected increase in terminal velocity at higher altitudes. Logged speeds will still be accurate, but an adjusted speed will be used to calculate tone pitch and rate. Hope this helps. If you have any problems, please don't hesitate to contact me. Michael

Total speed is your combined horizontal/vertical speed. This is useful, for example, for swoopers. A swooper's goal is to build speed with the landing turn, then retain as much as possible of that speed as the canopy planes out--really, exchanging vertical speed for horizontal. Total speed stays fairly continuous through that manoeuvre, so it can be useful to identify places where your input causes you to lose energy. The chirp is a work in progress. With any luck, I'll have it added to the beta version in the next couple of days. I'll let you know when it's up. Michael

When I get a moment, I'll update the configuration page on the wiki to include the additional settings. In the meantime: All of the "option_2" values control the tone rate in the same way that the "option" values control the tone's pitch. By default, the rate of the tones depends on the change in the indicated value--i.e., glide ratio, speed, etc. The tones speed up a little when things are changing, and eventually settle down to 1 tone per second. That's what the FlySight does when "Mode_2" is set to "9". However, maybe you want to indicate two different values. For example, a swooper might use the tone's pitch to indicate total speed, and the rate to indicate vertical speed. That way, if they are practising up high, they can not only get an indication of their total speed, but also if they are flying level. In this case, they would set "Mode" to "4", and "Mode_2" to "1". I suspect this is more information than someone can intuitively handle, but the beta firmware is all about experimenting with new ideas, so the option is there. The "Min_val_2" and "Max_val_2" values control the range used for the tone's rate, in the same way that "Min" and "Max" control the range used for the tone's pitch. Continuing with the example of the swooper above, these would control the relationship between vertical speed and tone rate. The swooper might choose "0" for "Min_val_2" so that the slowest rate corresponds with level flight. "Max_val_2" could be set a little higher than the fastest expected rate of descent. "Min_rate" and "Max_rate" control the actual tone rate at each of these extremes. By default, the slowest tone (i.e., when nothing is changing) is 1 tone per second, while the fastest (things are changing very quickly) is 5 tones per second. "Flatline" controls the behaviour of the tones when the indicated value drops below "Min_val_2". Remember--this is based on the settings for tone rate, not tone pitch. With everything else set to the defaults, if you change "Flatline" to "1", the tone will flatline when your glide ratio is changing very little. Going back to the swooper example, the tone rate will decrease as the swooper gets closer and closer to flying level. But what he really wants to know is when he's in level flight. So, he could set "Min_val_2" to some very low vertical speed, and set "Flatline" to "1". With these settings, the tones would get slower and slower until "level flight" was reached, at which point they would suddenly flatline. The sharp change in indication can be useful if you want to know precisely when your vertical speed drops below some value. My feeling is that most people's eyes will be glazing over a bit by now, which is why these changes haven't made it into the production firmware. For the most part, I think the tone rate is something you shouldn't have to mess with--the default behaviour is pretty intuitive. In cases like yours, what is needed is simply a clear indication (e.g., a chirp) of when the indicated value is outside the "Min/Max" bounds. Hope this helps! Michael

Ah, yes. To update the config file, delete the old one, unplug the FlySight from your PC, and turn the FlySight's power on then back off. When you plug it in again, the new file should be there. Michael

Atmel broke my link! If you go to the FLIP download page here, version 3.4.3 should do the trick: http://www.atmel.com/dyn/products/tools_card.asp?tool_id=3886 Or a direct link: http://www.atmel.com/dyn/resources/prod_documents/JRE%20-%20Flip%20Installer%20-%203.4.3.exe You can work out your canopy glide ratio using FlySight's data, as well, though I think Paralog trims this during import. To view the full data set, try the FlySight Viewer program here: http://tomvandijck.com/flysight/ The viewer will give you your glide ratio, but I don't think it can output KML files yet. There is a link here to a GPSBabel style file which may help you convert FlySight CSV files into KML, though the process is a little tricky: http://flysight.ca/wiki/index.php?title=FlySight_viewers A word of caution, though: The actual glide ratio data is not as useful as you might think, because winds affect it quite a bit. Although FlySight's tones would also appear to give you glide ratio data, this isn't exactly what they're doing. Unless you happen to have perfect pitch, you'll have a very hard time telling what your glide ratio is by listening to FlySight's tones. However, most people find it very easy to identify changes in pitch. FlySight uses this "loophole" to tell you if your glide ratio just went up or down--a much more useful piece of information. All of that said, if you compile a bunch of data on different days, you certainly might be able to get a better idea of how your canopy flies in various conditions. Have fun! Michael

There is a little more about the threshold here: http://flysight.ca/wiki/index.php?title=Configuring_FlySight Basically, when calculating glide ratio, you divide the horizontal speed by the vertical speed. If the vertical speed becomes very small, the calculation becomes increasingly inaccurate. With the production firmware, there is a setting called "Threshold" in the configuration file which sets how fast you must be falling before FlySight will produce a glide ratio tone. When you're using the vertical speed mode and the production firmware, the threshold is ignored completely. Initially, this setting was simply a way to avoid the mathematical issues around calculating glide ratio. However, it now seems like it's more useful as something that differentiates between, e.g., freefall and canopy time, so in the beta firmware, the vertical speed threshold has been extended to all modes. In the beta firmware, we've essentially duplicated all of the "pitch" settings to add "rate" settings. So, for example, you could have the pitch of each tone indicate your horizontal speed, and the rate indicate your vertical speed. After playing with it a bit, I think this may simply be "too much information". One of the things I like best about FlySight's tones is that they don't require much explanation. However, as soon as you use them to indicate more than one thing, you wind up trying to decipher the tones in freefall--not a good thing, in my mind. Even with the beta firmware, there isn't a really good way to indicate if you're going too fast. You could do something sneaky like use the vertical speed threshold to prevent tones below some speed, and then when the tones start to sound you know you're going faster than that--but it's a bit of a hack. What I have in mind at the moment, to help with this sort of thing, is to have the usual tones within a range of speeds, but then when you go over the max speed, we can change the default behaviour (which is to keep using the highest pitch tone). Instead, we could use a downward "chirp" tone. http://en.wikipedia.org/wiki/Chirp The samples on the Wikipedia page are a longer than I would use (I'd like to use something not much longer than the usual tone), but the "exponential chirp" should give you an idea. This should be a lot easier on the ears than a flatline, but still really easy to identify in freefall. Michael

The beta firmware is a development version with a few features that aren't quite ready for prime time yet. The main difference right now is increased flexibility in tone generation, at the cost of a more complex configuration file. You can find instructions for updating the firmware on the wiki: http://flysight.ca/wiki/index.php?title=Firmware_upgrade I believe it is also possible to update the firmware using a Mac, but the tools required are pretty low level. If you run into difficulties with the upgrade, please feel free to shoot me an email (michael at flysight dot ca) and I'll do my best to help. Michael

Currently, you can use the FlySight to indicate vertical speed, using the settings catweazle linked to. I'm trying to think of how you would best accomplish what you're looking for... It would be nice if there were definite "edges" on the indication, so you'd know right away if you're going too fast/slow. In the "production" firmware, the vertical speed threshold is active only in the glide ratio modes. This has been changed in the "beta" firmware--it's now used in every mode. However, this only really gets you a solid indication on the bottom end. The beta firmware also adds min/max limits on the indicated value (i.e., glide ratio, vertical speed, etc.), rather than just max. By default, FlySight will keep indicating the min/max value if you go under/over the limit, but in cases like this, it might be helpful if it did something more obvious--maybe if it went quiet, or if it flatlined... Does anyone have a better idea? Might be time for a little firmware work this weekend.

As promised, here are a couple of photos of the completed mount. Michael

I do. Thanks for reminding me! The first batch of mounts are in, with the flat, 90-90, 141-110 and 141-200 models available. These are machined to accept #6 screws, but also come with VHB tape for mounting. I've got short straps fitted with a camming buckle which secure the FlySight beautifully and allow you to remove it very quickly. I'll post a couple of photos of the completed mount tomorrow morning. I've been trying to find time to update the website, but that doesn't seem like it will happen right away. For pricing information, please PM me here, or shoot me an email (michael at flysight dot ca). Thanks! Michael

The GPS signal is about 20 dB below the thermal noise floor at the receiving end. This means the signal is about 100 times weaker than the signal generated just because the things around us are warm. As you say, the receiver is only able to use this information because it knows precisely what it's looking for. Michael

Thought I'd update everyone on the aluminum mounts. I've got a bunch of camming buckles made, which will hold the FlySight in place wonderfully. Unfortunately, machining is taking a lot longer than expected. The first batch of aluminum mounts should be available in the first week of July. To those who have been waiting--thanks for your patience! Michael

Ordinarily, I would say there shouldn't be a problem as on long as the antenna side (i.e. the side with the light on it) has a clear view of the sky. Most people seem to get good results even if the antenna is facing sideways when in flight. My only hesitation would be the carbon fibre in this case. I know that some high-carbon plastics can interfere with reception. As mentioned previously, I think the best thing would be to mount the FlySight where you plan to, run it for a bit in an area with a reasonably clear view of the sky (i.e., outside and not in an urban environment, if possible) and then check the number of satellites (the last column in the CSV file). If you're getting 8-10, you're in good shape. More than 10, and you're in excellent shape. Michael

I'm thinking of adding a "demo" mode to the config.txt file, which would run through the range of tones (some pitches are louder than others). For now, though, I also use MrCat's method. Michael

Unfortunately, production issues have been holding things up a bit. I'm hoping to have the mounts ready to ship in the next two weeks, but there are a few things (like the looming Canada Post strike) which could delay that a bit further. I think it could be a while before the big dealers start carrying mounts, since there are a few sizes to stock. I'd recommend ordering the FlySight from Para-Gear right away, and then you could order the mount directly when it becomes available. Michael

Plastic/fiberglass are likely in order. I'll be very interested to hear if the FlySight can get a lock with a metal enclosure, though. Michael

Luke is right. Ideally, the FlySight should be fixed on the back of the helmet so it has a clear view of the sky. With the unit mounted on the side of the helmet, signals coming from one half of the sky will be muted, which may reduce the accuracy of the position and speed measurements. In practice, oddly, it doesn't seem to make too much difference. I've made a few jumps with the FlySight tucked into a pocket, for logging purposes only, and the data seems to be fine. If you want to be sure, as Luke says, you could make a jump with the FlySight mounted on the side of your helmet, and then look at the log file. With good visibility, the "numSV" column usually sits in the high single digits (8 or 9 satellites used to compute your position/speed), and the speed accuracy usually sits around 0.2 to 0.5 m/s. If you're seeing fewer satellites than this, or if your accuracy is much worse, it could indicate that the FlySight's position is not ideal. Michael

I've got a batch of 4 models being machined right now. These should be complete this week. The four models include one for flat surfaces and three for different curved surfaces, based on measurements I got from individuals and manufacturers. Hopefully these will fit a variety of helmets, and for those who can't find a model that fits, we'll start building a list of requests for the next production run. For testing, I've been using a piece of double-sided Velcro to hold the FlySight in. This works fine as long as the Velcro is in good condition, but I'm working to have a batch of straps with low profile camming buckles manufactured, which should make the mount more secure. The straps should be ready in about two weeks, if all goes well. For anyone who buys a mount before the straps come in, I'll just send the strap separately when it becomes available. The mounts will ship with 3M VHB tape in place, but they also have two counter-sunk holes machined to accept #6 flat-head machine screws. The mounts will be sold on the website, and hopefully through dealers as well (though the fact that there are many different models makes them a bit tricky to stock). I'll let you know when they're up. I've attached a draft version of the mount template, as well as a couple of photos showing how the template is used. Basically, you will need to print and cut out the template, then check how well the "feet" on each side match your helmet's curvature. You'll want to take measurements horizontally and vertically in the area you want to mount the FlySight. Ideally, the feet should sit flat against the helmet, but you can get away with a size that touches on the outside, with less than 1 mm gap on the inside of the foot. For the first production run, I've ordered "90/90", "141/110", "141/200", and "flat/flat" models. Michael Edit: It looks like you may have to download the PDF in order to view it. Clicking on the PDF directly doesn't seem to work.