Why do these miss?

2 tracks attached. AUTO bombing on buildings. Slight dive, stable flight, bombs well short. Don't know what I did wrong. It just sometimes happens to me for seemingly no reason. I know AUTO isn't the most accurate but consistently 100m short leads to believe I'm doing something wrong, just can't figure out what.

It's frustrating on deep strike missions to have all that set up, pop up, have everything right, and the string just goes short out of nowhere. I can't seem to fix it with piloting. It seems being in a dive and adjusting designation late exacerbate it, but you can see in the second track I don't fiddle with the designation late and it happens anyway.

Anyone can tell me what I did wrong? Tips/tricks to share?

miss_1.trk

miss_2.trk

The links in your profile make me want to stay away from your attachments, but I am having the same problems with auto mode.

Would be interested in knowing what others see.

On "miss 1" I only see a tiny short miss. I did see a much larger one on "miss 2". When I took over control I didn't get as bad a short but definitely noticeably short, about a bomb crater diameter or two.

Your waypoint seems good. In general I'm guessing the MK-83 ballistics are a little more draggy than the computer thinks. I don't know why sometimes it's well short and most times it's only barely short.

At first I thought it was a baro alt issue. The SLT was -2 and baro alt was hugely off from actual but one it should be INS-based and two I screwed around with the setting and no change so rules that out.

The links in your profile make me want to stay away from your attachments, but I am having the same problems with auto mode.

 

Would be interested in knowing what others see.

Not sure what you mean? Someone posted on my visitor's wall some nonsense back in 2017, but that wasn't me. That's public and I don't have control over what people post there.

My attachments are all DCS tracks. If you look at my post history you can see plenty of people have downloaded tracks from me and none have complained about anything out of the ordinary.

I have 20% warn because I posted a document about JDAMs that I found out wasn't formally declassified, but it wasn't a virus or anything crazy like that. Just a misunderstanding.

Frederf, thanks for checking it out. I reported it in the bug section, but everyone told me they couldn't reproduce it and I was wrong. However, the same thing happens in the A10 and the JF17 and I can reproduce it reliably. I cannot test the Viper as I do not own that module. It's hard to test the Mirage because the CCRP aimpoint doesn't line up in the hud, so there is ambiguity there. Have yet to test the Harrier. Not only do I not use mods, I have never installed a mod, so this is as stock as DCS OB can get.

I think the baro is off because DCS has an issue with cold weather screwing that up. You can tell in the Viggen because the WP markers in cold weather will be below the target, or underground, when correct QFE is set. At 20 deg C, no problem.

The exact same thing happens with Mk82's, so it's not just Mk83. Haven't tested 84's yet.

Newy, can we get a second look at this?

To reproduce the bug:

1. Use WPDSG on either waypoint 3 or 4 in the track. You can see in the ME the WP's are properly placed.

2. Set up bombs for pair release or a small stagger, like 2 @ 25ft spacing

3. Dive on the target 10 degrees or more, keeping stable flight and stable speed and drop

The bombs will land short 90% of the time. They may get close enough at times to destroy the target, but they'll still be short of the aimpoint. Since these releases are in dives at altitude of around 5-6k feet, time of flight is around 7-9 seconds, so very short. There is no wind in the mission. They shouldn't be that inaccurate that often.

Baro being off isn't wrong. QNH (or really QFF) is an altimeter calibration which can only be accurate at one altitude. It's perfectly normal and correct for properly set barometric altimeters to be wrong like this. It doesn't matter because whatever is going on it's fully independent of baro alt.

In real airplanes you'd have some uncertainty as to target and airplane elevation to do the math with. Usually airplane is some form of altitude: baro, radar, INS and target is either assumed to be at the steerpoint elevation (or terrain surface elevation database) if there isn't some direct slant range measurement device. The other source of error, lateral-longitudinal is almost never a factor in cases of systematically coming up short.

Testing methodology is to simplify as much as possible and then try one variable at a time. So ditch the FLIR pod and just drop a single Mk83 on coordinates. The FLIR is weird since it can change the 2D target position but there's no way for it to really know slant range so I'm guessing it assumes waypoint elevation unless it has a terrain database like A-10/F-16. Just for fun I ran the LTD/R while releasing on some tests because the laser should get accurate slant range and fix any mistakes in geometry and it made no difference. I'm pretty sure that there's nothing wrong with the input geometry in the bomb calculation. The only thing I'm suspicious of is target elevation effect. Is the issue similar at 3000' as sea level?

That leaves ballistic calculation. Maybe the bomb traj isn't accounting for something like cold air density, BRU ejection velocity, ejection wobble energy loss, separation airflow impulse, something. I even checked if MFUZ vs EFUZ was a factor because an M904 fuze (3D model visuals) is a little draggier than a smooth ballistic cap and an FMU-139 screwed in the back (assumed actual config). Heck even the US Navy putting extra thermal protection coating on a bomb can make it fly different. The real airplane has inventory codes for with and without that stuff. If possible a single MK-83 on the direct bomb rack which is simply hooked released might have a different ballistics than one on the dual rack adapter which probably has ejection pistons.

Baro being off isn't wrong. QNH (or really QFF) is an altimeter calibration which can only be accurate at one altitude. It's perfectly normal and correct for properly set barometric altimeters to be wrong like this. It doesn't matter because whatever is going on it's fully independent of baro alt.

 

In real airplanes you'd have some uncertainty as to target and airplane elevation to do the math with. Usually airplane is some form of altitude: baro, radar, INS and target is either assumed to be at the steerpoint elevation (or terrain surface elevation database) if there isn't some direct slant range measurement device. The other source of error, lateral-longitudinal is almost never a factor in cases of systematically coming up short.

 

Testing methodology is to simplify as much as possible and then try one variable at a time. So ditch the FLIR pod and just drop a single Mk83 on coordinates. The FLIR is weird since it can change the 2D target position but there's no way for it to really know slant range so I'm guessing it assumes waypoint elevation unless it has a terrain database like A-10/F-16. Just for fun I ran the LTD/R while releasing on some tests because the laser should get accurate slant range and fix any mistakes in geometry and it made no difference. I'm pretty sure that there's nothing wrong with the input geometry in the bomb calculation. The only thing I'm suspicious of is target elevation effect. Is the issue similar at 3000' as sea level?

 

That leaves ballistic calculation. Maybe the bomb traj isn't accounting for something like cold air density, BRU ejection velocity, ejection wobble energy loss, separation airflow impulse, something. I even checked if MFUZ vs EFUZ was a factor because an M904 fuze (3D model visuals) is a little draggier than a smooth ballistic cap and an FMU-139 screwed in the back (assumed actual config). Heck even the US Navy putting extra thermal protection coating on a bomb can make it fly different. The real airplane has inventory codes for with and without that stuff. If possible a single MK-83 on the direct bomb rack which is simply hooked released might have a different ballistics than one on the dual rack adapter which probably has ejection pistons.

Ok time to run some new tests then. I get the same effect if I use WPDSG instead of the FLIR pod. I assumed LITENING was using angle rates in lieu of laser ranging if laser ranging wasn't provided since I believe that is how it works. I don't think laser ranging is modeled at all currently. I think it's "magic" right now and knows the exact range to the spot on the ground you're pointing at, regardless of the presence of any intervening objects you may be pointing at. Also, having a PTRK doesn't increase accuracy of aimpoint at all, it still ignores the object it's tracking for range and targets the area you are looking at behind the target at the time of TDC depress, so it's not using angle rates or lasers, but is still accurate enough to deliver a JDAMs. At any rate, I eliminated aim point as an issue two ways:

1. By running the same test with WPDSG

2. By using the TPOD aim point to drop JDAMs.JDAMs was able to successfully hit the target using the same FLIR designation you see in the tracks.

I will test tonight:

1. Using single ejectors instead of the doubles I've been testing

2. Placing targets at higher elevations, as high (but still flat) as possible to magnify any changes

3. Using Mk84

4. Dropping QTY=1 to rule out errors in multiple bomb computations

Ok conducted more tests.

Attached track here, using WPDSG, both mk83 and mk82 dropped in singles. Multiple misses, all but one falling short. Last drop down at 3k ft level scores a direct hit to show diving is an exacerbating factor.

loads_of_misses.trk

More testing. This time showing a technique I know reliably produces hits. Getting the FLIR POV at roughly a line just past the target, then diving about 15deg reliably produces hits. The PTRK on the boiler houses, if you keep pressing TDC depress up until 2 sec before release, will give you a perfect angle. Otherwise, try to get the FLIR reticle at roughly 45 deg.

There's something wrong here.

I can also show short misses on level approaches at greater than 6k ft on WPDSG targets, all of them falling short.

hits.trk

Auto delivery is bugged since ever.

Auto delivery is bugged since ever.

Is it? I just completed this campaign (twice at that) and I had zero problems in Mission 5 where you have to bomb 6 road blocks with Mk83s: I dropped 6 bombs in single AUTO mode from level flight at angels 9, and all 6 hit their target just fine (and I did it twice, so that's 12 for 12).

Do you have various winds at different altitude or strong gusts?

These are all thing the targeting computer cannot take into account.

Is it? I just completed this campaign (twice at that) and I had zero problems in Mission 5 where you have to bomb 6 road blocks with Mk83s: I dropped 6 bombs in single AUTO mode from level flight at angels 9, and all 6 hit their target just fine (and I did it twice, so that's 12 for 12).

That may be so, but it doesn't answer the question. A road block is a bigger target than a building. If you saw the tracks, you would see the bombs all land within a road block of the target.

The question is, why do they miss the buildings exactly the same way every time? Using a smaller target shows errors in accuracy (as opposed to precision) more clearly.

I then posted a track where I hit every target by intentionally designating a point behind the target. That's a single bomb on a building-sized target, not a road block. This is to show the misses aren't random chance and that there is an issue with AUTO dropping the bombs short.

The winds are set to 0 for all altitudes in the tracks.

That may be so, but it doesn't answer the question.

No it didn't, as it wasn't meant to. It was simply meant to refute the "CCRP is bugged" claim.

As for your tracks, yes I did watch them before posting my comment, and didn't see anything wrong myself.

So I just ran a test myself (using a waypoint instead of a TPOD), using the same conditions you set: 2 Mk83s with 25 ft spacing, on a fuel tank target.

One bomb landed just short, the other right behind the target, with the TANK smack in the middle, which is I'd say how it's supposed to work.

I re-loaded the same test mission, but now I used single bombs. On my first run the bomb landed just behind the target; on my second it landed perfectly on target.

I'm pretty sure CCRP isn't meant to be used on small targets, but is meant for heavily defended factories and such, where pinpoint accuracy doesn't matter that much.

For smaller targets I use either CCIP or a laser guided bomb.

I did some tests myself and now I too believe it's bugged.

I think I also was able to find the root of the problem - airspeed at drop.

In the mission there are several containers and a Hornet full of Mk82s.

0 wind.

2 Drops, both at 9000 ft:

1st drop at 440 Kts - miss (by a lot)

2nd drop at 300 Kts - direct hit

The only two variables in these drops were airspeed and attack direction (but since there was no wind attack direction didn't matter).

The track is attached below.

Hornet AUTO bomb test.trk

No it didn't, as it wasn't meant to. It was simply meant to refute the "CCRP is bugged" claim.

 

As for your tracks, yes I did watch them before posting my comment, and didn't see anything wrong myself.

So I just ran a test myself (using a waypoint instead of a TPOD), using the same conditions you set: 2 Mk83s with 25 ft spacing, on a fuel tank target.

One bomb landed just short, the other right behind the target, with the TANK smack in the middle, which is I'd say how it's supposed to work.

I re-loaded the same test mission, but now I used single bombs. On my first run the bomb landed just behind the target; on my second it landed perfectly on target.

I'm pretty sure CCRP isn't meant to be used on small targets, but is meant for heavily defended factories and such, where pinpoint accuracy doesn't matter that much.

For smaller targets I use either CCIP or a laser guided bomb.

This does not address the precision problem at all. Did you see the track where I purposely designate behind and hit all but once to show it wasn't competence or randomness? Did you see where I also used WPDSG to rule out the TGP?

Harpoon I'll test that on my end. You may be on to something. I did test acceleration_deceleration at drop, but not total speed.

Also note the same thing happens in the A10 and JF17, and I have a bug report with supporting tracks on DEKAs forum as well.

Testing

15,000' level release from center station, one MK83 at various KCAS airspeeds against prepared target waypoint along Batumi runway. Weather DCS default.

200 KCAS, bomb short 10'

300 KCAS, bomb short 20'

350 KCAS, bomb short 50'

400 KCAS, bomb short 180'

450 KCAS, bomb short 300'

500 KCAS, bomb short 440'

Looks like a speed-based issue to me. Maybe it's a mixup between KCAS and KEAS? Weird compressibility divergence?

Testing

15,000' level release from center station, one MK83 at various KCAS airspeeds against prepared target waypoint along Batumi runway. Weather DCS default.

 

200 KCAS, bomb short 10'

300 KCAS, bomb short 20'

350 KCAS, bomb short 50'

400 KCAS, bomb short 180'

450 KCAS, bomb short 300'

500 KCAS, bomb short 440'

 

Looks like a speed-based issue to me. Maybe it's a mixup between KCAS and KEAS? Weird compressibility divergence?

Definitely! Harpoon is on to something. Speed definitely effects bomb impact.

I just ran a test here, where I purposely tried to hit every target, and see what that would look like. What I found is if I take the TPOD and aim it a few taps longer than I thought the center of the target was (ignoring the actual target, of course, and just considering the ground underneath it as laser ranging is not currently modeled), I could achieve some pretty darn good accuracy. See that attached track where I hit almost every target with a single drop almost dead center most of the time by intentionally aiming long and going less than 300kts.

However, it is more complicated than this. If you descend to 7k ft. and bomb flying level, you will find an overshoot situation like Harpoon showed if you are flying greater than 320-350kts or so. Slowing down helps, but causes the bombs to land short. I've attached a track here where I fly level and release single Mk82s @7k ft going over 400kts and overshoot. Slowing down to less than 300kts makes the bombs land short. This means at 7k ft there is some speed where my tendency would be to hit dead center.

This tells me there are idealized pairings of altitudes and airspeeds where the solution is valid.

Speed and altitude both seem to play a part. It would be interesting to re-run your tests @7k ft and see what your observations are.

Track where I hit everything and track where I demonstrate the effects of airspeed at 7k ft attached.

how_to_hit.trk

alt_effects.trk

Did a few more tests. There are definitely altitude/speed pairings that have to be maintained to be accurate in AUTO. Basically, the lower you are, the fasteryou need to go until you hit a middle point (looks like 7kft 350ish kts) when that inverts, and you need to start slowing down to make hits until you reach an altitude so high that it's no longer possible to go as slow as you would need to to hit (which Frederf is seeing in his track).

AUTO is bugged. See attached track. Going fast causes 7k ft level bombing to go long, going slower causes them to land short, cutting the difference in half causes a hit (I was off laterally, but I was asymetric. The distance was on. I then went to 6k ft and 340ish kts and shacked a BTR to further prove the point.

Hope ED will finally look into this.

alt_speed_combo.trk

I'm looking into optimal speed and altititude combinations at the moment and was wondering if you referenced Ground Speed when you were doing these Tests?

I'm looking into optimal speed and altititude combinations at the moment and was wondering if you referenced Ground Speed when you were doing these Tests?

Good question. It was whatever speed is displayed by default on the HUD