Using the INS for precission bombing

[Zeus67]

I created a similar mission to the one used by Zaelu. I found some bugs but none related to his main complain.

 

 

 

[Zeus67]

 

 

[Zeus67]

 

 

[Zeus67]

Bugs found and to be killed:

 

- Radar antenna does not move to its intended elevation for position update.

- PCN rounds the value of Rho (distance) to an integer.

 

I also found a difference between the map in the ME and the map in DCS. When setting up Waypoint 3 I centered it on the TACAN station building as per the ME map, yet when I arrived at the waypoint I saw that the cross was displaced at least 100 meters from the building in the sim map. Since the coordinates did not change, that means that the ME map and the DCS map have a coordinate difference. This problem merits more testing but it is quite possible that the map builders made a mistake on either the ME or the DCS maps. Not sure if that is the case and I am not calling it for now.

Edited October 19, 2016 by Zeus67

[jojo]

Even with INS drift off in option menu, if I place a waypoint on an air base control tower, in the sim the + won't be exactly in place.

[Zeus67]

Flew the mission a second time. This time I got a bullseye. Hit the span dead center. No visual effect on the bridge.

 

[Frederf]

The inability to enter decimal numbers into the PCN (except lat/long) has been reported a few times. Rho, theta, delta-km all need better than integer resolution to be useful. What would be a nice feature apart from being able to enter in the full range of values those slots can take would be to autopopulate the BAD data based on ME data (e.g. if task was bomb and it has an offset triangle on a string).

 

Investigating the ME coordinate readout it appears that the coordinate readout doesn't round it truncates. Assuming the L/L blue lines are on each minute the readout is 59'' below the line and 00'' on and above the line.

 

Reexamining BLD's location more precisely the center of BLD is 72 feet north of 35 59 42''. Taking the latitude spacing of 30.9m per 1'' is 0.71''. BLD's latitude is more accurately 35 59 42.7''.

 

BLD has been mercifully been placed about 3 feet east of 114 51 49'' or 0.04'' (longitude spacing being 25.0m) which when rounded to the nearest 0.1'' is 49.0''.

 

Now we convert to the Mirage's format and observe the effects. The Mirage's coordinates with an additional decimal place is 35 59 42.712', 114 51 49.816'. Notice this is different than what was attained a few posts above and my own previous look.

 

Switch to runtime and check this again in F10. The first thing we notice is that BLD is positioned somewhere between 44'' and 45'' in latitude. That's well wrong compared to the ME saying it was between 42'' and 43''. The measuring tool is only accurate to 0.01+-0.005nm or 18.52+-9.26m. Instead the X/Z coordinate option is used to subdivide the arcsecond. 44'' = ...462 45'' = ...430 BLD at ...440. This puts BLD at 44 and 22/32nds'' or 44.6875 or 44.7''. The F10 map is either exactly or approximately 2'' off in latitude at this particular location. That's a concern but not an insurmountable one.

 

Next check a cheated perfect INS against the runtime coordinates. First it's seen the longitude doesn't match F2. 114 56.30 on INS corresponds to 114 56.283. .29 to same, .28 to .266. Just as the seconds tick down to 00'' (potentially 00.99999'' truncated) the PCN shows 0.02'. This follows a logic of taking the untruncated seconds and converting to the nearest 0.01'. For example the latitude displays 17'' which means it's somewhere between 17'' and 17.9999999'' which correspond to 0.283333' and 0.30000'. The displayed 0.29' is not inconsistent with this range.

 

Since the Mirage uses 1/100th of minute resolution (displayed, calculation might use more) and the F2/F10 displays are at most 1/60th minute resolution (unless you use MGRS or X-Z grid). Even though you can get 0.001' displayed you'll find they are always the decimal equivalents (trunc) of the 1:60 steps.

 

Next we look at what coordinates were auto-loaded into the PCN by as precisely as possible putting the waypoint over BLD. Mine came back with 35 59.75', 114 51.82'. This doesn't match the ME coordinates but it's a possible version of the runtime coordinates. I found the BLD to be ~44.69'' which is 74.48'. The Mirage has chosen to convert this point into the northern of the two options or ~15m too north. Had it chosen the southern one it would be almost the same distance too far south by 15m.

 

I then go to fly over the waypoint and to my surprise it's exactly on the BLD building. It didn't pick .75' or .74'. It picked .745 or even more precise. The auto-populated values in the INS are more precise than what is being displayed. When I change 35 59 75 to 35 59 75 the symbol moves. The display was exactly the same but entering what was displayed wasn't the same value.

 

Flying over BLD as exactly as possible I get the X-Z grid location: X-0042441 Z-00001426. This appears to be a 1m grid. The INS didn't switch from .74 to .75 displayed until ~15m beyond the center of the building which is consistent with earlier findings.

[Zeus67]

The inability to enter decimal numbers into the PCN (except lat/long) has been reported a few times. Rho, theta, delta-km all need better than integer resolution to be useful. What would be a nice feature apart from being able to enter in the full range of values those slots can take would be to autopopulate the BAD data based on ME data (e.g. if task was bomb and it has an offset triangle on a string).

 

Investigating the ME coordinate readout it appears that the coordinate readout doesn't round it truncates. Assuming the L/L blue lines are on each minute the readout is 59'' below the line and 00'' on and above the line.

 

Reexamining BLD's location more precisely the center of BLD is 72 feet north of 35 59 42''. Taking the latitude spacing of 30.9m per 1'' is 0.71''. BLD's latitude is more accurately 35 59 42.7''.

 

BLD has been mercifully been placed about 3 feet east of 114 51 49'' or 0.04'' (longitude spacing being 25.0m) which when rounded to the nearest 0.1'' is 49.0''.

 

Now we convert to the Mirage's format and observe the effects. The Mirage's coordinates with an additional decimal place is 35 59 42.712', 114 51 49.816'. Notice this is different than what was attained a few posts above and my own previous look.

 

Switch to runtime and check this again in F10. The first thing we notice is that BLD is positioned somewhere between 44'' and 45'' in latitude. That's well wrong compared to the ME saying it was between 42'' and 43''. The measuring tool is only accurate to 0.01+-0.005nm or 18.52+-9.26m. Instead the X/Z coordinate option is used to subdivide the arcsecond. 44'' = ...462 45'' = ...430 BLD at ...440. This puts BLD at 44 and 22/32nds'' or 44.6875 or 44.7''. The F10 map is either exactly or approximately 2'' off in latitude at this particular location. That's a concern but not an insurmountable one.

 

Next check a cheated perfect INS against the runtime coordinates. First it's seen the longitude doesn't match F2. 114 56.30 on INS corresponds to 114 56.283. .29 to same, .28 to .266. Just as the seconds tick down to 00'' (potentially 00.99999'' truncated) the PCN shows 0.02'. This follows a logic of taking the untruncated seconds and converting to the nearest 0.01'. For example the latitude displays 17'' which means it's somewhere between 17'' and 17.9999999'' which correspond to 0.283333' and 0.30000'. The displayed 0.29' is not inconsistent with this range.

 

Since the Mirage uses 1/100th of minute resolution (displayed, calculation might use more) and the F2/F10 displays are at most 1/60th minute resolution (unless you use MGRS or X-Z grid). Even though you can get 0.001' displayed you'll find they are always the decimal equivalents (trunc) of the 1:60 steps.

 

Next we look at what coordinates were auto-loaded into the PCN by as precisely as possible putting the waypoint over BLD. Mine came back with 35 59.75', 114 51.82'. This doesn't match the ME coordinates but it's a possible version of the runtime coordinates. I found the BLD to be ~44.69'' which is 74.48'. The Mirage has chosen to convert this point into the northern of the two options or ~15m too north. Had it chosen the southern one it would be almost the same distance too far south by 15m.

 

I then go to fly over the waypoint and to my surprise it's exactly on the BLD building. It didn't pick .75' or .74'. It picked .745 or even more precise. The auto-populated values in the INS are more precise than what is being displayed. When I change 35 59 75 to 35 59 75 the symbol moves. The display was exactly the same but entering what was displayed wasn't the same value.

 

Flying over BLD as exactly as possible I get the X-Z grid location: X-0042441 Z-00001426. This appears to be a 1m grid. The INS didn't switch from .74 to .75 displayed until ~15m beyond the center of the building which is consistent with earlier findings.

 

The offset between the ME map and the DCS map seems to be an artifact of rounding errors. Similar to the 1 arc-second error when entering the initial position when doing an INS alignment. This error comes from the way DCS itself convert geographical positions from a sphere into a flat map. ED has tried and cannot get rid of it.

 

Of course, flight plan coordinates are more precise than manually entered one. Because they are stored to the last decimal while the others are rounded and lose precision.

 

As much as I'd love to enter 3 decimals for Lat/Lon, I don't have the screen real estate for the LON values. Even the real device does not have the real estate for 3 decimals and that is why it only uses 2.

[Azrayen]

The inability to enter decimal numbers into the PCN (except lat/long) has been reported a few times. Rho, theta, delta-km all need better than integer resolution to be useful.

We should indeed be able to enter (and see + use) one decimal through the PCN. Not more.

2 decimals through the mission preparation + datacard system (aka ME in DCS).

As Zeus said, it's a "display real estate" issue :)

[zaelu]

Bugs found and to be killed:

 

- Radar antenna does not move to its intended elevation for position update.

 

 

Is this the reason the Diamond stays up?

 

Does this modifies in any way the precision of Updating?

 

Bugs found and to be killed:

- PCN rounds the value of Rho (distance) to an integer.

 

 

My solution was to move the targets at exactly 6 n-miles.

 

Then I observed that the Mission editor map and F10 Map had a difference of one degree when measuring the line from BUT to BAD

Edited October 20, 2016 by zaelu

[Zeus67]

We should indeed be able to enter (and see + use) one decimal through the PCN. Not more.

2 decimals through the mission preparation + datacard system (aka ME in DCS).

As Zeus said, it's a "display real estate" issue :)

 

Input parameters that use integers: ΔL/ΔG, ALT, ΔALT.

Input parameters that use one decimal: CP/PD, RD, θ, DEC.

Input parameters that use two decimals: L/G, TD, ρ.

[Zeus67]

Is this the reason the Diamond stays up?

Yes. It is fixed in development.

 

Does this modifies in any way the precision of Updating?

I'm checking.

 

My solution was to move the targets at exactly 6 n-miles.

 

Then I observed that the Mission editor map and F10 Map had a difference of one degree when measuring the line from BUT to BAD

I did not have to move the target distance (Rho) but I did find out that if I manually modified the Lat/Lon values for the waypoint so they were over the TACAN station that the BAD would be moved laterally and away from the bridge. I guess that is the reason why.

 

I did not have to do any target movement. All I had to do was calculate the approximate ΔAlt for the bridge span. The ME and F10 maps return the terrain altitude for the river not the span, that is why I measured both bridge shoulders and used them for the span. In my second run I did the bullseye with the bomb hitting the center of the span instead of one of the pillars. Unfortunately the bridge is not destructible and some areas do not have a collision model.

 

Bottom line, there are a lot of conversion problems between maps. DCS use a flat map with coordinates starting from the center. Unfortunately we don't. We use a geographical, in other words spherical, map to plot nav points. DCS loses precision each time it converts from the flat map to the spherical one and viceversa. As far as I know this problem will remain with us until ED changes the maps from a plane to a sphere, but the problems involved with that means that the conversion will take some time.

[zaelu]

Zeus

 

I observed something. After I modified my mission to start the plane Hot on ramp not Cold rampstart, the starting coordinates were far far better than before. The INS was aligned already obviously.

Then when I arrived at IP to update my diamond was not wrong at the top but down in the HUD.

 

 

Also although the cross was off after I did the update the BAD was pretty much dead on target. (I heave two groups, one on the bridge, the other where the cross is)

 

 

The single GBU16 bomb fell badly though, way over the target. Also once during the attack run the steering cues were glitching telling me abruptly to bank 90°.

[Frederf]

Of course, flight plan coordinates are more precise than manually entered one. Because they are stored to the last decimal while the others are rounded and lose precision.

 

But should they be?

 

Can the real data transfer tape supply the INS with waypoint data with greater precision than can be displayed or manually entered? I'm trying to narrow down if this is a realistic discrepancy between the ability to tape-enter or manually-enter data or if it is a fictional distinction because the auto-populated is over-modeled.

 

When the script runs that shoves ME waypoint positions into the INS databanks does it trim the precision the DCS engine provides down to a known realistic finite capability of the Mirage or does it store that number in its fully glory?

 

Come to think about it I don't even know if the Mirage 2000C uses a data cartridge system at all. Does it?

 

---

 

As for the ME-F10 misalignment I don't appreciate the "3D world to 2D" reasoning. Both the ME and F10 are 2D representations of a 3D world. The F10 map is accurate and the ME map isn't. Why can't the ME map do whatever the F10 is doing successfully? The function that relates the 2D map cursor position to the 3D coordinates underneath is some tractable bit of math.

 

It's not RAZBAM's problem I guess. Eagle Dynamics needs to go back and rewrite the formula for how coordinates are translated from map position (and the ruler tool) such that it works as well as it does in the F10 map.

 

I find the F10, 3D world, and Mirage to be in good agreement. The ME not so much.

 

---

 

The resolution of the INS stated values is of no real consequence if the relative BAD displacement is high resolution. If the IP is half way between two possibly held values then when the INS update is done exactly on it the INS be shifted to an in between value and the relative BAD displacement will be correct.

 

How are you supposed to enter decimal values into the PCN? So far I've just been plugging in the digits and assuming the fixed location decimal will take care of itself. Right now that discards the decimal portion and I can't get decimal values into the PCN as they round or trunc to the integer.

[BlaizzMC]

When I enter ρ=4.88Nm in the ins it register ρ=4.00

 

is it normal ?

[Zeus67]

When I enter ρ=4.88Nm in the ins it register ρ=4.00

 

is it normal ?

 

No. That is a bug I am working on right now.

[Azrayen]

Input parameters that use integers: ΔL/ΔG, ALT, ΔALT.

Input parameters that use one decimal: CP/PD, RD, θ, DEC.

Input parameters that use two decimals: L/G, TD, ρ.

Right :)

Thanks for being more precise than I was.

 

But should they be?

Short answer: yes :)

[Zeus67]

Come to think about it I don't even know if the Mirage 2000C uses a data cartridge system at all. Does it?

 

Yes, it does.

It is called the Module d'Insertion de Paramètres MIP. You can see it in the manual. It is located between the PCN Mode selector and the PCN operational mode knobs.

As far as I know, you can even change cartridges in flight.

[Frederf]

OK the pilot cannot manually enter values that the ME can. That does mean that multiplayer clients have no access to those because you know sucks to be them. A multiplayer mission planner has been called for for a while now anyway and that's first party work.

 

However with two distinct tools which aren't currently working to the required degree: INS update and BAD offset it doesn't matter if the BUT coordinates are wrong by a kilometer. Once those two are working properly the pilot entered BUT resolution will be close enough.

[zaelu]

I observed that using ZBI in conjunction with IP makes the diamond to get low. However the effect is the same. BUD is way off. I placed the Waypoint/IP to Groom Lake airfield and the BAD/targets at the end of the runway exactly 3 miles off and only 30 feet lower. but the BAD was way way way off. I killed the Shilka with the guns because dark side took over :D.

 

Also. If you carry 4 bombs... how do you do multiple passes on same BAD? Currently after first release you need to take it from beginning.

[jojo]

IRL, for fighters like F-16 or M-2000 and "dumb bomb", a CEP of 20m (70ft) is considered a good job with direct attack.

 

The "IP CCRP" attack is supposed to be loft profile for stand off purpose. You can say goodbye to your 20m CEP. So you release all your bombs at once to increase hit probability.

 

And if you really want to re-attack, I can't imagine any other way than starting over from IP designation.

[zaelu]

Makes sense jojo. The error I was doing was either not to select to launch all 4 bombs or to space them which meant not all at once release.

 

I tried again once today and after I entered the F10 Map data instead of ME data (basically the angle was not 340° but 339°) I managed to bomb with all 4 Mk82s pretty close (all enemies survived...).

 

If it's realistic behavior I can live with it. Next time I take MK20s.

 

edit

 

I mean this close :D

 

Edited October 22, 2016 by zaelu

[Lorenzo.D]

With this metod i must not push rs and tas on the pca its true?

 

Inviato dal mio ASUS_Z00LD utilizzando Tapatalk

[Frederf]

It doesn't matter if you have TAS and/or RS selected since it doesn't use those sensors.

[jojo]

It doesn't matter if you have TAS and/or RS selected since it doesn't use those sensors.

 

Yes you do. You need a sensor to designate the Initial Point.