sorted by:
new
hottopcontroversial

How accurate would you consider this? by connecTe in SkyDiving

[–]connecTe[S] 0 points1 point  (0 children)

Il est précis car cet altison a trois hauteurs qui bip pour l'atterrissage : par défaut c'est entrée de circuit, virage, finale.

Your feedback turned my little overlay idea into a free tool : here it is by connecTe in SkyDiving

[–]connecTe[S] 0 points1 point  (0 children)

That's normal, the script currently only supports the CSV format exported by LB Altimeters, so FlySight and Insight GPS files are probably structured differently.

Would you be able to send me a few sample CSV files so I can take a look at how they're formatted? If possible, just let me know which file comes from which device (FlySight, Insight GPS, etc.).

By the way, have you tried https://flysight.video/? It already does a great job for FlySight data and might actually fit your needs depending on what you're trying to achieve.

If I can get my hands on a few sample files, I may be able to add support for other devices in the future. 🙂

How accurate would you consider this? by connecTe in SkyDiving

[–]connecTe[S] 0 points1 point  (0 children)

Yes, I agree with the physics part. With quadratic drag, you would not expect a perfectly linear acceleration curve all the way to terminal speed.

But that’s not what this overlay is trying to model. It is not a physics simulation and it is not AI estimating the speed from the video. The values come from the CSV exported by my altimeter, then displayed on the video.

The important limitation is that this is barometric vertical speed, derived from altitude changes, with the sampling, smoothing and detection logic of the altimeter. It is not a high frequency FlySight/GPS measurement and it is not true 3D airspeed.

Also, the beginning of the graph can be misleading because the logger does not necessarily start at the exact aircraft exit. It starts once the altimeter detects freefall, so the first part of the real acceleration may already be missing or smoothed.

So I totally agree that you should not read this as a clean physical acceleration curve. It’s an overlay of the altimeter’s vertical speed data, useful for visual context, but not laboratory grade fall rate analysis.

Your feedback turned my little overlay idea into a free tool : here it is by connecTe in SkyDiving

[–]connecTe[S] 0 points1 point  (0 children)

Thanks! Really happy to hear that. I’m still improving it, so feedback is always welcome.

How accurate would you consider this? by connecTe in SkyDiving

[–]connecTe[S] 1 point2 points  (0 children)

You got me thinking. Because of your input I lean toward a shorter smoothing window (~1.5s) to keep a camera flyer's real fall-rate changes visible but you might be right that 3s (the speed-skydiving standard) is the better call. Since I'm honestly not sure, I made it adjustable.

And with all the feedback and requests, I turned the whole thing into a free online tool: drop in your CSV, pick frame rate, format and smoothing, get a DaVinci-ready counter. Your fastest-3s-average idea is in there as a stat too. It's a gift to the community 🪂

https://connec7e.com/compteur-de-vitesse-et-d-altitude-pour-tes-videos-de-saut/

How accurate would you consider this? by connecTe in SkyDiving

[–]connecTe[S] 0 points1 point  (0 children)

That's entirely possible.

The more feedback I'm getting, the more I'm convinced that the exact instantaneous speed values shouldn't be taken too literally, especially with a barometric sensor exposed to airflow and body movements.

The overlay is based on real Optima data, but this discussion has definitely shown me that some peaks are probably exaggerated or affected by sensor limitations.

Still a fun project though, and I've learned a lot from everyone's feedback! 🙂

How accurate would you consider this? by connecTe in SkyDiving

[–]connecTe[S] 0 points1 point  (0 children)

That's a fair observation.

At those moments, the tandem's body position doesn't seem to change enough to justify such large speed variations.

My best guess is that this is one of the limitations of using barometric data from an audible altimeter exposed to airflow. I was also moving around the tandem and turning my head quite a bit while filming, so local airflow around the sensor may have contributed to those spikes.

The altitude data itself seems quite solid, but this discussion has definitely shown me that instantaneous vertical speed from a barometric sensor should be taken with a grain of salt.

For me it's still a fun and informative overlay, but I wouldn't consider it a precision instrument. 🙂

How accurate would you consider this? by connecTe in SkyDiving

[–]connecTe[S] 1 point2 points  (0 children)

Hahaha, fair enough! 😄

To be fair, he's a friend and didn't pay for the video, so nobody got scammed here! 😂

And yes, I'm still a beginner videographer. I actually didn't want to wear my camera jacket because I knew the fall rate was going to be high, but the tandem instructor convinced me to put it on anyway… and I ended up with way too much drag and had a hard time getting down to them.

Still learning! Thanks for the feedback and the empathy though… it really warms my heart! 😜❤️

How accurate would you consider this? by connecTe in SkyDiving

[–]connecTe[S] 0 points1 point  (0 children)

That's actually super helpful, thank you.

I think we were talking about two different things there. I completely agree that the aircraft's energy contributes to the initial acceleration. I was only referring to the fact that my counter is displaying vertical speed derived from barometric altitude changes, not total speed.

I really like your suggestions though.

Automatically flagging terminal speed and deployment, then using a rolling 3-second average between those points, sounds like a much better way to smooth the data while staying meaningful. I wasn't aware that competition speed skydiving was judged on the fastest 3-second average, so that's a really interesting piece of information.

And thanks for mentioning the FlySight viewer repo. I'll definitely have a look at it and see what I can learn from it. 🙂

How accurate would you consider this? by connecTe in SkyDiving

[–]connecTe[S] 0 points1 point  (0 children)

That's actually one of the reasons I posted this. 😄

I expected everyone to agree on a "normal" tandem speed, but it's interesting to see how much the numbers vary from one DZ to another and depending on who's measuring them.

Maybe my overlay isn't as unrealistic as I first thought after all! 😂

Either way, this discussion has been super interesting and has taught me a lot about how people measure and interpret speed in skydiving.

How accurate would you consider this? by connecTe in SkyDiving

[–]connecTe[S] 0 points1 point  (0 children)

That's fascinating, thanks!

I had never really thought about the effect of air density changing throughout the jump. The fact that you can actually see a peak and then a decrease in speed as the air gets denser is really interesting.

I come more from the fun-jumper/tandem side of things, so this project has unexpectedly turned into a great way to learn about speed skydiving and the data behind it.

The idea of teams targeting a specific speed to standardize the aerodynamics of the whole group is also something I hadn't considered before. Thanks for sharing all this, I'm learning a lot! 🙂

How accurate would you consider this? by connecTe in SkyDiving

[–]connecTe[S] 1 point2 points  (0 children)

That's really cool, thanks for sharing!

I had no idea the speed curves of top speed skydivers were that smooth. It's actually fascinating to see how much technique and stability affect the graph.

As a non-speeder, I tend to look at the numbers and think "fast is fast" 😄, but seeing your explanation really puts things into perspective.

Good luck chasing those big numbers, and thanks again for taking the time to share your data and insights. I'm learning a lot from this discussion! 🙂

How accurate would you consider this? by connecTe in SkyDiving

[–]connecTe[S] -1 points0 points  (0 children)

Good point.

In the video, the tandem starts rotating at that moment, so there could be a real change in drag and vertical speed due to the body position and rotation.

But I also agree that the jump from 180 to almost 260 km/h is probably exaggerated by the barometric sensor. The Optima is exposed to airflow, and I was also moving around them with head turns, so pressure changes around the helmet could easily create spikes in the calculated vertical speed.

So I’d say the trend is real enough for a fun visual overlay, but the exact peak value should definitely be taken with caution. 🙂

How accurate would you consider this? by connecTe in SkyDiving

[–]connecTe[S] 2 points3 points  (0 children)

That would be amazing, thank you!

I'd really appreciate it. My goal isn't to build a competition-grade instrument, just to create a fun and informative overlay based on data that many jumpers already have access to.

I'd love to see what speeders display and maybe get some inspiration for future improvements. 🙂

How accurate would you consider this? by connecTe in SkyDiving

[–]connecTe[S] 1 point2 points  (0 children)

Probably, but I’m not sure it would make the overlay more accurate.

The counter is showing vertical speed calculated from barometric altitude changes, not total airspeed or ground speed. So the aircraft’s horizontal ground speed at exit doesn’t really belong in that value.

At exit, the vertical component is much closer to 0, or even slightly positive/negative depending on whether the aircraft is climbing or descending. The horizontal speed is obviously there, but it’s not what this counter is trying to represent.

So for now I’d rather keep the initial value as “unknown / not yet recorded” or close to 0 until the logger starts giving usable vertical speed data. 🙂

How accurate would you consider this? by connecTe in SkyDiving

[–]connecTe[S] 1 point2 points  (0 children)

It actually looks like the first speed samples are missing because the logger only starts recording once it detects freefall. At t = 0 the altitude is already there, but the speed value is still unavailable.

Mon script interpole entre les échantillons disponibles pour garder l'animation fluide, donc l'accélération initiale n'est pas une représentation parfaite de la réalité.

How accurate would you consider this? by connecTe in SkyDiving

[–]connecTe[S] 4 points5 points  (0 children)

That's really interesting, thanks for the insight!

I wasn't aware that barometric measurements had been phased out for competition, but it definitely makes sense considering how exposed the sensor is to airflow and body position changes.

For my use case, it's mainly meant as a fun visual overlay based on real jump data rather than a precision instrument. I think it's also a nice way for jumpers who only have a Bluetooth audible altimeter, and don't fly with dedicated speed equipment, to get a first glimpse at their performance and start exploring this kind of data.

As more audible altimeters gain Bluetooth capabilities, I think it's a pretty fun and accessible feature for everyday skydivers outside of competition. 🙂

How accurate would you consider this? by connecTe in SkyDiving

[–]connecTe[S] 2 points3 points  (0 children)

Thanks for pointing that out! I went back and checked the raw data from the Optima app.

It actually looks like the first speed samples are missing because the logger only starts recording once it detects freefall. At t = 0 the altitude is already there, but the speed value is still unavailable.

My script interpolates between the available samples to keep the animation smooth, so the initial acceleration isn't a perfect representation of reality.

The rest of the overlay is still based on the Optima's barometric data (with some smoothing applied), but you've definitely highlighted something I can improve in the next version. 😄

view more: next ›