SDRplay RSPdx with go2MONITOR

Thanks to SDRplay, I was sent both their new RSPdx and older RSPduo SDRs at the end of January.

The main reason was to get them integrated into Procitec’s go2MONITOR and go2DECODE software, to increase the number of SDRs that the company’s products are compatible with.

This I’ve been successful in doing with the RSPdx – I’m still to unbox the RSPduo at this time of writing.

First of all though, I’ve been extremely pleased with the RSPdx in its own right. The SDRuno software works really well, is pretty easy to use – and it looks good too.

SDRuno running the RSPdx
The RSPdx also works with SDRConsole

The fact that you can have up to 10 MHz of bandwidth is brilliant, and it isn’t too bad on the CPU usage either – running at around 25% with 10 MHz bandwidth on my ancient PC. Used with SDRConsole you can cover a good number of frequencies at once, and can record them if necessary. Of course, you can do this with SDRuno too, but at the moment only IQ – you can’t record individual frequencies.

Saying that, I’ve seen the SDRuno Roadmap for future releases and not only will recording of individual frequencies be possible, a more advanced scheduler is to be included. This is something I feel SDRConsole – amazing though it is – is lacking when it comes to single frequency recording. There is also the issue with SDRConsole that you are limited to recording only 6 hours worth of wav file per frequency.

Anyway, I digress. Back to the RSPdx and go2MONITOR.

To get the SDRs to work correctly with any of the go2 products means creating a configuration file and adding a ExtIO DLL file to the software. This is reasonably easy to do once you get use to it and it enables a GUI to become active so that you can control the SDR through go2MONITOR.

One interesting aspect with the RSPdx GUI is that regardless of what you enter as some of the parameters in the configuration file, the ExtIO file overrides these. Effectively, I just left some of the data as found in a basic configuration template and let the GUI do all the work for me.

So, below are some of the results with today’s first test.

First of all I went into the VHF/UHF side of things and targeted the local TETRA networks. These were found easily and after messing around with the GUI, I was able to get go2MONITOR set up to nicely find all the emissions within the 1.6 MHz bandwidth I’d chosen to use

From there, all I had to do was to select one of the found emissions and let the software do its thing.

Next I moved on to HF where there’s a plethora of data to choose from to test out the SDR. There was quite a large storm going through at the time and my Wellbrook loop and coax feed were getting a bit of a bashing with some considerable interference being produced with the really strong gusts, as can be seen below – the interference between the two HFDL bursts is one such gust.

I’ve frequently mentioned the Results Viewer that’s part of go2MONITOR and with things such as HFDL and TETRA, that process data quickly from lots of signals, this part of the software comes into its own.

The image below is two minutes of HFDL monitoring. All the red blocks is received data that scrolled through the Channel window too quickly to read live. In the viewer you can select any of the signals and you’ll be shown the message as sent. In this case, it is one sent by an Open Skies Treaty observation flight OSY11F.

By looking at the Lat/Long and comparing it to the flight history from FlightAware and its location at 1313z it ties in nicely. This flight was carried out by the German Air Force A319 1503 specially kitted out to make these flights.

go2MONITOR has a basic map function within the Result Viewer function so if there’s any Lat/Long position within any message it will plot it – as shown below for OSY11F at 1313z.

Within the General tab of Result Viewer you can get all the parameters of the signal.

One final test that I carried out was how well everything coped with a bigger bandwidth. In HF I can use up to 3 MHz of bandwidth with the licence I have – going up to 10 MHz once into VHF/UHF. In HF then, I selected 3 MHz in the GUI and then ran an emissions search.

My PC is nearing the end of its life but it coped easily with the amount of data found despite only having 4 GB of RAM with a 3.6 GHz AMD processor – a new PC is in the pipeline that is going to give me much better processing power.

Despite having 3 MHz available, not everything was identified. Most of this was at the fringes of the bandwidth, but some of the weaker signals also failed. That doesn’t mean you can’t then process them further, you can, it’s just the Emissions scan hasn’t quite been able to ID them. Saying that, the software managed to ID things within 2.2 MHz of the 3 MHz bandwidth.

I picked one of the weaker signals to see how both the RSPdx and software coped and they did very well, pretty much decoding all of the CIS-50-50 messages that were coming through on 8678 kHz.

So, overall, pretty pleased with how the RSPdx works with go2MONITOR.

Once I get a better PC I’ll be able to test at bigger bandwidths but even with 3 MHz here I was able to achieve the same, if not better, results than I have with the considerably more expensive WinRadio G31 Excalibur I have been using previously (running with the G33 hack software).

Not that I’m likely to really use go2MONITOR at big bandwidths – 1.6 MHz is probably fine for me – but for Pro’s there’s no doubt that having these “cheaper” SDRs would make absolutely no difference over using an expensive one such as those in the WinRadio range. In all honesty, I don’t think I’ll be holding on to the WinRadio for much longer – I’m more likely to get another RSPdx to cover this area of my monitoring.

On its own, as an SDR, the RSPdx is worth the money I’d say. I like it just as much as I do the AirSpy HF+ Discovery – the only real difference I can see between these two SDRs is the max bandwidth available.

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??

PROCITEC go2MONITOR overview

If you follow me on Twitter you’ll see that in the last month or so I’ve been sending out images of classification and decoder software go2MONITOR working with a number of my SDR’s.

go2MONITOR is part of the go2SIGNALS range of software solutions created by PROCITEC GmbH operating from Pforzheim in Germany, themselves part of the PLATH group. PLATH Group is the leading European-based solution provider for communication intelligence and electronic warfare (EW) with worldwide government customers. The group covers all aspects of signal interception and analysis split between a number of companies such as PROCITEC. EW, COMINT/SIGINT, Jamming and Decoding are just a small part of what the group specialises in.

go2MONITOR is advanced high-performance, automatic HF, VHF and UHF monitoring software capable of recording, SDR control, wideband and narrowband classification and multichannel signal decoding.

It isn’t for the faint hearted, but once you get used to using it, it really does make gathering information on networks extremely easy. And it decodes many modes other software can’t.

In a series of blogs I’m going to show you the capabilities of this amazing software, though I must stress now, it is aimed at Professional SIGINT gathering and it comes with a Professional price tag.

Saying that, it doesn’t mean it isn’t available to the non-professional. It is open to all and to cover this it comes in various versions starting with the Standard package progressing to a full Military package – which gives you the full range of HF, VHF and UHF classification and modem recognition decoders available, including PMR and SAT (Inmarsat AERO). The Standard version isn’t to be sniffed at, it still gives you an amazing range of decoders, though you could easily argue that many of these are available in other free – or near to free – decoding software like MultiPSK or Sorcerer. A full list of decoders available can be found here. Note, this list is broken down into the various packages and not all are available with the Standard option. Confirm what belongs to what if you’re thinking of purchasing.

Various signals within the Satellite L-band using an AirSpy R2 and SDR#

So what’s the difference in what go2MONITOR can do with other software available? That’s the idea of these blogs, to answer just that question. It will take quite a few blogs – mainly because there isn’t just one answer.

Here then, is a brief overview of what can be done, what SDR’s it works with – in fact, not just SDR’s but all receivers that can produce a recording – and any other things I can think of.

As, I’ve said then, it can decode pretty much any data signal out there. Obviously, some signals are encrypted so it wouldn’t fully decode unless you had the key, but you can get the encrypted messages. It can also classify voice signals, not just data. So, if you wanted to hunt out various voice networks, go2MONITOR can assist you in doing this.

Here is where it excels. Classification – and doing it very quickly.

Imagine being on your SDR (SDR1) and you can see a whole load of data signals on the waterfall/spectrum and you quickly want to know what they all are. With go2MONITOR operating another SDR (SDR2) you can dial in the centre frequency of the bandwidth shown on SDR1 into the go2MONITOR/SDR2 combo, click one button – Find Emissions – and within seconds the whole bandwidth has been analysed and every signal classified.

I’ll go back a step though here. You don’t need two SDR’s. One will do. SDR1 – as long as it is a compatible SDR – can be controlled through a GUI by go2MONITOR. The software includes a waterfall/spectrum display. Like all SDR software, these displays are fully adaptable to how you like to see the signals.

The previous L-band bandwidth but his time using go2MONITOR and the AirSpy R2 GUI, decoding INMARSAT 3-F2

Either way, you now have a list of every emission that go2MONITOR has received within that bandwidth. This list includes Modulation type, Frequency, Bandwidth, Symbol (Baud) rate and SNR. It also shows which SDR you have used for interception (useful if you’re using go2MONITOR with more than SDR at the same time, but also with other advanced features such as network control), and it also shows if the frequency is already stored within the frequency database – yes, you can create this too; or import ready made databases in a CSV format.

All the emissions within the bandwidth have been analysed and types ascertained.

Already then, you have built up a picture of what these signals are. One thing to note. If the signal type is not one of those included within the package you have, it will be classed as unknown. Example – a STANAG 4285 will show as unknown in the Standard and PMR/SAT package, but will be classified correctly in the MIL package.

OK, those of us that are looking at SDR’s all the time can pretty much tell what the signals are just by looking at them, so there’s no great advantage here is there? Except, now go2MONITOR has logged these in its database which can be searched through at a later date – handy if you’re looking for potential schedules for example.

However, the next step is where things get interesting. By putting one of these emissions into a “Channel” you can carry out an advanced classification, recognition and decode. You have multiple choices here, but I generally start off with a Classification. Whilst the software has already decided what the emission type is, by doing this it double checks just this one channel and produces a choice of decoders that it is likely to be.

go2MONITOR in Classification mode. Here it has calculated that the FSK emission received has a 50 Bd symbol rate with two tones with 859 Hz spacing. From this it has deduced it is likely to be one of four modems – one of which is ALE-400.

By using STANAG 4285 as an example, it will put this into the list of choices, but it may put other PSK signals there too. By clicking on another button, this puts the channel into Recognition mode and it reduces the hundreds of decoders down to just those in the classification list produced. The software then calculates which is the best decoder and starts to decode the signal.

If you think about STANAG 4285 in other software, you generally have to try all the various potential Baud rates – is it Long Interleaving? is it Short? etc etc. Well go2MONITOR does this automatically. It checks the alphabet and protocol and will decode it if known. More often than not it can’t calculate the alphabet, but every now and again it does and it will produce encrypted data – don’t forget, if it’s encrypted it won’t decrypt it without the correct key.

By continuing on the process from the Classification mode into the Recognition & Decode mode, here from another emission go2MONITOR has selected the CIS-50-50 modem and started to decode the message.

This further Recognition and Decoding is also stored in the database for later analysis, along with a recorded wav file for playback and deeper signal analysis.

Seriously, it is harder describing it in text than it is doing it so I’ve created a video that’s at the end of this blog.

I mentioned previously that the software works with receivers that aren’t SDR’s. That’s because, as long as you can create a wav file recording – Narrowband as it’s known in go2MONITOR – it can be analysed. There are things missing, the actual frequency for instance (though this can be typed into a text box so that you can then have the right information – this i’ll show in a later blog). Time stamps aren’t naturally there but again you can add these by telling the software to use the time the recording was started.

I’ve used recordings made on my Icom IC-R8500 as an example of this but it is literally the bandwidth of the mode used by the receiver that is shown on the go2MONITOR spectrogram.

You don’t actually need to own a receiver of your own. Use an online SDR such as a KiwiSDR, record the IQ as a wav file and play it back through go2MONITOR for analysis. I’m doing just that for a Jane’s Intelligence Review magazine article.

If you use SDRConsole, then you may have also tried the File Analyser function that I blogged about in August last year. The File Analyser in SDRC is excellent, there’s no doubt about it, but it has one drawback. Once you’ve carried out your recording you have to create a run through of the recording, making an XML file that effectively joins all the wav files up. If you’ve made a wide and long IQ recording this can take quite some time. With most of my overnight recordings – normally 7 hours long, with a 768 kHz bandwidth – this takes around 45 minutes to complete.

With go2MONITOR you can also record the bandwidth IQ data. With this you can do two things. Firstly you can run it through as a normal playback, classifying and decoding as you go. Secondly though, you can open the Results window which gives you a time based view of the whole recording allowing you to immediately see any transmissions. Unlike SDRC Analyser, the signals have already been classified, and more importantly, this is done straight away without any need to create an XML file first. The Results window will be covered in greater detail in a blog of its own.

Analysing a Wav file made using the IQ recording capabilities with go2MONITOR
Further analysis of a STANAG 4285 emission within the recording.

However, there are no decodings here. With just an IQ recording you need to play it back and run an emission search etc. There are some basic automation tasks available, such as setting up an emissions search every 10 seconds.

But, if you have the Automated Monitoring and Tasking package, you can also have the software automatically record, recognise and decode a single emission type – or all emissions types within the bandwidth, a set frequency, between two frequencies or any other parameters you may wish to set up.

The go2MONITOR results window of a IQ recording that has been set up to automatically run an emissions search every 10 seconds. The blue rectangles are every emission found. By running the mouse of them you can get basic information on each emission. Clicking on them brings further details that can be viewed in the tabbed area to the right.
The red rectangles are emissions that have also been Recognised and Decoded. By clicking on them the decoded data is shown in the tabbed area.

The list of SDR’s that can be used with go2MONITOR is pretty good, though due to the target audience, many of them are high end, “government/military” receivers. But, it does work with Perseus, SDRplay RSP1 & RSP2, RFSpace NetSDR and SDR-14, and of course AirSpy R2 – and now the AirSpy HF+ and AirSpy HF+ Discovery.

Supported receiver list:

ReceiverMax. Rx bandwidthSpectrum overviewScanRemark
AirSpy2 MHz  Experimental support
CommsAudit CA78515 MHz  VITA 49
Grintek GRX Lan1 MHz   
IZT R3xxx series20 MHzXXUp to 3 channels  spectrum
IZT R4000 (SignalSuite)1 MHz  1 channel only
Microtelecom PERSEUS800 kHz  Limited USB 3.0 compatibility
narda® NRA-3000 RX320 kHz   
narda® NRA-6000 RX320 kHz   
narda® IDA 2320 kHz   
narda® SignalShark®331020 MHz  VITA 49 support. Only 1 MHz and no receiver control at LINUX
PLATH SIR 211020 MHz  LINUX recommended. External receiver control only
PLATH SIR 21154×20 MHz  External receiver control only
PLATH SIR 511012 MHz  16×768 kHz subbands External receiver control only
PLATH SIR 5115Full HF  40×768 kHz subbands External receiver control only
R&S EB5005 MHzX No gain control available
R&S EM100 / PR100500 kHzXX 
R&S ESMD15 MHz  External receiver control only
RFSPACE NetSDR2 MHz   
RFSPACE SDR-14190 kHz   
RTLSDR/Noxon USB-sticks3.2 MHz  Experimental support. Continuous signal up to 2.4 MHz
SDRplay RSP1 & RSP26 MHz  Experimental support
ThinkRF R5500-4086.25 MHz  VITA 49
ThinkRF R5500-4276.25 MHz  VITA 49
ThinkRF WSA5000-408780 kHz  VITA 49
ThinkRF WSA5000-427780 kHz  VITA 49
WiNRADiO G31DDC800 kHz   
WiNRADiO G33DDC4 MHzX  
WiNRADiO G35DDC4 MHzX  
WiNRADiO G39DDC4 MHzX Up to 2 channels + spectrum
Generic VITA 49 receiver supportMax. receiver bandwidth  Can be configured in a wide range for different receiver types
Other generic “Winrad ExtIO” supported receiversMax. receiver bandwidth  Experimental support

As you can see, there is a huge difference in bandwidth capabilities for each receiver. I use my WinRadio G31DDC quite often with go2MONITOR, but the AirSpy HF+ Discovery (not listed as i’ve only just got it working) isn’t much worse with it’s full 610 kHz bandwidth.

When you think that the G31 has a much better operational bandwidth than 800 kHz when you use it on its own, it’s obvious which is better value if you were buying an SDR solely for using it with go2MONITOR. It is this kind of thing that many Government agencies are looking at when it comes to funding operations aimed at large scale monitoring.

That then is a very basic overview of go2MONITOR. The quick video and images have hopefully shown you a little of what is possible.

Outside of a Professional SIGINT operation, why would an amateur radio monitor need something like go2MONITOR? And would they pay the price?

I think they would. After all, most of us have spent a fair amount on radio monitoring over the years, so why not on software that would make their monitoring not only quicker and easier, but potentially open up new areas of monitoring.

Many of us specialise in certain monitoring areas – Russian military, particular the Navy and Strategic aviation for me for example. With go2MONITOR I have already used it to hunt out potential Russian Northern Fleet frequencies by running an automated 10 second CW emission scan overnight within a bandwidth block. By doing this, and then analysing data found in the results window, I was able to target certain frequencies to see what activity there was on subsequent nights.

Whilst there are other decoders available – some of which are plugins in software such as SDR#; some of which are free – it is the quickness and ease with which it can be done that makes go2MONITOR attractive. The big question is, would you pay for this?

Exercise Joint Warrior 192

Sunday the 6th of October 2019 sees the start of Exercise Joint Warrior 192.

Royal Navy Type 23 Duke class FFGHM HMS Sutherland (F 81) went into Faslane, here passing the Cloch lighthouse near Gourock.

Taking part primarily to the North West of Britain, mainly off the coast of Scotland, the exercise brings together a number of navies and ground forces for two weeks of training.

Despite media headlines such as “Joint Warrior 19(2) features 17 countries, 75 aircraft, 50 naval vessels and 12,000 troops” this isn’t the JW of old. It is one of the smallest, if not the smallest, in participant numbers since the exercises started and the headlines are completely incorrect – in fact most of the headlines use stock Royal Navy media notices that cover all JW exercises.

In reality, JW 192 has 16 ships, will not really go over 30 aircraft at any one time and feature nowhere near 12,000 troops. Rumours have it that the exercise would have been cancelled had not the French elements insisted on it taking place. Unfortunately, media outlets have misinterpreted some of the RN notices as ships from other countries – such as Japan – participating, when in fact the countries have sent a number of officers to observe or be trained in the handling of exercises.

This JW has coincided with other NATO exercises – Dynamic Mariner/Flotex-19 for example -which are taking place in far sunnier climes, so the draw of the rough seas and bad weather of Western Scotland was not so great on this occasion. And with NATO forces spread out on real world tasks, the number of ships, aircraft and personnel required to cover all of these exercises is low.

The weather has already taken its toll with some of the first few days activities cancelled due to high sea states. Whilst you could argue that surely they should be able to “fight” no matter what the weather, in reality in the real world, operations do get delayed because of this. For exercises though, safety must come first. However, MPA activity is taking place with at least three flights up at the time of writing on Monday 7th October.

One saving grace for the number of ships and personnel that are taking part is the fact that Exercise Griffin Strike is shoehorned into JW192. Griffin Strike is a training exercise for the Combined Joint Expeditionary Force (CJEF) involving the UK and France and which is due to become fully implemented in 2020. Griffin Strike will contain the Amphibious part of JW192.

There are no visiting fighter aircraft from other countries, but there are the usual Maritime Patrol Aircraft (MPA) consisting of 2 x US Navy P-8’s, 2 x Canadian CP-140’s and 2 x French Navy Atlantique ATL2’s. These are operating out of Prestwick again, likely doing the usual 4 hours “on-station” missions. This means that there will likely only ever be two or three airborne at any one time with a 1 hour or so transit each end of the flight. Callsigns so far have been OCTOPUS** and SUNFISH**(FNY), DINKUM** (RCAF), GROMMET** and DRAGON** (USN).

My friend, Rob Banks, captured most of the MPA participants on October 4th.

Also out of Prestwick will be mixed Royal Navy and Royal Air Force Hawks, along with Cobham Aviation Dassault Falcon 20’s acting as enemy aircraft. For information on how the Falcon 20’s operate read my previous blog on monitoring Joint Warrior.

There will be other aircraft movements of course, with RAF Typhoons playing their part. Also expected are E3’s of both the RAF and NATO fleets, RAF Sentinel and Rivet Joint aircraft providing ISTAR support and Air to Air refuelling from RAF Voyagers and C130’s. I would also expect F-35’s from 617 Sqn at Marham to be involved in some form, though I can’t confirm this for sure. These will all be operating from their home bases.

The aviation side of the exercise is capped off with plenty of helicopters operating from both land and sea, with Chinooks operating from Lossiemouth and most ships providing one or two various types. I was able to watch one Chinook, ONSLAUGHT01, practising a deck landing on RFA Lyme Bay (using callsign 4QW) to the front of my house in the Firth of Clyde. Lyme Bay later tweeted the event.

The most disappointing aspect of the exercise is the maritime part. The ships are sparse in numbers in comparison to previous exercises, with a light participation by the Royal Navy. The RN is providing Amphibious Assault Ship HMS Albion, possibly using her Landing Craft Utility (LCU) Mk.10 class vessels operated by the Royal Marines. Albion is the current RN flagship. Also taking part is Duke (Type 23) class FFGHM HMS Sutherland and a small number of Minesweepers and Minehunters.

Royal Navy Albion class LPD HMS Albion (L14) approaching Faslane

**Edit: RFA Lyme Bay is now also confirmed as part of the exercise. RFA Argus and RFA Tidesurge are also now confirmed.

France has also sent a Amphibious Assault Ship in the form of FS Tonnerre, a Mistral class LHDM. Tonnerre can embark 450 fully kitted troops and 60 armoured vehicles or 13 main battle tanks, along with Landing craft and up to 16 helicopters. No helicopters were observed on deck as she arrived at the Greenock area on Friday 4th October 2019 – it is not known whether they, if any, were on the hanger deck. The same goes for APC’s/MBT’s on the lower decks.

French Navy Mistral-class Amphibious Assault Ship FS Tonnerre (L9014)

Modified Georges Leygues class FFGHM FS La-Motte-Picquet arrived into Glasgow on the afternoon of 2nd October along with Éridan (Tripartite) class minehunter FS Cephee going into Faslane earlier in the morning.

French Navy Modified Georges Leygues-class DDGHM La Motte-Picquet (D645) arriving into Glasgow

The German Navy has sent a single ship – the Berlin (Type 702) class replenishment ship FGS Berlin – whilst the US Navy, who normally send a number of frigates and cruisers, have only sent Military Sealift Command Lewis and Clark class dry cargo/ammunition ship USNS William McLean.

German Navy FGS Berlin (A1411) arrived early, on a very murky morning.

Finally, Danish Navy Iver Huitfeldt class FFGHM HDMS Iver Huitfeldt is also participating, but due to other tasks is heading straight to the exercise area rather than going to Faslane for the pre-exercise briefings.

US Military Sealift Command Lewis and Clark class USNS William McLean (T-AKE12)

For submarine participants, Norwegian Type 210 (Ula) class SSK Utsira is one of the MPA targets. She arrived earlier in the week and departed on Sunday 6th October as the exercise began.

Also, an Astute class SSN of the Royal Navy departed Faslane on friday 4th. Though not confirmed, again it is highly likely to be taking part in some form or other.

Unknown Astute class SSN departs Faslane

As well as areas in and around Scotland, it is highly likely there will be the usual missions around the Spadeadam Electronic Warfare Tactics range and possibly areas out over the North Sea. GPS jamming also normally takes place as part of the exercise, normally out in danger areas situated to the NW, over the sea.

There should be Maritime Gunnery firing off the west coast of Scotland. Timings and areas are normally reported via the Royal Navy’s Gunfacts service either by a recorded telephone message and on NAVTEX at 0620 and 1820 UTC. Coastguards also broadcast the details at 0710, 0810, 1910 and 2010 UTC. If you happen to be in the area where gunnery is taking place then the duty broadcast ship sends out details at 0800 and 1400 local, or 1 hour before firing, by making a call on Maritime channel 16 and then the appropriate broadcast frequency for the area.

The navy also provides SUBFACTS warnings on submarine operations on the same telephone hotline and NAVTEX.

NOTAMs will also be available that provide warnings on most of the activities taking place. A good place to look for these is on the NATS AIS NOTAM page.

The amount of frequencies used for the exercise is huge, and near impossible to list. However, there is a list of VHF/UHF and HF frequencies on my Monitoring Joint Warrior Exercises blog from 2014. Despite being 5 years old, the HF freqs tend to be the same especially those used by the MPA’s when communicating with Northwood (Callsign MKL).

Noticeable so far has been the fact that the P8’s and CP140’s have both been out on their frequencies by 1.5 to 2.0 kHz when calling MKL on 6697 kHz (primary freq) and 4620 kHz.

The VHF/UHF frequencies won’t have changed that much either, but as most of the exercise is at sea, and generally out of range of most of us, it is hard to gather them all. Certainly the standard Swanwick Mil, A2A and TAD’s will be used, so if you have these you’re bound to get something.

Murmansk-BN HF EW Complex

Murmansk-BN of the 475th Independent EW Centre near Sevastopol

Brief Murmansk-BN overview

Murmansk-BN has been operationally active from at least 2014 when the 475th Independent EW Centre of the Russian navy set up a complex in the Crimea south of Sevastopol. The system has a primary role of eliminating, or trying to eliminate, High Frequency (HF) broadcasts from NATO forces – in particular the HF Global Communications System of the United States (HFGCS).

HFGCS operates on well known HF frequencies with regular broadcasts of Emergency Action Messages (EAM’s) and other operational messages, phone patches etc. as required. To this date though, I am unaware of any reports that HFGCS has been interfered with by jamming. This in itself isn’t surprising. HF is a difficult thing to jam due to the very nature of using the ionosphere to carry the broadcasts. Throw in multiple frequencies in use at the same time, the same message being broadcast on numerous occasions, propagation and all other things related to HF reception means the message is likely to get through regardless of the attempts made to jam.

The Murmansk-BN complex is a fully mobile system and comprises of groups of up to four extendable antenna masts – two of which each on a dedicated Kamaz or Ural truck, which then tows a further antenna on a trailer. The masts extend to 32 metres in height. Each full Murmansk-BN complex normally has four of these antenna groups, making 16 antennas in total.

Further to that there are numerous support vehicles including a Kamaz 6350 Command vehicle and a Kamaz 6350 generator vehicle per four antenna group. Other vehicles include fuel bowsers and troop transport. Not always four antennas are used per group.

Murmansk-BN is in operation with units of both the Russian army and the navy – for the army with the 15th EW brigade in Tambov, 16th EW Brigade in Kursk, 18th EW Brigade in Yekaterinburg and 19th EW Brigade in Rassvet – for the navy with 186th Independent EW Centre of the Northern Fleet in Severomorsk, the 471st and 474th Independent EW Centres of the Pacific Fleet in Petropavlovsk-Kamchatsky and Shtykovo respectively, the previously mentioned 475th Independent EW Centre of the Black Sea Fleet in Sevastopol and the 841st Independent EW Centre of the Baltic Fleet in Yantarnyy.

It is highly likely that the 17th EW Brigade at Khabarovsk also has Murmansk-BN in operation but a this time I haven’t been able to locate any of the systems.

Screen grab from one of the Murmansk-BN videos showing an Icom IC- R8500 in use as the main receiver in each command vehicle
AOR 500 in a R330ZH Zhitel – image credited to
twower.livejournal.com

One aspect about the system is its use of analogue receivers rather than Software Defined Radio (SDR) technology – Icom IC-R8500 receivers have been noted in all the video footage available so far. This isn’t unusual for Russian EW systems – the AOR 5000 receiver is used in R330ZH Zhitel which is a mobile system primarily used in the jamming of satellite and cellular phone communication systems operated in the 100 to 2,000 MHz range. The AOR 5000 has multiple versions available, one of which has the cellular bands (824 to 849 MHz and 869 to 894 MHz) unblocked. Zhitel was used in the Crimean conflict with the high likelihood that the AOR 5000 was used to jam or intercept mobile phone communications. Recent reports have shown that Zhitel is still in use in the occupied Luhansk region.

I use an R8500 myself and it is an excellent receiver. I normally use it in conjunction with my SDR’s that provide me with a wider view of the HF bands so that I can search out signals. From the videos available online, the Russian military don’t do this but instead slow scan manually through the bands or scroll through frequencies saved to the receivers memory bank.

The receiver is linked to a PC using software that shows a visual spectrum taken from the audio output from the R8500, but this is limited to the mode in use. Video footage shows the likely use of AM mode to give as wide a visual spectrum as possible but this would be limited to the R8500’s 12 kHz maximum bandwidth. More on the software later.

The slow scan/memory scan method is not the best and would likely mean that any interception would be caught mid-way through a message. It is also time consuming. I am highly surprised there isn’t some sort of auto-scan software included. For instance I personally use df8ry’s CSVUserListBrowser to control not only my R8500 but most of my SDR’s. This can scan through stored frequencies on the Icom at a slow 1 second pace, but its better than sitting there turning a knob continuously for hours.

As the Icom is a receiver only, it needs to be linked to a transceiver using its CI-V remote jack point that then sends out the jamming signal – whether this then means another Icom transceiver is located within the command vehicle is unknown as, whilst confirmed from commentary and interviews with Russian personnel in the videos I found, there is no visual confirmation of what is used as the transmitter.

Each antenna group can operate individually or as multiples. Reports also state that the complexes can be integrated into the Russian EW command and control system.

The software

The software in use cannot be identified. It appears to operate like an automatic signals classifier, such as go2MONITOR by Procitec, but it is hard to assess whether it has this capability. It would be unusual not to have a classification capability, even if it meant manual selection of a signal.

There are a number of different screens, some tabulated, that control different functions, or provide different data.

One screen shows spectrum information split into four panels. The top panel shows the selected frequency, and what looks like audio taken from the Icom in AM-Wide mode – this differs from cuts to the Icom itself which shows it is in AM mode. If in AM-Wide it would mean the maximum audio spectrum available would be 12 kHz as this is all that the Icom can manage in this mode below 30 MHz, whilst AM would only produce a 5.5 kHz wide spectrum. However, using either of these modes would make it possible to visually obtain a signal from this.

What is interesting here though is that in the video, the top panel appears to show a bandwidth spread of 30 kHz with an area of 6 kHz in a lighter colour, possibly depicting the true area that a signal can be classified or monitored. 30 kHz is not a selectable bandwidth for the R8500 in any mode, with the maximum possible being 15 kHz above 30 MHz in WFM mode. Also of note is the noise floor indication which appears to be between -40dB and -50dB.

It could well be that this panel does not actually show a signal from the Icom, but could be the panel that shows the transmitter that produces the jamming signal.

The next two panels appear to show the signal with sensitivity information from the incoming audio. The final panel is unknown as it is not shown in any video close-up.

Another screen shows interface information to the bottom left. This has a number of tabs that control some the external elements that assist in the suppression of a signal. Connection status is shown by a green or red button.

Firstly, one tab shows the connection to a Protek KS-100M navigation device which is a GPS unit. This is connected to an antenna mounted to the top of the command vehicle and provides an accurate position for probable signal reception direction finding/triangulation purposes when connected to the other command vehicles KS-100M’s.

The KS-100M is also found in the Zhitel system as shown here in the far right panel. It is used for Direction Finding purposes in both systems – image credited to
twower.livejournal.com

To the left of the KS-100 tab are two unknown connections marked as ГТ-11and ГТ-11.1 (GT-11 and GT-11.1). ГТ in the Russian military is normally an abbreviation for rehepatop which translate to generator. In another part of one of the videos it shows the ГТ-11.1 title again, this time with four green boxes, each with what appears to be a tick box. Two of these appear to be connected as there is a joining line between them.

The final tab is unknown but marked as ГТ-205-ОПМ (GT-205-OPM) which if using the standard abbreviation format would also be related to a generator. However, the generator shown in the video appears to be named as an AD-100-T400-1R. Alternatively, you could break down the OPM part into two which would give supply (OP)/ engine (M).

What doesn’t quite tie up is that each four antenna group only has one generator, so does this section actually have something to do with the four antennas themselves and whether they have power going to them?

Above the four tabs is a box that is titled Information about current IRI. Below this is information on the signal being suppressed: Frequency – 9 961 02 kHz Type of target – unclassified Bandwidth – 3.36 kHz Duration – 16 msec Strength – 16 dB Bearing – 179 7 (1) – 0

This box is likely associated with the KS-100M tab.

The large window to the right shows what I thought at first was historic signal information in the selected bandwidth. However, looking closer I wonder if this is the case as the “signals” are too regular – they are evenly spaced. In other shots there are up to 20 signals shown. My thoughts are that these are connected to the KS-100M and are signal strengths of GLONASS GPS satellites. But again, without clearer screenshots or a confirmed ID on the software in use, this can only be guessed at.

There are numerous other tabs and screens available, but these are unreadable in the videos found.

Locations

The various units I have listed above. The sites used so far, despite Murmansk-BN being fully mobile, have been very close to the units home base. Despite the area required for a full complex deployment being large, they can be difficult to spot, but once you know the locations used – or the area – then it makes checking on them relatively easy.

The 15th EW Brigade at Tambov has not been observed on Google Earth (GE) as deployed as yet but the vehicles can be seen at their HQ at 52.666385N 41.537552E

Latest 15th EW Brigade site imagery near Tambov. Dated 13/11/18 and is the first time the Murmansk-BN was observed here.

The 15th EW HQ is situated in a large area of military ranges with plenty of surrounding free land available. It is presumed that this area will be used when setting up the complex. There is also an area to the NW that previously contained numerous antennas, but is now disused.

The 16th EW Brigade at Kursk uses a military training group for its deployment site. Only two antenna groups have been observed since first deployment in April 2015.

Latest 16th EW Brigade site imagery near Kursk at 51.713194N,
36.290736E. Dated 3/9/19

The 18th EW Brigade at Yekaterinburg is a very active unit with just two Murmansk-BN antenna groups in use at any one time according to GE imagery. Moreover, it seems to be a unit that likes to train in setting up the complex as it is quite often observed in different states. The Murmansk-Bn is spread over two sites – a permanent one (site one below) and a secondary site located in a field about 1.6km away (site two). In some imagery of site two only one antenna is up in two “groups” and quite often the site is empty.

The continuous erecting and disassembling of the complex’s could hint at the unit being involved in training. As shown in the image below it also tends to use truck mounted antennas at site two. There are no trailer mounted antennas visible, whilst they are in use at site one. However, the fact that there are six truck mounted here points to the 18th EW having a full compliment of Murmansk-BN equipment, despite only using two groups at the same time.

Murmansk-BN equipment of 18 EW Brigade at site two in a stored state

The 18th EW was also used in one of the videos. Comparing the video to GE imagery I was able to identify various features that confirmed that site two was used for the filming.

Site two confirmed as used in the Pravda.ru video

The 19th EW Brigade at Rassvet, near Rostov-on-Don, has had Murmansk-BN since at least 19/6/2016 when equipment first appeared in GE imagery at the HQ. Since then it would appear that it has not been deployed as the vehicles have stayed in a parked up state in all imagery from that date. The number of vehicles indicates only two groups have been allocated to the Brigade so far.

19th EW Brigade HQ in latest imagery dated 15/2/19

On the Russian navy side of things, the 186th Independent EW centre is based near Taybola at 68.515306N 33.290056E on the old airfield for the town. Taybola used to be a Soviet R-14 (SS-5 ‘Skean’) intermediate-range ballistic missile (IRBM) base with at least two silo complexes, a rail head, and the airfield.

The latest imagery on GE has just two Murmansk-BN groups set up at the northern end of the runway and old dispersal, but older imagery has a further group half way down the runway to the south.

GE imagery dated 18/8/17 showing the three locations of Murmansk-BN groups. the 186th has had the Murmansk-BN capability since at least 20/8/15 according to GE

The 471st Independent EW centre at Petropavlovsk-Kamchatsky, has a full complement of four Murmansk-BN antenna groups though it has had differing numbers in use since the system first arrived from at least 15/8/15. The latest imagery on GE below, dated from 3/11/18, shows just about a full complex in use. The NW group has one antenna missing.

471st Independent EW centre situated at 53.053583N 158.828178E

The 474th Independent EW Centre at Shtykovo, is also sited at a disused airfield. It has had three antenna groups in place at least once, but the latest GE imagery has just two in use.

The actual location of the 474th HQ is unknown and there no immediately close active military bases. There are numerous bases at a distance away, with a potential SIGINT site 12km to the SW. Analysis of these don’t provide any other Murmansk-BN vehicles.

The 475th Independent EW Centre is probably the most well known of the Murmansk-BN deployments. It is located to the south of Sevastopol in the Crimea at a coastal base and has been widely exposed on social media and articles since it became active. First shown in GE imagery dated 15/11/14 with one group, it has expanded to a full four group complex.

The 475th complex shown here, dated 26/8/18, with just the NW group active

It was news about the deployment of Murmansk-BN to the 841st Independent EW Centre at Yantarnyy in the Kaliningrad Oblast that drew my attention to the system. It is known that the 841st has a full compliment of four antenna groups but it is unusual to see all deployed. The image below, dated 11/9/17 is one of those times that it is fully active.

It is usually the northern site that is active when the 841st deploy. This is situated at 54.832506N 19.958467E. The “town” of Okunevo is actually a comms site.

The news I mention was reference the “new” deployment of Murmansk-BN to the Kaliningrad region, yet what is strange is that from GE analysis it is obvious the system has been in use there since at least 11/4/16 – so why this sudden hype? My only thought is that there was a major NATO exercise on in the region at the time which included USAF B-52’s carrying out Global Power missions from the US to Europe.

Was this news a counter to the US stating that Russian forces could interfere with their operations?

From all accounts, and from reported loggings of HFGCS messages since the Murmansk-BN system has been available for use, there has been zero suppression of any HFGCS frequencies that I’m aware of.

This then, with the fact that most units have not fully deployed their systems, makes me wonder whether Murmansk-BN is not quite so good as expected and claimed.

Here are the videos used for analysis:

This is the longer of the two videos and actually contains the second one.

https://www.yacoline.com/video/168091/

Second, shorter video showing the 186th Independent EW centre

SDR Console V3 analyser

The shack, finally operational after a few months off.

With the rebuild of my shack complete I’ve been able to start testing out all my radios, new connections etc.

The Mini-Circuits components all come well packaged in anti-static bags

A whole bundle of new cables from Mini-Circuits arrived last of all and have helped tidy up the back of the radio 19″ rack considerably. I’ve previously installed quite a few Mini-Circuits components, including 0.141″ diameter Hand-Flex interconnect cables, and so it was more of these that I opted for. The bonus with these cables is that they are hand formable meaning you can shape and bend them into pretty much any area that you want to. The 141 series (which I use) are capable of a 8mm bend radius, whilst the thinner 086 series can be bent to 6mm.

Being able to manipulate the cables certainly helps in tight spaces, and when you don’t want them to hang down

Previously I used hand-made cables with RG58U coax, but in order to have a 19″ rack that can slide out from under the desk, the cables needed to be longer than actually required. Because of this the cables would drop down into all the others attached to the PC and in some cases cause a little interference. With the Hand-Flex cables I’ve been able to use the same length of coax to allow me to move out the rack, but be able to bend them up and out of the way of the PC cables.

They’re also very good for the radios on the rack, being able to bend them and hold in place around the radios and other cables. They are near lossless too with a quoted insertion loss of 0.01 dB in the HF band to 0.55 dB at 18GHz. I normally run tests of the Mini-Circuit components when I receive them and find that the figures quoted are near spot on. I highly recommend these cables if you’re looking to upgrade your systems, and are available from the Mini-Circuits website, along with lots of other goodies that will tempt you.

Measurement of insertion loss of the Mini-Circuits ZF3RSC-542B-S+ Power Splitter/Combiner I also purchased as part of my plans for satellite communication monitoring. This is connected to the AirSpy SDR and takes feeds from two SatCom connections (currently deactivated) and a WinRadio AX-71C Discone Antenna. Mini-Circuits quote an insertion loss of around 19.5dB at 130 MHz which is confirmed here with a signal generated at -20dB being less than 1dB out at -40.48dB when passed through the combiner.

This image shows how the cables can be held in place without cable ties

The radio setup now includes two new SDR’s – an AirSpy HF+ and a standard AirSpy with the HF+ replacing the Enablia TitanPro. I’ve also reinstated my WinRadio G31DDC which had been in storage for a year or so. I really do like the TitanPro, and have put it into storage for the time being. The recording capabilities in particular are great with it being able to select 40 frequencies at once spread over numerous bandwidths, but I have had issues with the power supply – one being it caused interference. I attempted to make one of my own but it has a 6v(+/-1v)/2.5 Amp current requirement and no matter how many different methods of building my own supply using a 12v feed downgrading to 5, 6 or 7 volts, it just wouldn’t work in a stable manner. In the end it was easier to remove it and slot the G31DDC back in its place.

As it is, I’d forgotten how good the G31DDC is and I don’t really feel like I’m missing much thanks to the ability to use the other SDR’s with SDR Console V3 and it’s SDR Analyser.

The three 19″ racking units from Penn Elcom, along with all the shelves, have been very useful and certainly makes things easier when it comes to changing radios and connections over. I can just disconnect a few things and slide the whole unit out. I also obtained a 19″ Project box from them which I used as my main 12v switch unit. This is connected to two regulated desktop power supplies that act as master switches.

Although the SDR Console website page for the Analyser states it isn’t available yet, this is incorrect and it is downloaded with the latest version of the main programme.

If you’re a current user of V2 or have been in the past then you won’t notice much difference. You can have up to 24 parallel demodulators operating within the SDR’s bandwidth that you have chosen, all of which can run independent of each other in receive and record. You can also run each demodulator through a decoder such as MultiPSK independently and decode these in parallel with each other. This capability has taken that step towards those of the TitanPro, especially when being used with the Elad FDM-S2 that can provide a Maximum DDC bandwidth of 6144kHz’s.

Unfortunately, whilst you can schedule recordings of IQ data, you still can’t do this for individual channel recordings. This is a real shame as it would be a fantastic addition to the capabilities of SDR Console.

Getting back to the analyser though this does, in theory, cancel out the lack of channel recording scheduling.

When you record IQ data it is saved as WAV files, split into multiple ones depending on how long a recording you make . All of these files can be individually played back through the incorporated SDR Console player but even better is the use of the File Analyser.

With this you get a visual “image” of the complete recording, whereby after opening the analyser you get it to combine all the files into one XML file. For the image below I used the FDM-S2 with a selected bandwith of 768kHz centred on 4425kHz, hoping to catch calls to Russian Naval base Severomorsk in CW(RJD99) from ships operating in the region. I set the scheduler up to record from 0000z to 0700z which worked perfectly, giving me 78 files totalling 78GB – obviously, the bigger the bandwidth, the larger the total file size.

After clicking on New in the analyser and browsing to the relevant folder the WAV files are saved in, the analyser finds the first one and gives this as an option to open – it automatically adds the remaining WAV files and starts the process. This can take quite some time to extract, around 45 minutes for the example shown. But you only need to do this once because once it has finished you can save it as an XML file and open it at any time – in this case it was a 28MB XML file.

A note here – do not then delete the WAV files as the analyser still needs them.

As you can see, I was successful in locating calls to RJD99, and I have highlighted some of the others that I took a look at – this is just a screenshot of two hours out of the seven recorded.

All you then need to do is find any signal of interest, and after clicking on select and start in the top ribbon, click on the signal. This will then start playing the file from that location in the main SDR Console window. You don’t need to stay on that frequency, you can use the Console as if you were listening live and move around the frequency range you dictated in the bandwidth of the recording.

And, as it is basically a live screen you can do additional things such as record and use decoding software.

RJI92 calling RJD99 on 4416 kHz during playback of the Analyser

When using the Analyser I run this through a separate PC meaning SDR Console itself can carry on working on the main radio control PC. This is also handy if you’re away but have time to go through the IQ data using a laptop. Just copy over the original WAV files to a portable hard drive/memory stick and carry on as described above.

There are numerous other functions available for you to use with the main part of SDR Console, some I still haven’t had the chance to play with completely. I’m still exploring things such as the Signal History function which can store up to 48 hours of data. Here you can export data in CSV format to third-party programs such as QtiPlot. Signal history can also be used within the Analyser

This is useful as it can give you a quick overview into single frequency use, signal strengths, fading and such like. Definitely something I need to spend more time on.

It’s been a long time coming, but Version 3 of SDR Console has been well worth the wait.

A quick update & Roland Proesch Radio Monitoring books 2018

Firstly, a quick update on what’s been going on with me.

In the world of radios, ships, photos and Russians – not a lot!! No blog since September 2017 wasn’t what I had planned that’s for sure. Much of my writing time has gone to Jane’s, which has been great. This has meant I had to prioritise any free time available to them, having to put my blog on the back burner. Overall I’ve written or carried out analysis for around 10 Jane’s magazine articles since September 2017, as well as my continual fleet analysis on the Russian navy for Fighting Ships.

One of my articles from the November 2017 edition of Jane’s Intelligence Review

With regards to any radio monitoring, that also had to go on a back burner. When the shack was rebuilt as part of the house renovations I installed all the coaxial in temporary locations, drilled through the outer wall and coming into the shack through a large 50cm by 30cm hole in the interior plasterboard wall. This was in April 2015!! Hardly temporary!!

Due to the pretty crap weather we get here, and the fact that I needed at least 5 days of continuous good weather to be able to do all the connections outside, it has taken until the last week – 3 years later – to finally get the sunny days I needed at the same time as being off work.

Over the last year, the temporary connections had become worse and worse, with lots of noise causing interference. Nothing was earthed correctly either. Other factors such as the neighbours installing dreaded solar panels really screwed up everything, totally wiping out the main Russian navy day frequency they use for CW.

Not only that, with the hole in the interior wall being the size it is, it gets very cold in the room during the Winter – and the rest of the year for that matter – with a large draft blowing in most of the time.

Anyway, new outside connections are complete, in nice new waterproof boxes. Now the exterior part is done, I’m not weather dependant on the rest of it and hopefully I’ll be back up and running in the next month or so. I’ll do a full blog on the new setup once it’s complete.

Roland Proesch Radio Monitoring books 2018

For 2018, Roland Proesch has updated two of the five books he creates in his Technical handbook range.

The first is Signal Analysis for Radio Monitoring Edition 2018. This has nearly 60 new pages of information on how to analyse various waveforms, including a new section on Satellite signals – useful if you’ve already purchased his Technical handbook for satellite monitoring 2017. There’s also a section on describing how to analyse RADAR signals. Other things such as useful software tools and PC calibration is also included. Here’s a PDF of the contents with new information highlighted in yellow.

The other book is Frequency Handbook for Radio Monitoring Edition 2018. Whilst many people would say a book containing information on frequencies used by various utility stations, armed forces and other agencies is dated and old school, I tend to disagree. There is so much useless information out there online, I prefer using a book for looking things up that I may have found on the HF bands. Granted, a book does go out of date – normally as it’s being printed – but you can quite easily add your own entries in the right places if needed.

This update has several hundred changes of new, deleted and updated frequencies ranging from 0Hz to 30000kHz, and contains a section dedicated to ALE frequencies and idents.

Both books, along with the ones released last year in one of my previous blogs, are available from his website. As usual, he has his bundle offers which makes the books cheaper if you buy two or more at the same time.

I’ve used his books for years and highly recommend them.

Liman follow-up

Well, it’s a couple of days now since my blog on the Liman incident went live. I’ve had some great feed back on my coverage.

There has however been one individual that has not liked it so much. This is Steffan Watkins, owner of the blog Vessel of Interest. Mr Watkins was one of the unnamed characters I referred to in the Liman blog. He is widely regarded as a conspiracy theorist, and even has to go to the extent of denying it on his own blog. Whether he is or isn’t is irrelevant really.

Interestingly, a recent piece of work I was asked to do for Jane’s Intelligence Review magazine was to analyse an image of Russian navy Vishnya-class AGI Viktor Leonov to try and work out the various intelligence gathering systems that may be on board via all the different antennas visible. The actual article was written by Mr Watkins.

Now, up until this stage I really didn’t pay much attention to anything Mr Watkins wrote, mainly because what he wrote was aiming towards being the aforementioned conspiracy theories. But, he kind of came through with an interesting article – though it was nothing I didn’t know, as a group of us have been following Viktor Leonov for a few years now.

So, why hasn’t he enjoyed my blog? Well, I suggest you read it and see what he has come up with, and then come back here where I’ll answer his “questions”.

Hopefully, then you have read his blog on Liman now.

Firstly, lets talk about the “expert” part. He seems to think that I am condescending towards others from my comments. I am fully open to ideas and theories if there is evidence to back these ideas up and people also listen to what is being presented to them. In this case he did neither. And my references to things such as the Heather Sea evidence is clear – the ship wasn’t involved, it never was and yet people were still saying it was (not Mr Watkins I hasten to add, he hadn’t looked into anything outside the bubble of Liman). It was a quick and easy search through AIS history to see that it wasn’t, and yet people weren’t doing this. My reference to not being an expert is correct. I have no qualifications in the field of Radio Communications, I do not have an amateur radio licence and such like. I do not have a degree or a masters or any other diploma in the theories of radio – therefore I am not an expert. In ATC we have engineers that are experts in that – I wouldn’t dare tell them their job, just like they wouldn’t tell me how to keep aircraft apart. This is the reference I am making to being an expert.

He also mentions banter on twitter. There was no such thing, certainly not in my eyes. I’ve been around banter for decades – in the forces you need to be able to take it, and give it – and it is actually worse in the world of ATC. I can recognise banter when I see it. He also mentions an exchange of ideas. Yes there were exchanges of ideas, but he really wasn’t coming up with anything of substance. Instead, from his comments, he gave a picture that there was a conspiracy behind the incident – there had to be something because of the nature of the ship involved – an Intelligence Gatherer.

He actually says this in his blog:
Any ship could have an accident while at sea, in the fog, early in the morning. But, this wasn’t “any” ship; just by being a Russian Navy AGI (a “Spy Ship”) it makes me +1 suspicious. There is no good rational basis for that suspicion, except it’s a Russian Navy AGI, it definitely has sensitive gear aboard, and having it sink leaves a gap in whatever task it was doing, on the deployment it was on.

Why does this receive an extra degree of suspicion? Oh, that’s right, there’s no rational explanation, it’s just suspicious.

I wonder what Mr Watkins reactions were to the collision between a French Navy SSBN and a Royal Navy SSBN in the middle of the Atlantic in 2009. Holy shit, the French are at it again, trying to sink our navy 🙂

He refers to the fact that surely the Youzar Sif. H must have been able to have seen the Liman on radar:
The Liman was not a “stealth” ship, and as far as I understand, should have shown up on the navigational radar of the Youzarsif H; isn’t that why navigational radar exists?
Well, if two of the most expensive vessels in the sea, with some of the most sophisticated sonar and listening equipment ever made managed to thump into each other in the wide open Atlantic, then it is perfectly feasible for two ships to hit each other in thick fog in one of the busiest shipping lanes on the planet.

And it doesn’t even have to be in thick fog or underwater – ships hit each other. His Canadian navy had such an incident in 2013 in perfectly good weather when they were approaching each other.

Or there’s the Turkish Coast guard patrol boat that was hit in broad daylight, in the middle of the Bosporus, by a 158ft long Bulk carrier in August last year

Further about the radar he stated:
They were in thick fog, only navigating by instruments, and didn’t see a ship directly in front of them on radar?
Isn’t that weird?
I don’t think it reflects well on the Youzarsif H’s crew, unless the operations of the Liman were causing issues for the radar of the Youzarsif H. Yes, that’s wild speculation, because it makes no sense how a ship doesn’t notice a giant hulk of floating steel in front of it on radar. Make up your own crazy theory! It’s better than what we have now, which is nothing.

None of us know what radar system Youzar Sif. H has in place. I’ve been on quite a few ships in my time, civil and military – and of course I work with radar all the time. You get plenty of radar returns or “primaries” which you don’t know what they are, and you do your best to avoid them if you are not sure, but you have to make an assessment as what you think is a ship/aircraft and what is just weather (or a wind farm in a lot of ATC cases these days). The image here shows just a basic ships radar image, a modern one at that, so actually could be much better than the one on Youzar Sif. H – we won’t ever know I expect. Other radars are available of course, with more detail, but if Mr Watkins can work out what is what in this image then well done.

The next statement he produces is:
There have been no reports regarding who ran into who; or if it was a mutual effort. The news media is making it sound like they were both moving and collided in the fog. I’m not sure that’s correct.
He produces a list of things that could have happened – yes all obvious – but then doesn’t actual state why he thinks the news media are incorrect?? So why do you think this Mr Watkins?

He then mentions jamming of the AIS frequencies, but thankfully seems to have realised that this wasn’t the case. At the time of the “banter” he wasn’t stating that though:
See, there you go down the rabbit hole again. I’m wondering if the AGI screwed itself by engaging in EW in the same frequency range as AIS. 161.975/162.025 MHz range, within the usual Marine VHF band, right? Might explain the sketchy AIS coverage immediately prior.
Firstly, I’m still not sure what he’s referring to with EW. Early Warning?? Electronic Warfare?? Neither of which Liman is equipped for. And, secondly I went into great depths, the best I could at the time (see later) to try to explain the likely reason for the sketchy AIS coverage – all of which he kind of brushed aside for his more extreme likelihoods. Here, again he gives the air of being a conspiracy theorist.

We now get on to my favourite part of his blog:
•The Youzarsif H’s AIS signal was being received by terrestrial based AIS receivers, which Mr Roper described in his blog post with excruciating detail. The signal was very spotty before the collision, and crystal clear after the collision. This is the thing that really draws my eye and triggers my curiosity; it is the basis for much of my suspicion regarding this event. On the day Mr. Roper and I were discussing this he specifically dismissed my speculation that the issue could be related to the sender and insisted the gap in reception must be related to the receiver, or environmental conditions.
“This totally depends on the receiver not the sender! The receiver may have been off.”
-Tony Roper, 6:29 PM EST, May 4 2017
I tried to convey that my interest was less with the gap before the collision, and more with the immediate change to the signal quality (seemingly crystal clear reception) instantaneously after the collision, which Mr Roper had no explanation for at the time. It seems after reflection, he now theorizes the sender, may have had their antenna(s) facing away (blocked by the ship’s superstructure?) from the shore-based receiver when travelling Southbound (toward the Liman) and immediately after the collision turned around and faced their AIS antenna(s) toward the shore-based AIS-T receiver. This is fantastic speculation, and would explain how the signal went from terrible, to perfect, immediately, while other ships in the area had AIS-T signal all along.

Firstly, by excruciating detail I’m guessing Mr Watkins didn’t understand it. You must forgive me for trying to explain how something works instead of just giving less than half information on how something works. If he thinks my information was excruciating then maybe he should read the Propagation pages in the ARRL handbook which is spread over 30 pages. Or maybe he should go to websites such as:
Make more miles on VHF
HF Propagation tools
Or one of the many pages by Tomas Hood on propagation
It is obviously a fault of mine to make something interesting for the reader, that will hopefully teach them something.

I said above that at the time I did my best to try to explain to Mr Watkins what may have happened. This he seems to have thrown back in my face, alluding that I may have changed my mind on my original thoughts. I didn’t dismiss his thoughts but pointed out that there may have been a break in coverage. The interesting thing is the quote he has used, taken at 6:29PM EST. This was actually 23:59PM UK time, I was in a hotel room, 450 miles away from my computers and AIS systems. Maybe Mr Watkins has presumed that the rest of the planet is running at the same time as Canada, and that we were all glued to our PC’s? I made the best assessment at the time – and you know what, I wasn’t far wrong in the theory of coverage, as I proved in the blog.

He says I have “reflected” and changed my mind. No, I haven’t Mr Watkins. It’s a combination of both sender and receiver. I didn’t reflect. What I did was, on getting home, do some further analysis. Something Mr Watkins has quite clearly not done. He can only produce the same data on the what Youzar Sif. H did both before and after the incident. He still hasn’t come up with anything else – yet he has the nerve to criticise my analysis.

Come on Mr Watkins, show us some workings out. Do some actual analysis.

Here’s something for you. Data taken today from the same region.

The image below shows the tracks for various ships and their plots as received on AISLive

Holy crap – how do we explain all those gaps in the plots especially the ones on the rough route Youzar Sif. H took?? How the hell does the furthest ship away from any receivers have the best plot history?? Hmmmm, please do tell Mr Watkins. Maybe the Russians are jamming the area from outer space? Maybe there’s another AGI there?? Or maybe there’s just a poor area of reception.

The picture below shows the same area, at the very same time, but this time taken from MarineTraffic.

I’ve purposefully highlighted Reina as it is also highlighted in the AISLive image. The red ship to at the bottom is also on the AISLive image as the fully tracked ship. But what is that? MSC Eleonora is showing here, but isn’t on AISLive – what the hell?? How does that happen?? Please explain with all your worldly knowledge Mr Watkins.

Here’s some extra data for you, just so that you realise that AIS receivers aren’t on all the time (mine was off whilst 450 miles away for the weekend by the way). The three receiver examples that I used for the blog have the following averages for receiver availability over the last two months:
Istanbul = 93.3%
Burgas = 98.9%
Elena = 97.95%
So, not available all the time then.

He ends the large waffle with:
Can we prove this theory with the available data? Well, it’s certainly not as clear as I would like it to be. It is still crystal clear that immediately after the collision the AIS transmissions went from random times between successful transmissions to a steady stream at 3-4 minutes

The following day, still in the hotel 450 miles away from all my gear, I sent Mr Watkins roughly the same as the above showing a plot of another ship with the same loss of coverage. That obviously wasn’t enough evidence to make it “crystal clear”. I then produced my blog with further evidence – including an example of Youzar Sif. H with a loss of 14 hours of coverage – which again obviously wasn’t “crystal clear”, but was in fact excruciatingly full of too much detail for Mr Watkins. I have now produced the above which explains – yet again – that there are gaps in the coverage, yet other ships somehow have a better plot history. I suspect though, that all this will be far too foggy for Mr Watkins and he still will not be able to see anything clearly – except for a conspiracy.

Full analysis of the sinking of Liman

With it being a month this weekend since the Russian navy Moma-class AGI Liman was hit by another ship resulting in its sinking in the Black Sea, I thought I’d publish my full analysis on the incident.

Originally this work was created for Jane’s Intelligence Review, but due to space limitations in the magazine, it was condensed into a half page report. This blog includes all the imagery and extra text that was left out, but also some further analysis that I’ve been able to do in the mean-time. Because of this, I must state that the analysis published here has nothing to do with any IHS publication, and that any views (unless otherwise stated) are all my own.

Liman, taken in November 2015 by Yörük Işık

A brief account of what happened

On the morning of Thursday 27th April 2017, at approximately 0830z, reports on social network starting coming in that Moma-class Intelligence gathering ship Liman of the Russian navy had collided with a livestock ship in the Black Sea at a position approximately 30nm to the North of the entrance of the Bosporus Strait. There was thick fog in the area at the time of the incident.

Early information from the Russian Defence Ministry stated that Liman had collided with a ship named Ashot-7 but a search through ship registries quickly showed that this ship did not exist. From AIS analysis however, a ship identified as Youzar Sif.H had departed the port of Midia in Romania for Aqaba in Jordon at approximately 1645z on the 26th April heading for the entrance of the Bosporus Strait. The ship was carrying livestock, reportedly sheep. From the AIS data it was noted that Youzar Sif.H was cruising at a speed of 11 knots for most of the journey across the Black Sea until at 0845z on the 27th April the ship came to a sudden stop. It is here that the two ships collided.

Liman was operating without any form of AIS at the time, despite being in thick fog – it is likely not to have had the system installed. To this date, the Russian Defence Ministry, has not reported what tasks Liman was carrying out but it is known that it wasn’t due to pass through the Bosporus Strait.

The collision holed Liman below the waterline which led the ship to starting to sink. Though most of the [up to] 85 crew members evacuated, it is known that some remained on board to, in the words of the Russian Defence Ministry, [remove] all special equipment, documentation, weapons and ammunition. [The] ship’s crew were evacuated to life-saving appliances, and then safely transported to the base of the Black Sea Fleet in the Crimea.

Almost immediately following the reports of the incident, new Project 22870 Ocean-going Rescue Tug SB-739 was sent to the scene from the Black sea navy base in Sevastopol. SB-739 does carry AIS equipment and analysis of this shows that the ship departed at approximately 1030z on the 27th, arriving 20 hours later. SB-739 carries the latest ROV to be deployed to the Russian navy, the Marlin-350 made by Tetis-Pro. This ROV can operate up to depths of 350 metres, with charts of the incident area showing depths of between 50 and 100 metres.

It was noted at the time of the incident that a Russian flagged Civilian Survey ship Хезер Си (Heather Sea) had commenced operations approximately 20nm to the NW of the collision site. The final position where Liman supposedly sank has been reported on social media at 41.50N 28.95E, the area where Heather Sea was operating, but this is a long way for the Liman to have drifted prior to sinking. A good friend of mine intercepted a navigational warning sent out by the Turkish authorities on Navigational Telex (NAVTEX) stating the final sinking position as 41.30 24 N 028.57E and it is here that SB-739 positioned itself on arrival.

Youzar Sif.H rescued some of the Liman crew members, and it is believed that another Russian flagged cargo ship, Ulus Star, also took part in rescuing crew as AIS analysis shows the ship deviating from its course to the incident area, before continuing on through the Bosporus later on in the day. At one stage it rendezvoused with both Youzar Sif.H and a Turkish government tug, Kutarma-3, which was one of the Turkish SAR ships sent to the area.

AIS data combined into one image
1 – Youzar Sif.H cruising at 11kts at 0813 UTC 27 Apr 2017
2 – Youzar Sif.H technical stop/malfunction at 1854z having started to return to Midia
3 – SB-123 arrives at the incident site at 0615 UTC 28 Apr 2017
4 – Heather Sea stays on task throughout incident

Youzar Sif.H returned to Midia, whilst SB-739 remained on site. Another Russian research vessel, Project 11982 AGOR Seliger, broadcasting as a “Law Enforcement” vessel on AIS, joined SB-739 at the area where Liman sank on the 1st of May . Seliger carries a submersible vehicle which was used to examine the wreck of Liman. Further reports of two other ships arriving around the 10/11th of May were given. These were KIL-158, a Kashtan-class buoy tender that has lifting equipment capable to take weights of up to 130 tonnes and Epron, a Prut-class rescue tug which is used for diver operations.

With the arrival of KIL-158 and Epron, it is highly likely that the Russian reports that all equipment was evacuated before the sinking were false and that these ships were here to recover those items still left on board. In particular, recent images of Liman show it with a large SATCOM dome towards the stern. This will almost certainly have contained a dish used for a SATCOM system given a NATO codename “Punch Bowl”. This communicates with store and dump type satellites such as Strela, Raduga and Rodnik. Information is collated and stored within the system and transmitted when a satellite passes within range. The satellite stores the information and “dumps” the data once in range of an appropriate ground-station. It would not have been possible to remove this system from the deck quickly and it is likely it went down with the ship.

With the final result of this incident being a lost ship, luckily with no loss of life , it highlights why the requirement of AIS on all shipping, even military, should be mandatory, especially in areas of high intensity traffic such as the Bosporus Strait.

What happened next….

There quickly followed a media frenzy of accusations and denials.

Russian media accused the Turkish government of sending divers to the wreck within an hour of Liman sinking and stealing all the equipment left on board – this is despite publishing on the same day how all the equipment had been recovered by the heroic crew of Liman. It is totally unlikely that the Turks had managed such a feat. Apart from the fact that it is dangerous to be diving on a wreck that soon after it has sunk, as shown by the ships needed by the Russians to do the actual task of recovery, the Turks sent nothing of the sort to the area. In fact, they did a great job of assisting a ship in distress.

Close-up of Youzar Sif.H’s track following the collision. The grey ship is Kutarma-3, which stayed to assist the sinking Liman.

The Russians then accused the crew of Youzar Sif.H of operating their ship dangerously in conditions that were unsuitable for a speed of 11 knots, including suggestions that the crew were drunk. Of course, they said nothing of the fact that their own ship was operating clandestinely (be it in open sea and legally) without the safety net of AIS equipment. The Russian navy is currently trying to sue the operating company of Youzar Sif.H for the loss of Liman.

Also of note was an interesting statement by Captain Vladimir Tryapichnikov, the head of naval shipbuilding, at the recent launch of the second Project 18280 AGI Ivan Khurs on May 16th. He alluded to the fact that Ivan Khurs would replace Liman in the Black Sea fleet, and that there would be a further two ships of the class built. His actual words were:
Let’s give the fleet the second ship, and then talk about the next two. Defence plans indicate that the Navy will receive them before 2025

This is almost likely to be false – on both counts. There has never been four ships planned and the replacement of Liman with Ivan Khurs would be a ridiculous waste of money. The Russian navy has a terrible funding problem, with not even enough projected funds available to build new Destroyers they have planned. They are also desperate for a new Aircraft carrier, but funding makes this highly unlikely; and they are seemingly already having problems funding the refit of Kuznetsov(orel)-class Aircraft Carrier Admiral Kuznetsov which is about to begin. With this in mind, and other on-going funding problems with frontline ships and submarines, it is very unlikely they will put aside any cash for two more AGI’s.

Further more, the Project 18280 AGI’s are not designed for operations in areas such as the Black Sea, but more for in areas further from Russian shores such as off the East coast of the USA – for example, those tasks carried out by Project 864 Vishnya-class AGI Viktor Leonov which is often operating near to Cape Canaveral and the USN Naval Submarine base at Kings Bay, Georgia. If Liman were to be replaced by anything it is more likely to be by one of the remaining Project 861 Moma-class AGS Survey/Research ships that the AGI versions were converted from. This makes even more sense if equipment was rescued before the ship sank as it would be an easy fit. My analysis of Liman makes me think it wasn’t a fully converted AGI as it still retained the crane on the forward deck, which other AGI’s had removed and that the AGS’s retain. This to me shows that not much structural work would be needed to get a quick replacement available – and at not much cost.

Liman, taken again by Yörük Işık, but this time in October 2016. Now the ship has the “Punch Bowl” SATCOM dome at the stern.

The statement by Tryapichnikov was more than likely a face saving one following the sinking of Liman and I totally expect Ivan Khurs to eventually end up with the Pacific fleet as planned. It may, however, first make a trip to the Black sea/Mediterranean to prove some sort of point.

Ironically, exactly one month later, Youzar Sif.H anchored to North West of the Bosporus awaiting its turn to transit through, having left Midia on the 26th May. It did so on the 28th, it’s destination this time is Misrata.

Whilst then, the dust has settled on the actual incident itself, it did highlight some other points.

Social media and its self-professed experts

Now, we all kind of love Social media and the internet – we do, there’s no denying it. After all, I wouldn’t be here doing this, I wouldn’t have access to endless amounts of information, data and history at the click of a button. But, what I ALWAYS do is check, check and check my facts.

I know my stuff, but am I an expert? No, I would say I’m not. It would be a dishonour saying I am to those that are actually experts. For instance, despite being quoted as a Jane’s Fighting Ships correspondent in IHS publications, I still quite often ask for advice from the yearbooks editor. He is after all an ex Commander of Royal navy ships, NATO and the MOD – totalling over 30 years in the Royal navy. I’m, in reality, an Air Traffic Controller that has a high interest in the Russian navy because of my “hobby” of monitoring their ship HF frequencies. One thing, has effectively led to another.

What this incident has very much highlighted is just how quickly false information is put out to the World without any actual analysis before doing so.

Take the operations of Heather Sea. Many social media “experts” stated that Heather Sea was sent to the aid of Liman when in fact, from simple analysis of AIS information, it was obvious that the ship had departed Varna in Bulgaria at approximately 2030z on the 26th April – some 12 hours before the collision reportedly took place! Very clever of the Russians to know that the collision was going to happen and send a ship there, ready for it to take place! Moreover, Heather Sea remained on its task site for over a week, 20 to 30nm from the position of the collision – having arrived there at 1500z on 27th April, some 8 hours after the reports of the collision started to filter through. It is fitted with modern ROV’s and so would have been ideal to carry out rescue/recovery, but it didn’t. It had nothing to do with the rescue of the Liman and the “experts” had given out incorrect data and positions.

Other experts suggested, even betted, that the arrival of KIL-158 and Epron was so that Liman could be raised from the sea bed and taken back to base. This just shows sheer stupidity rather than any knowledge.

Epron taken by Yörük Işık

And then there are the “There is something highly suspicious about this incident” people of social media. They deny it, but they are similar to conspiracy theorists. And I say this because unless they carry out full analysis on what happened and look into every possibility, what they are stating as fact, is actually incomplete and cannot be relied upon. Their ignorance and stubbornness of just basic principles again shows them as being a theorist – and yet, they say they are an “expert” even when they are shown strong evidence that shows their thoughts as being wrong. Even worse is the fact that some get a social-media following that believes everything they say and that they are an expert – this leads them to believe even more so that what they are saying is correct, when it isn’t.

One ridiculous suggestion was that Liman was jamming the AIS frequencies with its operations. Firstly, why would it have only hampered Youzar Sif.H, as every other ship in the area at the time was perfectly ok; and secondly, it would be a very clever ship to be able to carry on its frequency jamming from the depths of the Black Sea as other ships, including Youzar Sif.H on its revisit this weekend, have been lost from AIS receivers – as shown later on.

Let’s get back to Liman then, and the events leading up to the collision.

There are people out there that have stated that Youzar Sif.H had drifted off-course or wasn’t on the standard route and had even switched off their AIS equipment to hide this. Firstly, there isn’t a set course for getting from Midia to the Bosporus – the ships can get there in whatever route they want to. The fact is though, that they are on a schedule and want to get there the quickest and cheapest way possible and so they will go direct.

The social media experts have concluded that Youzar Sif.H was off-course because they ran a quick look at the traffic density data available on MarineTraffic. Now this data is all well and good, but it has it’s faults. The main one is that the data is basic. It draws a line from one point to another, taken from position reports from AIS data – and if the there’s a gap of 100nm it will draw a line still between these points. In areas of no AIS receiver coverage these lines will still be drawn, but there’s no proof that the ship actually travelled this course. The same principle occurs with all other basic online AIS software providers, including AISLive provided by IHSMarkit.

Youzar Sif.H was tracked pretty well after departure and did deviate from the route shown on the traffic density maps, but only just. A few hours before the collision took place Youzar Sif.H was no longer tracked by any MarineTraffic or AISLive feed, until at 0813UTC when it appeared again. Not long after, the collision took place.

Because the ship was tracked fully after the collision it has been alluded to by some that the AIS system on Youzar Sif.H was switched off for a while, and was only put on again just before the collision. Now why would a ship carrying sheep do such a thing, especially in dangerous conditions such as fog? The ship had nothing to hide, and the likelihood of switching off the one thing that would help them from hitting another ship in such conditions is certainly unlikely. AIS is only useful if all ships carry it, and here Liman didn’t. No doubt there would have been a basic primary return on the radar of Youzar Sif.H but it may well have been too late by then. The cause was that Liman was operating in fog with no anti-collision system in place. To further add to the conspiracy theory, Youzar Sif.H was able to be tracked most of the way back to Midia.

Youzar Sif.H transiting the Bosporus on the 28th May 2017 taken by Alper Boler

I go back again to me saying that I’m not an expert, but I’ve listened to radio since I was around 13, especially Air Traffic Control. This led to my 28 year career in the RAF and Civil ATC. From this I’ve learnt about how radio waves travel. But am I an expert in this principle? No, I’m not. There are guys and girls out there that know a hell of a lot more about it than I do. Here’s the thing though. I know the basic principles.

A very basic and simple fact is that Very High Frequency (VHF) radio transmissions travel with a line of sight principle called the Radio Horizon. In other words, two antennas need to be “in sight” of each other to receive that which the other is sending. No, you don’t actually have to see the other one, but in theory you need to be able to – in most cases. There are other principles and phenomenon such as VHF Tropospheric Ducting which allows for radio waves to travel hundreds of miles, but even then they can skip the hundred miles in-between leaving a null zone.

Take ATC again. The higher an aircraft is, the more likely it is to receive a signal from the ground as the “line of sight” is better, though it does also rely on the power of the transmitter. The curvature of the Earth can stop this and does. As an example, at work we have difficulties sometimes with USAF C-130 Hercules aircraft that are operating at the furthest range of one of our transmitters when they are cruising at FL230/FL240 – the Earths curvature, along with where the antenna is placed on the airframe gets in the way. Two or three thousand feet higher and they would receive us. If flying towards the transmitter then this isn’t a problem as the aircraft will come over the horizon and within “sight” of the transmitter, but going away means that sometimes a relay is required from another aircraft.

The same goes for things such as Mode-S receivers widely available for tracking aircraft. They only have an optimal range before the amateur can no longer pick up traffic – actually, this applies to physical radars too hence why many countries have a large amount of them to cover the whole country, and further. Stick a mountain, or even just a small hill somewhere and the reception range will be reduced for aircraft “below the horizon”. There’s a reason why military aircraft fly at lowlevel.

A great page for showing the principle of VHF reception is on Neal Arundale’s AIS page where it has a graph showing the principle.

My Mode-S antenna is on the roof of the house and I get a range of about 250 miles for aircraft that are at a high altitude. Out to the east of me, less than a mile away, is a hill of around 300ft which means I tend to lose aircraft descending into Edinburgh for instance when they go through around 15000ft – yet 200 miles away I’m picking up traffic over the North Sea.

My AIS antenna is lower than this. And it is in the loft. I have great reception to the North/Northwest, yet to the Southwest it is dead for me. Why? Well, because the signal from any ships has to not only pass through three houses, it also has to get through the three foot thick, sandstone walls of the house. The signal is wiped out.

My AIS coverage taken from MarineTraffic. Very strong to the North, but poor to the SW

Add to that that I am only a few metres above sea level and it makes my Radio Horizon not very good. You see, taking into consideration Neals data, I quite often struggle to get a small fishing boat which is between me and a large oil tanker that is further away that I am receiving. This is because, more often than not, ships radio masts are at the tallest point on a ship and an oil tankers one will be near on 60 metres above the sea, whilst a fishing boat around 10m. An oil tanker is also likely to have a more powerful transmitter as the ships size means it can carry bigger equipment.

So, where am I going here with relation to the Liman incident?

As previously stated, it has been suggested that Youzar Sif.H had switched off its AIS system. But a simple look at coverage information available on MarineTraffic would show that the Black Sea has some patches that are not covered very well by AIS receivers. I always say this about things like AIS or Mode-S feeds – they are only as good as the information that is fed to them.

The image here shows the coverage from the two main receivers for the area approaching the Bosporus from the Black Sea from this afternoon – 29th May. The receiver to the NW is on a 90m high block of flats and the one at Istanbul is on a two storey building on a hill. They have a great range because of this height. But, nearly the entire area SE of Varna is blank. These receivers do not pick up anything. Now, these coverage maps, like the density ones, can be a little false because they only work because they’ve picked something up, so the darker areas that show a dense level of traffic here, could be lighter at another time due to a quieter day – and vice-versa. But I’ve been looking at these areas frequently since the incident to see if my conclusions are correct, and they have remained pretty much the same. Further north are a few more receivers, but except for one they rarely stretch far into the Black sea – in other words there is a reception black hole for the receivers that feed MarineTraffic and AISLive. It just so happens that Youzar Sif.H travelled through the black-hole on the day of the collision.

This image shows the coverage from the Elena Station in Bulgaria which has fantastic coverage of the Black Sea in this region, but even this has reception black holes, particularly on the Youzar Sif.H route.

The image below shows the reception plots of Youzar Sif.H on the 26/27th of April on AISLive

Whilst the image here shows the reception on the 26/27th of May. This one is in fact worse than the day of the collision! It went near 14 hours without being picked up by any AIS receiver that fed AISLive.

Not only does this happen to Youzar Sif.H, it happens to many other ships that travel the same route.

This is the reason why Youzar Sif.H was not picked up until just before the collision and not because of stupid reasons such as it had switched off its AIS or been jammed by the operations of Liman. In fact, it had its AIS on at all times and other ships within its Radio Horizon would have picked it up, just as it would have picked up the other ships.

Now, the conspiracy theorists will be saying ” Well, hang on, Youzar Sif.H was tracked very well following the incident”. Well yes it was, but there’s a couple of good reasons why. Firstly, the main antennas on Youzar Sif.H are at the back of the ship but it also appears that there is one at the front on the mast. Is this the AIS antenna? Whilst it is hard to see which one it would be, if it is the one at the front this would explain a lot. The average reception distances for the stations is interesting for the day of the incident. The Elena station showed an average of 112nm which actually nearly corresponds to the site of the collision, so this station was covering out to that area. The signal from Youzar Sif.H would fade as it travelled away from the receiver. But after the accident and it was heading back to Midia, the front of the ship would have been facing the receiver which could mean a better signal getting through. The fact that on its journey back to the area this weekend produced the same tracking results, if not worse, than the incident ones shows that Youzar Sif.H has problems with being tracked in certain areas.

The station on the flats at Burgas had an average range of 26nm and would have possibly covered the early part of the voyage too.

And the Istanbul receiver only had an average of 10nm – but again this is roughly where the collision took place, and of course, Youzar Sif.H was head on to the receiver.

At the end of the day, I doubt we’ll ever find out for sure what happened. But I can honestly say that I believe it was a pure accident, and the fact that no AIS data was received from Youzar Sif.H was down to the pure science of a lack of radio reception at the AIS receivers covering the area, rather than the switching off of the systems on the ship.

One thing is for sure though. Those people that insist on churning out information, data and theories need to be sure to get their facts right first; and they need to do some basic research on things that they are commenting on. Otherwise they just make themselves look like complete idiots.

Quick LNA4ALL test

Despite the best efforts of the Royal Mail service, I have been able to get my hands on a Low Noise Amplifier created by Adam at LNA4ALL. The Royal Mail showed just how useless it is, when the parcel arrived here in the UK in just 11 hours from Croatia on February the 14th, but then not getting delivered to me until March the 14th – yes, one month! There is no surprise that courier companies such as DPD and Hermes are getting more business than the Royal Mail – they are bloody useless.

Anyway, the reason for the purchase is for a later review on an AIS dongle that I will be testing, but which has unfortunately been possibly damaged before getting to me.

So, as I had some time to spare I thought I’d run a quick test on how the LNA performs against the claims that is shown on the LNA4ALL website. For the test I used a quickly built 12v to 5v PSU that was connected to a Maplin bench PSU and also a Rigol DP711 Linear DC PSU where I could ensure a precise power input. As it was, it was good that I used the DP711 because my quick PSU was only chucking out 1.2v at connection to the LNA4ALL, despite an unconnected output of 5v – some work needed there I think.

Despite this lower power the LNA4ALL still worked with just the 1.2v input, though the results where not as good.

Other equipment used were a Rigol DSG815 Signal Generator and a Rigol DSA1030 Spectrum Analyser (no longer available), along with various Mini-Circuits shielded test cables. The Rigol equipment I purchased from Telonic Instruments Ltd last year.

Below then is a table that contains all the relevant data. As you’ll see the Gain claim is pretty much spot on with some being over. Just a couple of frequencies are below that which is claimed, especially at 28 MHz.

LNA4ALL Frequency data

A couple of things to note.

Firstly, somehow I managed to miss testing 1296 MHz. I obviously didn’t put it in the table in Excel before I started 🙂 Also, the DSG815 only goes up to 1.5 GHz so I couldn’t test above that.

Secondly I ran a test for the AIS centre frequency of 162 MHz, for which there was no comparison to the LNA4ALL data. A gain of over 24dB though shows that the LNA would be perfect for those of you with AIS receivers that may want to get better reception. To prove the theory I compared the LNA reception against data without it connected to the NASA Engine AIS receiver that I currently use. In ShipPlotter I average a max range of around 15nm without the LNA, but with it connected this increased to around 22nm. The number of messages received also tripled as it was able to dig out the weaker signals.

The NASA Engine isn’t a bad receiver, but it is a frequency hopper rather than a dual monitor, and so it changes between the two AIS frequencies every 30 seconds (161.975 MHz and 162.025 MHz). I suspect a dual monitor would give better message numbers and range.

Below is a graph made using the excellent software by Neal Arundale – NMEA AIS Router. As you can see the message numbers (or sentences) for over an hour are pretty good – well, it is a vast improvement on what I used to get with my current “temporary” set-up, with 419 messages received in an hour. The software is available at his website, for free, along with various other programs that you can use with AIS. If you’d rather not use ShipPlotter he has created his own AIS Decoder which can be linked into Google Earth and such like. Visit his website for more information.

My antenna isn’t exactly top-notch. It is at a height of just 4 metres AGL in the extension loft, and it is made from galvanised steel angle bead used by plasterers to strengthen corners prior to skimming – this I cut down as a dipole for a target of 162 MHz. As usual with my trimming of antennas, I cut just too much off and ended up with it cut to 161.167 MHz. It gives a VSWR of 1.018 and Return loss of 40.82dB, with 162 MHz being approx. 30dB Return loss which equates to 1.075 VSWR – that will do.

Also, as I live right on the coast, about 50 metres from the sea, I’m practically at sea level, which doesn’t help much with range and signal reception either. Despite this the antenna produces great results, though it is just temporary until I can get a new homebuild up on the roof.

VSWR reading for the homebrew loft AIS Antenna

The LNA4ALL retails at various prices depending on what option you go for. I went for the aluminium box version so it was around £54 including the delivery. I had looked at a Mini-circuits equivalent, and when it looked like the LNA4ALL was lost I did actually order one. But this was nearly twice the price, and seeing as the LNA4ALL contains many components from Mini-Circuit I doubt it is any different really.

All in all the LNA4ALL is all you need to boost your weak signals – couldn’t get any more all’s in 🙂