crwper

Ah, nuts. That one's been on my mind for a while, too. I'm going to add the file name to the title bar like other applications do. Ditto for the video windows. Michael

Problem solved, I hope. I've uploaded a new package to the website. If you repeat the download, the program should work properly. Thanks! Michael

Interesting... Looking into it now. Michael

I've got a couple of new things for you all this weekend. First, there is an updated beta firmware available here: http://flysight.ca/wiki/index.php?title=Latest_firmware As usual, the update procedure is here: http://flysight.ca/wiki/index.php?title=Firmware_upgrade It's easiest to update on Windows XP/7. The update process on a Mac is oddly a bit more involved, but it is possible. At the moment, it's not possible to update on a Windows 8 machine without updating the FlySight's "bootloader"--something that can't usually be done in the field. I think I've finally worked out all the glitches with speech (on all FlySights) and 10 Hz logging (on FlySights with SN 1247 and later). I did receive one report of someone who had "clipped" speech. This turned out to be a bad microSD card. If this happens to you, let me know and I'll send a replacement microSD card your way. As always, if you find any other issues please let me know. There is also a new version of the cross-platform FlySight Viewer available: http://flysight.ca/wiki/index.php?title=Cross-platform_FlySight_Viewer This project started out as an experiment in rapid data analysis. The goal is to put as few barriers as possible between "questions" and "answers". If you can think of a way to do things with one fewer click or keystroke, or if you find yourself reaching for a pen and paper to figure something out, I'd love to hear about it. The new viewer includes a couple of really awesome changes: A map view and synchronized video. These are both described in the link above. Michael

One more correction: Thanks for organizing this one, Spot. As always, it was a pleasure to be a part of the competition! Michael

Bear in mind that if you go the Bluetooth route, you'll also need to plug an adaptor of some sort into the FlySight itself and you'll have two extra pieces to charge (the adaptor and the remote speaker). A simpler solution may be to install motorcycle helmet speakers in your helmet. I've had some success even with cheap speakers like these: http://www.ebay.com/itm/7-5ft-3-5mm-Motorbike-Helmet-Speakers-Great-for-MP3-Motorcycle-Bike-GPS-/221456623175 The main thing is to make sure that the speakers use a stereo jack. Some speakers use a mono jack, but this is not compatible with FlySight--it will short out the contacts and can cause damage. Michael

Odd... That may be related to the bug I mentioned before, though I'm surprised to hear it's happening at 5 Hz. Can you make sure you've got the latest beta posted above and confirm if the bug still occurs? Thanks! Michael

The beta version does have elevation alarms, but I would be cautious about depending on them for break-off. There are a couple of issues I see at the moment: Because the FlySight doesn't know where the ground is, you'll need to update your alarms when you move from one DZ to another. When you forget to do this--because eventually you will--you won't hear the alarm as expected. If you lose GPS signal, run out of battery, or if the earphone falls out of your ear in freefall, then you may not hear an alarm. All of these things are less likely with something like an audible altimeter, which doesn't require a sensitive GPS signal for its measurements, has a long-lasting battery, and requires no earphone to be audible. Neither of these is an issue for non-critical alarms, but for these reasons the elevation alarm feature should not be used for anything where safety of life is a concern. Michael

Hi All-- Sorry I haven't been around. The beta version on the website hasn't been updated for a while because we've been working on a glitch in the original beta--it would occasionally produce a corrupt CSV file where the next line started before the previous one was done writing. I've attached the latest beta version here, which fixes that issue. There is one more issue I'm working on right now... If you're logging at 10 Hz, with this version you'll occasionally see missing data points. You shouldn't have any problems if you're logging at 5 Hz. I've been putting off updating the beta version on the wiki until I get that taken care of, but there seems to be a lot of interest here in an update of some sort, so I thought I'd upload what I've got. The procedure to update using this file is the same as usual: http://flysight.ca/wiki/index.php?title=Firmware_upgrade Be sure to copy the updated "audio" folder included in the zip file onto your FlySight. Otherwise, you might find the speech a little... odd sounding. A couple more points worth mentioning... There is a bug in the Atmel processor which makes it impossible to update the FlySight with a Windows 8 machine. The problem can, in principle, be fixed using a hardware programmer (something you would have to send your FlySight in for), but I haven't got that worked out yet. In the meantime, Windows 8 users will need to find a Windows XP/7 machine for the update. Mac users are fine. I'm hoping to have the last glitch taken care of in the next week or two, and then I'll update one more "beta" version to the wiki. I'll let you all know when it's there just in case you want to hold off a few more days.

Alas, Windows 8 doesn't work with the firmware update. As it turns out, there's a bug in the Atmel bootloader (a bit of code that ships with the processor and is responsible for firmware update) that incorrectly identifies the interface as "USB 20.0" instead of "USB 2.00". Windows XP, Windows 7 and Mac don't seem to notice, but Windows 8 won't recognized the device. We're working on a resolution, but it will certainly require that the FlySight be reprogrammed with a hardware programmer--something that can't be done in the field. In the meantime, if you can find a Windows XP/7 or Mac machine, you should be able to update without issues. Michael

There is usually a decal on the back of the FlySight which includes the serial number. If the decal has been removed, you can usually find the serial number printed on the PCB inside the FlySight. Michael

Bingo. Michael

You are mistaken, I think. The details of GPS processing are a little outside my area of expertise. However, roughly speaking... The GPS C/A code is transmitted on the L1 frequency at a rate of 1.023 Mbps. The C/A code itself is a 1023 bit "pseudorandom" sequence. This means the code has certain "nice" properties that random signals do, but the sequence can be generated by a simple function. This means the C/A code repeats 1000 times per second. To distinguish one satellite from another (and from background noise), the GPS processor correlates the incoming signal against the known pseudorandom sequence for each satellite. Thus, we might expect that there is a natural limit somewhere around 1 kHz sampling. What keeps us from realizing this 1 kHz sample rate is the enormous amount of computation that needs to take place in order to perform the correlations mentioned above. The ability to perform these computations while remaining space- and energy-efficient is one of the things that separates one GPS chipset from another. For now, the rate that we get solutions is mainly limited by a balance between cost, energy-efficiency and space. With each generation, u-blox has reduced the scale of their fabrication process, which allows them to squeeze a few more transistors into the same space with minimal impact on power requirements. Consequently, we see a bump in the specs each time. Hope that helps clear some things up! Michael

By default, the FlySight uses GPS only. Newer units (SN 1247 and up) use the u-blox NEO-7 module, which supports GPS, GLONASS, Galileo or QZSS--but only one at a time. The firmware doesn't currently expose this feature, but it certainly could. Michael

The "beta" firmware currently on the wiki can sometimes produce corrupt CSV files, but shouldn't affect time to first fix. We should have an updated beta firmware available soon (most likely this week) which fixes the "corrupt CSV" issue. We've managed to get up to 10 Hz logging (on newer units) with glitch-free speech. I'll let you all know when the updated firmware is available. Michael

Often when I hear a problem like this, the cause is a non-existent or abbreviated "warm-up". There are a couple of steps which should be followed to give the FlySight the best chance of getting a lock: The 15 minute warm-up. At the start of every weekend, put the FlySight in an open area and turn it on. Wait until the green light starts blinking, then start a timer. Leave the FlySight on for at least 15 minutes. During this time, the FlySight downloads "almanac" data from the GPS satellites that tells it roughly where they are orbiting. Strictly speaking, it takes 12.5 minutes to download the data and it's good for several months. However, it's a good habit to do this at the start of each weekend just to be sure the data is current for wherever you happen to be. The 1 minute warm-up. Just before you get on the plane, turn the FlySight on for 1 minute. Again, the timer starts when the light starts blinking and it has to be a full minute. During this time, the FlySight downloads "ephemeris" data from the satellites. This is much more precise information about the orbit, but because it's so precise, it's only good for a few hours. Broadly speaking, these two steps give the FlySight the information it needs to figure out what's going on quickly when you get out of the plane. If you miss one of these steps, the FlySight winds up trying to figure out where it is in a really dynamic situation--i.e., when you've just fallen out of a plane. That takes time. If you're already following both of these steps, shoot me an email (michael at flysight dot ca) with the following four files: The "config.txt" file from your FlySight; The file from the 15 minute warm-up that weekend; The file from the 1 minute warm-up before that jump; The CSV file for the jump. We'll definitely get it sorted out for you. Definitely send me an email with the information above and I'll take a look. It sounds like you may also have a loose audio jack, which I can sometimes fix. In any case, we'll make sure everything is working 100% for you. I would also be interested to know the serial number of your unit and your friend's. In the last year we moved to a newer version of the u-blox module, which could account for some of the difference between the two units. Michael

I gave some thought to a similar system last summer, but ultimately I felt that size and battery life would be an issue. After some searching, though, I came across this: https://www.sticknfind.com/sticknfind.aspx Range is only about 100 feet, but the size and battery life are great. I haven't experimented with it myself, but here's my thinking... When we're looking for a canopy, it's not usually because we have no idea where it is. Usually, we have some idea but it's hard to find because of tall crops, trees, etc. In that case, putting a full GPS/cellular module on the canopy might be overkill... What we really want is to find something we can't see. With the StickNFind, your worst case scenario would be to walk up and down rows a little less than 100 feet apart. Eventually, you should get a signal and then you can quickly narrow down the precise location. It would take a little more time than walking straight to a GPS location, but I wonder if the savings in space and battery life would make up for it. Michael

The two GPS "warm-ups" allow the FlySight to download orbital data from the GPS satellites. Each warm-up addresses a different kind of orbital data: Almanac: Takes 12.5 minutes to download. Tells the FlySight roughly where all the satellites will be in the sky and gives basic ionospheric correction information. This allows the GPS receiver to get a fix faster and also helps improve the accuracy of the measurements. Almanac data is valid for about 6 months, but I recommend doing the 15-minute warm-up at the start of each weekend as a matter of habit. Ephemeris: Takes 30 seconds to download. Tells the FlySight much more precisely where visible satellites will be. This means that when you get out of the plane, the FlySight knows precisely where it's expecting the satellites to be, and it can quickly separate their signals from the background noise. Bear in mind that GPS signals are well below the level of thermal noise, so this kind of information is critical in getting a quick fix. Ephemeris data is valid for about 2 hours, which is why it's important to do the 1-minute warm-up every time while waiting for the plane. Without these two pieces of information, what you'll usually see is that the FlySight won't get a fix until you're under canopy (a much less dynamic situation), or it will get a fix in freefall, but only using a handful of satellites. It's important that the two warm-ups be completed, but leaving the FlySight on for longer than the recommended time won't usually improve things--either the FlySight has the most recent almanac and ephemeris, or it doesn't. There are two things I look for to determine if the FlySight's data is solid: number of satellites used in the fix and the error estimates (horizontal position, vertical position and speed). Usually, in the skydiving environment, the number of satellites is not a limiting factor. If the warm-up has been completed properly, you should see 8-9 satellites once you're in freefall--more than enough to compute a good fix. Things become more complex on BASE jumps, where half the satellites might suddenly disappear behind the mountain on exit. The error estimates use "circular error probable". Of course, the FlySight doesn't know where it actually is, so it estimates error based on the spread of results it gets from different satellites. Usually, this gives a pretty good estimate of the position error, but it's important to remember that there are some cases--e.g., if the signal is bouncing off a valley wall--where the estimated error can be strangely low. In the skydiving environment we usually have near-optimal conditions, so the error estimates are generally good. Let's take the jump data I posted earlier as an example. It's not in the plots, but the number of satellites in freefall sits around 8-9, so you're in good shape there. Looking at the errors, you can see that things improve rapidly once you leave the plane. It takes about 30 seconds for things to really settle out, but the errors are mostly decreasing during this time, which leads me to believe the GPS is just building confidence in data which is generally good. The exception on those plots is the sharp spike in velocity error where you plane out. On paper, it looks like it goes from about 0.3 m/s up to about 1.6 m/s, but I wouldn't treat these figures as absolutes. The spike is only about 3 seconds wide, so it's a very dynamic event. I would take any velocities reported during that time with a grain of salt. However, if we used the "2 g" or "4 g" settings instead, we might find that this peak is significantly reduced. In that case, I would be more inclined to say that the GPS recevier's internal model has a pretty good handle on things, and the data is likely accurate within the stated errors. Assuming that the number of satellites, position error and velocity error all look good, I would trust the GPS data over the barometric data. I'd be very interested to see the raw pressure readings which the Alti-Track is using to make its measurement. When I was developing FlySight, I experimented with pressure data, but found that it was incredibly noisy. I'm curious to know what the altimeter sees, for example, when you suddenly plane out. It could be that a subtle change in your wrist position puts the Alti-Track in a low-pressure region, and that smoothing filters turn that into a slow climb. Ultimately, I think what gives me the most confidence in the GPS data is that it reports several values which help us determine its reliability. Without access to the raw pressure data from the Alti-Track, it's hard to say whether or not we should trust its results except in a very stable situation. Maybe it's time to start experimenting with pressure sensors again. :-) Michael

It does look like your first jump exceeded the model's acceleration limits: Acceleration: http://imgur.com/KQFoGMZ Interestingly, this seems to have had an effect on speed accuracy, but not position accuracy: Speed accuracy: http://imgur.com/pZvZ9bw Position accuracy: http://imgur.com/3Z0HSD0 Paralog bases its calculations on position data only, but I think I'll probably bump up the acceleration limit on the competition units to see if the velocity error is improved. I've been giving some more thought to the article I posted, as well. The main concern for paragliders is to stay within certain flight levels, which are defined by barometric altitude. This doesn't apply to us, but I think a different consideration may. FlySight logs raw velocity, but when it calculates tones, it adjusts velocity to account for the reduced air pressure at altitude. I'm not sure if Paralog currently accounts for these differences when comparing jumps at different locations, but it occurs to me that altitude could have a significant impact on the time and speed rounds. If we wanted to correct for this effect, it would be best to use barometric altitude/pressure rather than GPS altitude. That said, your comments have me thinking that the error introduced by trying to measure pressure in a dynamic situation may be greater than the error introduced by using GPS altitude rather than barometric when adjusting velocities. Michael

A while ago, someone sent me this excellent article on the difference between barometric and GPS altitude: http://www.xcmag.com/2011/07/gps-versus-barometric-altitude-the-definitive-answer/ In a nutshell, there's potentially a difference on the order of 200 meters between GPS altitude and barometric altitude. Some of this depends on where you are--i.e., differences due to the definition of the geoid vs. MSL--and some of it depends on the weather--i.e., differences due to the definition of the "standard day" for barometric altitude. Given the abruptness of your plane-out, one other source of error comes to mind... Any GPS has an internal model of the sort of motion it expects--usually things like "pedestrian", "automotive", and so on. FlySight includes a handful of "airborne" models which are what we most often use. These models assume a maximum acceleration, with three different pre-set levels: 1 g, 2 g, and 4 g. For wingsuiting, we usually use the "1 g" model, since we don't usually see accelerations larger than that. However, I'm wondering if your agressive plane-out might be exceeding these limits. I'll take a look at some of your data from the competition to see if that might be a factor. In general, I think we'd see more reproducible results in competition if competitors could use the FlySight itself to indicate the start/end of the competition window. Naturally, we don't want audible feedback used during competition, but I wonder if there is some value in making sure that the feedback a competitor gets comes from the same source we're using to judge their flight... Michael

I'm a bit late to the party, but wanted to let you know that this is something the "in-development" FlySight viewer can do. The main design goal with the new viewer is to keep the interface as simple as possible, but give quick access to the most important things we look for in a jump. Here's what it looks like now: http://imgur.com/FzwrL2L The top view is the usual something-versus-time/distance plot. The bottom three are the "front", "top", and "side" views of the part of the jump shown above. You can also see there's a small dot which shows up under the mouse, and is reflected in all three views so that you can easily connect, e.g., an increase in vertical speed with a turn. It's a bit rough around the edges, and development has been slow lately because I've been busy with other work. However, if you're interested in giving it a whirl (Windows/Mac) shoot me an email at "support at flysight dot ca". Let me know which operating system you use, and I'll send the latest version. The source code (C++/Qt) is a total mess right now, but as soon as I get a chance to tidy things up a bit, I'll be making that available too. Michael

Glad to hear you got it sorted out! The volume seems to vary quite a lot from one speaker/headphone to another. Did you try changing the volume setting as well? Michael

Here's another one produced using FlySight, Paralog and Dashware: http://www.youtube.com/watch?v=FGhF0NR-xAQ&feature=youtu.be&hd=1 Unfortunately, I don't know the details of how it was created. Michael

I should probably pass this up, but really wanted to set the record straight on this one if I can. As many people here know, I'm the manufacturer of FlySight. The reason FlySight is more expensive than the keychain GPS you linked is because it serves a much smaller market, but has similar development, testing, and production costs. Keeping those costs in mind, my main goal in pricing FlySight has been to offer it at as low a cost as I can, while still ensuring that I can afford to offer you all the level of service you deserve. I have a "day job" that pays the bills, but also offers me enough flexibility to continue working on FlySight. FlySight is something I do because I love it, and because I love the community it serves. Whether or not you buy a FlySight is, of course, 100% up to you. If it doesn't add value to your skydives, I wouldn't dream of convincing you to buy one--you just wouldn't happy with it. However, for those who find the audible feedback and/or reliability in freefall useful, I will continue to build them. I hope I've helped to clear up any misunderstanding about why FlySight costs what it does. Thanks! Michael