[CAN NOT REPRODUCE]AUTO Bombing algo broken

Attached 5 tracks.

In tracks 1-3, I am bombing the same target at an alt of roughly angels 12 with 4 mk83 with 100ft spacing. All passes, the entire string lands short.

To eliminate wind as a factor, I recorded "no wind" to show the same behavior was still occurring.

Then, I recorded "low alt" where I release much lower and string, though not hitting the target (100ft is too much for this target), it perfectly brackets the target as I would expect.

Altitude has an effect on where the bombs land, long or short, irrespective of flight skills, designation point, and atmospheric conditions.

This strongly suggests there is a bug in the bombing algo. I tested the aimpoints with GBU38's to confirm that it wasn't a designation point issue, and it isn't. It's definitely the bomb drop logic itself.

This definitely needs to be corrected, as AUTO bombing with iron is really not a good idea in the Hornet right now unless you can go low alt ( < 5000ft for best results).

To reiterate, and ward off the cavalcade of inevitable "I saw X pilot say AUTO isn't accurate" posts, the bombing method is PRECISE, but it is not ACCURATE, meaning the dispersion pattern is as expected, but the actual point the system thinks it's trying to drop on is wrong. Random dispersion issues from large WEZ would be circular in nature, whereas this issue is linear.

hornet_auto_issue_1.trk

hornet_auto_issue_2.trk

hornet_auto_issue_3.trk

hornet_auto_issue_nowind.trk

hornet_auto_issue_lowalt.trk

I watched your tracks and did my own tests from 20000ft, MK-83, Level AUTO.

The results are the same as yours, bombs fall short.

However, I did similar tests with a 30 degree dive, 12000ft ish release, AUTO mode - and the impacts are spot on. It's the level release that's the problem.

I guess employing dumb bombs from a level medium altitude delivery is not a typical use case, and so the issue can be circumvented by using a much more common dive delivery.

However, they still should be little more accurate, so it may need adjusting.

Agreed. And since they always fall short they seem to be pretty accurate but the computed release point is wrong.

I haven't seen the tracks but just to make sure... Are you guys placing your auto release tgt diamond in the middle of the line/column or row of whatever you're bombing?

I tested it minutes ago and it worked fine.

I haven't seen the tracks but just to make sure... Are you guys placing your auto release tgt diamond in the middle of the line/column or row of whatever you're bombing?

 

I tested it minutes ago and it worked fine.

Yes. I'm using PTRK and making sure the reticle snaps to the target, then lasing while pressing tdc depress each time to ensure a consistent aim point.

I watched your tracks and did my own tests from 20000ft, MK-83, Level AUTO.

 

The results are the same as yours, bombs fall short.

 

However, I did similar tests with a 30 degree dive, 12000ft ish release, AUTO mode - and the impacts are spot on. It's the level release that's the problem.

 

I guess employing dumb bombs from a level medium altitude delivery is not a typical use case, and so the issue can be circumvented by using a much more common dive delivery.

 

However, they still should be little more accurate, so it may need adjusting.

Sorry to start up an old debate again, but I just don't get why you guys say that about CCRP (AUTO). It is intended for use in level flight. Safer but less accurate than CCIP.

Anything I have ever read or heard says that, as well as my own flight sim experience, so I'm a little confused about your comments. It is not a 'more common dive delivery' in CCRP at all, IMO.

I tested level auto delivery again. No issues so far on my rig.

I didn't go above 5k feet. The dispersion at 10 or 12k is too big.

First test: Level at 4k, 480 kts. The interval set at 10ft since the target vehicles are closely spaced. I used 4x Mk84:D The dispersion looked OK, evenly spaced around the tgt.

Second: Level at 5k, 520 kts. The interval set for 200 ft. The vehicle column was 1600 ft. long.

I used 8x Mk83 making sure the tgt. designation was in the middle of the column not on the first vehicle. It worked out OK. 2 vehicles got away... they must have seen the jet approaching;)

No laser ranging on either run.

https://youtu.be/EtXC9IJJ2vA

Sorry to start up an old debate again, but I just don't get why you guys say that about CCRP (AUTO). It is intended for use in level flight. Safer but less accurate than CCIP.

 

Anything I have ever read or heard says that, as well as my own flight sim experience, so I'm a little confused about your comments. It is not a 'more common dive delivery' in CCRP at all, IMO.

At the risk of beating an old horse.....

AUTO can be and is used in level flight, However that doesn’t exclude its use in a dive. The issue here is that tactical jets wouldn’t typically drop unguided dumb bombs in level flight. Especially at medium altitude.

Depending on the jet, either CCIP or AUTO may be preferable in the dive. F-16 might prefer CCIP, due to AGR only available in CCIP. That doesn’t apply to Hornet.

I tested level auto delivery again. No issues so far on my rig.

I didn't go above 5k feet. The dispersion at 10 or 12k is too big.

 

First test: Level at 4k, 480 kts. The interval set at 10ft since the target vehicles are closely spaced. I used 4x Mk84:D The dispersion looked OK, evenly spaced around the tgt.

 

Second: Level at 5k, 520 kts. The interval set for 200 ft. The vehicle column was 1600 ft. long.

I used 8x Mk83 making sure the tgt. designation was in the middle of the column not on the first vehicle. It worked out OK. 2 vehicles got away... they must have seen the jet approaching;)

No laser ranging on either run.

 

https://youtu.be/EtXC9IJJ2vA

Please watch the tracks. Issue is not dispersion. Everything is explained in OP and demonstrated in the tracks.

Please watch the tracks. Issue is not dispersion. Everything is explained in OP and demonstrated in the tracks.

The thing I don't get, is that I see the problem when I try your tracks, but I don't have that issue when I run any of my normal test bombing missions.

When I take control of the track replay and deliver the ordnance myself it seems ok

At what point did you take control? What did you do differently from me? Which track did you do this to? What was your altitude?

It would help if you saved your own track and posted it. We have several users claiming a repeatable issue with this. The lower the altitude, the less short the WEZ is.

The thing I don't get, is that I see the problem when I try your tracks, but I don't have that issue when I run any of my normal test bombing missions.

Tracks are good for troubleshooting hardware, software, add-ons, sometimes procedures, etc.

I find tracks inaccurate half the time when it comes to timing of events. Well... in A/A turning fights the tracks are 80% inaccurate:noexpression:

LastRifleRound, I ran your no wind track mission (deleting the first 2 waypoints) at 7k and 11k both level release, and these are the results.

Don't see what the difference is, but seems to work OK.

bomb 7k.trk

bomb 11k.trk

Ok I see what you guys are doing differently.

This is what happens when the laser ranging either not being implemented or ranging "through" buildings collides with another bug.

I can reproduce your results if I DO NOT update my designation with an additional TDC depress with 8 seconds to go.

In all my runs, I always designate the target with 8 seconds to go because my JDAM testing has led me to conclude you are actually not designating the building, but the spot "through" it on the other side.

Your aim points are all long, so your bombs fall more or less on target.

To illustrate, 4 tracks. 7k "update" wherein I update the target position with 7 seconds to release, and "no update" where I don't do this. "update" hits, "no update" is consistently long.

12k "update" falls consistently short (original bug report) and 12k "no update" falls more or less on target.

I have tested many more altitudes and bomb spacing with a similar continuum of results.

I've derived two conclustions:

1. The further from the target you TDC depress, the longer your aimpoint is from target center

2. The higher your altitude, the shorter the bombs fall from said aimpoint.

I believe this is why "AUTO bombing broken" reports abound on the regular forum but with wildly different results. To consistently test your results, you MUST make sure you TDC depress at the same distance and altitude each time to ensure your aim point is the same each time.

My aim point theory is in another bug post and is tested with JDAMs, so that is supported by evidence as well.

Trust me, there's something up here with AUTO.

hornet_auto_issue_7k_no_update.trk

hornet_auto_issue_7k_update.trk

hornet_auto_issue_12k_no_update.trk

hornet_auto_issue_12k_update.trk

Ok I see what you guys are doing differently.

 

This is what happens when the laser ranging either not being implemented or ranging "through" buildings collides with another bug.

 

I can reproduce your results if I DO NOT update my designation with an additional TDC depress with 8 seconds to go.

 

In all my runs, I always designate the target with 8 seconds to go because my JDAM testing has led me to conclude you are actually not designating the building, but the spot "through" it on the other side.

 

Your aim points are all long, so your bombs fall more or less on target.

 

To illustrate, 4 tracks. 7k "update" wherein I update the target position with 7 seconds to release, and "no update" where I don't do this. "update" hits, "no update" is consistently long.

 

12k "update" falls consistently short (original bug report) and 12k "no update" falls more or less on target.

 

I have tested many more altitudes and bomb spacing with a similar continuum of results.

 

I've derived two conclustions:

1. The further from the target you TDC depress, the longer your aimpoint is from target center

2. The higher your altitude, the shorter the bombs fall from said aimpoint.

 

I believe this is why "AUTO bombing broken" reports abound on the regular forum but with wildly different results. To consistently test your results, you MUST make sure you TDC depress at the same distance and altitude each time to ensure your aim point is the same each time.

 

My aim point theory is in another bug post and is tested with JDAMs, so that is supported by evidence as well.

 

Trust me, there's something up here with AUTO.

I'll have a look at your tracks, but I'm not sure I understand what the laser has to do with this. I noticed you armed it in your original tracks. Why?

Probably irrelevant to the issue, but...

Also, I haven't experienced the issue with JDAM aiming either. Strange one.

LastRifleRound, I ran your no wind track mission (deleting the first 2 waypoints) at 7k and 11k both level release, and these are the results.

 

Don't see what the difference is, but seems to work OK.

The problem here is you're using AREA track, so you are not repeating the experiment and introducing additional variables. Namely, aimpoint differences.

What you are actually doing here is designating a point behind the building (you are actually picking the building on the left instead of right, so it's also a different target), not the building itself, so your aimpoint is long.

I can prove this. Do the same thing, except launch a JDAMS in TOO at this aimpoint. Your JDAMS will overshoot the target quite a bit.

Track attached. I took control of your track about 40 sec before delivery, achieved PTRK, then updated designation by TDC depressing (without moving the cursor, of course) with 7 seconds to go. String falls short.

bomb 11k aimpoint comped.trk

I'll have a look at your tracks, but I'm not sure I understand what the laser has to do with this. I noticed you armed it in your original tracks. Why?

 

Probably irrelevant to the issue, but...

 

Also, I haven't experienced the issue with JDAM aiming either. Strange one.

I wasn't sure if laser ranging was implemented, so I always did it this way to remove it as a variable. I don't think it matters at all. Though I haven't seen an official response on my other post, I don't think laser ranging is actually implemented yet.

I've attached a track showing the JDAM going for the actual aimpoint, which is behind the building. This is the spot you guys are actually bombing if you don't update with another designate closer in.

hornet jdam issue.trk

OK, so here is a (fairly messy!) track using PTRK and targetting the same building as you. 7K and no updates. Works perfectly.

One of things I was always advised to do is aim at the bottom of buildings. Your target appears to be up on the roof. Don't know if that makes a difference either.

Sorry if we are missing the point here.

bomb 7k 2.trk

I wasn't sure if laser ranging was implemented, so I always did it this way to remove it as a variable. I don't think it matters at all. Though I haven't seen an official response on my other post, I don't think laser ranging is actually implemented yet.

 

I've attached a track showing the JDAM going for the actual aimpoint, which is behind the building. This is the spot you guys are actually bombing if you don't update with another designate closer in.

Ok, so as per my last post, I think you are aiming too high and overshooting the building in this JDAM track as well.

I tried it, took control, adjusted the target for the bottom of the building wall, as always advised, and it works perfectly. See attached result of running your track.

EDIT: I've added the track.

JDAM issue.trk

OK, so here is a (fairly messy!) track using PTRK and targetting the same building as you. 7K and no updates. Works perfectly.

 

One of things I was always advised to do is aim at the bottom of buildings. Your target appears to be up on the roof. Don't know if that makes a difference either.

 

Sorry if we are missing the point here.

PTRK ensures the exact center of the building, parrallax-free, is designated (can be verified as you overfly the target).

Using other modalities inserts aiming errors into the equation. Since aimpoint and the bombing algorithm are closely related, not controlling for one or the other will lead to inaccurate, non-repeatable tests.

Sorry, I don't understand your point. I feel we're not getting anywhere here. Did you look at my track of your JDAM example? Works perfectly, as the other examples do, if the target is the bottom of the building as has always been advised to me over the years.

Again, apologies if we are missing your point, but I just can't reproduce the issue.

Ok, so why don't we take the FLIR out the equation entirely?

That way LOS and ranging etc aren't dependent on what is or isn't implemented with the pod mechanics.

In my tests WP2 is precisely located on top of my target. A simple WPDSG and drop on that.

Level drops at 7000ft are pretty accurate, same at 14000ft. So far so good, as expected.

There is certainly more dispersion at 19000ft and 20000ft. In my tests there's also a tendency to drop short above about 18000ft, but you would expect less accuracy / more dispersion at that altitude. However, if the hits all group short in every test, that would indicate a problem. It might be that way, but more runs are needed.

You need to decide what we're testing - AUTO mode accuracy or the ability of the TGP to create a good desired aimpoint?

AUTO test 7k.trk

AUTO test 14k.trk

AUTO test 19k.trk

AUTO test 20k.trk

OK, so I tried my mission without the TPOD, and putting the waypoint directly on top of a building. WPDSG, and 3 of the bombs hit the target OK.