It’s not as simple as just being 20% at 100 km range. The accuracy depends on the amount of jitter and can be as good as 7-8% at 100 km range.
Spoiler
The fact the document says “accuracies of better than 20% can be expected” would suggest they expect jitter to be less than 300 µrad.
So if we assume a jitter of 300 µrad then according to the graph the ranging accuracy would be about 7.5% at 40 km, meaning the calculated range would be within 3 km of the true range. I have a primary source stating that AMRAAM should be able to successfully detect a 2m2 target so long as it is not displaced by more than 4 km from where the missile expects to see it. We can therefore reasonably conclude that the ranging data provided by PIRATE is accurate enough for AMRAAM guidance at 40 km, and likely some amount beyond.
For comparison sake the Rafale’s laser range finder apparently has a maximum range of 40 km.
The document comes from the early 1990s and isn’t even talking about PIRATE for a start. It’s about a technology demonstrator program that PIRATE was based on. It is entirely possible that further development work was completed in the 15 or so years between the paper being written and PIRATE entering service. As well as in the 17 years between PIRATE entering service and the present day.
But then again does it even need disputing given the above?
That’s an interesting graph. I guess the jitters come from small inaccuracies from movements of the target/plane and sensor limitations. Makes me wonder what were the conditions of the range acquisition of the target at 100km. If we stick to that 300urad, it would seem the max usable range to guide the aim 120 would be 40-45km, since above that we’d end up with more than your 4km leaway for the AIM120.
Interesting, I’ll have to find where that range comes from again.
But then again, as you say it so well, one of my main point about that mechanic is the fact that the plane needs to maneuver before getting a range. If the missile required guidance during its entire flight path, I do have questions on the usability of this mechanic for weapon guidance, since you might want to keep a somewhat accurate range for more significant time period until the missile can acquire the target with its own radar.
For example, it is known for the Russian aircrafts as well as the rafale that their optical + LRF systems can provide such guidance, but aside from these few informations about the kinematic ranging of the PIRATE, no informations actually hint towards the system being able to guide weaponry (only about slaving their sensors)
For a 40km shot that would only be ~18km of travel before pitbull. Say its averaging at a lower speed of mach 2.5 thats only some 20~ seconds of time PIRATE would need to provide guidance data.
Also if we assume head on attack, the jitter would likely be at its lowest. So the ranging data would be more accurate, target is unlikely to defend until pitbull and after that the PIRATE data is of no use.
Mach 2.5 would be arguably a bit low, so let’s say 15s guidance, which is still quite significant imp. It would require the plane to travel in a mostly predictable way for this period of time
I was under the impression that the ranging was more precise when flying at an angle to the target, hence the need for the maneuvering. But I haven’t read the whole paper presented by flame, so I can’t really comment on that
Might be the case I’ll have to read it again to be sure I’m not talking out my arse, but I was thinking intuitively, if the baring is largely static, I would assume that the jitter would be lower an as a result the error rate would be lower, and higher angular velocity relative to the EFT would result is higher jitter.
Well, maybe there’s a trade in bearing and jitter. My belief if that the algorithm works by sensing the change in bearing of a target in a certain time frame getting 1 (angular) vector, with the maneuver needed to get a second vector, and thus triangulating the position of the target. The jitter being a result of the inaccuracies of the system, and movement of both the plane and the target. In that sense it would make sense that with larger overall bearing trajectories, the triangulation would be more precise. But I might be completely wrong.
I wonder how much of that is about how they calculate the weight (e.g. Whether they calculate the weight of the computers and cooling system etc with it or not)
The OSF features both the IRST and the TV camera, and the IRST ball is installed on a fully rotating system, while the PIRATE has an internal pivot but is more limited in its total swivel capability (but actually no, I think I got confused). The OSF is also plug and play with those total 87kg, with the processing/compute system for both the IRST and TV channel installed.
It might be the case that the PIRATE weight is just for the sensor and not the computing system (but you might know this better than I do), so it might be a bit biased to compare just those 2 values indeed.
I don’t know anything about the OLS so I won’t comment on that
Yes, looks like that value was only for the sensor head. I don’t know why this value was so easy to find while that 60km figure was hidden in an Italian brochure
One of the brochures has it at 48Kg, but unsure if that was just a typo.
Spoiler
48Kg
8Kg
Systems like OSF as you said is one complete drop in unit, the processing power included for both optics. PIRATE system weight appears to just be the sensor head, likely the compute element is done by the EFT’s own systems.
Also here’s another slightly different angle to the sensor head;
Maybe the 48kg and 60kg are 2 different variants ?
Also, if the computing is done by a different system, it makes me wonder how plug and play it actually is. Thinking about German typhoons specifically. Since they don’t use the IRST, could it be that it the jets would need a significant retrofit to install the rest of the necessary equipment beside the sensor block ? Or is it already installed and just « dead weight » ?
If it makes use of the same systems that handle the CAPTOR-M/E, the DASS, etc. Then it wouldnt be dead wieght and you could be relatively plug and play. I guess the main thing required might just be firmware.
There’s definitely a system that handles all the data feeds and shares them where they need to be shared, but usually there are some initial computing/filtering/digitalizing the output etc… module that then send that information to the central module. From the size of the Pirate in the pictures above, I’m not sure this is handled directly on device (like it is for the OSF).
Maybe it’s part of said central module and raw data from the IRST is sent directly to it but just isn’t used by the German. It’s probably only a few kilos so not much « dead weight » but definitely makes their variant more expensive for nothing
Unless those internal modules normally used for handling Pirate can be re-tasked for something else and give the CAPTOR-M a little more processing power or something.
A lot of possiblities. As it stands anyway, Im fairly certain the German Typhoons have a ballast in place of the Pirate as the F-B-W would be off-balanced without, so either way, in terms of weight, there isnt any difference between German and Italian Typhoons. They just dont have the maintenance cost of the PIRATE and the slightly less drag
and Britain was considering not having a gun iirc, but again would have needed a ballast that would have cost more than just leaving the gun (I’ll need flame to double check whether im remembering that fact correctly or not)
I have numerous secondary references to PIRATE getting upgraded, including my recent FOI confirmed the latest version of the RAF’s doc on PIRATE was from Jan 2025.
So any information we have is either mixed for various versions or just out of date.
Yeah, so it’s similar to the OSF for the rafale. We do have the names of the various variants, but often times sources will just state « OSF » and it makes things harder to differentiate in their capabilities, especially when the second iteration of the OSF did not feature the IRST, but apparently was still somehow capable of using its TV sensor as a basic IRST.
