GPS DriftCast (GPS Drift 2.0) Vastly improved landing location prediction based on winds aloft forecasts

[Buckeye]

Here is a flight result. I ran DriftCast in the morning before the launch. I used simulations from OpenRocket. Standard atmosphere model for temperature and pressure conditions. I noticed right off the bat that the upwind distances and altitude loss from winds seemed ridiculously low as predicted by OR. Nonetheless, I put the results in the Weathercock table and ran the forecast. The predicted landings were in a good direction for recovery, so launch was a GO!



Actual flight was about 1:20 pm and temps were about 80 deg F. Here is the flight data from the Featherweight GPS:

Apogee = 13,378 feet AGL
Mean drogue vertical descent rate = 61 ft/s
Mean main vertical descent rate = 20 ft/s

So, the inputs to DriftCast were reasonable. Here is the ground shadow of the 1:00 pm prediction (yellow curve), and the actual flight (black curve). The agreement of the drift portion is very good, in both magnitude and direction. The forecast and drift calculations are working well!

What is not good is the upwind magnitude prediction. The difference between predicted and actual landing (about 1200 feet) can be pretty much attributed to the weathercock discrepancy. I am going to re-sim this flight in Rocksim and RASAero and see if there is stronger weathercocking predicted.

 

[ecargmij]

Oh man looks like it almost took a bath

 

[Buckeye]

Oh man looks like it almost took a bath

No fear. Trust the wind prediction!

Edit: Oh, if you mean the ditch along the road, then yes, it was almost wet

 

[DaHabes]

Downloaded the spreadsheet. Got it to run once successfully. Now I get an error on a second run:

Runtime error "13"
Type mismatch

From Debug > initAlt = GetAltitudeArray(stringResponses(k), model(k))

???

 

[dvdsnyd]

Downloaded the spreadsheet. Got it to run once successfully. Now I get an error on a second run:

Runtime error "13"
Type mismatch

From Debug > initAlt = GetAltitudeArray(stringResponses(k), model(k))

???

Did you change anything in any of the inputs between the first and second run?
If you shoot me a conversation with a few more screenshots, I'm sure we can work through it.
Thanks,
Dave

 

[Rocketclar]

We had a two day launch this past weekend. Weather was beautiful with very low winds. Our waiver is to 6,000’ AGL due to location near airports and power lines. My DriftCast calcs showed that my rockets should land very close to the pads…and many of the days’ launches did just that. Further, we had several 3-4K flights that landed 50’ or so from the pads…one even came in and draped part of the shock cord over a pad! Most excellent conditions!

I use Eggfinder GPS in some of my rockets (along with a handheld Garmin to project a course/waypoint when the rocket has landed.) So I recorded the landings of a couple of my rockets that I had run DriftCast on. Mine landed further from projected.

Prometheus (I-540): Ave of Egg Quantum and Quark was 2572’ vs. RockSim est of 2569’.

DriftCast predicted: 40.171885,-85.317411

Landed at: 40.16754, -85.31781



GL Scratch (J-315): Ave of Egg Quantum and MW RR2CL was 2938’ vs. RockSim est of 3150’.

DriftCast predicted: 40.170281,-85.315982

Landed at: 40.17199, -85.31026



So yes, there’s a difference between predicted and actual especially for my Scratch rocket. Looking at my actual descent data, I use too big of drogues. I wanted to go back and tweak the model using better data for the descents….but found out it only went back 12 hrs. NP, had a family commitment last night so I couldn’t get back to it until now. There are of course other sources of variability in all this. One, is the exact upright position of our rails….kind of eye balled them straight up….plus ours have some wobble. I could do a better job on this with a level and more stabilization next time. Any slight ‘sticking’ on a dirty rail could cause a problem too. Many of the launches this past weekend did come in very close to our pads as DriftCast predicted mine should have. So it’s encouraging!

There’s a couple of old saying on models…..all models are wrong, but some are useful. And, garbage inàgarbage out….so I need to put in the best data and conditions I can.



BTW…I’ve shared TRF link to your post on DriftCast along with some output from it to our club. (I had sent and taken printouts for show and tell.) There were several folks that were very interested in it.

I’m wondering if a Monte Carlo approach by introducing more variability into certain inputs would help give an estimated area of landing vs just a point. I’ll ruminate on this.

Thanks for working on this! I’ll continue to test!

 

[dvdsnyd]

We had a two day launch this past weekend. Weather was beautiful with very low winds. Our waiver is to 6,000’ AGL due to location near airports and power lines. My DriftCast calcs showed that my rockets should land very close to the pads…and many of the days’ launches did just that. Further, we had several 3-4K flights that landed 50’ or so from the pads…one even came in and draped part of the shock cord over a pad! Most excellent conditions!
....

Thanks for posting!!

I plotted your results and yea, they are a bit off.
What was your launch site lat/lon?
Were you using the upwind/Weathercock table, or simming vertical flights?
There are a ton of different variables in this whole thing.
Buckeye mentioned that same thing with going back only 12 hours. I updated it to 24 hours. Attached the sheet.
From the looks of it this is as far back as it can go right now.
I'm also trying to come up with a way to save the forecast for later analysis.
I'll ruminate on how to implement it... Thank you for the vocabulary lesson.

Dave

 

[dvdsnyd]

Here is a flight result. I ran DriftCast in the morning before the launch. I used simulations from OpenRocket. Standard atmosphere model for temperature and pressure conditions. I noticed right off the bat that the upwind distances and altitude loss from winds seemed ridiculously low as predicted by OR. Nonetheless, I put the results in the Weathercock table and ran the forecast. The predicted landings were in a good direction for recovery, so launch was a GO!
...

Awesome! Thanks for sharing Buckeye!
Will need to figure out something more with the upwind ascent portion.

 

[Rocketclar]

Our launch site is 40.170794 N, -85.317050 W.
I did both, with and wo weathercocking. Since the winds were all so low for those days, both were very similar. I did run RockSim though at the various wind speeds you suggested. Normally I use the Slightly Breezy input that varies from 8-14 mph.

 

[dvdsnyd]

You know what they say...be careful about random people's code on the internet...
Thanks to @Buckeye for finding a big bug in the logic. The way I had it up until now, the main deployment descent was never going to be used in a dual deploy scenario.
Should be fixed here.
Thanks,
Dave

 

[DaHabes]

I'm curious what versions of Windows and Excel people are running this on. The Get Directory and Get Location functions work, but the Run (main) macro craps out and has crapped out with two different errors with no apparent changes between the individual executions. Trying to understand where the failure point is. I'm running Windows 11 and Microsoft 365.

 

[Buckeye]

We had a two day launch this past weekend. Weather was beautiful with very low winds. Our waiver is to 6,000’ AGL due to location near airports and power lines. My DriftCast calcs showed that my rockets should land very close to the pads…and many of the days’ launches did just that. Further, we had several 3-4K flights that landed 50’ or so from the pads…one even came in and draped part of the shock cord over a pad! Most excellent conditions!

I use Eggfinder GPS in some of my rockets (along with a handheld Garmin to project a course/waypoint when the rocket has landed.) So I recorded the landings of a couple of my rockets that I had run DriftCast on. Mine landed further from projected.

Prometheus (I-540): Ave of Egg Quantum and Quark was 2572’ vs. RockSim est of 2569’.

DriftCast predicted: 40.171885,-85.317411

Landed at: 40.16754, -85.31781



GL Scratch (J-315): Ave of Egg Quantum and MW RR2CL was 2938’ vs. RockSim est of 3150’.

DriftCast predicted: 40.170281,-85.315982

Landed at: 40.17199, -85.31026



So yes, there’s a difference between predicted and actual especially for my Scratch rocket. Looking at my actual descent data, I use too big of drogues. I wanted to go back and tweak the model using better data for the descents….but found out it only went back 12 hrs. NP, had a family commitment last night so I couldn’t get back to it until now. There are of course other sources of variability in all this. One, is the exact upright position of our rails….kind of eye balled them straight up….plus ours have some wobble. I could do a better job on this with a level and more stabilization next time. Any slight ‘sticking’ on a dirty rail could cause a problem too. Many of the launches this past weekend did come in very close to our pads as DriftCast predicted mine should have. So it’s encouraging!

There’s a couple of old saying on models…..all models are wrong, but some are useful. And, garbage inàgarbage out….so I need to put in the best data and conditions I can.



BTW…I’ve shared TRF link to your post on DriftCast along with some output from it to our club. (I had sent and taken printouts for show and tell.) There were several folks that were very interested in it.

I’m wondering if a Monte Carlo approach by introducing more variability into certain inputs would help give an estimated area of landing vs just a point. I’ll ruminate on this.

Thanks for working on this! I’ll continue to test!

Does your EggFinder have a log file such that you can plot the entire flight in Google Earth, rather than just the final landing point? That would be useful in comparing the forecast to the actual flight, like my post #31.

 

[Buckeye]

Awesome! Thanks for sharing Buckeye!
Will need to figure out something more with the upwind ascent portion.

Not sure what more can be done in DriftCast. It is really up to the flight simulator to predict good values for the weathercock table.

I really don't know how weathercocking increases/decreases as the rocket gains altitude and encounters wind changes. I guess one would have to play around in Rocksim Pro or Rocksim Visualizer to see that. Or, try to use the wind table plug-in for OR, which I think is now DOA in the latest version of OR.

In my flight, I didn't check if the winds aloft were predicted to be more than 20mph, which was the maximum input to the weathercock table. If they were, that may explain some of the discrepancy. It might be good if the output table reported the max wind speed encountered in addition to the surface speed. Then, the user could fine tune the wind values in the weathercock table.

 

[Rocketclar]

Does your EggFinder have a log file such that you can plot the entire flight in Google Earth, rather than just the final landing point? That would be useful in comparing the forecast to the actual flight, like my post #31.

Yes, I have the data logger module with micro SD card. It doesn't have the DriftCast data shown on it for this launch last Sat. I didn't save a screen shot of the DriftCast landings, only the data from the Excel sheet. I will overlay later.

 

[Rocketclar]

Does your EggFinder have a log file such that you can plot the entire flight in Google Earth, rather than just the final landing point? That would be useful in comparing the forecast to the actual flight, like my post #31.

Here's the plot of the ground trace via EggFinder data logger and the predicted landing.

 

[Rocketclar]

Not sure what more can be done in DriftCast. It is really up to the flight simulator to predict good values for the weathercock table.

I really don't know how weathercocking increases/decreases as the rocket gains altitude and encounters wind changes. I guess one would have to play around in Rocksim Pro or Rocksim Visualizer to see that. Or, try to use the wind table plug-in for OR, which I think is now DOA in the latest version of OR.

In my flight, I didn't check if the winds aloft were predicted to be more than 20mph, which was the maximum input to the weathercock table. If they were, that may explain some of the discrepancy. It might be good if the output table reported the max wind speed encountered in addition to the surface speed. Then, the user could fine tune the wind values in the weathercock table.

Usually I run the NOAA model for winds aloft up to our waiver level a day or so before our club launch. This time I didn't do it either. Several of us noticed that there appeared to be quite a bit of thermal actions with rockets hanging for awhile and then dropping quickly on their chutes. Surface winds were pretty calm but temps unusually warm for IN this time of year probably resulting in stronger thermals.

 

[Buckeye]

Here's the plot of the ground trace via EggFinder data logger and the predicted landing.

Are my annotations correct? If so, there was a lot of weathercocking relative to the amount of drift.

 

[Rocketclar]

Are my annotations correct? If so, there was a lot of weathercocking relative to the amount of drift.

View attachment 646318

Land pad location is correct. Disagree about apogee.
Well, we did have very calm surface conditions. The Prometheus 3 (Composite Warehouse) does have a lot of fin area. I did use a high initial impulse motor (CTI I540) that simmed at leaving the rail at 51.1 mph. RockSim estimated an apogee of 2569’. My Quantum, with telemetry, reported 2561’and the backup Quark reported 2582’. The rocket didn’t appear to weathercock. Severe weathercocking would have lowered the apogee quite a bit. (I have seen the rocket weathercock before in windier conditions on a J270 with quite a loss of altitude vs the sim.) I know that you loose gps lock on the up part so my Egg data log plots for the up always look odd. Looking at the elevation plot it appears that the apogee is just over the NE end of the parking lot by the pavilion (where the arrow is.) It’s going down from there. The raw data file is attached. I had to rename it as a txt file since it wouldn't upload with the nmea extension.

 

[dvdsnyd]

Not sure what more can be done in DriftCast. It is really up to the flight simulator to predict good values for the weathercock table.

I really don't know how weathercocking increases/decreases as the rocket gains altitude and encounters wind changes. I guess one would have to play around in Rocksim Pro or Rocksim Visualizer to see that. Or, try to use the wind table plug-in for OR, which I think is now DOA in the latest version of OR.

In my flight, I didn't check if the winds aloft were predicted to be more than 20mph, which was the maximum input to the weathercock table. If they were, that may explain some of the discrepancy. It might be good if the output table reported the max wind speed encountered in addition to the surface speed. Then, the user could fine tune the wind values in the weathercock table.

I would imagine that the rocket will continue to tilt as long as there is wind to push against it. My guess is the winds aloft are quite a bit higher. I can output a table of the wind data to the debug area.

The simplistic assumption in DriftCast is that the majority of the weathercocking happens right at the surface and is mostly influenced by the surface level winds. Maybe it could be refined some based on some moment of inertia, CP/CG relationship information...again though, this gets into the realm of a much more involved simulation vs basic calculation.

 

[Buckeye]

@Rocketclar Yeah, that nmea log from Eggfinder looks like garbage. NMEA streams from my BRB900 are really good for plotting. Not sure why the Egg is so bad.

I did some editing of your file to find the "flight." This is the altitude vs. time. Max altitude is only 150m above the ground which does not agree with your Rocksim or altimeter reports.



Here is a side view of the flight trajectory. Did your flight look like this? I doubt it.

 

[Rocketclar]

Thanks guys for looking at my data! I've never been happy with my EggFinder's data log results. Basically the starting points are ok (parking lot, check in, pad), then landing spot. Ground traces seem reasonable. Profile/altitude are usually flaky looking. I'll continue to test DriftCast and will use as good of inputs that I can (better estimates of descent rates, run as close to actual for best winds aloft data, etc.)
Thanks again!

 

[kjhambrick]

Here is a flight result. I ran DriftCast in the morning before the launch. I used simulations from OpenRocket. Standard atmosphere model for temperature and pressure conditions. I noticed right off the bat that the upwind distances and altitude loss from winds seemed ridiculously low as predicted by OR. Nonetheless, I put the results in the Weathercock table and ran the forecast. The predicted landings were in a good direction for recovery, so launch was a GO!

@Buckeye --

How do you set up OR for your weathercocking and downwind drift info ?

I've been messing with the groundtrack plots but maybe there is a better way ?

Thanks !

-- kjh

EDIT: p.s. I also meant to ask if the Raven 3 calculates tilt and roll ?

 

[Buckeye]

@Buckeye --

How do you set up OR for your weathercocking and downwind drift info ?

I've been messing with the groundtrack plots but maybe there is a better way ?

Thanks !

-- kjh

EDIT: p.s. I also meant to ask if the Raven 3 calculates tilt and roll ?

Add wind to the simulation in OR, and plot altitude vs. "position north/east of launch" to see the weathercocking distance. Yeah, not very intuitive. See the Help tab in the DriftCast workbook for more info. Rocksim (2D) is more obvious as it is simply called "range."

I make my own kml files from my GPS data using GPS Visualizer. The 2D ground shadow is very useful for understanding where the rocket travelled over the ground. The 3D flight tracks that everybody posts to the forum are hard to look at and interpret, imo.

No tilt/roll in Raven3 or Raven4. Need the BlueRaven for all that stuff.

 

[Buckeye]

I would imagine that the rocket will continue to tilt as long as there is wind to push against it. My guess is the winds aloft are quite a bit higher. I can output a table of the wind data to the debug area.

The simplistic assumption in DriftCast is that the majority of the weathercocking happens right at the surface and is mostly influenced by the surface level winds. Maybe it could be refined some based on some moment of inertia, CP/CG relationship information...again though, this gets into the realm of a much more involved simulation vs basic calculation.

Looking at the basic sims, the weathercocking distance increases more rapidly as the rocket slows down at the higher altitudes. So, you may want to weight the higher-level winds more heavily in the weathercock table interpolation.

 

[sr205347d]

the weathercocking distance increases more rapidly as the rocket slows down at the higher altitudes

Gravity turn, not weathercocking. It would do that in dead air if launched at an angle.

 

[kjhambrick]

Gravity turn, not weathercocking. It would do that in dead air if launched at an angle.

Or both

One thing I found in OR is that the lateral distance ( "Position North of Launch" ) is 'randomly inconsistent' unless I zero out Turbulance Intensity and Standard Deviation.

This is "Nocturnal Missions" a 2.95-inch diameter Vulcanite Upscale, similar to your ( EDIT: @Buckeye's ) flight above ( but sadly no boattail ):


Note that I forced "Standard Deviation" and Turbulence Intensity" to 0.

Then I've been plotting ground track "Position North", Altitude, "Total Velocity" -vs- "Position North" ( odd, I know ):

And this is the plot:

The drift has been pretty close for two recent flights in a smaller rocket on H180W and I161W ...

HTH ...

-- kjh

 

[Buckeye]

Gravity turn, not weathercocking. It would do that in dead air if launched at an angle.

OK, I see that.

Nevermind. In OR, it looks like the weathercocking path is pretty well established closer to the ground (maybe first 20% of the altitude?) and stays that way until close to apogee. Based on a sample of one

 

[Buckeye]

This is "Nocturnal Missions" a 2.95-inch diameter Vulcanite Upscale, similar to your ( EDIT: @Buckeye's ) flight above ( but sadly no boattail ):

Interesting. Your model/flight is pretty similar to mine, other than I have a lot less stability margin (6%, 1.37 caliber). You have 1000 ft of upwind travel @ 12 mph, I have about 500 feet. I wonder if OR is overestimating the tail cone CP and preventing more weathercocking?

 

[kjhambrick]

Interesting. Your model/flight is pretty similar to mine, other than I have a lot less stability margin (6%, 1.37 caliber). You have 1000 ft of upwind travel @ 12 mph, I have about 500 feet. I wonder if OR is overestimating the tail cone CP and preventing more weathercocking?

Interesting, indeed.

A tailcone is destabilizing -- CP moves forward and CNa is reduced.

I wonder what you'll see if you temporarily 'disable' the tailcone by setting the length = 0.00 and d2 = d1 ?

-- kjh

EDIT: p.s. I put the dimensions of my 'conditional' assemblies in the title so I can 'fix it' when I am done

EDIT[ 2 ] - I'll add a temporary tailcone and see what's what with "Nocturnal Missions"

EDIT[ 3 ]

No tailcone, CP at 57.006, CNa = 14.479, apogee = 11,926 ft:


Fake tailcone, CP at 55.789, CNa = 13.353, apogee = 13,025 ft:


Edit: here is the plot ... not much 'upwind' change ...

So ... would this count as an "inverse Base Drag Hack" ?

 

[DaHabes]

OK, question...

The help tab shows the entering of weathercock data as positive numbers. My Rocksim sims show the range as negative numbers. Do I enter the number as a negative (per the Rocksim plot) or a positive number, per the help example? The help topic is silent regarding the impact of negative vs. positive range numbers from the simulation.

From the looks of it, Rocksim always provides the range as a negative number, as in the rocket got pushed downwind (as it would whether it weathercocked significantly or not) from the launch location, which is the opposite direction of where the rocket will float upon chute deployment. That would indicate the rocket will float back the way it came past the launch point in the direction of the wind.

If I DO enter the numbers as negative, the resulting landing location is FARTHER from the launch location than if I enter positive numbers. So, is the GPD DriftCast algorithm, in effect, accounting for the weathercocking as a positive number INTO the wind?