Weapon Delivery Planner released
-
Hey,
I’m sorry I have not been able to express myself clearly. I’ll try again, giving a concrete example.
When I use WDP 2.7 to calculate a Type 1, Low Drag, VRP pop-up attack with the following parameters…
500 ft
20 deg
450 CAS
4000 ft
7 sec
3 G
Right
076 deg
5 nm… I get a “Pull Heading” (which I understand is the heading I am suppose to pull to at the PUP) of 016 degrees. Now, when I load the DTC with this data and actually fly the mission, coming (for testing purposes, I know this is not how the attack is supposed to be flown) from the south-southwest, I am able to visually align the PUP and OA1/OA2 symbology (the latter obviously only in the horizontal) along heading (actually track) 016. In my understanding, this is only possible because the calculator does not figure in the 3G turn radius required to turn to a heading of 016 at the PUP.
Put another way: If I start a 3G turn exactly at the PUP, assuming perfect parameter flying, when rolling out on heading 016 (which is the “Pull Heading” calculated by the software), I should have the OA1/OA2 symbology (OA2 only if the “Place OA2 at the Aim Off Point” option is deselected) directly in front of me on heading (actually track) 016. This, however, is not the case. The OA1/OA2 symbology is actually further to the left, because the 3G turn to get to heading 016 has not been taken into account. Even under the assumption that the 3G turn is initiated simultaneously with the pull-up (which, according to the WDP manual, e.g. p. 26, and real-life procedures, is NOT how the profile should be flown), it should still not be possible to align PUP and OA1/OA2 along the “Pull Heading”, although the discrepancy would of course be mitigated.
If you look at the profile view of the attack I described, you will see that the attack track makes an in-place 30 deg check to the left exactly at the PUP, while it should actually make a curve appropriate for a (in this case) 3G turn radius, as does the turn from the reverse point to the target.
I’m claiming that a similar issue exists for the pull-up to the reverse point (OA1), even when using a Type 2 attack. Although 3G is selected in the attack profile, a precise 3G pull-up at the PUP will cause you to undershoot the reverse point (OA1). I am not sure whether in this case no turn radius is being assumed as in the case abovementioned, or a turn radius smaller than (in this case) 3G. From my tests, it appears to be a no-onset, about 6G pull-up.
I would like to make clear that I have no issues adjusting my flying to a no-turn-radius-situation if this is intended by design, however the fact that the manual (and you in your first reply) have stated that ALL the turns and pull-ups are supposedly calculated with the amount of G respectively selected makes me think that there is an oversight in the code.
Or, all this is just my imagination or has been caused by a fundamental misunderstanding on my part, in which case I humbly submit myself to your ridicule.
-
Hey,
I’m sorry I have not been able to express myself clearly. I’ll try again, giving a concrete example.
When I use WDP 2.7 to calculate a Type 1, Low Drag, VRP pop-up attack with the following parameters…
500 ft
20 deg
450 CAS
4000 ft
7 sec
3 G
Right
076 deg
5 nm… I get a “Pull Heading” (which I understand is the heading I am suppose to pull to at the PUP) of 016 degrees. Now, when I load the DTC with this data and actually fly the mission, coming (for testing purposes, I know this is not how the attack is supposed to be flown) from the south-southwest, I am able to visually align the PUP and OA1/OA2 symbology (the latter obviously only in the horizontal) along heading (actually track) 016. In my understanding, this is only possible because the calculator does not figure in the 3G turn radius required to turn to a heading of 016 at the PUP.
Put another way: If I start a 3G turn exactly at the PUP, assuming perfect parameter flying, when rolling out on heading 016 (which is the “Pull Heading” calculated by the software), I should have the OA1/OA2 symbology (OA2 only if the “Place OA2 at the Aim Off Point” option is deselected) directly in front of me on heading (actually track) 016. This, however, is not the case. The OA1/OA2 symbology is actually further to the left, because the 3G turn to get to heading 016 has not been taken into account. Even under the assumption that the 3G turn is initiated simultaneously with the pull-up (which, according to the WDP manual, e.g. p. 26, and real-life procedures, is NOT how the profile should be flown), it should still not be possible to align PUP and OA1/OA2 along the “Pull Heading”, although the discrepancy would of course be mitigated.
If you look at the profile view of the attack I described, you will see that the attack track makes an in-place 30 deg check to the left exactly at the PUP, while it should actually make a curve appropriate for a (in this case) 3G turn radius, as does the turn from the reverse point to the target.
I’m claiming that a similar issue exists for the pull-up to the reverse point (OA1), even when using a Type 2 attack. Although 3G is selected in the attack profile, a precise 3G pull-up at the PUP will cause you to undershoot the reverse point (OA1). I am not sure whether in this case no turn radius is being assumed as in the case abovementioned, or a turn radius smaller than (in this case) 3G. From my tests, it appears to be a no-onset, about 6G pull-up.
I would like to make clear that I have no issues adjusting my flying to a no-turn-radius-situation if this is intended by design, however the fact that the manual (and you in your first reply) have stated that ALL the turns and pull-ups are supposedly calculated with the amount of G respectively selected makes me think that there is an oversight in the code.
Or, all this is just my imagination or has been caused by a fundamental misunderstanding on my part, in which case I humbly submit myself to your ridicule.
Hi Bestandskraft,
Nope, no ridicule needed
You are understanding the matter perfectly and you are correct on all accounts.
As I can remember the turn is taken into account, but the pop-up code is the oldest part and been written several years ago.
I’ll have a look at the code and see.For now I think the reason is comming from several things. First the turn angle is only 30deg, so that makes the displacement from the turnradius very small.
Second you have the turn itself, flying at high speeds it does matter if you are a little late or early with your turn. Also flying a perfect 3G starting at the PUP and stopping at your pull heading is impossible.This will give you the randome under or overshoot.
But in the end it is not that important if you get the OA1/OA2 on heading 012 or 018. As long if you can turn the nose on the OA triangles in the HUD you are in the green.ps, I perfer Type2 Pop-ups myself
Gr Falcas
-
Had a quick look in the code and the turn is calculated. In your example the PUP is shifted about 1700’ away from the target to compensate for the turn.
This is only a small amount and that is why you are experiance what you have seen.
The offset angle (your example 30deg) is depending on the dive angle you choose. Taking a larger dive angle gives you a larger offset angle.
The shift for the turn is larger if the offset angle is larger.Gr Falcas
-
I really appreciate the time you are taking to debug this! I really love your program so I want to help make the most of it.
To continue the discussion (yes, I have too much time):
I did some testing, taking your input into consideration, and I think I can now describe very precisely what the problem is. I also disabled wind completely so as not to have drift interfere with the testing.
Take my values from above, except for “Tracking Time” put 5s instead of 7s (for some reason I cannot select 7s any more, but that does nothing to the purpose right now).Now, gradually increase the speed from 450 all the way up to 550 kts. You will see that (as you indicated), the PUP wanders further and further away from the target as you do this. The same is true for Gs. If you increase Gs, the PUP will wander closer to the TGT, and vice versa. This indicates that the position of the PUP is presumably calculated correctly, and that it will take your turn radius into account.
What does NOT take your turn radius into account, however, is the relative placement of the PUP and OA1. The fact that I am able to align PUP and OA1 on a heading of 016, which is the Pull Heading in our example, proves this. Assuming perfect parameter flying, I will always undershoot the OA1 symbology, meaning when rolling out on a heading of 016, the OA1 will be left of the nose. Even if you fly min radius parameters and start your turn right at the PUP, you will always reach heading 016 before you manage to point at the OA1.
As stated previously, I believe that the pull-up in a Type 2 attack likewise assumes an infinitely small turn radius in the vertical. You can test this the same way as before: Convert our example to a Type 2 attack and initiate a min radius pull up to 30° right at the PUP. You will undershoot the OA2. The same issue is most likely present with Type 1 attacks, although here it is masked by the check turn problem.
Now, as you stated before, the symbology is simply an additional aid for executing the attack. As far as I can tell, if you disregard the symbology (except the PUP, which as we established is placed correctly), you will be able to fly the attack on parameters as calculated. I don’t know how much effort would be involved in adjusting the symbology, this is obviously left to your discretion.
-
While further testing the attack planning tools in WDP 2.7 I came across a possible bug (yes, this time it’s not a feature as in the case above).
Whenever I calculate a Pop-up or a TOSS and change any values on the Input Panel, the new DED Data as displayed on the DED Data panel accessible via the cockpit knob displays any changes immediately. When I go to the DTC=>NAV OFFSETS page, those changes are also reflected there.
HOWEVER, whenever I calculate a HADB, while changes I make to the input values are still reflected in the DED Data panel, those changes for some reason do not carry over to the DTC=>NAV OFFSETS menu, even though I receive the usual “Pilot.ini and TEname.ini saved” dialogue box. Accordingly, those changes do not take effect in the cockpit.
The only way to actually cause effective changes to the HADB data in the DTC=>NAV OFFSETS menu at all seems to be to restart WDP, then, before loading the mission or a DTC file, calculate a HADB. However, the values that are calculated and displayed on the DED Data panel (which from the looks of it are correct) are still different from those that end up on the DTC=>NAV OFFSETS panel (which appear to be bogus, at least partially).
So, to repeat:
- Only HADB seems to be affected.
- Changing the values in the DTC=>NAV OFFSETS panel by recalculating the HADB only works when no mission is loaded, but the values that actually do make it to the DTC=>NAV OFFSETS panel are not correct as compared to the DED Data panel.
-
falcas i have a question.
A friend of mine modified the frequencies on a theater for personal use and noticed that wdp freq’s remain intact…(the change does not affect the wdp data)Is there a file with the freq’s somewere inside the wdp that i can edit to meet the theater ones or is there any other way (ie reinstalling wdp)
-
Do the WDP screens resemble the USAF AWE planning system or Weapons Delivery Planning Software??
-
falcas i have a question.
A friend of mine modified the frequencies on a theater for personal use and noticed that wdp freq’s remain intact…(the change does not affect the wdp data)Is there a file with the freq’s somewere inside the wdp that i can edit to meet the theater ones or is there any other way (ie reinstalling wdp)
Hi Condor,
I was a bit busy last weeks, had a very nice LAN this weekend
WDP has its own database and you can not change it. But I will update the database if that is needed.Gr Falcas
-
Do the WDP screens resemble the USAF AWE planning system or Weapons Delivery Planning Software??
WDP is not a copy of a other know software as those have parts that are classified. But I did had a little peek of FalconView. FalconView is the software used to plan the flights for the F-16 and save the data to the DTC.
WDP is inspired on these kinds of software.
A lot of data, like the performance calculations are comming from the F-16 manual.Gr Falcas
-
Thanks for the info. My question was generated by an interest in the general appearance of the USAF AWE planning software interface, which is different, I think, from FalconView.
-
Hi,
New version released. Latest version 2.8
Changelog can be seen over here: https://www.benchmarksims.org/forum/showthread.php?5293-Weapon-Delivery-Planner&p=66013#post66013Or go directly to the WPD website for your download: www.weapondeliveryplanner.nl
Enjoy,
Falcas
-
Hi,
New version released. Latest version 2.8
Changelog can be seen over here: https://www.benchmarksims.org/forum/showthread.php?5293-Weapon-Delivery-Planner&p=66013#post66013
Or go directly to the WPD website for your download: www.weapondeliveryplanner.nl
Enjoy,
FalcasGreat work mate .
Thank you .
Nikos . -
hi mate,
… keep on wondering: how do you find all this time to bring out this great stuff??
just out of our league …
Cool!
anyway, I like
Fan
-
hi mate,
… keep on wondering: how do you find all this time to bring out this great stuff??
just out of our league …
Cool!
anyway, I like
Fan
Just don’t work so much for the boss
-
While further testing the attack planning tools in WDP 2.7 I came across a possible bug (yes, this time it’s not a feature as in the case above).
Whenever I calculate a Pop-up or a TOSS and change any values on the Input Panel, the new DED Data as displayed on the DED Data panel accessible via the cockpit knob displays any changes immediately. When I go to the DTC=>NAV OFFSETS page, those changes are also reflected there.
HOWEVER, whenever I calculate a HADB, while changes I make to the input values are still reflected in the DED Data panel, those changes for some reason do not carry over to the DTC=>NAV OFFSETS menu, even though I receive the usual “Pilot.ini and TEname.ini saved” dialogue box. Accordingly, those changes do not take effect in the cockpit.
The only way to actually cause effective changes to the HADB data in the DTC=>NAV OFFSETS menu at all seems to be to restart WDP, then, before loading the mission or a DTC file, calculate a HADB. However, the values that are calculated and displayed on the DED Data panel (which from the looks of it are correct) are still different from those that end up on the DTC=>NAV OFFSETS panel (which appear to be bogus, at least partially).
So, to repeat:
- Only HADB seems to be affected.
- Changing the values in the DTC=>NAV OFFSETS panel by recalculating the HADB only works when no mission is loaded, but the values that actually do make it to the DTC=>NAV OFFSETS panel are not correct as compared to the DED Data panel.
Confirmed. I have the same problem. POP and TOSS works fine but HADB-info doesn’t update on the DataCard when you choose HADB-profile -> save DTC and then go back to view the DataCard again.
Still is a fantastic program! Thanks!
PS “I’m using V 2.8” DS
-
Thank you Falcas,
a pice of art you give us there - even more with the new update.
-
Confirmed. I have the same problem. POP and TOSS works fine but HADB-info doesn’t update on the DataCard when you choose HADB-profile -> save DTC and then go back to view the DataCard again.
Still is a fantastic program! Thanks!
PS “I’m using V 2.8” DS
Thanks.
Noted, will work on it.
Gr Falcas
-
First of I want to say thank you very much Falcas for your excellent program! I have been using it for many years and it’s getting better and better. However, in its version 2.8 I got one problem – it refuses to load Datacard for me. As soon as I choose package it displays such error:
After that, I’m not able to switch Coordination Card to Datacard. Interestingly, it happens on both of my computers. I’m on Win XP SP3.
-
Hi Zaltys,
Looks like something with the mission. Could be that your mission is corrupt, but most likely it is a bug in WDP itself.
Could you email me the mission files? and please let me know with which package and flight this is happening.
burgers6"at"xs4all.nlThanks Falcas
-
Files sent!