PDA

View Full Version : Typhoon cannot talk to F-22


ricardian
22nd Feb 2013, 19:52
Top U.S. Stealth Jet Has to Talk to Allied Planes Over Unsecured Radio (http://www.wired.com/dangerroom/2013/02/incompatible-comms-stealth/)

Courtney Mil
22nd Feb 2013, 19:57
It's an old argument. Link was never a "receive only" option. You have to ransmit to be part of the net. I recall our bomber boys wanting the same thing - so they could get an air picture without emmisions. You can't be positioned in a grid if you're not part of it. Now look what's happened.

BEagle
22nd Feb 2013, 20:15
Link was never a "receive only" option.

Uh... excuse me, Mr. Courtney? That's not entirely accurate....:uhoh:

Lima Juliet
22nd Feb 2013, 20:31
Courtney, ditto BEagle - receive only link is entirely possible.

Canadian Break
22nd Feb 2013, 21:26
Thought you had to transmit the round trip timing message (M1/81?) on L11 and transmit to gain fine sync on L16.

Easy Street
22nd Feb 2013, 22:15
You can't be positioned in a grid if you're not part of it.

My understanding was that if you're not contributing to the net, the kit doesn't need to transmit because it doesn't need to register itself to establish a transmission slot. It just listens to everyone else's messages?

kbrockman
22nd Feb 2013, 22:42
My understanding was that if you're not contributing to the net, the kit doesn't need to transmit because it doesn't need to register itself to establish a transmission slot. It just listens to everyone else's messages?

I think it works a bit like this, every unit estimates its own TQ (Time quality), based on the clock drift, past accuracy of determining NTR (Network Time Reference) which it can do during the time-refinement time in every time slot ,and finally how long ago it did an RTT-exchange.
If any of these three parameters increases the TQ goes down, below a certain TQ threshold or after a certain pre-set amount of timeslots has passed,every unit needs to an RTT exchange which means 2 way communication by definition, so all in all there will inevitably be 2 way (sending/receiving) moments for everyone that uses Link-16.

Could be wrong though, but that's basically how I remember it.

orca
23rd Feb 2013, 00:17
You can most certainly be in the link on receive only. I know a chap, let's call him my brother, who did exactly that just the oher day.

kbrockman
23rd Feb 2013, 00:38
You can most certainly be in the link on receive only. I know a chap, let's call him my brother, who did exactly that just the oher day.

That might be true but after a certain amount of time slots , every Link-16 unit does an automatic RTT, it's nor nearly as big as the actual DATA transfer blocks but it's there nonetheless and it's by nature 2 way communication.

As far as only using it as a receiver, I don't know how long it takes for the TQ to degrade for every different system and how much info you can receive comparing the different methods of data-packaging (standard double pulse -> 4 single pulse).

althenick
23rd Feb 2013, 01:02
I've never realy understood the Yanks myself. I thought it was iust me. Nice to know i'm not alone...

Bevo
23rd Feb 2013, 01:10
There are solutions in work:


The U.S. Air Force says it has successfully tested a classified information transmission technology from two F-22 Raptor 5th generation fighter aircraft to ground stations at the recent Joint Expeditionary Force Experiment (JEFX 08) exercise at Nellis Air Force Base in Nevada and Langley Air Force Base in Virginia with new tactical targeting network technology under development by Rockwell Collins. …….

During the exercise, two Lockheed Martin F-22 Raptors tested a new method for universal F-22 connectivity with an experimental version of the Rockwell Collins' Tactical Targeting Network Technology (TTNT). For the first time F-22 sensor data was down-linked to the Combined Air Operations Center (CAOC) using a tactical network. In a previous test performed as part of JFEX08-2 earlier this year, images were transmitted from an F-22 to an F-16 via a ground based gateway. Through this experiment, the new radio successfully sent classified sensor data to ground stations at Nellis and Langley Air Force Bases, which then relayed the data to airborne F-16s. According to Col. Moulton, the test provided essential support for further development of future. Battlefield Airborne Communications Node ( BACN) assets and a future ground mobile gateway are designed to support joint air and ground operations.
LINK (http://defense-update.com/features/2008/may08/F22_datalink_gateway.htm)

Justanopinion
23rd Feb 2013, 04:00
That might be true but after a certain amount of time slots , every Link-16 unit does an automatic RTT, it's nor nearly as big as the actual DATA transfer blocks but it's there nonetheless and it's by nature 2 way communication.

Can be done
actively = 2 way communication or
passively = not two way communication.

jwcook
23rd Feb 2013, 04:44
Topic title is wrong - The F-22 can't talk to the Typhoon

dervish
23rd Feb 2013, 05:49
IIRC this general problem once resulted in the Italians complaining they couldn't speak to Nimrod. I'm not sure about today, but not so long ago it wasn't policy to have this degree of interoperability. Somewhere, someone will be saying "Not a story, because not a requirement."

jwcook
23rd Feb 2013, 05:55
To be fair no one speaks to Nimrod today.:*

BEagle
23rd Feb 2013, 07:19
Could be wrong though, but that's basically how I remember it.

You describe active fine synchronisation with transmissions enabled.

However, coarse synchronisation also permits data to be received, provided that the user is on the right net with the correct cryptovariables. Transmission is not possible in coarse synchronisation.

If PPLIs are received, fine synchronisation can still be obtained using passive synchronisation; the JU will then be able to contribute in its assigned time slot as soon as the transceiver is switched to active mode.

Link16 is pretty amazing. I recall flying a VC10K3 back across the UK from a North Sea towline 13 years ago with the L16 in receive only mode - and still seeing F3s reported by an E-3D over Cumbria. We didn't lose the SRAP until we were on the final approach at Brize!

Transmitting on the ground certainly used to be prohibited. But fighter crews sitting on high readiness states whilst on exercise could get a lot of SA by using the SRAP to view the antics of their colleagues!

Lima Juliet
23rd Feb 2013, 08:49
BEags - spot on mate.

By the way...

Transmitting on the ground certainly used to be prohibited

No one ever told me that! :p

LJ

ORAC
23rd Feb 2013, 08:49
F-22 has a directional datalink, IFDL, to exchange formation between formation elements. It is not compatible with other data links. It was intended to upgrade the F-22 to be compatible with other platforms, that hasn't been funded (http://www.dodbuzz.com/2011/03/31/f-22s-wont-get-f-35-datalinksyet/).

The F-35 will have a similar directional datalink, MADL (http://en.wikipedia.org/wiki/Multifunction_Advanced_Data_Link), to exchange formation data, which is not L16 compatible.

The only way to integrate these platforms with existing L11/L16/MIDS/L22 platforms is through an ACN (http://en.wikipedia.org/wiki/Battlefield_Airborne_Communications_Node)/ BACN (http://www.northropgrumman.com/Capabilities/BACN/Pages/default.aspx)

In future the F-35 will use SATCOM to link through ground relays to transmit and receive data to be shared with non-stealthy platforms, but that has slipped to the Block 4 software build, and does require a view of a satellite, which is a major concern in the higher latitudes for both Canada (http://www.thearcticinstitute.org/2011/10/3245-canadas-new-f-35-stealth-fighter.html) and Norway. (http://theforeigner.no/pages/news/communications-trouble-for-norway-f-35s/)

Don't have a BACN or a SATCOM system? Too bad........

Lima Juliet
23rd Feb 2013, 08:51
PS - If I recall correctly there was a silent mode that threw up a SIL caption on the JTIDS Control Panel. There was no transmitting going on but I would certainly get the picture.

Lima Juliet
23rd Feb 2013, 08:53
BACN is a cracking piece of kit. I used it a lot in Afghanistan. It used the Global Express as a platform - now there's simething useful we can do with Sentinel!

The first time I used it, it was flying on a WB-57 Canberra!

LJ

Easy Street
23rd Feb 2013, 09:32
Can passive L16 synchronisation also be maintained by use of GPS time as the network master clock?

Courtney Mil
23rd Feb 2013, 09:56
My post was not clear. The point I was making was that that having "receive only" players was never really an option operationally. Whilst we were introducing it, a lot of folk imaginied that they were being asked to carry around a bloody great beacon that would give away their position during their, low-lovel ingress and that they could be full-up players in the net by just receiving.

You've made most of the technical points already concerning synch with the network timing reference. Not being able to transmit in coarse synch means no one else in the package/force/raid/etc can see you and you lose the obvious benefits to air battle management (tactical). Happy to transmit Mode 4, but not contribute to building the RAP was my real issue.

In my opinion, I always pushed for full participation with the option to use Conditional Radio Silence or Polling Mode if required, announcing that in the PPLI. That way, players got fine synch and could still use receive and transmit secure voice whilst in CRS mode and return to Normal Mode when appropriate. In that case F-22 would be able to share data, contribute to the net and transmit voice, which was the OP's original statement.

BEagle
23rd Feb 2013, 11:22
Not being able to transmit in coarse synch means no one else in the package/force/raid/etc can see you and you lose the obvious benefits to air battle management (tactical). Happy to transmit Mode 4, but not contribute to building the RAP was my real issue.

True that you wouldn't be able to send a PPLI or any other messages in coarse synch. However, provided that you were being seen by a suitable surveillance platform and your track was being reported, your position would still be available to other JUs on the net, but not as a PPLI.

Wensleydale
23rd Feb 2013, 11:41
True that you wouldn't be able to send a PPLI or any other messages in coarse
synch. However, provided that you were being seen by a suitable surveillance
platform and your track was being reported, your position would still be
available to other JUs on the net, but not as a PPLI.


One can but hope that your track being reported was friendly! During the Balkans campaign, it was almost expected that any new USN carrier group entering the Adriatic would misidentify tracks by not using the extant ID criteria. We once threw an entire Carrier Battle Group out of Link 11 because they persisted in identifying all non-USN aircraft exiting the AOR as assumed hostile. The problem then was that the ID in the E-3 changed and the incorrect ID was reported out on Link 16 to the defensive caps.

The major problem with L16 is that it tries to be all things to all men. The ID requirements to produce a surveillance RAP are often different to those IDs required by a fighter crew (there was no equivalence between Bandit and Bogie to RAP IDs in the surveillance documents for example and so the E-3 had to bastardise IDs in deployed operations and ensure that the GE did not interfere too much). This was fine when L11/IJMS were being used as the surveillance link, but using L16 for both weapons control and surveillance simultaneously has its own problems (and this without the problems of CAA agreements and time slot allocations). There were also conflicts between naval ID procedures and GE IDs which made associated support to one or the other very difficult with a host of conflict alerts being generated. Everyone seems to be agreed that host system software needs to be compatible with all other friendly platforms - as long as it is all the other platforms that have to change their software (at great expense).

Lima Juliet
23rd Feb 2013, 11:50
If the mud mover IPT and 1Gp had pushed harder for JTIDS for GR4 then we probably wouldn't have lost one of them to the friendly fire Patriot in 2003. This is because a PPLI from a JU sits higher up the ID matrix than Mode 4.

Spilt milk though...:(

LJ

LowObservable
23rd Feb 2013, 11:56
"It's not a bug, it's a feature".

Optimal stealth involves zero transmissions, and certainly none that are not governed by the EMCON functions in the aircraft or the four-ship unit. Hence the only transmit comms are the voice radio (outside threat range only) and IFDL. Any datalink that responds automatically to an outside query is verboten. It's like a ninja with Tourette syndrome.

Bevo is correct that other things have been demonstrated. However, the solution adopted in 2010 (IIRC) was to put the F-35's MADL (which for reasons unexplained can't talk to IFDL) on the F-22 and B-2, along with a fully cooked version of BACN called Objective Gateway. Unfortunately this was then :mad:canned on cost grounds (also, perhaps, in view of the real-world IOC of Porky).

My impression is that the stealth community is resistant on the grounds that their job is to go into the "red bubble" of denied airspace, and that if they have the means to contribute to the big air picture they will be under constant pressure from the joint air component commander to do that.

Courtney Mil
23rd Feb 2013, 12:43
You're right, LO. And that's why the option to go quiet as required is still, to my mind, the best one.

Always a Sapper
23rd Feb 2013, 13:29
Interesting, and something I didnt know. But did I need to know? And do others not in the loop need to know that the Typhoon can't talk to the F-22?








Ahhh, that'll be my taxi then. Now where did I put the hat n coat.

RAFEngO74to09
23rd Feb 2013, 15:09
LJ,

The 2 x WB-57F still perform the BACN role !

The Aviationist » NASA’s WB-57 Battlefield Airborne Communication Node gets new sensors, paint scheme for more clandestine missions (http://theaviationist.com/2012/09/04/wb-57-bacn-miramar/)

Great pics in this article:

Wb-57f News, Videos, Reviews and Gossip - Gizmodo (http://gizmodo.com/wb_57f/)

A third WB-57F was withdrawn from AMARG Davis Monthan mid-2011 and is currently being regenerated in Colorado for further service.

NASA WB-57F (http://www.u2sr71patches.co.uk/nasawb57f.htm)

Lima Juliet
23rd Feb 2013, 16:54
EngO

Thanks for that. Good to see the mighty 'Berra still doing stuff (albeit a US-built one).

I also note that the PR9 at Kemble has taken a step closer to flight :ok:

LJ

langleybaston
24th Feb 2013, 14:33
Standardisation and inter-operability problems are endemic to organisations like NATO. It was ever thus.

The Met. meetings on the subject at about Wg Cdr / Gp Capt level in Northag, AFCent and the like were just talking shops, with each country bragging about [usually miniscule] progress since last time, and more focus on Wives' Programmes and Dinings-In than business.

The level which really knew what was going on and where to make progress rarely got a look in beyond briefing their boss.

I reacted by sending my expert [at Flt Lt level], appointed him my deputy for 72 hours and awaited his report.

"They didn't have a clue what I was talking about, but they all agreed!"

Muddle along is the best description.

orca
24th Feb 2013, 15:42
Are we saying that the two genuinely have to communicate in non-agile, unencrypted UHF? That would be bad....but surely this isn't the case?

Corrona
24th Feb 2013, 16:02
This comms interoperability thing surely doesn't matter unless the USAF are about to start letting the F-22 'go places'.

Although clearly it doesn't sound very smart for such special friend's to not be able to talk secure.

ORAC
24th Feb 2013, 16:17
This comms interoperability thing surely doesn't matter unless the USAF are about to start letting the F-22 'go places'. US basing F-22 Raptor Stealth Aircraft at Al-Dafra Air Base on Iran’s back door (http://www.examiner.com/article/us-basing-f-22-raptor-stealth-aircraft-at-al-dafra-air-base-on-iran-s-back-door)

P6 Driver
24th Feb 2013, 16:21
If the Yanks ever want to tell other "friendly" forces about anything, they'll do it at a time and with a method of their choosing.

Corrona
24th Feb 2013, 16:55
OK ORAC, point well made!

Courtney Mil
24th Feb 2013, 17:23
Are we saying that the two genuinely have to communicate in non-agile, unencrypted UHF?

Perhaps they'll have to fall back on Havequick.

tucumseh
24th Feb 2013, 18:28
Perhaps they'll have to fall back on Havequick.

I think it was 1995 when the US decided to downgrade the HQII specification and de-modify the radios, including those we'd bought, without bothering to tell us or amend drawings. When THEY transmitted, we could receive; but when WE transmitted they could receive 50%. (In simple terms).

We re-modified our radios, but only for one aircraft fleet; the first fleet to encrypt a hopper. None of the other project offices (it was before the Mk2 IPTs were formed in 1999) even bothered updating their tech pubs, or ADS to inform the crews there was no point selecting a certain secure mode.

In 2001 a major initiative was developed to improve integration and interoperability. DEC demanded the word "interoperability" be removed as it was not policy for our Services to be interoperable with each other, never mind Allies.

BEagle
24th Feb 2013, 20:54
tuc, while HQII worked well in the VC10K, there were often occasions during OP WARDEN when we had to send a 'mickey' to F-15 crews, who couldn't get HQ to work.

But even with a correct WOD and TOD, it was reasonably common for the wrong OpDay to have been loaded - or for MWODs to drop during the change from external to internal power after engine start. So I decided that the ground crew comms NCO with HQ fill gun should remain on board until we were on internal power and had re-checked HQ comms with Mad Dog, then disembark - they readily agreed as at least they were interested in successful missions.

Sadly, most sqn crews new √(cock all) about HQ, RWR etc. Nor could they be ar$ed to read up about such systems, particularly on detachments as they were more interested in playing golf and general holidaying. Until, that is, a certain FI started including questions about such operational systems in routine Ground Cats....:E

Wensleydale
24th Feb 2013, 21:27
And, of course, HQ is not secure - it is jam resistant.

Two's in
25th Feb 2013, 00:32
Thank Christ the solution for this is obvious - let's have another OEM provided stove pipe comms solution, that'll fix it.

Lonewolf_50
25th Feb 2013, 00:41
P6 has the right of it.

orca
25th Feb 2013, 00:55
But HQII can be run through a cypher...to produce 'the purest green'.

BEagle old chap,

I also never understood how HQ got its own world of mythology...even in the old days checking MWODs, Op Days etc only took 5 minutes...for some reason the boat used to find it impossible to work on even days...somewhat frustrating when we kept explaining the bleeding obvious!

tucumseh
25th Feb 2013, 05:49
And, of course, HQ is not secure - it is jam resistant.

HQ (hopping) is termed Transmission Security, Encryption Communications Security. Both are "secure" but in different ways. In the early - mid 90s one could buy a simple off the shelf receiver that could track HQII, so the degree of TRANSEC became debatable, as you say.


Beagle

Agree, although of course I look at the issue as someone who wrote the specs and managed programmes to deliver the specs. The advent of GPS further complicated updating, partly because GPS was seen to be the great solution, but was actually in service for many years while still immature and little understood.

Someone mentioned the March 2003 Tornado/Patriot shootdown. (Root cause, refusal to integrate failure warnings). The same day two Sea King ASaCs were lost. The BoI report says Time of Day was not available to their HQII radios. (The same fault was in Chinook ZD576). What the BoI didn't mention was that at the same time the above secure mode "modification" problem was discovered (also affecting ASaC), so too was a feature of the GPS spec which meant most Mil Std GPS units could only support two ToD loads. A Buffer Unit was needed if you required more than two. e.g. JTIDS, 2 x HQII, Crypto etc. The BoI doesn't say why the HQII radios didn't have ToD, forcing "mickey". Or, of course, when this anomaly (because it apparently wasn't deemed a fault) occurred or if the crews knew of it. By not mentioning this (or, more likely, not being told in the first place) the BoI missed a very important factor. In other words, it is entirely possible a whole LRU was missing that was necessary to make the above systems function reliably; with no immediate indication to crew if they were not functioning (or even connected together properly). One thing is absolutely certain - neither aircraft was compliant with the specified build standard, and hence Safety Case. It is an interesting example of how a minor problem can mushroom if not controlled. In this case, the "control" was lost through loss of corporate knowledge. Detailed corporate knowledge was required at an individual level because of the aforementioned organisational fault. It is a vicious circle and almost impossible to counter once implemented.

All these events are closely linked. The problem, from my perspective, was due to stove-piping; the project that discovered the failures or problems was expected to solve the entire problem for MoD. The project that discovered the HQII spec downgrade and ToD Buffering was a Minor Equipment Requirement (MER) and could barely afford to solve them for it's aircraft (2 fleets), never mind the rest. This situation was brought about by de-centralisation of the process whereby build standards were maintained under a single funding line.

Evalu8ter
25th Feb 2013, 06:23
Tuc,
The TRANSEC element of HQII was the ability to hop around the UHF band to prevent spot jamming of frequency - thereby 'ensuring' the tx got through. The HQ project was initiated after sucessful Arab jamming of the IAF in the Yom Kippur war. When it entered service, the 'hop rate' conferred a degree of ComSec but, as you rightly identify, 'off the shelf' hopping units were soon available to negate this. Therefore, to ensure ComSec, a HQII radio must use a separate (KY series normally) encryption device. The HMI on our old HQ radios was pretty appalling; unfortunately I always seemed to be the only pilot on the Sqn that understood them so guess who got the job of loading and testing them prior to every exercise or Op mission......

SATURN hop rates are far higher than HQII to ensure TRANSEC but are still designed to operate in conjunction with Crypto to assure ComSec. Of course, SATURN should be the NATO-standard now (the clue is in the acronym)....yet another commonality allowed to drift.

tucumseh
25th Feb 2013, 10:52
Evalua8tor

Agreed. The programme I referred to above was the first to encrypt a HQII radio. And use it for UHF Homing. But switchable so you could use them in HQII mode only. The spec caused a stir at the time. I included the upgrade path to SATURN (I wrote it in Dec 94) but OR gave me an earful, stating the aircraft would "never" need or receive SATURN. Nevertheless, I contracted the system design without telling anyone and SATURN is, I believe, now fitted. I also had a 3rd design drawn up, to include BOWMAN. Another story......

The loss of a secure mode I referred to was either Di-Phase or Full Baud Binary - for the life of me I can't recall which one the US ditched. FBB I think. We simply couldn't understand why they'd de-mod the radios. If they didn't want to use one mode, then don't provide a switch on the controller. But don't deny other customers the option without telling them; it was one of the reasons why we'd bought the things int he first place. I remember sitting at a bench with the UK Design Custodian for a day physically comparing the new US printed circuit boards with our old circuit diagrams, until we eventually spotted which component was missing. It was a single diode. Their attitude toward configuration control was worse than the French, which is saying something. (But better than ours, because it was our policy NOT to maintain CC at all!)

BEagle
25th Feb 2013, 13:57
When I first saw a HaveQucik radio back in the late 1980s, my immediate concern was that loading the MWODs was too error-prone and that there was nothing similar to a 'checksum' to confirm that the correct MWOD had been loaded. My recommendation was for fill-gun MWOD loading. Another concern was that obtaining a TOD if OOA could be difficult, so a back up stable time reference was needed. GPS was immature then, so another option was a high stability 'rubidium oscillator' - mention of which at the subsequent squadron brief caused much mirth....

Roll on to GW1 and I was sprung from doing Jimmy Savile time at a UAS back to the VC10K. We used HQII, but loading MWODs was indeed time consuming and when the comms geeks found that we'd been photocopying the data and handing it to the crews, they went nuts. "How else do you expect us to load the damn things?" fell on deaf ears. Talking about deafness, we found that HQII radios, even in non-AJ mode, weren't as sensitive as non-HQII radios. It seem that to reduce the popping sound from squelch tails, 'someone' had raised the squelch threshold, so that weak AM signals didn't get through.

Some years later and another war. We now had new HQII radios with fill-gun MWOD loading, plus another LRU in the radio bay which contained the infamous rubidium oscillator! Just as I'd recommended about 12 years earlier....:rolleyes: But at least the aeroplane FRCs had been amended to include the same HQII idiots' guide which I'd written in 1991!

A customer's aeroplane, which has a secure voice system, is fitted with 'IF BW BB/DP' pushbuttons, the purpose of which, apparently, is to enable 'either Base Band (BB) or DiPhase (DP) to be selected as the bandwidth (BW) of the intermediate frequency (IF)'.

Well fine. That's rather less useful than the note in a car radio manual I once had 'If EOS is pressed in PTY mode, the display is switched to Swedish'. I tried it - it did. Fortunately un-Swedish-ing it was quite simple.

The crews had no idea whether they were supposed to use BB or DP and no-one knew anyone on the squadron who could explain the function :rolleyes: Another stellar piece of wacky-wireless procurement, it would seem!

langleybaston
25th Feb 2013, 14:29
Thank Christ the solution for this is obvious - let's have another OEM provided stove pipe comms solution, that'll fix it.

and presumably the Prophet, the Gurus, Ganesh, Moses et al.

to be ecumenical.