crwper

That's the heart of it. Ideally, the FlySight should be mounted with the "top" facing the sky, since that leaves the antenna facing upward. If you turn it sideways, at best it will only see about half the available satellites. If you're standing still on the ground, this may not be an issue, but in a dynamic situation like skydiving, you might find the data quality suffers. Michael

There are definitely a few swoopers using FlySight. A post to the swooping forum might get some answers, if that's where your main interest lies. As far as orientation goes, it's much the same advice as for wingsuiters--the top of the FlySight should be pointed toward the sky during flight. If you're thinking of using the FlySight for canopy flight, you'll probably mount it a bit closer to the top of the helmet, rather than at the back. Are there any specific questions I can answer for you? Michael

The most common way to correct for wind is just to measure wind speed/direction on the climb to altitude (the pilot can estimate this), and then subtract that from the recorded data. It's not perfect--the wind can obviously vary with altitude--but it's better than nothing. I've been giving some thought to a method for estimating the wind given GPS data from the climb to altitude... I think it should be possible to calculate wind speed and direction accurately given a GPS track with the following characteristics: Good satellite visibility through the "competition" window (2000 m AGL to 3000 m AGL for PPC). This probably means the GPS is placed at the front of the plane. I doubt the limited view out a side window will do the trick. Pilot flies as near as possible to constant airspeed through the competition window. The airspeed doesn't need to be known (it can also be calculated), but it needs to be constant. Pilot flies through a wide range of azimuths within the competition window--ideally, at least one full 360 degree turn. The idea is do a calculation similar to what is done visually with a rate-one turn, but with a lot more flexibility in terms of flight path etc. The main question, in my mind, is if it's really worth the extra trouble. A good pilot can tell you quite accurately the speed and direction of the wind. Do we need a more accurate measurement? One place a system like this might help is with verifying records... At the moment, we can trade GPS tracks, but wind corrections are dependent on what the pilot estimates. With a solid method of estimating winds from a second GPS track, there would be a bit more objective data to work with. Any thoughts? Snow's on the ground here, and I don't think I'll be able to get to the DZ to gather test data for a while. If someone out there is interested in gathering data following the above guidelines, I'd love to see what information we can extract from it. FlySight data would be ideal, since the 3D velocity is also stored in the log file. Michael

This is most likely due to hardware limitations. 10 Hz barometers are common, inexpensive, and use very little power. An accurate 10 Hz GPS is a lot harder to come by--especially with the antenna size limitations Recon is working with. Michael

For what it's worth, when I was doing testing for the design of FlySight, I experimented with a barometric altimeter as well. In my experience, a modern GPS is easily as accurate as a barometric altimeter for both altitude and vertical speed. This is not the case if vertical speed is derived from altitude measurements (as is often done with NMEA data), but if vertical speed is derived from Doppler measurements within the GPS receiver, you're good to go. As far as the reason why variometers use pressure sensors... This is likely based more on cost than accuracy. A GPS provides position information which is not necessary for variometer functionality, but would increase the build price of a vario enormously. Michael

I think this might be the best answer. Consider this: If we allow things like wingsuits and drogues when calculating freefall time, then--whether you're applying for a Guinness World Record or your AFF rating--the answer will always be to fly the slowest thing that you can get away with. To me, that's an uninteresting game, because it's entirely semantic. We can avoid that game if we use vertical distance fallen instead. If we don't allow things like wingsuits and drogues, then we are in the realm of "unconstrained motion". In that case, at least in principle, your freefall time and vertical distance are redundant measurements, since you can calculate one from the other. Again, we might as well go with vertical distance as our metric. I think there is a place for talking about things like "the slowest-falling wingsuit", but it's in a more technical discussion, among qualified individuals, where each person can decide whether or not the answer "counts". For something like records and ratings, you need criteria that are a bit easier to apply objectively. Otherwise, it just gets silly. Michael

Practically speaking, I think if we count Kittinger's drogue fall as "unrestrained motion", then we should probably also put wingsuit flight in the same category. Setting aside the comments of the announcers, I love that wingsuit technology has advanced to the point where this is even a question. I love that there are so many shades of gray between "constrained" and "unconstrained" motion. I imagine that, when the record was first set, it seemed relatively obvious what would count as freefall and what wouldn't. We've filled that gap with all kinds of fun activities! Michael

I don't have any experience with the S3 in particular, but wanted to share a bit of GPS experience... With any GPS, it's critical that you give it as good a view of the sky as possible. GPS signals are incredibly weak, and something like a human body between the receiver and the satellites can make or break your ability to get a fix. I'd be quite surprised if it were possible to mount the S3 on your chest and still get a solid fix--though I'd be interested to hear the experience of anyone who has tried. Michael

No problem at all. The left and right channels are connected internally. For the curious, the schematic is available on the wiki: http://flysight.ca/wiki/index.php?title=Schematics MrCat is absolutely correct about the problem with mono plugs--they short the audio signal to ground. Michael

I don't think it would make much difference. The audio section on the FlySight slams the headphones about as hard as it can with the 3.3 V available. If you combined the left and right channels, you'd get more or less the same voltage levels at the earphones. Michael

One note on helmet speakers: They must have a stereo plug, as in MrCat's photo. Mono plugs (two silver conductors on the jack instead of three) won't play nicely with FlySight, which was designed with stereo plugs in mind. Michael

Hi All-- I'm going to have more mounts cut soon, and would appreciate any feedback you can offer. I'm thinking of adjusting the models we offer to cover a bit more ground, and to give preference to symmetric models where possible (so you can mount with the jack facing sideways or downward). What I have in mind is to stock the following mounts: 90/90110/110141/14190/141 (jack on bottom) This eliminates two mounts we've offered previously: the 141/110 and 141/200. What I've found is that a difference of one "step" in one of the measurements gives about a 0.5 mm gap. It's better to be on the small side, since that means the corners are flush (less chance of line snag). In place of the discontinued mounts, you could use the following: 141/110: 110/110 or 90/141114/200: 141/141 The 141/110 has been a very popular model, so I'm hesitant to kill it, but I do think the above substitutions are solid. It's tricky to keep stock if there are too many models, so I'd like to keep the list as short as possible. What do you think? Michael

Spot on, I'd say. It's hard to say what effect removing the rig would have on the aerodynamics of the suit. With all his pre-jump preparation being with the rig, I think it would be foolish suddenly to remove it for the big jump. Michael

This is something I've thought about, but there is one major issue as I see it... The human head contains a whole lot of water, which absorbs GPS frequencies quite well. Regardless of the type of antenna used, by mounting it on the side of the head, you're losing about half your available satellites. Such a system can work--some people are using FlySight on the side of the helmet--but the data is not as robust as it would be if the device were mounted on the back of the helmet. Add to that the fact that helmets containing, e.g., carbon fiber will reduce the signal further, and it just feels to me like the back of the helmet isn't such a bad mounting spot. I am very interested to see how the pictured prototype manages given the above limitations. It's exciting to see something else coming to market! Michael

That does seem to be just a bit too asymmetric for any of the current mounts. There's a bit of leeway in the sizing--I've found that if the measurements are off by one "step" on one of the numbers, the match will still be within 0.5 mm or so. However, the 110-110 mount--probably the best fit to your measurements--is off by a bit more than that, and checking it with the models, I don't think I'd recommend it. The downside of the current mount design is that we need to stock so many different sizes, and machining costs dictate a minimum order volume for any new size. I'll add your measurement to the "to build" list, but I think it'll be at least a couple of months before we can get the next build going. Michael

An increase in speed error is sometimes due to a sudden loss of satellites, in which case there is no easy way around the problem other than the usual warm-up procedures. It can also be caused by flight parameters that push the bounds of the selected model. For example, if you've selected the "Airborne with < 1 G acceleration" model, and find yourself exceeding 1 G (common, for example, with swooping), then you'll see the speed error increase as the u-blox receiver tries to reconcile the two. In this example, you could improve the speed accuracy by stepping up to the "Airborne with < 2 G acceleration" model. So, really, both of the causes you mention are a possibility. Michael

The "Speed_Acc" threshold prevents the FlySight from logging points when the speed accuracy drops below a certain level. This was added to prevent spurious points--e.g., points recorded while still inside the plane--from interfering with post-jump analysis, but it does have the downside that offending points are not logged at all. In the most recent firmware, this threshold has been eliminated, and the filtering is instead done in software (e.g., when Paralog imports the file). To disable the threshold, you can set it some large value--say, "9999" or so. This should cause the FlySight to log every data point, even if the speed accuracy is quite high. BASE jumping is actually a slightly more difficult environment for GPS. What can happen is that the unit will get a fix at the exit point using, say, 8 or 9 satellites. Immediately after exit, half the satellites in view disappear because of the cliff. The receiver can suddenly be stuck without enough satellites to get a position fix, and at the same time in very dynamic conditions, in which it is difficult to reacquire the fix. That said, I've had really good results on BASE jumps myself, and have only ever heard of consistent issues for jumps in Lauterbrunnen, where most of the sky suddenly disappears when you drop off the wall. One factor which can play a big role in these cases is the "warm-up" time of 15 minutes at the start of the day and 1 minute before the jump. This time needs to be measured from the time the light starts blinking, and should not be shortened--i.e., you're better off to leave it on for 20 minutes after the light starts blinking, just to make sure the full 15 minutes has elapsed. Does this help? Michael Edit: Looking at the files you uploaded, it does indeed appear that the data points were chopped by the speed accuracy threshold. If you bump the threshold up to "9999" for future jumps, the problems should disappear completely.

Hi All-- I'm a bit late to this thread, as I've been on holiday, but wanted to add what I can. Unfortunately, I wasn't at the competition myself, so am gathering as much information as I can here and elsewhere to be as sure as I can about what happened. I appreciate all the reports I see here, as they will go a long way toward narrowing things down. The terrain shouldn't have a noticeable effect in this case. The only reports I've received of terrain having any effect at all are from Lauterbrunnen, where most of the satellites disappear behind mountains very quickly at the start of a jump. Jumping with a FlySight myself, I've been pleasantly surprised at how well it handles half the sky disappearing on more typical walls--generally without even a single glitch in the data. I would be very surprised if even rugged terrain had any effect at all on a skydive. The only other reports we've received of FlySights dropping data during jumps have been because of abbreviated startup procedures. The recommended procedure is as follows: At the start of the day, turn the FlySight on for at least 15 minutes. To be precise, the green light should be blinking for 15 minutes. Turn the unit off once this is done. Just before boarding the plane, the FlySight should be turned on for one minute, then turned off again. Turn the FlySight on during jump run. If you're using Paralog, you'll need to leave the FlySight turned on all the way to the ground, so it has an altitude reference there. To expand on these instructions a bit: The initial 15 minutes it the time during which FlySight downloads rough orbital data from the satellites. This information is valid for about 2 weeks, and helps the FlySight get a faster lock in difficult conditions (for example, when falling from a plane). The one minute before boarding the plane allows the FlySight to download more precise orbital data for the visible satellites. This information is only valid for 4 hours or so, which is why you need to do this before each jump. Again, the information helps FlySight get a lock quickly. We've had a handful of people report that their FlySight only started beeping late in the jump, or under canopy. In all of these cases, the issue was resolved by underscoring the above procedure. Basically, if the "warm-up" procedure is skipped or abbreviated, FlySight is going into the jump blind, and it takes much longer for it to figure out where it is. Although the recommended procedure is to turn the FlySight off before boarding the aircraft, this is mainly to conserve battery. I have no reason to believe that leaving the FlySight on during the ride to altitude would cause any problems. With regard to FlySight's hardware, Klaus has correctly indicated that it uses the u-blox 6 chipset--the latest from u-blox and a significant step up from the u-blox 5 chipset used in, e.g., the WBT-201. Of particular note, they've gone from 1 million correlators to 2 million. In real-world terms, this translates into improved performance in difficult conditions (e.g., sitting in the plane) and a shorter time to first fix--both very important characteristics in our sport. This is the main reason why the FlySight is able to get a fix in many situations where other units are not. I hate to chalk the problems up to jamming--it sounds a bit too much like people who tell me they must have a "virus" when their internet browser slows down. However, in this case the evidence seems to be pointing in that direction. Over the next few weeks, I'll be gathering as much information as I can to determine what happened here. If you have anything you think might be helpful, please let me know. Finally, of course, if you have any questions, I am always happy to answer them. Michael

Yes... FlySight 4S will be identical to the current model, but I'll add voice indication to the firmware and force everyone to upgrade to the new hardware if they want to use it. Muahahaha... Michael

Haven't seen those before, but I'll get in touch with them and see what would be involved. Thanks! Michael

During development, I played with a 4-digit LED display with numbers about 1 cm high, Without additional optics, it could be placed in front of the eye and read quite easily in freefall. What I found was that reading/understanding the numbers in freefall took a shocking amount of mental effort. This is something we mostly don't notice on the ground, but when you're flying, stopping to read four numbers takes you completely out of the jump. I found the whole thing very disorienting. Another possibility is something like a colour bar graph. The issue there, though, is that only the middle five degrees or so of our visual field responds strongly to colour. In order to read the display, you would have to look at it, which means you aren't looking at something else (e.g., the ground). The nice thing about sound is that it works in parallel with other activities. There is one other possibility, though it's a bit limited in the information it can display. The edge of the visual field is fairly good at picking out motion, or changes in brightness. It might be useful, for example, to put an LED in the corner of your vision, and use it to indicate some "alarm" condition. Michael

Hi All-- We've had a couple of reports recently of the USB connector coming loose on FlySights. Basically, the connector can't take much torque. With a cable plugged in, a relatively small pull sideways can separate the connector from the printed circuit board. Unfortunately, this sort of thing can't be repaired, so it's important to fix it before it happens. I've done a bit of testing, and found that a small amount of Krazy Glue under the connector makes it much stronger. In fact, after gluing the connector, a sideways pull broke the cable before the connector came loose. The following document describes the repair procedure in detail. http://flysight.ca/SB1.pdf If you have any questions, please let me know. The repair is pretty straightforward, but if you'd prefer it be done here, I can do that. Thanks for your help! Michael

I'd love to hear your impressions. I will definitely be adding the "Min" setting to the production firmware, but I am always a bit unsure if the rate settings are useful enough to justify the added complexity in the config file. Michael

You've got the right idea with the "Min" value. The full range of tones--220 Hz to 1760 Hz--is spread between "Min" and "Max". If you know you won't be flying at less than 1.5:1, you could increase the tone resolution by bumping "Min" up to 150. For any glide ratio lower than 1.5:1, FlySight will just output the lowest possible tone (similar to what it does when "Max" is exceeded). I've been meaning to get the rate settings up on the wiki. In the meantime, there are a couple of explanations here, which should get you started: http://www.dropzone.com/cgi-bin/forum/gforum.cgi?post=4166816#4166816 http://www.dropzone.com/cgi-bin/forum/gforum.cgi?post=4166830#4166830 If you have any questions, please let me know--it'll help me figure out what might need additional clarification in the wiki article. Michael

At long last, I've got mounts up on the website. I've replaced the old "Software" tab with an "Extras" tab. I'd like to expand this over time to include links to third party mounts, accessories, etc. If you have something you'd like to add, let me know. Michael