What do we know about the Longbow FCR Fire Control Radar?
The Longbow radar system is the mast mounted dome structure, easily observable (the same dome is also used in the Longbow UTA system for controlling UAVs but for the rest of this entry we'll assume it's housing the FCR) .
The FCR antenna has a mechanical offset arrangement but electronically scans a wedge. It has two primary modes of operation, ground tracking and air search with a number of variations for ground. Other snippets relating to ground modes can be found here.. http://www.voodoo-world.cz/ah64/ah64dl.html
The range for ground tracking mode is fixed at 8km and air search mode is I understand to be half that (inverse square law of radio wave propagation).
Janes Longbow was my bible for a while but clearly the 25km range settings on the radar are an interesting estimation of capability.
Combat-Helo will feature just the AIR and GTM mode and maybe an RMAP mode later if I can mock up something that looks reasonable.
To pick up on ric's comment...
BTW, I remember that when playing both Jane's Longbow 2 and modded (more realistic) EECH that when we lock a target in the FCR the type name of that target ("M1 Abrams" for example) appeared in a upper right display (I forgot that display's name). If this is what happens in real life than there must be some sort of database that stores the radar signatures for all known types of targets. What remains to be confirmed is if this feature (in Jane's Longbow 2 and EECH) is realistic or not?
The upfront display showing the target ID was totally, 100% a game conceit. For which I'm partly responsible for persisting. I spent a lot of time researching for the official EECH game manual and on occasion suggested how to blend authenticity with game mechanics. Remember at the time the bible on the subject was the seminal Janes branded Longbow, so it did share some features. They helped present important information to the player nothing more.
Again it's speculative, but I'm guessing the FCR simply looks at the size of the radar return and estimates a tonnage, then looks for generic vehicle feature returns such as wheels/barrels/turrets etc. Then it compares the feature and displacement returns with a database of generic vehicle types and provides an estimation of what it is.
If the FCR could identify the difference between say, an M1A1 and a T-72, then you'd have the basis of an IFF system. I'm sure the FCR page on the MPD would display different symbology for the two vehicles, or better still, a label, instead of just the generic H symbol for both.
There's a lot of problems with this. Labels are BAD things to have in small letters in a vibrating cockpit. Difficult to read.
I'm a systems guy so I'm in my element here. I built my first home computer at the age of 12 before my school had one. Then at 15 I built a weather satellite receiver complete with software so I could see my country from space. Making boxes talk to each other is something I had fun with at an early age, certainly my parents didn't know what I was up to and since I got teased at school for being a 'professor' I learned to play dumb early on.
With radar, the key to pulling out object details is wavelength, this also limits range and penetration.
Millimetric radar is a good frequency as it can pick out small detail, it's used (for example) at airports for foreign object detection, it can pick out moving objects from the background, sense cloud, rain, fog for weather radar applications. It was also why I wanted a tree/vegetation system capable of collisions over a large distance (to attenuate signal returns realistically).
Inverse square law of wave propagation says energy dissipates with range quite rapidly. With MMW (millimetre wave) radar you need less energy, however atmosphere and terrain adds scattering from water and dust in into the mix and this works in BOTH directions. Different frequencies give different penetration of atmospheric conditions.
Here's a page reference to a book on the subject with a study on medium and freq.
Keep in mind that a lot of signal processing is required because the signal return contains A LOT of information. It's not a black and white picture where you can see a turret, or a wheel. It's a sea of fluctuations that contain everything in-between.
Here you have a radar supplying a stream of data to a frame store.
Just picture what it's doing for a second. An antenna beam sweeps left to right, right to left, at different elevations sending signals returned from backscatter, dust, rocks, metal, walls. Everything without pause.
So you have a frame buffer with a lot of raw data, what happens to it?
A computer running software will filter out a lot of the unwanted bits. Always lagging behind the radar feed. It will search through the frame buffer looking for tell-tales that might suggest that part of the buffer is a structure or has been absorbed by rain, or hit a hard metal entity. Such indicators would come from a list or database, it might be a collection of peaks that in a certain combination like the chemical signatures contained in light. Whatever the format you would have *a clue*. Something software can look more closely at.
Combine it with a number of other clues, you would know the signal strength, the distance, angle, from which you can inference movement, is this a strong metallic object? How tall? Peaks would indicate structure, a combination would be a crib into structure type. Relative height of peaks might yield orientation. No one thing would give you an answer but in combination over seconds of processing you're in a position to generalise IF you have a key. And that key would come from known vehicles.
( I digress: Remember Airwolf's epileptic fit inducing target database search? What was quite funny in that show was that Airwolf would often identify the target incorrectly.)
By simple implication of the physical arrangement and description of function of these kinds of radar systems, you can deduce there is some database used to flag RCS returns as "returns of interest". I don't know if that's a real term as I just made it up, it could equally work in banking.
While it would be possible to include cribs for 'technicals' I'm guessing it would require an expensive engineering program to do this, as a programmer myself such specialist updates can be quite expensive.
But there are inherent dangers in expanding such databases. After all, a civilian vehicle with a large metallic load might conceivably exhibit a threat signature. From a simple back of the envelope cost vs risk factor, I wouldn't authorise cheques for such a program especially in the light of the development of more important upgrades.
I can see you
The current MTADS/TEDEC Arrowhead system yields much improved visual imaging at higher resolution at greater ranges. Imaging can show heat from power lines, people and vehicles. These are much more beneficial in terms of reducing crew risk and collateral damage.
Engagement doctrine usually requires *visual identification* so any tools such as auto classification are simply that, tools. Crews are not button pushing monkeys they are trained to use *all* the tools available to them and communicate with other elements. Professionals.
Last night while developing code to aggregate sensors for the game...this involves making units share an AABB or axis aligned bounding box, which is the sum total of the groups 'awareness' volumes. I discovered the scan volume for the ground radar maximum sweep is the same as the scan volume for air radar. Or so it is in Combat-Helo.
This shared group sensor volume is part of a culling process that occurs over time. If an entity enters this volume, it does not mean it is seen by the group. It only gets added to a list which is later checked for angle and visual line of sight (if applicable). I also take into account how long an object is sighted and this 'confidence' value decays over time. This also deals with entities tested if they happen to pass behind single trees, they don't get removed from the list unless they decay 100%.
Group sensor volume checks are staggered in a fashion similar to how you process cellular automata sand games, not all are processed every single frame but instead are cascaded and prioritised. This way, the number of units with active sensors should scale it up so you can have a rich real-time battlefield of emitters and receivers.
Friend or Foe?
If you look at photos of the Apache flight controls you can just make out the FCR mode selector. The 360 Apple Quicktime cockpit tour of the Mk1 Apache provided by the MoD is where we took our cockpit images. Mason Electric had a PDF brochure of the hand grips but I can't find a working link.
The Apache FCR has multiple modes which I think one was asked about recently...RMAP is a rectangular version of the FCR aids the pilot by adding vertical seperation by arranging tracks in a rectangular format. And probably has a zoom feature too like the fore mentioned F15 ground radar. This was the only FCR mode I was adding for time reasons and I'll create my version of RMAP later.
The FCR as presented in Combat-Helo does come with a FoF mode for rookie gamers (everything colour coded). It's a total fabrication but I do endeavour to add gaming elements for the new to simulation crowd, here it is...
|FoF mode active on my test range|
Tell me lies, tell me sweet little lies
I'm going to have a little soapbox time since it touches upon some of the above and thanks to a Discovery Channel programme about the Westland Merlin helicopter, a possible lack of hubris with these kinds of technologies.
The issue I have with auto classification/fof assignment in the digital space is seemingly little to no safeguard. Once software has made a decision about a flagged entity and this is passed though a network there's little time or incentive to backtrack. With databases there's always a trail so you can follow all transactions but often they are slow and difficult to get at.
Tests show people are more likely to trust information from a computer. It's on the computer and computers know more than you do, they don't have emotions, ambition, they just take cold hard data, run programs and tell you what you want. They they can't lie.
Let me tell you a story. Actually a story about a story.
Michael Crichton wrote a book about a dinosaur theme park and like many of his novels featured a theme park where technology is out of control. OK that's a novel turned Hollywood movie franchise, what has that got to do with anything? What elevates Jurassic Park in the sub-genre of "technology gone bad" was the well observed suggestion (and examples are given in the novel) that technology is most dangerous when it gives us the illusion of control. Jurassic Park the novel (not the movie) warns us that computers can deliver perfectly solid 100% accurate information and still lie.
Let me tell you a real story where this happened (but still kind of Dinosaur related).
In 2005 at a Texas oil refinery operated by BP, 15 oil workers were killed when a unit overflowed and exploded. The computers at the time happily reported the fluid level was at the top of the sensor just three meters high in the tank...in fact the fluid level was way above above sensor near the top of the tank, overflowing down a gas vent pipe, past 3 pressure valves, into and filling up another tank where it spewed out into the open air where the highly volatile liquid landed and ignited on a nearby truck. Massive explosion, resulting in loss of life. The sensor gauge was accurate, the computer displayed the level as recorded without any indication of danger.
(Dinosaurs = oil, yes? In case the link wasn't clear.)
Russian Helicopter Radar
A final note about the Russian use of ground radar on their helicopters.
The Russian Mi-28N was said to be equipped with both millimetric and centimetric radar which added to weight and complexity. The centimetric FH-01 was housed in a radome similar to the Longbow and mast mounted on a Ka-50-N "Nochnoy" (night).
I had some photos from a Paris air show showing what was probably a mock-up of the two radars, if I find them I'll post them here.