You can work it back from any of the values: if you know the FoR and the cant angle of the plate, the required e-scan FoV follows. For the ECRS Mk 0/2, we have a known ±100° FoR and the plate is canted at 30°, therefore the e-scan FoV must be ±70° to cover the whole FoR.
R − A = V, where R is the FoR, A is the cant angle, and V is the e-scan FoV.
So what can we learn from this? All ECRS variants share the same potential 200° FoR, since the repositioner is mounted at 30° on every version, provided the array can scan ±70°. The question then becomes: is the e-scan FoV of the ECRS Mk 1 presently just 120°, or are Hensoldt choosing not to scan the outer 10° each side for power on target reasons? Leonardo UK makes claims of Optimized Max Power on Target in the edges of the FoR, sounds like they did some extra work to make the zone viable that Hensoldt hasn’t or has yet to?
Their claimed 180° FoR does at least tell us the odds are it’s a 120° e-scan right now or, at a minimum, that they aren’t scanning that last 10° for some other technical reason such as the power loss at 70° on E-Scan radars that they haven’t over come yet. Though I do believe they’re getting more help from Leonardo in recent months so maybe the ECRS Mk1 Step 2 fixes this.
This exactly is why this all started.
Hensoldt hardly chooses to do anything.
Leonardo gave ECRS2’s FOR, but not FOV.
Hensoldt gave ECRS1’s FOV, but not FOR (at least the one acceptable by this community).
The conjecture is that FOR = FOV which in ESA’s case isn’t true, by definition and if Leonardo somehow managed to achieve that, it should be well documented and proven prior to accepting it as a fact, as it would be an exception.
Anyway, game works the wrong way and either ECRS2 has FOR200 and somewhat smaller FOV (not gonna get into this now), or ECRS1 has FOR180 (no evidence for that but for the sake of argument), but then can’t have FOV180, but smaller, as neither is MSA.
The game failed consistency test, in this particular case and the other conjecture, that Hensoldt is somehow incapable of differentiating FOV and FOR is also…I mean, cmon.
Yeah, you’re right.
The argument here is that ECRS2 e-scans +/-70 (to the FOR), while ECRS1 scans +/-60, which is normal for that type of the array. IMO, ECRS1 and 2 both have the same FOV, or ECRS2 has a bit better optimized edge, yielding FOV, say, for ECRS1 180, while ECRS2 has, maybe, 182, or so, but still the ECRS1 must have larger FOR than 180.
If GJ wouldn’t budge and insists that FOV = FOR for ESAs, then ECRS1 should also get >FOV180, just like ECRS2, as there is no evidence that ECRS1 has FOR180, apart from conjecture that Hensoldt is stupid.
So, now you want to boil it down to:
Manufacturers of both are lying, ECRS 2 does not cover 200, but 182, while ECRS 1 should have over 180 as nothing other than Manufacturer states it is 180, and the Manufacturer is wrong?
No, exactly the opposite.
Your (and GJ’s) interpretation “ECRS 2 does not cover 200, but 182” is conflating FOR and FOV for ESA which exists in game, but not in the real world, or, if it does, it should be really well documented and explained, as I’m sure many militaries would be interested to lay their hands on it.
This picture explains the issue pretty well and when I remember pointing it to GJ a few years back, they dismissed it. Now we’re having a circus, just as I though. :D
That one can’t conflate MSA’s and ESA’s FOV/FOR relationship and get away with it, which is what GJ did and still does. In WT, APG83 would pickup a target at ~47nm at 60° off bore. The reality is completely different.
you claiming that this radar array is tilted by only 10 degrees? It looks much more tilted to me. I think the field of view (FoV) should be stated as approximately ±120–130°.
Does anybody get random lock with the spice250 in the eurofighter? is it currently bugged? @Morvran It still flicks the TGP lock to random spots even if I turned off the radar.
The whole interplay between PIRATE, radar (TWS) and TGP is completely broken since always on the EF AESAs AFAIK. The broken third- (and first-)person lock-on for all SPICE-250/GBU-53 is just an additional bug.
