platypii

I did actually start with httrack, but I'm not an expert with it, and switched to wget. So you are right in that sense. But I stand by my statement -- I don't think it's possible to do a good job here by taking snapshots. Basejumper.com was a dynamic site, and it would have been very difficult to get a static snapshot of it. Would you want httrack to have a copy of every permutation of "sort by date (ascending|descending), on page number (X), with (20|50|100) hits per page? It also had a "threaded" view that basically no one used, but makes for a whole new set of problems. All those links would be available to users in the mirror, so you either capture all of them, or there will be broken links. Also the site does some weird stuff: if you're logged in, it tries to take you to the last page of a thread, but once you've viewed it will take you to the first page. If you don't want "NEW" to show up everywhere you need to handle the site's logic on viewed threads carefully. The ads would have been snapshotted too, but likely would break after some time. Oh and don't forget to to block the "add friend" links or else you'll spam everyone on the site. Sorry anyone who got a friend request from throwaway6667 Those are just some of the issues I ran into before I changed my strategy.

I started down the path of using a scraper like httrack, but I don't think it's possible to do a good job with it in this case. The problem is that the site had url parameters like "page", "max hits" and "sort". And the button for "add friend" was an http GET endpoint. So crawling links on the page will result in weird behavior, a huge number of downloads, and still probably won't get everything. The resulting archive would be massive. I think it was actually easier to write a structured parser specifically for bj.com.

I fixed some of the character encoding bugs people were seeing. That should take care of the "â€" bugs. I also fixed the inline image width with a css tweak. @dmcoco84 thanks for the heads up! Also thanks to those who have donated. For those curious, it was not as simple as using a web scraper. Because of the way that basejumper.com was structured, there were "duplicate" pages based on sorting, pagination, etc. Also I wanted to make sure I got the incidents section which required being logged in. So I wrote a structured scraper that parsed each page of the forums, threads, and individual posts. Raw data was written to json files. Attachments were also downloaded. The classic bj emojis obviously needed to be preserved too Then I made a quick webapp to render the json data and as html. I exported those rendered html files to amazon S3, fronted by cloudfront. There was some hacking to get the content-type to be correct on S3. Here are downloadable archives of the rendered html, and the structured json data. @Colm @sfzombie13 https://basejumper.net/bj-html-v1.zip (820mb) https://basejumper.net/bj-json-v1.zip (50mb)

Approximately 1gb zipped, including all attachments. I would be happy to share copies with people so that there are backups. In case my basejumper.net mirror ever goes in.

People say "the internet never forgets", but that is bullshit. Archival takes a lot of hard work. Thank your local data hoarder. https://basejumper.net/ This was the main documented history of base jumping from 2002-2021. Incident reports, ideas from jumpers who are gone. I felt it was important to preserve everything, including the attachments, etc. If you see bugs let me know, I might be able to fix them. Hosting provided by BASEline. If you feel like donating, there is a paypal link on https://baseline.ws You're welcome, assholes :-) Kenny / BASEline

The key to the biggest flares is 1) building up a lot of total speed, and 2) efficiently converting that into a flare. This is an example of a huge flare with 314ft of altitude gain: I think it's most useful to look at the speed polar: What this shows is (1) building up a huge amount of speed by diving aggressively. (2) continuing to dive but increasing the horizontal component of velocity. (3) as smoothly as possible exchange airspeed for lift. (3) begin going up. (4) maximum upward velocity 45 mph. (5) top of the flare, when vertical velocity hits zero. If you flare too hard, or if you break it up into "phases" between 2/3/4, you will lose more energy and not gain as much altitude. Also if you flare too gradually, you will bleed off speed due to drag and not gain as much altitude. It's a balance. Interestingly on this track, (2) has more total speed than (1). I actually think it should be more efficient to not go quite as vertical as that jump, and short cut the transition from 1 to 2. The main thing is to maximize total speed before the flare, but if you can do the same total speed at 1:1 glide as when vertical, then you're in a better position to start the flare.

Or maybe you don't understand standard deviations. If a sky canopy opens in 500ft +/- 500ft, but a BASE canopy opens in 200ft +/- 100ft even at terminal... then no, there is virtually no difference in risk pulling at 2000ft or 500ft with a BASE rig. You might have a little more time to fix a malfunction, but the difference in risk is pretty minor in my opinion.

Applied Wingsuit Equations: Reconstructed roll angle from GPS data, overlayed on terrain. @yuri_base

When I said "satellites are mostly near the horizon" I meant that statistically at any given time, you are more likely to have satellites off to the side, than overhead. And If you're trying to use triangulation to measure height and vertical speed... that's going to be less accurate without satellites overhead. Geometrically it's a fact that they are more likely to be near the horizon than overhead. Here's why. If you draw a line extending out 45 degrees above the horizon, then the area of sky "above" you is much smaller than the area to the sides. I get a ratio of more than 2:1 "near the horizon" vs "above" at GPS altitudes. Picture is drawn to scale. I will say though, I expected a bigger ratio. But because GPS orbits are actually quite high, this is less of a factor than if they were in lower orbit.

GPS units generally have a physics model of what is "realistic" speeds and accelerations. These are used in kalman filters to clean up noisy GPS data. It probably thinks that falling at 120mph is not realistic. Also the satellites are mostly near the horizon, so GPS is inherently less accurate on altitude than position. And finally -- check where it's mounted on your body. If its chest-mounted, you're going to be blocking its view of most of sky. Do you backfly? Cool project!

He's wearing a BASE rig, so no, he doesn't need emergency handles :-)

The 3-ring wikipedia article is surprisingly detailed, with a nice animation of the mechanism: https://en.wikipedia.org/wiki/3-ring_release_system

Just released a new version of BASEline tonight that will scale text with the android system font size. Thanks for the feedback. Keep us posted on your project!

I've done this using Google Glass and it works well. I'm the developer of BASEline Flight Computer, so it was fairly easy to port the Android app to Google Glass. You can find used Glass on ebay for around $400. As you mentioned, the advantage of a HUD is that you can see horizontal speed, vertical speed, total speed, and glide ratio all at once, and with much faster update than you could ever get with audio. I personally chose to display your speed as a "polar chart". Horizontal and vertical speeds on the axes, total speed equals the hypotenuse, and glide is shown by the slope: To get good data, pair the phone with a bluetooth GPS like the XGPS160. Let me know if I can help with anything. I would love for this to exist! But I don't expect most people to deal with google glass. If interested, the google glass version of BASEline is available on a github branch: https://github.com/platypii/BASElineFlightComputer/tree/glass

Computing velocity from noisy position data can introduce a fair amount of error. Here is an example. Your true velocity might be constant and actually look like: But GPS will have errors that might make the position look like any of the black dots here, and you can see how much error that can introduce to the velocity if computed using distance / time: It's possible to smooth this out by adding a Kalman Filter. But a filter will introduce its own errors and create a lag time before it accurately estimates your true velocity. However, as pointed out by @crwper, GPS actually has the ability to compute position directly, not using position and distance. Instead, many GPS chips can actually use doppler shift from the satellites to directly compute velocity. The accuracy and response time is much better. It is not clear whether the GoPro uses doppler velocity to compute 2D and 3D speed, but its definitely NOT giving the individual velocity components (vN, vE, vD) which would be nice to have.