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

[dvdsnyd]

@dvdsnyd --

Here is one ...

I have not tried to debug the data but I imagine there was a bad data set returned by 'Winds Aloft'

This is the same-ole T'Pring's P'Toy flying to about 3100 ft on an H128W at the Tripoli Houston South Site ( Alvin, TX ) this coming Saturday, Sep 28.

My GPS DC version 2.29 .xlsm is attached.

This is a screen shot of GPS DC after I clicked [Run GPS] showing an error message:
View attachment 668776

I was able to see the Wind Data in the [E7]..[M12] region populate row-by-row until the error box popped up.

Hope this is helpful !

I'll try again later ... maybe Helene is making a mess of the wind forecasts this morning ?

-- kjh

p.s. This is a run from Wed afternoon ... everything looked good, especially for the TX coastal plains !
View attachment 668779

View attachment 668780

I've never been to the TH South site so I am unsure of the Pad location but that's what is listed on the TH Website.

You are probably right about bad data.
I'll have to take a look tonight. Curious if you run a few shorter runs, hour at at time, if you can figure out which specific forecast is messing up?

 

[DavidBellhorn]

It appears to be the wind forecast at 3PM. The result table contents imply successful completion for 9AM through 2PM.

My best guess at altitude "0" the wind speed is shown as -0. That is the first negative value I can remember seeing in the raw data.

 

[DavidBellhorn]

The 2PM wind data also runs into an unrelated issue I have been working with Dave to resolve. Under certain conditions, the current calculations will flip the wind's direction. You can see that result in the 2PM flight scatter by a weird zig-zag pattern in the ground track.


David

 

[kjhambrick]

Dave --

Image display and uploading in TRF are broken for me right now.

It usually 'fixes itself' in the early morning so I'll post some images early tomorrow.

The punch line is, I ran another session for Saturday at the TH South Site this afternoon and it worked fine.

One thing I did see is that the Forecast Model changed at 14:00 from RAP to Open-Meteo ...

I'll get you some more data asap.

Thanks !

-- kjh

 

[kjhambrick]

@dvdsnyd --

Everything is running as expected again this morning -- both GPS DC as well as image handling on TRF.

This is TP on an H128W at the Tripoli Houston South Site on Sat, Sep 28:


This is the Landing Scatter in Google Earth:


As I said in an earlier post, I am not exactly sure where the pads are located but the Landing Scatter Plot looks REALLY nice, especially for the TX Gulf Coast !

I also attached the .xlsm and the .kml files for reference.

Thanks Dave !

-- kjh

 

[dvdsnyd]

It appears to be the wind forecast at 3PM. The result table contents imply successful completion for 9AM through 2PM.

My best guess at altitude "0" the wind speed is shown as -0. That is the first negative value I can remember seeing in the raw data.

Interesting, Thanks for digging into that.
I'm not sure where these errors come from. Almost has to be from the NOAA database?
I've added a remove duplicates function/check to my code a while back for the altitude array.
Maybe I can check for negative values in the wind direction array too, there shouldn't be any negatives if I'm thinking about that correctly, right?
Dave

 

[dvdsnyd]

@dvdsnyd --

Everything is running as expected again this morning -- both GPS DC as well as image handling on TRF.

This is TP on an H128W at the Tripoli Houston South Site on Sat, Sep 28:
View attachment 668957

This is the Landing Scatter in Google Earth:
View attachment 668958

As I said in an earlier post, I am not exactly sure where the pads are located but the Landing Scatter Plot looks REALLY nice, especially for the TX Gulf Coast !

I also attached the .xlsm and the .kml files for reference.

Thanks Dave !

-- kjh

Looks good! Hopefully you get to fly.
Like @DavidBellhorn showed earlier, there was a negative value in the wind speed. I'll try to implement some filtering for that, but unfortunately, with any sort of program, garbage in equals garbage out. Maybe in a future version, there could be some sort of forecast checker/validator, that would omit a forecast from the run, but would still allow the program to finish without crashing. Just typing out loud for now...

Dave

 

[kjhambrick]

@dvdsnyd --

Jimmy sent an announcement this morning that the Tripoli Houston South Site launch is canceled because the bird hunters will be out this weekend.

Shucks ! I'll get down there eventually, but not yet ...

I'll leave the Excel debugging to you and @DavidBellhorn -- your four hands are much better hands than mine with two left thumbs

Next launch will be AARG at the Hutto Site on Oct 5 ...

I don't think I can make that one because it is my Granddaughter's birthday and Nana has something else in mind

Too bad for me ... at 8-days out, the wind speed forecast looks moderate and the direction is favorable for now for Hutto.

Holler if you need any data though, I love running GPS DC sessions !

Thanks !

-- kjh
.

 

[dvdsnyd]

Thanks everyone for the support here!
Special thanks to @kjhambrick and @DavidBellhorn for recent debug and support!

I'm releasing GPS DriftCast 2.30 - This one includes a pretty big bug fix with regards to proper wind direction calculations!!!!

Here's the release notes:

-Bugfix, courtesy of @DavidBellhorn - Old Wind direction algorithm produced an inverted bearing when oscillating around North. Example, Altitude at 2000ft has wind direction of 350 degrees. Altitude at 1000 ft has a wind direction of 10 degrees. The actual average result should be 0 or due North. However, the old algorithm would calculate (350 + 10) / 2 = 180, or due South. WRONG!!!!!!! David pointed this out and provided code for the fix.

-Updated code for wind speed and wind direction values to be absolute (only positive) when being read from the API string when getting data from Winds Aloft. Will see if this fixes the error that popped up this week.
-Fixed a few spelling errors/clean up
-Added a Known Issues/ Limitations section above release notes. Added a note taht there is a limitation with time zones between where you run GPS DC and where you are flying rockets. If the time zones between these two are different, the results will be off by the time zone difference. This should be able to be "fixed" by setting your computer's time zone to that of the launch site prior to running GPS DC.

As always, please keep suggestions, bugs, flight reports coming! I greatly appreciate all of them! This project has become so much more than I could have imagined!
As usual, I ran a couple tests and everything "appears" to be working nominally, but you all know my track record around here...there's a reason why we are at version 2.30

Dave

 

[DavidBellhorn]

Dave and I were just discussing how the visualizations I sent helped him understand the wind direction bug. Figured posting one here may be useful!

Black arrows represent the 350° and 10° wind directions he mentioned above. What we want is the green arrow between them. Averaging just the raw numbers results in the red arrow pointing due South at 180°.


Unfortunately Excel does not have any tools for dealing with time zones itself. We might be able to solve the issue with external support, but I am still investigating.

David

 

[sr205347d]

Unfortunately Excel does not have any tools for dealing with time zones itself. We might be able to solve the issue with external support, but I am still investigating.

Use UTC, or Zulu time.



The user should know what time zone the launch site is in. To get time in UTC in the eastern time zone, add four hours to the local time. Add an hour for each time zone further west. Add another hour in the winter for standard time.

 

[DavidBellhorn]

The user should know what time zone the launch site is in.

Asking the user to provide a time zone for the launch site was indeed the first solution we discussed. Certainly the simplest to implement within GPS-DriftCast. There are some caveats to that choice.

For example, stating the user should know the time zone is simple to say. I'm not convinced it is necessarily true though. I could not find it mentioned on the NSL East website. That launch site is in Georgia which I think is all EST. Tripoli lists the time zone for LDRS directly on their event page, but I do not see it for BALLS. That launch site is in Nevada which I think is all PST.

There are so many weird exceptions for time zone borders I personally never feel confident. To be honest, I still get confused converting local time to Zulu when calling in NOTAMS. I'm sure it is simple for some people. I always second guess myself.

Personally, I'm much more likely to drive/fly to the location and let my cell phone deal with local time changes.

Regardless of that, I always find the user friendliness of software decreases as the amount of manual data entry increases. Plus the likelihood of mistakes can be reduced through automation.

GPS-DriftCast already requires the launch site's coordinates. There are a handful of web services which will provide a time zone based on that. My preference is to handle everything in the background so users never have to think about it. I'm just researching which service would best meet this situation.

David

 

[kjhambrick]

I believe the TZ / offset from Zulu time can be calculated or downloaded from ( lat,long ) and date and time ( think Arizona).

How to Calculate Time Zone from Latitude and Longitude

HTH

-- kjh

 

[sr205347d]

Time zone map.

 

[sr205347d]

Time zone by zip code.

 

[sr205347d]

Or, just Google “what is the time zone for XXXXX.”

Fill in town name, zip code, area code, etc.

 

[kjhambrick]

Sorry for terse reply ... on my phone ... we have lat and lon for waiver center ... Google API and others ...

 

[DavidBellhorn]

I believe the TZ / offset from Zulu time can be calculated or downloaded from ( lat,long ) and date and time ( think Arizona).

I'm extra confused thinking about Arizona. Which parts use "Mountain Standard Time" versus "Arizona Mountain Standard Time"?

All the options you both provided for a user to lookup the time zone are perfectly valid.*

For me it comes down to being as user friendly as possible. Which wind drifting app is someone more likely to use versus skip. One where they have to do a web search on how to identify a time zone, submit the required coordinates/town name/zip code/area code, look up how to convert that into Zulu, then manually enter the hour offset? Or one where time zone is never even mentioned?

Avoiding user workload is definitely my personal philosophy when designing software rather than a hard and fast rule.

That may not be Dave's preference. He may well add a user entry field to GPS DriftCast and move on.

* (Well, except the Google API. That requires an unique API key which gets charged after a certain amount of usage. Can you tell I have also been researching how to automatically display landing locations on a map?)

 

[kjhambrick]

I'm extra confused thinking about Arizona. Which parts use "Mountain Standard Time" versus "Arizona Mountain Standard Time"?

I believe all of Arizona is in the US Mountain Time Zone but they don't do daylight savings time ( ? except maybe the Navaho Nation ? ).

That means in summer they are 2-hours behind TX but in winter they're only 1-hour behind.

It confuses me all the time too

All the options you both provided for a user to lookup the time zone are perfectly valid.*

For me it comes down to being as user friendly as possible. Which wind drifting app is someone more likely to use versus skip. One where they have to do a web search on how to identify a time zone, submit the required coordinates/town name/zip code/area code, look up how to convert that into Zulu, then manually enter the hour offset? Or one where time zone is never even mentioned?

Ick yes, requiring a user to research and enter duplicate info can be annoying

OTOH, my Linux systems have the zdump command to show year-by-year how my time zone differs from UTC in seconds and when it changes for DST:

$ zdump -v -c 2023,2025 America/Chicago
America/Chicago  -9223372036854775808 = NULL
America/Chicago  -9223372036854689408 = NULL
America/Chicago  Sun Mar 12 07:59:59 2023 UT = Sun Mar 12 01:59:59 2023 CST isdst=0 gmtoff=-21600
America/Chicago  Sun Mar 12 08:00:00 2023 UT = Sun Mar 12 03:00:00 2023 CDT isdst=1 gmtoff=-18000
America/Chicago  Sun Nov  5 06:59:59 2023 UT = Sun Nov  5 01:59:59 2023 CDT isdst=1 gmtoff=-18000
America/Chicago  Sun Nov  5 07:00:00 2023 UT = Sun Nov  5 01:00:00 2023 CST isdst=0 gmtoff=-21600
America/Chicago  Sun Mar 10 07:59:59 2024 UT = Sun Mar 10 01:59:59 2024 CST isdst=0 gmtoff=-21600
America/Chicago  Sun Mar 10 08:00:00 2024 UT = Sun Mar 10 03:00:00 2024 CDT isdst=1 gmtoff=-18000
America/Chicago  Sun Nov  3 06:59:59 2024 UT = Sun Nov  3 01:59:59 2024 CDT isdst=1 gmtoff=-18000
America/Chicago  Sun Nov  3 07:00:00 2024 UT = Sun Nov  3 01:00:00 2024 CST isdst=0 gmtoff=-21600

Anybody up for a night launch on Sat Nov 2 2024 ?

I imagine Windows has the something similar and OSX is BSD so it should have zdump or something very similar ...

I was thinking since GPS DC already does a Web API call to Winds Aloft for the ( lat,long ), one more call to get the time zone and local time for the site would be doable without needing any more user input than is already required ?

But that is easy for me to say, sitting in my comfy armchair

Avoiding user workload is definitely my personal philosophy when designing software rather than a hard and fast rule.

Mine too !!!

That may not be Dave's preference. He may well add a user entry field to GPS DriftCast and move on.

* (Well, except the Google API. That requires an unique API key which gets charged after a certain amount of usage. Can you tell I have also been researching how to automatically display landing locations on a map?)

Oops ! I should have read the Google API instructions !! Dang !!!

-- kjh

EDIT: I have to stop reading TRF on my phone ... I repeated what you already said ... oops ... Never Mind -- Gilda Radner

 

[kjhambrick]

I should leave the programming to the programmers, so back to our regularly scheduled program ...

While I am still able to attach images in TRF from my laptop, this is GPS DC version 2.30 for TP on an H128W to 3100 ft at the AARG Hutto Site on Oct 5:


I believe the direction change from 354 deg across 0-north to 5 deg between 11:00 and 12:00 would have exercised the pre-version 2.30 direction bug ?

So I quickly loaded my old version 2.29 GPS DC .xlsm for TP at Hutto and ran it:


Dooh ! version 2.30 retrieved the RAP forecast but version 2.29 was getting Open-Meteo which is completely different !!

I tried several times but I could not get a RAP forecast from version 2.29 ...

And every time I ran version 2.30, I got a RAP forecast.

Sigh ...

The version 2.30 Landing Scatter plot looks OK to me:


Note that the landing pins trace a nice, continuous clockwise oval on the ground, even when the wind direction crossed 0-deg north between 11:00 and 12:00.

For completeness, these are the version 2.29, Open-Meteo pins in Google Earth:

Quite a difference between the two forecasts, but we are still a week out ...

Attached the version 2.30 .kml files in case they might be helpful ...

Thank you for all your great work, Dave and David !!

-- kjh

EDIT: I can't spell forecast

 

[DavidBellhorn]

I was thinking since GPS DC already does a Web API call to Winds Aloft for the ( lat,long ), one more call to get the time zone and local time for the site would be doable without needing any more user input than is already required ?

But that is easy for me to say, sitting in my comfy armchair

Yes, this is my preferred answer as well. My goal is to add a "Get Time Zone" button or piggyback on "Get Elevation". Sorry for not stating that more clearly!

I have identified a handful of Web API which accept Lat/Long and return a Time Zone. Some limit the rate of requests. Some add artificial delays for free accounts. Just need to pick one at this point, but I have been focused on other tasks.

Super weird that the two GPS DriftCast versions are using different forecast models. That should only depend on how far in the future your launch occurs. Hopefully I will have time to compare the scripts later today if Dave does not beat me to it.

David

 

[dvdsnyd]

I should leave the programming to the programmers, so back to our regularly scheduled program ...

While I am still able to attach images in TRF from my laptop, this is GPS DC version 2.30 for TP on an H128W to 3100 ft at the AARG Hutto Site on Oct 5:
View attachment 669078

I believe the direction change from 354 deg across 0-north to 5 deg between 11:00 and 12:00 would have exercised the pre-version 2.30 direction bug ?

So I quickly loaded my old version 2.29 GPS DC .xlsm for TP at Hutto and ran it:
View attachment 669079

Dooh ! version 2.30 retrieved the RAP forecast but version 2.29 was getting Open-Meteo which is completely different !!

I tried several times but I could not get a RAP forecast from version 2.29 ...

And every time I ran version 2.30, I got a RAP forecast.

Sigh ...

The version 2.30 Landing Scatter plot looks OK to me:
View attachment 669081

Note that the landing pins trace a nice, continuous clockwise oval on the ground, even when the wind direction crossed 0-deg north between 11:00 and 12:00.

For completeness, these are the version 2.29, Open-Meteo pins in Google Earth:
View attachment 669082
Quite a difference between the two forecasts, but we are still a week out ...

Attached the version 2.30 .kml files in case they might be helpful ...

Thank you for all your great work, Dave and David !!

-- kjh

EDIT: I can't spell forecast

I should leave the programming to the programmers, so back to our regularly scheduled program ...

While I am still able to attach images in TRF from my laptop, this is GPS DC version 2.30 for TP on an H128W to 3100 ft at the AARG Hutto Site on Oct 5:
View attachment 669078

I believe the direction change from 354 deg across 0-north to 5 deg between 11:00 and 12:00 would have exercised the pre-version 2.30 direction bug ?

So I quickly loaded my old version 2.29 GPS DC .xlsm for TP at Hutto and ran it:
View attachment 669079

Dooh ! version 2.30 retrieved the RAP forecast but version 2.29 was getting Open-Meteo which is completely different !!

I tried several times but I could not get a RAP forecast from version 2.29 ...

And every time I ran version 2.30, I got a RAP forecast.

Sigh ...

The version 2.30 Landing Scatter plot looks OK to me:
View attachment 669081

Note that the landing pins trace a nice, continuous clockwise oval on the ground, even when the wind direction crossed 0-deg north between 11:00 and 12:00.

For completeness, these are the version 2.29, Open-Meteo pins in Google Earth:
View attachment 669082
Quite a difference between the two forecasts, but we are still a week out ...

Attached the version 2.30 .kml files in case they might be helpful ...

Thank you for all your great work, Dave and David !!

-- kjh

EDIT: I can't spell forecast

Hi Konrad,

Specifically just looking at the issue between versions not pulling the same forecast...

I think the issue is the date for the launch.
At the very least, looking at the screen caps you took:
The first one for Ver. 2.30 you say 10/5/2024, but the launch date in the program shows 9/28. This was pulling RAP, which is correct.
The second for version 2.29 shows 10/5. This was pulling Open-Meteo, which is correct.

I'm thinking this is why you were getting the different forecasts.

Make sense, or am I missing something?
Thanks,
Dave

 

[kjhambrick]

Hi Konrad,

Specifically just looking at the issue between versions not pulling the same forecast...

I think the issue is the date for the launch.
At the very least, looking at the screen caps you took:
The first one for Ver. 2.30 you say 10/5/2024, but the launch date in the program shows 9/28. This was pulling RAP, which is correct.
The second for version 2.29 shows 10/5. This was pulling Open-Meteo, which is correct.

I'm thinking this is why you were getting the different forecasts.

Make sense, or am I missing something?
Thanks,
Dave

Dooh !

Good eye, Dave -- holy cow, how embarrasing !!

Sorry about the rabbit hole, y'all !!!

-- kjh

 

[kjhambrick]

So, @JimJarvis50 announced the AARG Launch for Oct 5 last Sunday and as always, he will thoughtfully base the waiver of the day on the conditions at the launch site.

Folks,

Our October launch is this coming Saturday at the Hutto field. The weather looks good, but the wind is towards the house to the southwest. We will probably have some altitude limitations due to that. I'll post some values in a couple of days, and I'll also include a link to the sign-up sheet.

The field has been turned again, but there is still some residual corn material present. For this month, no sparky motors please.

Jim

I found out yesterday that the girls are going down to the valley for a big birthday party this weekend with their Daddy and all their cousins so I should be able to launch !

So what should I fly ?

Hmmm ... One thing that Jim has been calculating by hand for each launch since I re-BAR'd is a 'Single Deploy -vs- Dual Deploy' landing scatter plot.

I fly dual deployment but I also consider his single deployment plot because I might screw up my shear pins and end up flying the single deployment path.

So I decided to try both Landing Scatter Plots ( dual -vs- single ) in GPS DC for this month's launch:

I really want to fly T'Pring's P'Toy just barely transonic on another I211W to see if her 'Vulcanite lines' suffer aerodynamic issues while transonic, or if the ugly flight was due to random YEET or YOINK during the relatively windy Memorial Day Weekend at the TXSO in Seymour.

So I've been siming her on another I211W to 6,100 ft in GPS DC for months now.

As long as the main stays in until she descends to 400 ft AGL, she should land 1,700 -to- 1,800 ft SW of the pad, safely away from the Stately Manor 3,000 ft to the southwest.

Not bad !

But what if I screw up or something random happens to cause main deployment at apogee ?

This is what:


There are two groups of pins. The close ones are for the I211 flight where dual deployment works as expected.

But the distant, more scattered set a statute mile -or- more out, mostly across CR 101, are where the main is deployed at 6,100 feet ( the red circle is the 1-nm waiver radius for Hutto, generated by GPS DC ).

I don't think I want that hike

So this is a repeat of my Aug 3 flight on an H128W to 3,100 ft:


That looks nice and safe ( around 1,000 ft SW for dual deploy -vs- about 2,900 ft for single deploy and the Stately Manor is about 3,000 ft out where the 1pm pin is 2,500 ft out ).

One never knows when it comes to the art of rocket science, so it looks like another 3,100 ft flight on an H128W this month unless the wind forecast changes ( and being TX, it probably will ) and finally, if Jim calls in a waiver that allows for a 6,100 ft flight this coming Saturday ...

-- kjh

p.s. I double and triple checked the launch dates this time

 

[dvdsnyd]

SO.... Some of you may have already noticed that the only forecast that was being sent back was Open-Meteo.
@DavidBellhorn let me know that he noticed that WindsAloft wasn't outputting the RAP forecast.
After some more digging, it turns out the gooberment shut it down to the public, for now.
This is the redirect:
https://gsl.noaa.gov/tmp/302-redirect

Found this, which adds a little more color(see pic below)
Hopefully they can get 508 compliant soon. Not holding my breath.
Whole thing is a bummer because the RAP forecast really was the best one for GPS DC.
We are looking at other options, but nothing is glaring at us right now.

Dave

 

[kjhambrick]

Alrighty then ...

Today has turned into a pretty good day to fly high at the AARG Hutto Site.

Wunderground is forecasting partly cloudy skies with temp / pressure ranging from 76F / 30.05 inHg at 09:00 to 95F / 29.96 inHg at 15:00 when the waiver opens and closes, respectively,

One never knows when another such day will come along, so I decided to fly T'Pring's P'Toy on an AT RMS 38/600 I284W to about 8,200 ft.

This is GPS DC v2.30 for the flight:


And these are the Landing Scatter Pins in Google Earth:


Not bad at all !

The only hazards possibly in play would be the high tension power lines about 1,200 ft north of the landing zone and the 'Stately Manor' about 1,600 ft southwest.

Even if my shear pins let go, I should be fine but tired after a long, long hike

So, let's see how it goes !

I'll let you know.

Thanks for GPS DC Dave, it really is a great planning tool !

-- kjh

 

[kjhambrick]

Dave and David --

I have some 'interesting' data to post but I am up to my ears helping customers on the FL Gulf Coast move Apps and Data someplace safe.

I tried to run GPS DC last Saturday after the flight but I got no winds aloft from Open Meteo ... is that what you were discussing in post #175 ?

Is anyone else getting winds if they run GPS DC after the waiver is closed for the day ?

My apogee was 1,000 ft or so short, maybe because TP coned as she flew transonic -- just as she did on an I211W last May.

What I was hoping to try is to force the Blue Raven cross-range + down-range distance and the actual apogee to back-calc the landing scatter but I got nowhere.

Anyhow I'll be back ASAP ... after Milton.

-- kjh

 

[dvdsnyd]

Dave and David --

I have some 'interesting' data to post but I am up to my ears helping customers on the FL Gulf Coast move Apps and Data someplace safe.

I tried to run GPS DC last Saturday after the flight but I got no winds aloft from Open Meteo ... is that what you were discussing in post #175 ?

Is anyone else getting winds if they run GPS DC after the waiver is closed for the day ?

My apogee was 1,000 ft or so short, maybe because TP coned as she flew transonic -- just as she did on an I211W last May.

What I was hoping to try is to force the Blue Raven cross-range + down-range distance and the actual apogee to back-calc the landing scatter but I got nowhere.

Anyhow I'll be back ASAP ... after Milton.

-- kjh

Weird.
No that isn't what we were talking about. The RAP forecast has been disabled for the foreseeable future, so you should only be seeing Open-Meteo forecasts.
I just ran GPS DC, and I was getting forecasts for today.
Sounds like you had an interesting flight.
Excited to hear more about it!
Good luck helping everyone out!
Dave

 

[DavidBellhorn]

I tried to run GPS DC last Saturday after the flight but I got no winds aloft from Open Meteo ... is that what you were discussing in post #175 ?

I agree with Dave this should not prevent you from getting winds aloft from Open-Meteo. WindsAloft used the RAP forecast for locations on the continental US when available. Otherwise it fell back to Open-Meteo. The only change now is RAP will always be unavailable in the foreseeable future.

Jumping to an assumption, were you running GPS DC on Saturday evening for earlier times on Saturday morning? Historical wind data is only available for the previous 12 hours. Running at 11pm would fail to get winds at 9am and 10am for example.

Sadly I was unable to pay as close attention to T'Pring's P'Toy's full flight profile as I had hoped. LCO duties demanded my attention once I verified it was descending safely after apogee.

Overall my observations on Saturday matched with GPS DC predictions. Pack 1720 had 50 Scouts sign up to participate at AARG's launch. I calculated drift for a typical model rocket launching with a B6 motor from our standard low power pad location.


This reported landing on our Port-a-potty, along the road usually full of spectators, and the beginning of vehicle parking. We shifted all pads North along the road rather than East into the field based on that information. The vast majority of Scout rockets landed safely in the western field away from people. Only a few odd launch angles necessitated a heads up call.

Predictions for higher altitude launches showed a nice curve northeast around people in the morning. Moving the high power pads north certainly helped with this, but drift patterns did seem to match from my observations. These are for 2500 feet which was single deploy maximum for the day.


Launches trended more directly east and northeast as the day progressed. The final launch of the day even landed on the high power lines in the northeastern field. (He was still able to get sign off on his L2 certification.) I attribute those differences to real-world weather not matching longer term forecasts rather than GPS DC itself.

David

 

[kjhambrick]

I am a little late with my analysis this week because of Milton.

The hurricane didn't affect me directly but we have three customers on the beach in Bradenton and they asked that we 'clone' their servers and make them work on our LAN.

Anyhow.

I am pleased with the results of GPS DC for TP on an I284W.

I know where she was launched and where she landed from the positions recorded by GPS Map Camera on my Phone:

And the Blue Raven onboard told me that she YOINKED ( or maybe YEETED ) about 1920 feet horizontally ( ! )

So I did a little 'mapping' in Google Earth.


SO ...

The orange circle is a 1921 ft circle around the actual pad position which came from the Blue Raven Cross-Range and Down-Range positions at apogee as sqrt( CR^2 + DR^2 ).

The yellow circle is a 1370 ft circle around the actual landing position.

The yellow line from landing back to the yellow circle is a 53-degree track line, parallel to and the same distance as the GPS DC Track for 11:00 AM.

I would say that GPS DC did a GREAT job !

As for TP ... not so much

She seems to have an aerodynamic problem when she goes transonic but that's a story for another thread.

And I am still studying my Blue Raven Data

Thanks Dave and David !

GPS DC is a KEEPER !!!

Now I need a rocket that flies straight when flying fast

-- kjh