skywombat

No takers? Okay, I made my own fixes for the date rollover bug (and for the encryption key update that Alti-2 sneakily snuck into their Y2K update). Update found here: https://github.com/evilwombat/alti2reader Needs a little documentation but it seems to be working. Note that the 'master' branch is for Linux (via Mono), but there's a 'windows' branch for, well, windows. This is provided "AS-IS" with no warranty of any kind.

Hello. For the past few years, I've been happily using Alti-2 Reader to download and back up the logbook and jump details from my N3. However, it seems like with the recent N3 update for the "logbook date rollover bug", Alti-2 Reader can no longer communicate with the N3 because Alti-2 changed the encryption protocol, almost deliberately to keep people out. Is anyone aware of an updated version of Alti-2 Reader somewhere, which gracefully handles both encryption schemes and date formats? I finally got a chance to sit down and figure out the new encryption, and things seem to be working. However, it is going to take some effort for me to clean up the code and make everything nice and backwards-compatible, and it would be silly to go through this effort if someone else already did it. So, before publishing my own fork of Alti-2 Reader, it would be good to know if anyone else out there already did. I've also been trying to get in touch with the original author of Alti-2 Reader (to send updated encryption code and to ask permission to publish my own version), but it seems like so far I've had no luck. Any ideas? Thanks! -Steve

Here's a screenshot

Raised by 300 ft ("A3") following discussions / recommendations during Safety Day, primarily due to terrain in the immediate vicinity of the DZ.

No updates for a long time. Any idea what became of it? Is the author okay?

There exists "Wingsuit Lite" in the Android Market, which is quite decent.

I can't imagine wearing the thing on landing. The vertical field of view is restricted quite a bit. I have a rule of pulling higher when wearing it (in case I need to rip it off my face to see better to deal with stuff) and I feel like pulling it off for landing is a must for me. Otherwise it is hard to get a feel for your glide path near the ground.

To some people, 105 is just another number ;) But this is about the device, not the people marketing it. I only wish they release updates based on customer response. Maybe we can roll our own firmware, but an update file would be a good start for such efforts. I would settle for an option to swap for speed and glide indicators.

I know someone who lost his while wearing them outside of the helmet, so make sure they are strapped down well. There may be a helmet clip you can use. Have not had issues with goggles flipping up, but they can shift around and make the screen hard to see. There needs to be an option to make glide the bigger of the two numbers. Seeing handles? With difficulty indeed. I pull higher to get extra time to deal with things. Arguably "flying like jeb" would make this program not applicable ;)

1.2 -> 1.4. I am still learning. But it is a learning tool. Glide increases right as I change body position. Winds were constant that day.

My glide improved by 0.2 in two jumps based on seeing the glide on-screen and then asking for advice about how to improve that.

Okay, I am stupidly tired right now, but for anyone who wants to try converting their data, the following may be useful. ZIP file: https://github.com/evilwombat/flight-converter/archive/master.zip Github: https://github.com/evilwombat/flight-converter That should convert the Recon DAYxxxx.RIB files into GPX files that you can load into Google Earth and see your flight. Just uncheck "Adjust altitude to ground level" when importing, or it won't be very exciting. Don't forget to install java. I'll write better documentation later ;). Also, I'll try to get drag-and-drop conversion for Mac working later (I don't actually own one). But if you're handy with Terminal, you should be able to do something like java -jar FlightConverter.jar DAYxx.RIB (Just copy the file off the HUD first). Windows users can drag-and-drop files onto Convert_Win and it should "do the right thing". Linux users - just launch the JAR file with RIB files as arguments. Maybe I'll turn this into a new thread later, but sleep is really getting the best of me right now. Steve

I've got a GPX converter written and am told it outputs valid-looking results (it has been cloudy so I don't have my own data to convert yet). The converter is a straightforward C program and maybe I can put it into github soon, if I can ever get off work tonight ;) Windows and Linux users should be fine, but.... How hard is it to compile from source on a Mac, if there are no dependencies and if POSIX C APIs are used? I might just quickly rewrite this thing in Java just for that whole cross-platform aspect, to keep things simple for everyone. Thoughts? Edit: Yeah, I think I'll try to do a quick Java port, even though it is the only language I know of where 'byte' is a signed data type by default Edit more: Re-wrote the whole thing in Java today. It seems to work on my Windows VM, and on Linux. I tried to write a Mac OS launch file, which should work in theory, but I don't have a Mac to test it on. This needs a bit more testing, and I should be able to post it soon. Current output format is GPX but others should be doable as well.

Ah, scratch parts of that. Looks like I am off on parts of the format. Each file looks like it can store multiple "runs" and I think I've got the flags better figured out this time. I will know more once I can actually put some jumps on the thing to check my decoded data, but the new test data I do have looks more sane. If someone wants to send me a DAYxx.RIB file to try and decode, I'll see what I can do ;) Note that this file contains your location.

If I ever get some free time, maybe I will write a converter that does not rely on the lousy engage website to extract the data. Yes, it has some nice features, but the whole browser plug-in thing is less than stable, even when you use a supported OS. I still can't wait to jump the thing - where is the "make it sunny" button?

Have you noticed anything about the impact on the vertical angle of view? Can you still see your handles well?

Ah, cool- someone wrote a decoder. But it seems to be online-only, with no source or spec. Regardless, the .RIB files seem to follow a repetitive pattern of 20 bytes. Looking at my unit and with the help of the online converter, the data encoding seems to be as follows (big-endian): 4 bytes - latitude 4 bytes - longitude 2 bytes - speed, in increments of 0.1km/h 2 bytes - altitude 5 bytes - ??? 3 bytes - time (one byte for hours, minutes, and seconds). Latitude and longitude are encoded in a somewhat funky format. The first byte is the whole number of decimal degrees. The second byte is the whole number of minutes, with (I am guessing) bit 7 actually being used as a sign bit for the overall number. The third byte is in decimal minutes in increments of 0.01. The fourth byte is in decimal minutes in increments of 0.0001. So basically, convert all four bytes to decimal, clear bit 7 of byte 2 as needed, and "put them next to each other" and you should have a coordinate in the form of DD MM.MMMM. One data point seems to be recorded every second. In addition to this, there seems to be a general data header. I haven't decoded this, but at least 2 bytes of it seem to be the current month and day. Oh well. Keep in mind this is based on a single data point. I am sleepy. One more thing- the goggles seem to not interfere with my helmet (bonehead, open-face) but just barely. I hope the field of view is not too much of an issue. I like to pull off my goggles after opening, but this looks like it may be more difficult. One unfortunate consequence of having all that padded material at the bottom of your field of view is that HANDLES are harder to see now. Guess I'll just have to pull high and deal with it if I have to.

Yeah, the fedex guy surprised me this morning :) Let's see... basically, this is going to be interesting and I can't wait to jump this thing. From a day of playing with it, some observations: - The thing likes to eat battery quite a bit, though with disciplined use only during flight, I could easily see this lasting for a day or two of jumping. - I did not see any issues with GPS lock times - The lens is on a pivot arm and it helps to adjust it for optimal viewing - Altitude can be adjusted in increments of 3 feet by pressing left/right - The display is a color LCD screen (not just a simple 7-segment screen as someone asked about above) - When you reach a maximum speed, the display pops up a window with your new personal best. This is nifty, but it covers up the altitude indicator, but as the manufacturer plainly says, you should not be using this as an altimeter anyway - The display shows speed, altitude, and glide ratio. The glide ratio indicator seems to change colors depending on how well/poorly you are flying. There also seems to be a vertical line indicator for speed - The goggles tend to limit the vertical field of view a bit, but I have not had a chance to jump yet so I don't know what the impact would be When connected to a computer, the device shows up as a USB storage device. Data is stored in various files in a funky binary format. The manufacturer’s website has a browser plugin that will interface with the USB storage device and overlay your data on a map. With a little bit of work it should be possible to decode the data format so that all the linux geeks out there don't feel left out. Perhaps when I get some time... See attached photos. Due to the fancy optics, it is very difficult to get a good photo of the display using a regular camera, but I tried as best I could. In reality it does look better than what is pictured here. Final thoughts: this thing seems pretty sweet. I can't wait to jump with it.

I would absolutely recommend the IHOP. Think of it as a regular house (with kitchen, shower, bathroom, etc) only with a stack of beds in each bedroom. $15/night sounds about right, and it is located at the opposite side of the DZ parking lot, so you can just walk to the DZ (and stumble home afterwards). It can get quiet or busy depending on how many people are staying there. I've only been there with two or three other people, so your mileage may vary.

I've heard the advice about batting gloves as well. Personally I am a fan of these: http://www.sportchalet.com/product/shop+by+sport/baseball+-+softball/batting+gloves/301602_3011245.do?sortby=newArrivals&page=2 I like these because they are relatively thin and do a decent job of keeping the cold out. Your mileage / personal preference may vary.

I wonder if they will allow software modification, for those proficient with ARM systems. This really has potential as a general-purpose platform.

Congratulations! Welcome to a new world. This might just turn out to be one of those things where you make one jump... then you make another... and then it just kind of consumes your life. That's what happened to me, and hey, I'm not complaining. See you out there!

Canopy courses definitely do exist. There is more to flying than the basics taught in AFF, and it is great that you are trying to seek out further instruction. Ask around your DZ and they can point you in the right direction. Flight-1 has a schedule of courses online where you can check what is in your area, but they are not the only ones teaching them. Definitely try to sign up for a canopy course if you can find one in your area. You will likely learn more about canopy flying than was probably presented in your initial training, and the information becomes more easy to digest now that you've done a handful of jumps. Expect the course to cover things like proper flaring, flat turns, braked turns, etc. These techniques will put you in a better position for making it through a less-than-ideal landing situation, should you ever find yourself there.

Analog vs digital is not the issue. The real issue is reliability, and in a broader sense, suitability for a specific purpose. Your concerns about update rate (and likely, latency) are legitimate. My advice: use the right tool for the job.

Even completely sincere and honest AAD analysis may not always reach accurate conclusions with certainty, and the manufacturers are probably well aware of this. For instance, a plausible failure mode would be the AAD pressure sensor reporting an incorrect altitude value, in which case the AAD might both record and fire at what it believes to be the correct altitude, regardless of the actual altitude at the time. The failure might be transient, and not reproducible in a chamber after the fact. How might one even conclusively detect such a failure (without an independent secondary sensor or some other recording mechanism), or be certain it did not occur?