Jump to content

OBOE! - Mission / Script inside


Draken35

Recommended Posts

It certainly has, I learned a lot, thank you!

 

If you're interested, here's my oboe mission, the bare version without voice overs or anything, just to show the technique.

 

I've since narrowed the path to 105 feet (was 300), fixed the release signal to be 7.5 sec long and changed it in accordance with the latest info, so no steady course from the 3 min point, but follow the path all the way and drop tangentially.
 

 

Link to comment
Share on other sites

v1.06 is posted... Details in the OP but basically I modified it to use a tangential release vector and added some training wheels to help pilots like me, navigate the path... They are off by default (turn on in settings) and can be easily disabled from the script.

 

Now, lets talk bomb accuracy... Surprisingly a topic that has not come up yet...

 

Quote

The system of ground-controlled blind-bombing used by the Pathfinder Force of Bomber Command of the Royal Air Force since December 1942, and later by the United States IXth Air Force, is described in detail.The system enables an aircraft flying at a height of 30,000 ft to be controlled from pulse ground stations up to a range of nearly 300 miles, and to drop its bombs with great accuracy.Trials undertaken on bombing ranges in this country show that for an aircraft flying at 300 m.p.h. at a range of 110 miles, the average radial error for bombs dropped from 6,000 ft is 45 yd, and for bombs dropped from 25,000 ft is 100 yd. For a similar aircraft flying at a range of 250 miles the average radial error for bombs dropped from a height of 30,000 ft is 150 yd.Of the bombing error about 10% is taken up by the system errors, 45% by flying errors, 30% by inaccuracies in meteorological wind forecasts and 15% by bomb ballistic errors.

from https://digital-library.theiet.org/content/journals/10.1049/ji-3a-1.1946.0133

 

And "within 1400ft from the target" in operations from a source I cannot remember... 


Edited by Draken35
  • Thanks 1
Link to comment
Share on other sites

  • 6 months later...

Continuing our discussion from the file comments, I once again want to thank you for putting this together. Your and Reflected's work have really stirred my imagination and problem-solving drive. I've learned a ton from playing this mission, studying historical documents, and playing with your code. I have some insights and suggestions I want to share.

Bugs

The Report Results feature does nothing after the bombs landed. There is nothing unusual in dcs.log.

Feature Requests

  • Briefing should have both ground speed and indicated air speed with clear distinction between the two.
  • Swap the sign convention on the training aid so the range is negative if you're too close to the Cat station and positive if too far. 
  • Add a rough function for bomb trail so the bombs land in the target zone. More on this below.
  • I would like to see how precisely I flew on the beam (RMS error about the Cat radius) and how close to the nominal parameters (beam distance, heading, speed, altitude, timing) my release was. It's possible to use the linearized equations below to see how each error contributed to how much the bombs missed.
  • It may be better to report the bomb results in along-track and cross-track components rather than polar coordinates.
  • Add an Air Start option near the 20-mile rally point so it's possible to get more practice.

Staying on beam

While on beam, use shallow bank (<10 degrees) to make course corrections of 2-5 degrees. Very little rudder is required for coordination because you are at cruise speed, but a brief tap is helpful to initiate yaw when banking. Avoid using pitch to initiate the turn because it will mess up your speed and altitude. Use the turn coordinator to ensure turns are consistent.

For a ground speed of 300 mph and a Cat radius of 100 miles, staying on beam means turning toward the Cat station at and average rate of 3 degrees per minute. This is 1/60th of a standard-rate turn and requires about half a degree of constant bank. While Mosquito pilots report being able to stay on beam using gentle pressure on the rudder, this might not be easy for the average sim player's hardware. I think the best beginning strategy is to bounce between the edges of the beam in straight and level flight. This is similar to how real pilots fly DME arcs.

The length of the longest possible straight path through an equisignal beam with width w and radius r is approximately 2*sqrt(2rw). For a 100 mile Cat radius and 32 meter beam width, this is 4 miles, or 48 seconds at 300 mph. One possible strategy for flying the beam is to bounce along its edges like a photon in an optical fiber. Fly in a straight line and make a 4 degree turn toward the Cat station every time you hear dashes and a 2 degree turn away from the Cat station every time you year dots. Adjust the turn heading if you go more than 30 seconds without the beam.

While in level flight, you are always being accelerated away from the Cat station in the rotating frame. This means you need less extreme course corrections to move away from the Cat station than to move toward it. While within the beam, try to compensate for this centripetal by making gentle turns of about 1 degree toward the Cat station every 10-20 seconds.

Accuracy

The basic equation for the travel distance of a projectile launched in a vacuum is:

gif.latex?L%20%3D%20vt

where L is the along-track displacement of the projectile, v is the ground speed, and t is the time of flight.

The cross-track error T may be expressed according to the course error (delta_theta) and distance from the beam:

gif.latex?T%20%3D%20vt%5Csin%5CDelta%20%

For a projectile in a vacuum, the time of flight may be expressed as

gif.latex?t%20%3D%20%5Cfrac%7B1%7D%7Bg%7.

For a drop from 20,000 feet, the fall time is about 36 seconds. Therefore, the distance traveled is:

gif.latex?L%20%3D%20%5Cfrac%7Bv%7D%7Bg%7

L = \frac{v}{g}\left (\sqrt{2hg+\dot{h}^2}+\dot{h}\right )\\

where g is the acceleration of gravity, h is the release height, and hdot is the vertical speed (which is much smaller than 2hg). This equation does not account for trail to to drag, but trail is normally only about 10% of the total distance traveled. This vacuum equation can be differentiated to explore the relationships between small errors in the release parameters and the impact point. So, if we differentiate L and T with respect to all six terms, we get the following approximate linearized relationship between the impact point and errors in the release parameters.

gif.latex?%5CDelta%20L%20%3D%20v%5CDelta

\Delta L = v\Delta t+ t\Delta v+\frac{v}{gt}\Delta h+\frac{v}{g}\Delta \dot{h}

gif.latex?T%20%3D%20vt%5Csin%5CDelta%20%


The implications of these equations are that in order to get within 100 meters of the target, the Mosquito needs to release with six parameters matching their nominal values, in order of priority:

  • On beam
  • ±2 mph of ground speed
  • ±1 degree of course
  • ±0.3 seconds of the release signal
  • ±300 feet of altitude
  • ±600 feet per minute of vertical speed

Speed, beam position, and course are the most critical. There's a ton of flexibility in altitude and vertical speed, meaning that the pilot should prioritize matching the correct ground speed at the release over altitude. The easiest way to get to a speed quickly is by changing pitch because gravity provides more acceleration than the engines. Good energy management on the flight path can ensure that speed and altitude are easily converted into an accurate shot. At 300 mph GS, 100 ft of excess altitude may be converted into 5 mph of speed while conserving energy.

Heading needs to be adjusted to the correct release heading by the dash on the 5T release signal. If you're steady on the beam, you should be close enough to the correct heading to have time to make this correction.

Bomb Trail Distance

I noticed in your script that the target zone was displaced from the nominal target because of the vacuum approximation. I did some simulations of the bomb's trajectory, using Tacview for calibration and found a good empirical function for trail distance. I modified the code and now I can get the bombs within 100 meters of the target.

I took at peek at the Lua files for WWII weapons and found the mass and frontal area of the GP 250 Lb Mk V. The cx_coeff line for the drag coefficient and its dependence on Mach number is inscrutable to me, so I had to to infer the drag coefficient using a least-squares fit to the vertical speed of the bomb as function of time. I generated a simulation of the bomb's trajectory using SciPy's odeint at various release heights and speeds. To find the drag coefficient, I also propagated a state transition matrix to linearly relate the initial parameters to small differences in these parameters as a function of time. I then used least-squares to fit these values to vertical velocities measured in Tacview, which gave me a good estimate of the modeled drag coefficient. My trajectories can predict the Tacview data within about 1 m/s. I used the Prandtl-Glauert factor to approximate the drag coefficient's dependence on Mach number.

With a good drag coefficient model in hand, I simulated trajectories for a range of of release heights and was able to generate contour plots of trail distance as a function of release altitude and speed. These functions were relatively smooth, so I fit a power law to them, which yielded this:

gif.latex?%5CDelta%20L_%7B%5Crm%20trail%

Forgive the unit system stew. This expression typically matches my simulations within 30 meters. Notice the near-linear dependence of the trail distance on altitude. This jives with the conventional wisdom that bombs fall at a constant trail angle that depends only on airspeed.

I added this formula to the Oboe script and then subtracted the trail distance from the release distance in the code. I can now get within 100 meters of the target, but I have yet to actually damage the ground unit.

gp250lb.png

20220422210100_1.jpg

20220422210034_1.jpg

oboe.lua OBOE_DEMO_DAY_quickmod.miz


Edited by contactlight
Text got deleted from post for some reason. Added it back.
  • Like 1
  • Thanks 1
Link to comment
Share on other sites

Hey glad you made it here!

10 hours ago, contactlight said:

Bugs

The Report Results feature does nothing after the bombs landed. There is nothing unusual in dcs.log.

Unfortunately I cannot reproduce this one... I downloaded the mission (just in case my copy had something extra) and try 5 time and the report worked in all of them. Are you using a modified version of the script (or Mist?) . 

 

10 hours ago, contactlight said:

Briefing should have both ground speed and indicated air speed with clear distinction between the two.

Clarifying that the speed in the briefing is actually the ground speed should be easy. Now, I would need to figure out how to get the air speed from there.

 

10 hours ago, contactlight said:

Swap the sign convention on the training aid so the range is negative if you're too close to the Cat station and positive if too far. 

Shouldn't be that difficult either but I do not recall my reasoning (if any) for having it like it is now. I would have to look at the code and flight OBOE to bring bag my memory

10 hours ago, contactlight said:

I would like to see how precisely I flew on the beam (RMS error about the Cat radius) and how close to the nominal parameters (beam distance, heading, speed, altitude, timing) my release was. It's possible to use the linearized equations below to see how each error contributed to how much the bombs missed.

This one actually goes with the kind of DCS work I've been doing as of late (Target Impact Tracking Script). I'll add it.

 

10 hours ago, contactlight said:

It may be better to report the bomb results in along-track and cross-track components rather than polar coordinates.

I'm not sure if my ,as of yet, un-caffeinated mind is follows you. Currently the scripts reports the distance of the impacts from the target and the direction, in clock face format, being 12 o'clock the actual release heading.  For example: 250m @ 8 o'clock means that the drop was short and to the left of the target... Please, give me an example on how you visualize using the tract as a reference.

 

10 hours ago, contactlight said:

Add an Air Start option near the 20-mile rally point so it's possible to get more practice.

The script doesn't really care where the player starts and was intended as a mission building tool. The provided missions are just demo's for the script (notice the lack of flak ? :D). 

The demo mission randomly selects on target out of 5. The first 4 are just 2 actual targets but the beam flow in clockwise and counter-clockwise directions. There is not really a way to put any airplane closer to the targets in this setups, since you wouldn't know what plane to choose and can end up being in the worst possible place...

Now,  the script allows mission builders to select a target from the list. To do so, you just put the target number in the select target function parameter

image.png

You get the target number from the target list in the script:
image.png

The approach tell you in which direction to fly the beam . 

Then, you just add an airplane in the position you want  and save the mission as a copy

11 hours ago, contactlight said:

Add a rough function for bomb trail so the bombs land in the target zone. More on this below.

I saved the best one for the end 🙂 .. That is actually something that sparks my interest and I'll look into it... Just it will not happen soon. My DCS development time is short  and I'm working in other projects at the moment. Also, in the last 6 months I've gotten more acquaintance with LUA than I was 6 months ago and when I was going thru the script to try to figure out the results bugs you reported and refreshing my memory on how I did things, I was shaking my head 😄 ...  So, we might see a 2.0 in the future. That might get back into the Mozzie.

I'll take closer look at the code you provided next week (my weekends are to fly, not to develop 🙂 )

Thanks a lot for your feed back! It is really appreciated! 

 

 

  • Like 1
Link to comment
Share on other sites

53 minutes ago, Draken35 said:

Unfortunately I cannot reproduce this one... I downloaded the mission (just in case my copy had something extra) and try 5 time and the report worked in all of them. Are you using a modified version of the script (or Mist?) . 

 

I wish I could be more helpful. I am using a modified version of your script, but the error predates the modifications. I'm using the same Mist library as was provided in the original download. 

54 minutes ago, Draken35 said:

Clarifying that the speed in the briefing is actually the ground speed should be easy. Now, I would need to figure out how to get the air speed from there.

 

Here's a Python function from my ballistics code for computing atmospheric density as a function of altitude, surface pressure, and temperature lapse rate. To convert true airspeed to indicated at low Mach numbers, you simply run this function at altitude with the surface temperature and pressure in the briefing to get the local air density, and then estimate IAS by multiplying the true airspeed by the square root of the ratio of the density at altitude to the density at sea level under standard temperature and pressure (1.225 kg/m^3).

IAS = TAS*sqrt(density(h, p0, T0, lapse_rate)/1.225)

def density(h, p0, T0, lapse_rate):
    M = 0.02896968
    R = 8.314462618
    g = 9.80665
    p = p0*(1-lapse_rate*h/(273.15+T0))**(g*M/R/lapse_rate)
    rho = p/(273.15+T0-lapse_rate*h)*M/R
    return rho

 

1 hour ago, Draken35 said:

I'm not sure if my ,as of yet, un-caffeinated mind is follows you. Currently the scripts reports the distance of the impacts from the target and the direction, in clock face format, being 12 o'clock the actual release heading.  For example: 250m @ 8 o'clock means that the drop was short and to the left of the target... Please, give me an example on how you visualize using the tract as a reference.

 

It's the same idea, but instead projecting the error on the sine and cosine of the clock angle. In your example, what I'd be looking for is something like:

Distance: 250 m L: -125 m T: -216 m 

The L (longitudinal, along-track) component says how short or long the landing was, indicating how well I timed my release and flew the correct ground speed and altitude. The T (transverse, cross-track) component tells me how far left or right the bombs landed, which is a function of how close I was to the beam and correct release heading. Obviously, the most important thing to know is the total distance because it predicts damage, but I think the Cartesian approach allows the user to better understand why their shot missed.

A more plain-language approach might be:

250 m from target | 125 m LEFT | 216 m SHORT

 

1 hour ago, Draken35 said:

The script doesn't really care where the player starts and was intended as a mission building tool.

We're good, then. You can see in the attached mission that I have already moved the aircraft and fixed the target to a non-random value. It's good to leave these instructions up.

 

Link to comment
Share on other sites

12 minutes ago, contactlight said:

I wish I could be more helpful. I am using a modified version of your script, but the error predates the modifications. I'm using the same Mist library as was provided in the original download. 

I'll add some debugging code and PM it to you later in the week. That code is rather simple and I don't really see where or why it is failing consistently for you and not for me...

 

15 minutes ago, contactlight said:

The L (longitudinal, along-track) component says how short or long the landing was, indicating how well I timed my release and flew the correct ground speed and altitude. The T (transverse, cross-track) component tells me how far left or right the bombs landed, which is a function of how close I was to the beam and correct release heading. Obviously, the most important thing to know is the total distance because it predicts damage, but I think the Cartesian approach allows the user to better understand why their shot missed.

Ah! Make sense now. Yes, that will be useful. Thanks for the suggestion. It will make it to the script at some point.

 

16 minutes ago, contactlight said:

Here's a Python function from my ballistics code for computing atmospheric density as a function of altitude, surface pressure, and temperature lapse rate. To convert true airspeed to indicated at low Mach numbers, you simply run this function at altitude with the surface temperature and pressure in the briefing to get the local air density, and then estimate IAS by multiplying the true airspeed by the square root of the ratio of the density at altitude to the density at sea level under standard temperature and pressure (1.225 kg/m^3).

Interesting... Not sure if the surface pressure and/or the temperature lapse rate are available in the ED provided API (I guess, for the TLP the average can be used - Google says 6.5C/Km ). Need to do some research.

Link to comment
Share on other sites

2 hours ago, Draken35 said:

Interesting... Not sure if the surface pressure and/or the temperature lapse rate are available in the ED provided API (I guess, for the TLP the average can be used - Google says 6.5C/Km ). Need to do some research.

I think 6.5 C/km that may be your best bet. It's tied to the International Standard Atmosphere and ICAO reference atmosphere and applies to typical water vapor content. I let an F/A-18 glide to the ground on idle and its inlet and fuel temperatures varied by about 4-6 C/km.

Link to comment
Share on other sites

I found this postwar film on RAF radar research that contains a sample of what Oboe may have sounded like. The section on Oboe begins at 24:49 and the sound sample is at 25:35. Pardon that the video was posted by a UFO enthusiast.

The Cat tone in the film is much higher frequency than what we've been working with in DCS, about 1 kHz fundamental with a roughly triangular waveform. The Mouse release signal is more buzzer-like and easily distinguished from the Cat. It has a more sawtooth waveform.

I wanted to verify what the tone may have sounded like and Jones (1946) says the audible Cat tone had an audible frequency of 1064 Hz. The X, Y, Z, A, B, C tones are at 194 Hz. These line up with the film well. These tones are unpleasant and I can understand if you and @Reflected choose to stick with a more pleasant woodwind sound.

The Morse signal is also modulating a continuous tone rather than performing on/off keying, so the pilot hears the dots and dashes bumping the 1064 Hz tone louder. When the aircraft is on the beam, the dots and dashes fade, resulting in a continuous tone. An error of 18 yards or 1/6 of a degree is sufficient to hear faint dots or dashes.

Another interesting detail from the paper was that the the Cat signal was modulated according to both the residual range and range rate (or course deviation times speed). If I'm reading this correctly, this means that the pilot would hear a continuous tone if they were off the nominal range, but their course deviation was appropriate to get them back on track in a certain amount of time. The feedback was tuned so the ratio of range deviation to range rate deviation was normally 40 seconds, which is both roughly the typical fall time for a bomb and the maximum amount of level flight time within the beam. This is useful because adding a velocity feedback term both dampens the oscillations of the flight path over time and ensures the pilot's range error on release are compensated by their course error. As the equations I posted above show, you can hit your target if you're off beam with a course deviation inversely proportional the your speed and the bomb time of flight. In terms of the game, I think adding a velocity term to the "on track" condition could result in a smoother Oboe flight. 

Screenshot_20220424-080141_Drive.jpg


Edited by contactlight
  • Like 4
Link to comment
Share on other sites

Would it be possible to get a tutorial or a helping hand on how to implement this in historical missions? Im working on the Avro Lancaster and ive got a few missions built on historical raids, is there a way to get the OBOE to work with a singular target? The Lancs used Gee systems later in the war which i believe is roughly similar to OBOE but allows more than 1 aircraft to use it simultaneously which shouldn't be needed for the SP campaign so would it be possible to use?

Minor Lancaster Fanboy

EDbanner.png

Link to comment
Share on other sites

1 hour ago, Scoobyon said:

Would it be possible to get a tutorial or a helping hand on how to implement this in historical missions? Im working on the Avro Lancaster and ive got a few missions built on historical raids, is there a way to get the OBOE to work with a singular target? The Lancs used Gee systems later in the war which i believe is roughly similar to OBOE but allows more than 1 aircraft to use it simultaneously which shouldn't be needed for the SP campaign so would it be possible to use?

The script was designed from the ground up to be used in multiple missions... The target list can contain only one target if needed (see screen shots in  this post).. To define a target in the ME, you just put a zone on top of it and 2 zones for the Cat and Mouse stations

image.png

Of course, you have to define the release parameters and add those (in the proper units!) to the target definition:

image.png

The demo mission contains al the necessary triggers to load the sounds and make the script works..

To be honest, I have no clue if it would work in multiplayer since I only play SP and the code is not fresh in my memory... 

Of course, if you have specific questions, don't doubt on posting here or PM me.

 

 

 

Link to comment
Share on other sites

@contactlight thanks so much for the information, I've never dreamed of hearing the actual signals. This is super helpful. Now based on this I managed to recreate the exact cat and mouse signals for my upcoming campaign.

I could not make the Cat signal modulated based on heading too, like you described, so in my mission it will be solely dependent on the aircraft's range from the station. But that's close enough for me.

Thanks again!

Link to comment
Share on other sites

5 hours ago, Reflected said:

@contactlight 

I could not make the Cat signal modulated based on heading too, like you described, so in my mission it will be solely dependent on the aircraft's range from the station. But that's close enough for me.

Thanks again!

I tried implementing this for Draken35's code. The trick is that you have to low-pass filter the radial velocity (v dot r/|r|) using a simulated RC filter with a 40 second time constant to match how the tracking station circuitry differentiated the range trace. This is only a handful of additional lines of code. If you don't do this, the slightest bank will shift the beam by hundreds of meters in seconds. You then multiply the smoothed velocity by 40 seconds again and then shift the Cat range by that integrated range. 

To be honest, I tried it and I don't think it makes flying the mission easier. It has a weird effect of straightening the flight path out when viewed in Tacview and my aim was confused enough to get me about 300 meters to the left of my target. It does make the approach somewhat easier since you get a signal to turn inward several kilometers before you hit the nominal track. I might just need more practice, so I'll experiment more and let you know.

Link to comment
Share on other sites

@Reflected Here's my attempt at recreating the sound. This is a sweep from -320 meters to 320 meters, transitioning from on-off dots to a continuous tone and then dashes plus a tone. Curiously, I can't hear modulation of less than 10% (32 meters of error or 0.4 dB), whereas pilots were expected to be able to hear about 5%. I added a second harmonic to the carrier tone to make it less harsh.

  • Like 3
Link to comment
Share on other sites

  • 1 year later...

What an amazing thread.

Never noticed this one before.

Gotta have a play with this.

 

  • Like 1
  • Thanks 1

System: 9700, 64GB DDR4, 2070S, NVME2, Rift S, Jetseat, Thrustmaster F18 grip, VPC T50 stick base and throttle, CH Throttle, MFG crosswinds, custom button box, Logitech G502 and Marble mouse.

Server: i5 2500@3.9Ghz, 1080, 24GB DDR3, SSD.

Link to comment
Share on other sites

19 hours ago, Mr_sukebe said:

What an amazing thread.

Never noticed this one before.

Gotta have a play with this.

 

Fascinating stuff. I thought it was getting a bit above my head early on. Then it went vertically at about Mach 2. I mean, I’ve read some words and seen some numbers here and there but whoosh. :fear: 😁. Hats off I say. 

Link to comment
Share on other sites

That was truly awesome.  One of the most impressive mods that I've yet seen.

I was happily able to use the demo mission and was within .3 of a mile from the target, whilst bombing from 20,000'.  I couldn't even see the target from the cockpit, I was too busy trying to keep it straight and level.  Have to say that I'm amazed at the accuracy.

Is there any way to account for wind and it's effects on the bombs, whilst calculating the release point?

System: 9700, 64GB DDR4, 2070S, NVME2, Rift S, Jetseat, Thrustmaster F18 grip, VPC T50 stick base and throttle, CH Throttle, MFG crosswinds, custom button box, Logitech G502 and Marble mouse.

Server: i5 2500@3.9Ghz, 1080, 24GB DDR3, SSD.

Link to comment
Share on other sites

OK, have been playing some more and have now incorporated your scripts into my generic Normandy WW2 (1943) scenario.

There's a lot of other stuff in there too for anyone interested.

If anyone fancies a play, the miz and an Oboe guidance kneeboard are attached.  The appropriate flight to use for the Oboe mission is the 604 Squadron (night).

I have tried flying this at night, so far it's just shown me that I need a "spot of practice".  I dialed the take off time to a little before sunset.

Thanks again for the work to make this happen.  Simply awesome stuff.

Oboe.png

Normandy - 1943 - Attrition v8.miz

  • Thanks 1

System: 9700, 64GB DDR4, 2070S, NVME2, Rift S, Jetseat, Thrustmaster F18 grip, VPC T50 stick base and throttle, CH Throttle, MFG crosswinds, custom button box, Logitech G502 and Marble mouse.

Server: i5 2500@3.9Ghz, 1080, 24GB DDR3, SSD.

Link to comment
Share on other sites

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...