Jump to content

air ground attack precision


blast

Recommended Posts

- Real life Mirage 2000C CCIP and CCRP are useless

Since the Mirage 2000 is combat proven you can rule this one out :doh: Don't confuse the real fighter with its simulation.

By the way, I don't have any problem hitting targets in CCIP with TAS mode (radar ranging).


Edited by jojo

Mirage fanatic !

I7-7700K/ MSI RTX3080/ RAM 64 Go/ SSD / TM Hornet stick-Virpil WarBRD + Virpil CM3 Throttle + MFG Crosswind + Reverb G2.

Flickr gallery: https://www.flickr.com/gp/71068385@N02/728Hbi

Link to comment
Share on other sites

This is some narrow delivery method which disguises the bug. The system designates the wrong location. This is true even if bombs never leave the airplane. What this steep dive and release in similar dive does is make red and green lines close together so the issue is hidden. Yes I found that some deliveries mask this issue too.

 

I think because baro pressure knob on altimeter has an effect on solution I can "dial away" this bug and see if CCRP (direct) is accurate when designated point is returned to surface.

 

By distance value I wonder if it is supposed to work a different way than the usual bomb spacing. Most airplanes use "option 2" definition but what confuses me about Mirage and maybe they use "option 1" concept is the values.

 

In Mirage you can pick 01, 02, 03,...79,80x10m value or 10m through 800m in 10m increments. But what case in the world would use the 800m setting or anywhere close to that? With cluster bombs 100m maybe. Illumination flares? Nuclear weapons? What makes sense for such huge numbers? Even minimum 10m is still not extremely dense. Where is 5m? 3m? 15m? 25m? Who is using the 61x10m setting?!

 

Instead if Mirage uses concept "option 1" then life makes more sense. 10 cluster bombs over total length 800m is only 89m spacing which is useful. Delivering four bombs on 20m total length is 6.7m spacing. These are useful spacing values.

 

I guess there is also "option 3" concept which that 01...80 is spacing but there is omitted a decimal point so it is 0.1x10m through 8.0x10m spacing. But this sounds wrong because why have X.X and then have painted "x10" after? It's silly.

 

 

This is option 2, and this isn't a guess.

 

 

DIST = 01 (10m) not very "dense": I would rather not be within 10m of a detonating Mk-82, and even less between 2 detonating 10m apart (at the most 5m of each one) :music_whistling:

 

 

 

Cluster bombs: France did use (not anymore) BLG66 Beluga which disperse 151 sub-munitions.

The bomb weight 290kg.

2 selectable dispersion patterns:

- 120m long x 40m wide. (dense)

 

- 240m long x 40m wide.

 

 

So here is the use of long DIST intervals.

-----------------------------------------------------------------------------------

 

You were right about the designation problem.

I closed to the target after designation, and indeed the + in HUD slide after the targeted point.

 

When I release from longer distance, the bombs are released "nose high" and arrive on target with a more vertical angle, and hit behind intended point.

 

I can't say if this is parallax issue or under the ground target.

Mirage fanatic !

I7-7700K/ MSI RTX3080/ RAM 64 Go/ SSD / TM Hornet stick-Virpil WarBRD + Virpil CM3 Throttle + MFG Crosswind + Reverb G2.

Flickr gallery: https://www.flickr.com/gp/71068385@N02/728Hbi

Link to comment
Share on other sites

I can't say if this is parallax issue or under the ground target.

 

I estimate the parallax error of the M2K HUD waypoint cross to be 7-8 pixels @ 1080x1920

 

AV-8B is around 2-3 pixels.

 

attachment.php?attachmentid=190222&stc=1&d=1531965542

 

Tested with M2K Gyro Drift disabled and INS does not require alignment, using air starts in DCS 2.5.2.19273.

365189435_M2KHUDParallaxError2_5_2_19273.thumb.jpg.eb7763c3b6f370936415cc6fe8d75bcd.jpg

i9 9900K @4.7GHz, 64GB DDR4, RTX4070 12GB, 1+2TB NVMe, 6+4TB HD, 4+1TB SSD, Winwing Orion 2 F-15EX Throttle + F-16EX Stick, TPR Pedals, TIR5, Win 10 Pro x64, 1920X1080

Link to comment
Share on other sites

12 is long? Selections go to 80.

I don’t know how much DIST goes to, but in the AG this is the least of my concern.

As I explained to you, 24 could be appropriate for BLG66 with long dispersion pattern.

Mirage fanatic !

I7-7700K/ MSI RTX3080/ RAM 64 Go/ SSD / TM Hornet stick-Virpil WarBRD + Virpil CM3 Throttle + MFG Crosswind + Reverb G2.

Flickr gallery: https://www.flickr.com/gp/71068385@N02/728Hbi

Link to comment
Share on other sites

We talk about bombing and designating accuracy without fully investigating fundamental assumptions about some systems. I am assuming that everything else is working properly.

 

First thing I placed 4 objects at N45*4'0'' E033*16'0 on the four corners of a box where each object is at the extreme position before the ME display of coordinate would change to 59'' or 01''. This makes a box 21x30m. This 630 square meter area is all considered that coordinate point, at least by the DCS GUI. I place a 5th vehicle in the center of this box to mark its average position.

 

First question is are these rollover values from 59-00-01'' happening by rounding or truncating? Is this 00'' display happening between 59.500 and 00.499 or between 00.000 and 00.999? We place the Mirage editor waypoint inside the box in different places to give clues.

 

Looking at the L/L PCN output for central but slightly north east shows .01'' instead of .00''. Alternatively putting the waypoint south west of center shows .00'' on the display. This suggests that the DCS GUI values are truncated while the Mirage uses rounding. So the speed boat (vehicles I used) that most accurately represent the point N45*4'0'' E033*16'0 is the one which is as south and west as possible without the (DCS GUI) display digit rolling over.

 

Just for completeness we example what the display shows when rounding up. We put the editor waypoint just SW of the boundary and look at the display. N45*03.100' E033*15.100'. Oops, a formatting mistake for RAZBAM to fix. It should read N45*04.00' E033*16.00' since 100/100ths of a minute is another minute. But formatting goofs aside it's showing a reasonable value.

 

We move the waypoint around and check its display to ensure that the precision of the point is different than the display granularity. Indeed changes of ~3m seem visible which is much more fine grain than what can either be displayed on the PCN or manually entered. That's normal for these kinds of systems, accepting more decimal places of precision for cartridge entry than cockpit entry.

 

Small text because it is not important for the topic.

attachment.php?attachmentid=190260&stc=1&d=1531984529

 

Then we move on to checking how the cross symbol is displayed at different ranges. The maximum display range is 10nm at which point the location is superimposed on the lowest extent of the 12 o'clock segment of the cross, a display error of a few mils. While it is practically impossible to tell as the center and "bottom of upper tic" describe less separated places it appears this relationship holds all the way to zero range. No change is noticeable in cross display positioning while closing from 10 to 0 nm. Maybe it happens at 0.2 or 0.1nm but at any useful range it's "bottom of upper tic plus about a thickness of line."

 

Now we try CCRP designate cross instead of navigation cross. It can't be assumed that our designated cross is positioned or displayed correctly either. Different designating behavior must be checked by getting in close and checking zero-range cross positioning.

 

One technique is to designate when aligned with the cross for the navigation waypoint. The cross will shift visually not at all. If the designation and display errors are equal and opposite then designating in this way should produce a point equal to the waypoint at least a direction along a line of sight.

 

And there is also the issue of radar ranging. Using the *.* km readout on the HUD it appears the range is equal to the point somewhere in the upper half of the diamond, above the central pipper dot in the empty upper triangular area. It appears to be the same location as the 4-segment cross symbol when the two symbols are superimposed.

 

After much careful observation I think I've found the display error for 4-segment cross and pipper error for diamond symbol in terms of correlation with the true displayed point or captured vector. It's not the correct spot but slightly elevated the same amount in both symbols. If symbols are 20mil tall then I think point is displaced ~4mil above center in both cases.

 

What comes next after we can designate points properly is examining CCRP accuracy against well designated points.

Link to comment
Share on other sites

  • Recently Browsing   0 members

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