Manual Radar DO

[Frederf]

I've been trying this new feature and while it is not complete it is certainly interesting. Perhaps this is a thread which can be dedicated to discussing it. The following is a combination of how it is currently, how it may be after some fixes, and some estimations on how the whole thing is supposed to work.

 

The purpose of the system is to generate an artificial radar display object based on pilot inputs of particular numerical values. The benefit of such a displayed object is that it makes easier intercept of a notional target without reference to ownship radar either due to inability of the radar or the desire to remain undetected. Probably this system was intended to be delivered automated information by ground controller datalink and this manual entry was a backup. Interface is by the eight switches on each side of the VTB.

 

[TABLE=head]Switch|Symbol|Value|Min|Max|Step|Up Action|Down Action

DEB/FIN|ΔT|Time since, s|0|>4000|1|Begin new entry|Commit entry

-|N|Reference point|00|20|1|Increase|Decrease

-|ρ|Range, nm|000|999|1|Increase|Decrease|

-|θ|Bearing, °T|000|358|2|Increase/Erase|Decrease/Erase|

-|C|Track, °T|000|355|5|Increase|Decrease|

-|Z|Altitude x100ft|000|500|20|Increase|Decrease|

-|M|Mach|0|3.0|0.1|Increase|Decrease|

-|T|Time since report, m.ss|0.00|60.00|15s|Increase|Decrease|

[/TABLE]

 

A report received may be something like this: "Target bullseye 214 224 track 095 altitude 32 mach 1.4 age 8.5 minutes." This would correspond to an entry of:

N 05 / ρ 212 / θ 225 / C 095 / Z 320 / M 1.4 / T 8.30

 

Note that it is common for heading and track of targets to be used interchangeably and for target track to be rounded to the nearest 5 as part of intercept control. It's a little surprising that bearing from reference point is not allowed to be every degree although the amount of resolution in the difference is heavily dependent on the ranges involved. If target is 600nm from the reference point a degree is 10nm.

 

The first thing you notice when inputting these values is that you must flick the switch up and down repeatedly for every increment. Entering in 100nm rho is quite a chore! It's likely a practical system would have a feature of rapid increment by holding the switch.

 

When the DEB/FIN switch is pressed downward the object is saved into memory and displayed on the VTB. Critically I estimate that the object is displayed at a position consistent with its entered position evolved forward in time based on the some of delta-T and the report age. E.g. if target is entered as at a certain position and ΔT = 090 and T = 8.30 that the system will display the object 10 minutes away from the entered position. After all the FIN switch was pressed 8.5 minutes after the report was taken and 1.5 minutes after the DEB switch was pressed. Currently I don't think that is the case.

 

Even further I estimate that the displayed object on the VTB should change in estimated position over time. For example if the information entered is exactly right the displayed object should represent the actual object's position indefinitely with only one entry. Currently this is not what happens, an object entered as running directly away from you at greater than your speed will be overrun like a pin stuck in a map.

 

When the data entry yellow text is not visible flicking the theta switch up or down will erase the saved object as indicated by the yellow "RAZ" text on the VTB.

 

There is a question about what should be the initialized values for the 8 numbers on the next entry. Presumably the system would be designed on the assumption that you are inputting better data from newer reports as the intercept continues.

 

ΔT should start at 000 as that is a counter to compensate for the time of pilot data entry. N should be as previous as this report is probably using the same reference waypoint as the last. Range and bearing should probably be the current estimated position of the target as it has dynamically evolved previously. E.g. if 100nm 100° was entered and ten minutes has elapsed the target may be expected to be at 080nm 112°. This minimizes the need for alteration. C & Z & M should remain as previously entered as there is no reason to expect the target has changed these. T should probably default to either zero or last entered. The timeliness of each report is probably similar but resetting to zero might also be desirable.

 

It is noted that repeated exit and entry does some weird things to these values like the age (T) constantly increasing, Mach getting faster, and so on. That will probably clean up during development. I noticed that C values can get away from the increments of 5 degrees, e.g. 22 and inc/dec will give 17 or 27 until you get to 000 which forces it back to the "grid".

 

Anyway this is an interesting feature and with polish it could become quite fun and useful. Have a good night.

[myHelljumper]

You got it all in a clear manner, thank you for this post.

 

I hope the devs will finish/fix this feature as it is a very unique and interesting one while not being extremely useful.

 

As you speculated, this system was supposed to be also feed information from some proprietary datalink between the aircraft and GCI ground station, the PCA "TAF" button and IDN "TEL" position were supposed to be used for this. IIRC it was never implemented in the real plane.

Edited September 3, 2020 by myHelljumper

[jojo]

You got it all in a clear manner, thank you for this post.

 

I hope the devs will finish/fix this feature as it is a very unique and interesting one while not being extremely useful.

 

As you speculated, this system was supposed to be also feed information from some proprietary datalink between the aircraft and GCI ground station, the PCA "TAF" button and IDN "TEL" position were supposed to be used for this. IIRC it was never implemented in the real plane.

 

Not use very often: probably.

Never implemented: I wouldn’t be so sure.:music_whistling:

[myHelljumper]

Not use very often: probably.

Never implemented: I wouldn’t be so sure.:music_whistling:

 

Are you talking about the TAF ?

 

That's interesting....

[jojo]

Are you talking about the TAF ?

 

That's interesting....

 

I saw some picture of TAF panel inside Mirage 2000-5F cockpit.

So if it was never used on Mirage 2000C, why still test it on Mirage 2000-5F ?

Still I'm not sure of anything on that matter...

 

Now Mirage 2000-5F have been upgraded with Link 16.

[Ramsay]

I saw some picture of TAF panel inside Mirage 2000-5F cockpit.

So if it was never used on Mirage 2000C, why still test it on Mirage 2000-5F ?

Still I'm not sure of anything on that matter...

 

Perhaps the 2000-5 picture was of an upgraded 2000C ?

 

Domestically, Dassault needed an order from the AdA to help promote foreign sales and, in 1993, the AdA decided to upgrade 37 of their existing Mirage 2000s to the 2000-5 specification as a stopgap before the arrival of the Rafale in AdA service.

 

The upgraded aircraft were redesignated Mirage 2000-5F, and became operational in 2000. They retained the old countermeasures system with the Serval/Sabre/Spirale units and did not receive the ICMS 2 system.

 

https://en.wikipedia.org/wiki/Dassault_Mirage_2000

[jojo]

Perhaps the 2000-5 picture was of an upgraded 2000C ?

 

https://en.wikipedia.org/wiki/Dassault_Mirage_2000

 

Off course since all French since all French Mirage 2000-5F are upgraded Mirage 2000C. RDI.

But there is no chance that the equipment was just left there. The cockpit and weapon system are totally new. This was a factory modification with a rewiring of the aircraft.

 

And "Mirage 2000-5F" is the specific designation for French Mirage 2000-5 :smilewink: