crwper

That's pretty much what I have planned for the demo video. The hard part is synchronization. I'm actually going to bang together a custom firmware that records tone change data (rather than GPS data) with precise timing, and blinks the FlySight's LED when it's turned on as a way to synchronize the clock with video. Then, back at home, I'll use a second custom firmware to reproduce the FlySight's sounds exactly using the recorded timing data. However, this is likely way too complex for anyone else to use. If I was shooting first-person video and wanted synchronized sound, the best would be to have a camera with a mic input. Failing that, Klaus's idea is probably the next best thing. FlySight's audio output can be pretty loud, so it just might work. Michael

I'm hoping to do some jumps with a friend this weekend to see if we can set this up. It'll probably take another week at least to put the video together, but I'll let you know when it's posted on the website. Michael

Lou: I've worked with Klaus to make sure that Paralog can import FlySight data flawlessly. The main thing to remember is that you need to log data all the way to the ground under canopy so that Paralog has a solid ground reference. Otherwise, look for FlySight in the device options when importing from a GPS. Seth: I haven't defined a warranty period, but I will stand behind what I've built. Certainly, if you experience hardware problems in the first 30 days, let me know and I'll replace your FlySight without question. I am shipping within about a week right now, using standard air mail. This week, I'll be setting up large scale production. There may be a small delay in the interim, while production shifts to the new facility, but I will put a note on the website if that's the case. I'd like to clean up the firmware a bit before I publish it. My first priority is to ensure that hardware production is adequate, so you can expect this to take the back burner for the time being. If you have a particular interest in the firmware, shoot me an email. Michael

Indeed. It's been a while in development, but it's finally here. I am happy to answer any questions you guys may have. Michael

The signals used by GPS are right-hand circularly polarized. By using the right kind of antenna, GPS receivers can eliminate quite a lot of noise simply because it does not have this polarization. The effect is similar to what you get with polarized lenses. Without them, any reflective surface produces a lot of glare. Polarized lenses reduce the glare by blocking light that does not have a particular polarization. Typically, GPS receivers use ceramic patch antennas or, less often, helical antennas. Both are tuned to receive only right-hand circularly polarized signals. Functionally, the main difference between the two is that the ceramic patch antenna tends to reject signals which are not coming from "above". This can be a problem if the antenna is not oriented toward the sky. The upshot is that it eliminates many reflected signals, which make it harder for the GPS to get a lock. You'd think a helical antenna, which is less directional, might be better in the skydiving environment. However, because it is less selective, it's also less sensitive. The best choice for wingsuits is a ceramic patch antenna properly oriented toward the sky. There are GPS-specific external antennas. Usually, these consist of a ceramic patch antenna and an amplifier. The amplifier boosts the signal enough that it can survive the trip through a coax cable to the GPS receiver. Why is all this necessary? GPS signals are about 20 dB below thermal noise when they arrive at your antenna. This means the noise is actually about 100 times stronger than the signal when it reaches the antenna. A GPS receiver is able to overcome this hurdle using some really clever signal processing, but a poor antenna makes its job much harder. Not sure if this answers your question. Let me know if I missed anything. Michael

This sounds dodgy. Is it based on RF design experience, or just a common familiarity with antennas generally? GPS uses a right-hand circularly polarized signal. At the very least, the kind of antenna you're describing would not take advantage of this polarization. More likely, I think, the GPS won't pick up a signal at all when using such an antenna. Why keep the GPS on while in the plane? I've been testing a new GPS, and have had no issue at all with turning the device on when the door opens. I get a lock within a couple of seconds in freefall. Michael

These pages should do it for you. First, the LANC pinout: http://pinouts.ru/DigitalCameras/sony_lanc_pinout.shtml Next, the pinout for the Sony 10-pin connector (the half-moon connector): http://www.dvinfo.net/forum/attachments/sony-hvr-a1-hdr-hc-series/16718d1267336727-hdr-hc9-v-remote-terminal-lanc-sony_10pin_diagram.png You'll need to wire pins 2, 3, and 4 from the half-moon connector to pins 1, 3, and 2 of the 2.5 mm jack. Michael P.S. If this helps, I could sure use a photo of the LED end of the CamEye, as mentioned in this thread: http://www.dropzone.com/cgi-bin/forum/gforum.cgi?post=3877386 Thanks! P.P.S. Looking at the 10-pin connector pinout, I just realized you may also need to pull pin 7 to ground through a 100k resistor, in order to activate the LANC interface. P.P.P.S. I also just realized your half-moon connector has only 6 wires coming from it. I'm guessing they might be breaking out only the A/V pins (i.e. everything but the 4 LANC-related pins). If this is the case, the connector you have isn't going to cut it. It might be best to purchase an adaptor cable like this one: http://www.appliedlogiceng.com/index_files/Page499.htm

Thanks, Ian. Have you used either of these? Any comments on durability? Michael

Hi All-- I'm developing a GPS for skydivers with real-time visual feedback in the form of a red/green LED mounted much like the CamEye II. I'm curious how they've designed the LED end of things, since their design seems quite well liked, but can't find any decent photos using Google--just low resolution stuff. If someone has/could take a photo of the LED end of a CamEye II and/or describe it, it would be a great help. Also, if you've used the CamEye II, and have any comments on its usability, e.g., in bright light, I'd love to hear them. Thanks! Michael

To be fair, the Ripxx offers information that cannot be inferred from a GPS log, namely, accurate rate of turn and acceleration information. However, I'm not sure this information is useful for wingsuit pilots, except in real-time applications. Michael

Alas, I think that would only tell you why it has issues. Really, what you're looking for is a solution, and I think the best solution is probably to find out what works for others, and go with that. Sounds like you've got it mounted well, so I guess there is something with the unit itself that's causing problems. Michael

I would think they all have a Kalman filter, since it would be hard to get usable GPS data at a decent rate without making some assumptions about the kind of movement you expect. I'd say there are two major factors that contribute to good/poor GPS data quality: An appropriate filter model. If the model assumes your motion will look like driving a car, and then suddenly you're in freefall, it may not give very accurate results. Good signal-to-noise. This is partly a function of hardware design, and partly a function of GPS placement. Where are you mounting the GPS? The best way to figure out if the model is good, I think, is to see what kind of results others have had with the same GPS and similar mounting. Michael

Could be related to the model the GPS is using. Most GPS units use a Kalman filter with an associated model which basically describes the kind of motion you're expecting. This allows the GPS to be much more accurate than it otherwise could be, provided your motion is described well by the model. With my old Garmin GPS-10, I noticed that the results it returned in freefall sometimes looked uncannily like a series of parabolas, which led me to believe that the GPS had lost satellites, and was now extrapolating data. In your case, I wonder if the values for the second jump are dominated by extrapolation, rather than actual data. Michael Edit: What GPS are you using?

Ah, The Wicker Man. http://www.imdb.com/title/tt0070917/ Michael Edit: Gah! Linked the wrong one. Here's the original (1973) version.

Gotcha. That's exactly right. The device mounts as a USB disk, so what's written to disk is exactly what the user sees. Michael

Why store it in the same format as you export it in? I'm not sure I understand what you're asking. Right now, I receive data from several onboard devices in whatever format they use. The data is used to generate a tone, and then the relevant parts are written to flash memory in some format. In this context, I'd have said "storing" and "exporting" both refer to the same step--i.e., writing the data to flash memory. What do you have in mind? Michael

phoenixlpr: In this case, the "download" channel, a USB connection, is quite reliable, so I don't think we need worry too much about response to errors. Generating a GPX file would probably be easy enough, but I'm concerned that a format like XML or JSON is really built more for heterogeneous records, as opposed to a homogeneous stream of data. One thing which could be a larger concern is file size. At the moment, the largest flash chip I can get is 8 MB. It would be nice to use microSD, but they are just too big, and in any case, the best I can manage is a full speed USB connection, so transfers would take all night. I actually built several prototypes around the Garmin GPS 10, specifically because it uses a proprietary NMEA sentence for 3D velocity. However, I get an uneasy feeling about shoehorning my data into a format which happens to match it in some places, but not in others. I am aware that NMEA remains a virtually universal format, but can't quite bring myself to use it as the primary method of storage for a device which I hope will grow in unexpected directions. Klaus: I've actually never played with Paralog before, but will take a look a it. It would be lovely if there were already avenues for analyzing and compiling the data. The best case scenario for me would be third-party software which offered solid analysis of the data output by the GPS. Herwig: No chance of my going to a proprietary binary format. I want to keep this thing as open as possible, in order to encourage innovation. Part of that, to me, is ensuring that the data recorded by the device belongs to the user, not to someone else. Michael

One problem I ran into, actually, trying to use Bluetooth GPSes, is that everyone focuses entirely on NMEA output. Some of these units have proprietary binary formats which include vertical speed, but on the rest, you'd need to use finite differencing on altitude, and that's rubbish. Finally, after a lot of experimenting, I decided it might be easier just to build the GPS into the unit. This also eliminates the need to "pair" the two. That may be best. I was hoping to learn a bit more about the software people are using, but that doesn't seem to be getting anywhere. Are people just not using any software? Are Google Earth and Tracking Derby the only tools available to someone who doesn't want to write their own? Michael

My raw GPS data isn't in NMEA--it's in the u-blox UBX binary format. The reason for this choice is the fact that NMEA does not support vertical speed. Vertical speed as reported by a GPS is actually computed using Doppler measurements on the incoming signal--not by finite differencing on altitudes. Vertical speed derived from Doppler measurements is a lot more accurate than finite differencing, so I think it's important to write it out. True, but I am also trying to look forward. If I write my own extension, what are the chances that other software will ever support it? Pretty much zilch. If I write data in an open, extensible format, these chances are much higher, because, as software evolves, other software will surely have the ability to read generic columnar data. Actually, strictly speaking, CSV is a well specified format. Things get a bit hairy as soon as you want to write a field that includes a comma, like "Hello, world", and the format specifies how this should be done, for example. Michael

I thought it might be fun to include an example of the feedback I was talking about. In the attached plot, the left vertical axis shows glide angle times 100, and the right vertical axis shows speed in cm/s. The horizontal axis is time in ms. The three lines are glide angle, horizontal, and vertical speed. In testing, the horizontal speed seems to have almost no lag. There is a small lag in the vertical speed, which may contribute to this effect. I'm pretty excited to see what kind of numbers I get from the barometer, in the next prototype. The chip itself will give an accuracy of about 0.25 m, but it remains to be seen how noisy that is when it's mounted to the back of someone's head. Michael P.S. I hope others don't consider this to be off-topic. I've built this thing entirely with wingsuit flight in mind, so it was the first place I thought to post. If anyone feels differently, please let me know.

Herwig: I agree wholeheartedly, flying should be, first and foremost, fun. This is one of the reasons I've avoided visual feedback, until now. My next prototype (waiting on boards) includes the ability to output to a 4-digit 7-segment LED display. However, I suspect this will be more distracting than audible feedback. Furthermore, I suspect audible feedback gives a more intuitive sense of change, whereas visual feedback requires us to remember what the number was a moment ago. Ultimately, I think the best solution is the simplest one. For the most recent round of development, my goal has been to build kind of an "iPod" for glide ratio--something you don't have to think too hard about, just put in an earphone and go. This leaves more attention for flying, and generally, I think, removes the focus from absolute numbers. Of course, if you want absolute numbers, you can view the logs later. But I don't think "in the air" is the time to do this. The tones I am producing right now have been surprisingly helpful. There are two aspects to the tone I produce: The tone's pitch is determined by the value being measured--for example, glide ratio.The tone's rate is determined by the change in value, with a minimum rate of 1 Hz. The device tries to ensure that one tone is produced for each semitone change in pitch. So, if you're flying well, you hear a regular high-pitched tone. If you make a change, you hear a momentary acceleration of the tone's rate while the pitch changes, then it settles into a steady rate at the new pitch. The effect is quite intuitive. Interestingly, in testing, we've actually noticed the effect of this feedback as a 5-10 second wobble in the glide ratio. Without earphones in, the wobble does not occur. With feedback, the user decreases vertical speed, but at the cost of horizontal speed. This results in improved glide angle, but the situation is temporary. Eventually, the loss of horizontal speed catches up, vertical speed once again increases, and the cycle continues. So, one challenge in using the device is learning not to chase these small bumps, but instead to fly steadily. It's my hope that this device will be something someone can "play" with in freefall, rather than getting hung up on maximizing the pitch moment to moment. Michael

phoenixlpr: There are a couple of related problems with NMEA: The records generally contain information we are not actually interested in, e.g., "time since last DGPS update" in the venerable GPGGA message.Unfortunately, NMEA has no support for 3D velocity. In particular, there is no record that contains vertical speed. At the root of it, NMEA is a standard for communication between nautical instruments. It's been adopted by GPS manufacturers as well, but because of its heritage, it's not really a great fit. Basically, even assuming that we could shoehorn our current 3D PVT data into the NMEA format, there's no guarantee that we could find similar workarounds for data that might be available in the future. The fact that I even have to use words like "workaround" in talking about the NMEA format turns me completely off of it. Does the software you guys are using right now include any support for CSV? What kinds of analysis do you do on data after a jump? Michael

Herwig: I've used something similar to JSON for the configuration file, but Im not sure JSON has any advantage for logging the data itself. The first few lines of the CSV file might look something like this: time,lat,lon,elev,vel_n,vel_e,vel_d 59518750,510166666,-1140166666,1048000,0,0,0 59519000,510166666,-1140166666,1048000,0,0,0 59519250,510166666,-1140166666,1048000,0,0,0 This is fairly easy to parse for a human reader, and doesn't get much easier for a computer. If more information needs to be added--say, when I add a barometer to the device--I just add columns on the right, with an appropriate label at the top. The equivalent JSON records will look something like this: [ { "time": "59518750", "lat": "510166666", "lon": "-1140166666", "elev": "1048000", "vel_n": "0", "vel_e": "0", "vel_d": "0" }, { "time": "59519000", "lat": "510166666", "lon": "-1140166666", "elev": "1048000", "vel_n": "0", "vel_e": "0", "vel_d": "0" }, { "time": "59519250", "lat": "510166666", "lon": "-1140166666", "elev": "1048000", "vel_n": "0", "vel_e": "0", "vel_d": "0" } ] To my eye, this is harder to parse and scan quickly, takes more space on disk, and isn't really more extensible than CSV. Finally, I'm pretty sure software support is better for CSV than for JSON. Surely any program that can read tabular data as a JSON file can also read it as CSV. Am I wrong about this? Michael

Hi All-- It's been a while since I posted on this topic. I've been working on the skydiver's GPS, and am perhaps three months away from what I'd call a marketable product. Key stats are: 2" x 2" x 0.5"4 Hz u-blox NEO-5Q GPS receiverReport glide ratio, horizontal velocity, or vertical velocity as audible tones through earphonesUSB interface for configuration, charging, and reading logged dataOpen firmware, so sufficiently nerdy users can play. At the moment, the unit logs to a CSV file, which can be read when it is plugged into a USB port. The CSV file includes time, latitude, longitude, elevation, and 3D velocity. The next prototype will include temperature and pressure as well, which will also be used to improve the accuracy of calculations. From my viewpoint, the CSV is a compact, versatile format. However, in testing by others, it's become apparent that there might be a problem for some users, who are unable to use Excel to do number crunching. My questions, then, are: Is there a preferred output format which would be most easily readable by third-party software?What third-party software is available to do this kind of number crunching? I'd like to retain all the measured data in the log, which excludes some of the less flexible formats. My preference would be simply to write a CSV file, and then have the number crunching done by software after the fact. This keeps the firmware simple, and the device as versatile as possible. Any thoughts? Michael

Of course, you need a bit of money to jump, but I'd be cautious about putting things off until you have "enough" money. Like many, I started skydiving while I was in university. I worked hard during the summer, played hard on the weekends, and leaned on student loans a bit during the school year. Still, I managed about 100 jumps a year during that time. I also spent pretty well every weekend at the dropzone, rain or shine. Sometimes things cleared up enough to jump, and sometimes it was just a good place to hang out. I guess what I'm trying to get at here is, for most of the people I know who got past one or two tandem jumps, it was never about the money. If you really want to do this, don't wait for the stars to line up. Just get going, and before you know it, you'll have 200 jumps. It sounds like you might be talking about wingsuit BASE jumping. In that case, you're probably looking at a lot more than 200 skydives. I'd recommend you look at that as a long-term goal, otherwise you'll burn out for sure. In the meantime, start jumping, and enjoy the short-term goals along the way. Michael