Link-11 SLEW with go2MONITOR

In early November, whilst working on an article for Janes, I noticed a Link-11 SLEW signal on 4510 kHz (CF) that was slowly growing in reception strength. I’d been monitoring frequencies used by the Northern Fleet of the Russian navy around this one and had already spotted that Link-11 CLEW was being used on a nearby frequency, though this remained at a constant signal strength at my location. The fact that the Link-11 SLEW was getting stronger made me stop what I was doing and start concentrating on this instead.

AirSpy HF+ Discovery SDR with SDRConsole operating software. Link-11 SLEW signal in Receiver 1, and the weaker Link-11 CLEW signal in Receiver 3. Whilst there a two SLEW signals showing, there is just one, with the left hand one being produced by the strong signal. You can see the weaker transmissions from a receiving station between the stronger ones on the correct frequency, but not on the “reflection”.

Link-11 SLEW (Single-Tone Link-11 waveform) ,or STANAG 5511, is a NATO Standard for tactical data exchange used between multiple platforms, be it on Land, Sea or Air. Its main function is the exchange of radar information, and in HF this is particularly useful for platforms that are beyond line of sight of each other and therefore cannot use the UHF version of Link-11.

With propagation being the way it is, in theory radar data could be exchanged between platforms that are hundreds to thousands of miles apart, therefore providing a wider picture of operations to other mobile platforms and fixed land bases. This data can also be forwarded on using ground stations that receive the data and then re-transmit on another frequency and/or frequency band. However, the approximate range of an individual broadcast on HF is reported to be 300nm.

As well as radar information, electronic warfare (EW) and command data can also be transmitted, but despite the capability to transmit radar data, it is not used for ATC purposes. In the UK, Link-11 is used by both the RAF (in E-3 AWAC’s and Tactical Air Control Centres) and the Royal Navy. Primarily it is used for sharing of Maritime data. Maritime Patrol Aircraft (MPA’s) such as USN P-8’s and Canadian CP-140’s use Link-11 both as receivers and transmitters of data, so when the RAF start using their P-8’s operationally in 2020 expect this to be added to the UK list. Whilst it is a secure data system, certain parameters can be extracted for network analysis and it can be subjected to Electronic Countermeasures (ECM).

Link-11 data is correlated against any tracks already present on a receivers radar picture. If a track is there it is ignored, whilst any that are missing are added but with a different symbol to show it is not being tracked by their own equipment. As this shared data is normally beyond the range of a ships own radar systems, this can provide an early warning of possible offensive aircraft, missiles or ships that would not normally be available.

I started up go2MONITOR and linked it to my WinRadio G31 Excalibur. Using a centre frequency of 4510 kHz I ran an emission search and selected the Link-11 SLEW modulation that it found at this frequency.

It immediately started decoding as much as it could, and I noticed that three Address ID’s were in the network.

go2MONITOR in action just after starting it up. Note, three ID’s in the network – 2_o, 30_o and 71_o

As the signal was strong, and it is normally maritime radar data that is being transmitted, I decided to have a quick look on AIS to see if there was anything showing nearby. Using AISLive I spotted that Norwegian navy Fridtjof Nansen class FFGHM Thor Heyerdahl was 18.5 nm SW of my location, just to the west of the island Ailsa Craig. Whilst it was using an incorrect name for AIS identification, its ITU callsign of LABH gave me the correct ID. This appeared to be the likely candidate for the strong Link-11 signal.

Position of Thor Heyerdahl from my AIS receiver using AISLive software

It wasn’t the best day and it was pretty murky out to sea with visibility being around 5nm – I certainly couldn’t see the Isle of Arran 11.5 nm away. I kept an eye on the AIS track for Thor Heyerdahl but it didn’t appear to be moving.

Whilst my own gear doesn’t allow me to carry out any Direction Finding (DF) I elected to utilise SDR.hu and KiwiSDR’s to see if I could get a good TDoA fix on a potential transmitter site – TDoA = Time Difference Of Arrival, also known as multilateration or MLAT. Whilst not 100% accurate, TDoA is surprisingly good and will sometimes get you to within a few kilometres of a transmission site with a strong signal.

One of my thoughts was that the signal was emanating from the UK Defence High Frequency Communications Service (DHFCS) site at either St. Eval in Cornwall or Inskip in Lancashire. With this in mind I picked relevant KiwiSDR’s that surrounded these two sites and my area and ran a TDoA.

St. Eval transmitter site at 50°28’43.0″N 4°59’58.0″W
Inskip transmitter site at 53°49’26.6″N 2°50’14.1″W

As expected, the result showed the probable transmitter site as just over 58 kilometres from St. Eval, though the overall shape and “hot area” of the TDoA map also covered Inskip, running along the West coast of England, Wales and Scotland. It peaked exactly in line to where the Norwegian navy ship and I were located! With the fact that there were signals being received from three different sources it is highly likely this has averaged out to this plot.

TDoA result showing the likely transmitter site at 50.60N 4.20W. Note the elongated “hot spot” which denotes the area that the transmitter site is likely to be situated.

Just after 10am the weather cleared allowing me to see a US Navy Arleigh Burke class DDGHM between myself and Arran. This added an extra ship to the equation, and also tied in with the TDoA hot spot. Things were getting even more interesting!

Link-11 SLEW at its strongest which also coincided with USS Gridley being its closest to my location.

Thor Heyerdahl still hadn’t moved according to AISLive but the Arleigh Burke was clearly heading in to the Royal Navy base at Faslane. With my Bearcat UBC-800T scanning the maritime frequencies it wasn’t long before “Warship 101” called up for Clyde pilot information along with an estimate for Ashton Buoy of 1300z. Warship 101 tied up with Arleigh Burke USS Gridley.

The Link-11 SLEW signal was considerably weaker at the time USS Gridley was at Ashton Buoy.

As USS Gridley progressed towards Faslane, the signal started to get weaker. Ashton Buoy is where most ships inbound for Faslane meet the pilot and tugs, taking up to another 30 minutes to get from there to alongside at the base – a journey of about 8.5nm.

At 1328z the Link-11 SLEW signal ended which coincided with the time that USS Gridley approached alongside at Faslane. It would be at about this time that most of the radar systems used on the ship would have been powered down so data was no longer available for transmission, therefore the Link-11 network was not required any further and it was disconnected.

The Link-11 SLEW signal disappeared at 1328z
Some images of USS Gridley arriving into Faslane taken by good friend Dougie Coull

So, was this Link-11 SLEW connected to USS Gridley? And was the ship also the NCS of the network? I think the answer is yes to both, and I’ll explain a couple of things that leads me to this conclusion. But first…………….

Link-11 SLEW Technical details

Using Upper Side Band (USB) in HF, a single waveform is generated in a PSK-8 modulated, 1800 Hz tone. The symbol rate is 2400 Bd and the user data rate is 1800 bps. Link-11 SLEW is an improved version of the older Link-11 CLEW modulation and due to enhanced error detection and correction is a more robust method of sending data. This makes it more likely that transmissions are received correctly the first time. Moreover, an adaptive system is used to counter any multipath signals the receiving unit may experience due to HF propagation.

The waveform transmission consists of an acquisition preamble followed by two or more fields, each of which is followed by a reinsertion probe. The field after the preamble is a header field containing information that is used by the CDS (Combat Data System) and an encryptor. If a network Participating Unit (PU) has any data, for instance track data, this follows the reinsertion probe. Finally, an end-of-message (EOM) is sent followed by a reinsertion probe.

The header is made up of 33 data bits and 12 error detection bits (CRC – Cyclic Redundancy Check). The 45 bit sequence is encoded with a 1/2 rate error correction code therefore giving a 90 bit field. The header contains information on the transmission type used, Picket/Participating Unit (PU) address, KG-40 Message Indicator, the NCS/Picket designation and a spare field.

Broken down, each piece of information is made up as follows:

The transmission type indicates the format of the transmission – 0 for a NCS (Network Control) Interrogation Message (NCS IM); 1 for a NCS Interrogation with Message (NCS IWM) or a Picket reply.

The address contains either the address of the next Picket or that of the Picket that initiated the call.

The KG-40 Message Indicator (MI) contains a number sequence generated by a KG-40AR cryptographic device. Synchronization is achieved when the receiver acquires the correct MI. For a NCS IM this will be made up of zeros as no message or data is actually sent.

The NCS/Picket designation identifies whether the current transmission originates from the NCS or PU: 0 = NCS; 1 = PU

Following on from the header, the SLEW data field consists of 48 information data bits along with 12 error detection and correction bits, themselves encoded with 2/3 rate error correction. This creates a 90 bit data field. 

The EOM indicates the end of the transmission and is also a 90 bit field. There are no error detection or correction bits. Depending on the unit that is transmitting, a different sequence is sent – NCS = 0’s; PU = 1’s

Analysis

There is a specific order of transmissions which takes place for data to be exchanged.

Ordinarily the NCS sends data that creates the network, synchronizing things such as platform clocks etc. Each PU is called by the NCS and any data that a PU has is then sent, or the NCS sends data, or both. This is a very simple explanation of how data is exchanged but if you monitor a SLEW network you’ll see the exchanges take place rapidly. Except for the message itself which is encrypted, go2MONITOR will decode all the relevant information for you for analysis. This means that you don’t need to look at each raw data burst as sent to calculate whether it was a PU reply or NCS IWM, the decoder will do this for you.

At this point I need to say that Link-11 decoding is only available in the Mil version of go2MONITOR so doesn’t come as standard. Should you be interested in Link-11 decoding yourself then you would need to go for the full go2MONITOR package to enable this.

As previously mentioned, the data itself is encrypted but it is possible to try to calculate who is who within the network, and the analysis of the header information in particular will give you a good clue if you already know of potential PU’s that could be on the frequency.

In this case we already have four possible PU’s:

  1. USS Gridley
  2. Thor Heyerdahl
  3. St. Eval transmitter site
  4. Inskip transmitter site

It later transpired that Thor Heyerdahl had gone into Belfast Harbour for repairs so this practically cancelled out this ship as the NCS though it could still be a PU. Moreover, Thor Heyerdahl and USS Gridley were part of the same NATO squadron at that time which meant it was highly likely they were on the same network. This left us with three choices for the NCS, but still four for the network.

Here, I’d cancel out Inskip completely as both the NCS and a PU as the TDoA appeared to give a stronger indication to St. Eval – that left us with three in the network.

The pure fact that the strength of the major signal increased as USS Gridley got closer to my location, then slowly faded as she went further away added to my theory of her being the NCS. This was practically confirmed when the signal stopped on arrival to Faslane. Throughout the monitoring period he other signals on the frequency remained at the same strength.

Based on this, this meant that the strong signal was USS Gridley using ID Address 2_o.

Let’s take a look at one the previous screenshots, but this time with annotations explaining a number of points.

Firstly, we need to look for the NCS. The easiest way to do this is to look at the NCS/Picket Designation and find transmissions that are a zero, combined with a Message Type that indicates it is a NCS IWM. Here, there is just one transmission and that emanates from Address ID 2_o – the long one that includes a data message.

We next need to find NCS/Picket Designation transmissions that still have a zero – therefore coming from the NCS – but that have a Message Type that show it to be a NCS IM. These are calls from the NCS to any PU’s that are on the network looking to see if they have any “traffic” or messages.

Because of this there should be numerous messages of this type, and if you notice none have an ID address of 2_o. However, all of these messages are actually coming from 2_o as the ID address shown in a NCS IM is that of the PU being called rather than who it is from.

Any reply messages from PU’s will show as a NCS IWM/PU Reply transmission, but importantly the NCS/PU designation will be a one – showing it isn’t the NCS. Here there is one data reply from 71_o. You’ll notice that in the “reflection” there isn’t any transmission, unlike the ones from 2_o.

Moreover, though not shown here as the messages were off screen and not captured in the screen grab, you can see that one of the PU’s sent another reply message. As I was able to look at the complete message history I was able to see that this was also from 71_o – and 2_o either replied to this or sent further data.

There are two fainter transmissions which were not captured by go2MONITOR. These were from a PU, and must have been 30_o as there are no transmissions at all in the sequence that are from this ID address.

We now have a quandry. Who was 30_o and who was 71_o?

Data is definitely being sent by 71_o so to me this is more likely to be a ship rather than a transmitter site – but – a strong TDoA signal pointing at St. Eval makes it look like 71_o is this location instead.

Now though, we need to think outside the box a bit and realise that I’m looking at two different sources of radio reception. The TDoA receivers I selected were nowhere near my location as I’d selected KiwiSDR’s that surrounded St. Eval. This meant the signal that was weak with me could have been strong with these, therefore giving the result above.

If I base the fact that I think USS Gridley is 2_o due to strength, then I must presume the same with 71_o and call this as Thor Heyerdahl as this is the second strongest signal. I can also say that having gone through the four and a half hours of Link-11 SLEW transmissions available that 30_o never sent a single data transmission – or rather, not one that was received by me.

Full four and a half hours of Link-11 SLEW as shown in the go2MONITOR results page. You can see other areas (in red) that I was decoding at the same same. By selecting an area in the results page you can access the data as decoded, saved into files. I could have further enhanced this and carried out a full audio recording for further analysis, but I didn’t on this occasion.

Here then is my conclusion:

  1. USS Gridley = 2_o and the NCS
  2. Thor Heyerdahl = 71_o
  3. St. Eval transmitter site = 30_o

Of course, we’ll never really know, but I hope this shows some of the extra things you can do with go2MONITOR and that it isn’t just a decoder. It really can add further interest to your radio monitoring if you’re an amateur; and if you’re a professional with a full plethora of gear, direction finders, receiver networks etc. then you really can start getting some interesting results in SIGINT gathering with this software – and highly likely be able to pinpoint exactly who was who in this scenario.

Now, how do I get some Direction Finders set up near me….Hmmmmmm??

An updated AIS system

Back in March I blogged about my AIS system, in particular about the LNA4ALL and how it coped with the low signal reception of my homemade antenna.

Things went really well until one day the reception dropped out completely.

A quick test of the system showed that something had gone wrong with one of the pieces of equipment though at the time I was unsure whether it was the antenna, the LNA or the NASA Engine AIS decoder.

As I was due to go away for a short while I decided to tell all the relevant websites that I feed (IHS AISLive, MarineTraffic and VesselFinder) that my system would be offline until further notice due to a technical fault, and that as soon as I’d worked out the issue that I’d get it fixed and back online.

The guys at MarineTraffic were very quick in getting in contact with me and offered to help with a new decoder as long as I didn’t mind being a beta tester for the equipment and some of their new software. I was very happy to agree to their offer.

The decoder they organised for me was a new Comar Systems SLR350ni Intelligent AIS Decoder and it arrived with me about ten days after I agreed to their offer.

The main thing that really appealed to me about this decoder was the fact that it links directly to your home network either by WiFi or hardwired using RJ45 Ethernet cable. This meant that I could install the decoder remotely, nearer to the antenna and out of my radio shack, but have full control of it from my main PC. The decoder itself is interfaced to a Raspberry Pi™ 3 computer, comes with aforementioned WiFi and Ethernet connectivity, 4 USB ports and an HDMI connector for a monitor display. It can be used in any AIS setup and is a dual channelled parallel receiver.

Installation was simple. Within 15 minutes the decoder was connected to my home-made antenna and we were receiving data – and at a much faster rate than the NASA due to the dual channel capability.

The MarineTraffic part of the agreement included some new software that they are testing, which includes the capability of sending received raw AIS data to five feeds such as AISLive. Any of these decoders obtained using MarineTraffic come with their host settings hardwired in so any data received through it is automatically sent to them – you don’t have to do anything to send data to MarineTraffic, just attach an antenna, connect it to your network and switch it on – that’s it.

In the new software there is a page where you can add other host iP addresses and port details. Doing this means a couple of things:

1 – You no longer need to use other software such as ShipPlotter or Neal Arundale’s NmeaRouter/AisDecoder software to forward on the data.
2 – You don’t actually need a PC connected directly to the Comar decoder.

The second point is interesting as it means you no longer need to have a PC running 24/7 to feed any of the AIS data to whichever sites you want. This is a bonus if you currently switch off your computers when you go on holiday or are away from home for a while. It still means you can provide the data whilst you are away.

Personally I have the following set up:
MarineTraffic (hardwired)
AISLive (iP host)
VesselFinder (iP host)
ShipPlotter (internal network address)
AIS Decoder (internal network address)

Using the ShipPlotter software still means I can get a better picture of what I am receiving, range of reception etc.; whilst using the AIS Decoder software means I can look at any of the messages sent in greater detail.

I have to say that I am very impressed so far, and highly recommend the Comar decoder. It is available from numerous online shops, but if you are going to feed MarineTraffic you may as well get it from their site, currently priced at €379.00. Doing this means it already comes pre-programmed to send to MarineTraffic.

A new antenna too

I had gotten round to testing all the equipment to see what the cause of the original loss of reception was and it turned out to be the LNA4ALL. This was a shame as I had new objectives for the LNA with regards to the reception of weather satellites so it means I’ll have to get a new one. Luckily I don’t need to replace the whole thing, just the circuit board, so it will be much cheaper – but a pain none the less, especially if I have the same issues with UK Customs that I had previously. The likely cause of the failure was an Electrostatic Discharge of some sort or other. There had been some Lightning storms nearby over the previous days and it could well have been this that had done it – strange though as my equipment is very well protected from this happening. The area I live in is prone to power surges and power cuts – the joys of living in a remote area in Scotland, still backwards in many things the rest of the UK take for granted.

With the loss of the LNA, this drastically reduced the range of my home-made antenna and so I decided it was time to buy a new one. I’d toyed with building a better one but in the end I just couldn’t be bothered and so I went for a Metz AIS antenna, bought from the Salty John website. Great service from them meant it arrived within 48 hours and so when it came to installing the Comar decoder I also rigged up the antenna in the loft space next to my home-made one at the same time.

If I have one complaint about the Metz, it’s that it doesn’t come with any form of protection for the co-ax connection area. This is especially strange as it is designed specifically for boats and would therefore be exposed to wet/salty conditions all the time. Add to that that the threaded area is over an inch long, much longer than what you would get with a UHF connector, this makes it a weak area for the lifetime of the antenna. If you were to install it outside (which is the general recommendation for AIS reception) then you would need to cover it in self-amalgamating tape and check it regularly to ensure it is still working. Not perfect if you need to climb up on the roof of your property.

One other option would be to use the tightening nuts supplied to fix some plastic or aluminium tubing around the connection, but again this is some extra hassle which could have been remedied by Metz themselves.

As it is, I seem to be getting great coverage from the Metz from it’s position in the loft, though I may still add a LNA4ALL to boost it even more.

With the antennas side by side I was able to run some quick comparisons between the two. The images below show the Spectrum analysis using my Rigol gear.

From the images you can see that with my messing around of the home-made antenna I had over trimmed it to be tuned to 180MHz rather than the required 162MHz. At 162MHz it measured in at 9.3dB which wasn’t even worth calculating the VSWR, whilst at 180MHz its VSWR was 1.23:1

In comparison the Metz antenna, which is a half-wave whip antenna, came in nicely at 83.6MHz with a measurement of 30.15dB/VSWR 1.07:1. Metz communications specify less than 1.2:1 VSWR so this is spot on.

With the new set up things have definitely improved. I also ran a quick test using AISDecoder to see how many messages the two antennas fed to the Comar, be it in a very basic manner of waiting till there was some ships being picked up, running the software with one antenna for a minute, noting how many messages were received and then swapping to the other antenna for the same length of time. In theory it is a reasonable test as the ships won’t have travelled far in that time, but not 100% perfect. Regardless, the Metz was able to pick up 19 messages in its minute test, whilst my home-made antenna only managed three! The test was carried out in less than five minutes.

In conclusion, whilst it has been a pain to lose the LNA4ALL, it has turned out better in the end for my AIS station. Statistically my data feed has improved no end for AISLive and MarineTraffic; and having gone away twice now since installation I have still been able to provide 24/7 coverage where I would normally have switched the whole system off.

Area coverage provided to MarineTraffic since the new installation. Fitting a LNA4ALL in the future should make this even better.

ShipPlotter example with the new installation. The bold plots are being received by my station and show 4673 messages received by 1032z. The image below shows the same but at 1753z and a message number of 28135. This averages out at about 52 messages a minute, though it was a busy time with lots of fishing boats in the area.

NOTES:

Following a couple of questions regarding the Comar decoder I’d like to add that it doesn’t have to be connected to the Internet or a Network to work. It can be used “locally” using the USB connections direct to a PC.

Also, you do not NEED to feed MarineTraffic if you don’t want to. If you don’t want to do this then buy a unit from another supplier which won’t have the files installed.