The Bear Net “Pirate”

The “Bear Net” of Russian Long Range Aviation has been relatively busy during the last few months, no doubt some of this due to the exercises playing out in Northern Europe by Western countries and NATO. They also tend to increase activity around the same time as USSTRATCOM have their Global Thunder exercises, one of which kicked off on the 29th October and lasted for just over one week.

Three Russian missions took place within the last two weeks, all of which travelled through the same airspace as the area covered by Exercise Trident Juncture 2019 (TRJE18) off the North coast of Norway. One flight was of a single Tu-142M, RF-34063//Red 56, that made a low pass near participating ships. I was unable to follow this flight so not received by me, the likely callsign on the CW frequencies for this was LNA1. This was intercepted being called by IWV4 on 8112 kHz at approximately the same time as the pass was being made. Images of the pass were caught by AFP correspondent P. Deshayes who was on one of the ships.

One of the other missions was of more interest than normal. The “Bear Net” is always an interesting thing to follow on HF, but when extras are produced it makes them even more fascinating. In this case it wasn’t so much what the Russian did, but what happened late on in the mission that wasn’t them.

Stepping back, we’ll go to the beginning of the day – 31st October 2018. The net was still on the autumn frequencies with ground station CW first being picked by myself sending “W” markers at 0920z on 8162 kHz. I quite often put one of the receivers on the current season ground station frequency to get any alert of possible flights heading out thanks to the markers sent every 20 minutes at H+00, H+20 and H+40. With this 0920z interception I started recording the frequency and I switched all radios to the other known frequencies – 9027 kHz for Air CW and 8033 kHz for Simplex USB voice comms – and got set up to start recording these should anything happen.

The 0940z W marker came, but interestingly when I went through the recordings later on I was able to hear a very faint G marker in the background. This had at least two operators carrying out the task as there were two distinct methods of sending. One would use the standard G every two seconds, whilst the other sent as double G’s and slightly quicker. The marker also started approximately 10 seconds earlier than the W and – guessing as it was stepped on by the W – looks to have lasted the two minutes too. You could hear it in the background between the odd W space.

At 0949z 8033 kHz became active and I started up recording on multiple SDR’s whilst using my Icom IC-R8500 as the live radio. By this time, I had also observed callsigns associated with QRA flights on my SBS so was pretty certain something was heading towards the UK.

With a few more USB calls following, but no CW traffic except for the markers I was certain the aircraft involved were Tu-160’s as they don’t use CW.

My Russian is still pretty basic (if that) so I totally rely on recordings to go through it all in slow time. I had been able to work out live that there was at least the usual STUPEN callsign along with TABLITSA; but I was also hearing another one that when going through the recordings I worked out to be KONUS – this one I hadn’t heard of before.

Going through the recordings, this mission certainly helped my knowledge of Russian numbers, or rather the methodology of how the messages are sent, as there were plenty of messages involved. The two aircraft callsigns were 16115 and 16116. These callsigns carry on in sequence to those that were used on a mission a few days earlier on the 28th with 16111, 16112 and 16114 being used by Tu-160’s and 50606 by an accompanying A-50.

In general 16115 was much harder to understand than 16116. 16116 said it all much slower and louder. STUPEN was very clear at the beginning, but faded towards the end, whilst TABLITSA may of well have been in my room, she was that loud.

Here then is the first part of my USB log:

8033 – Bear Net

0941z 16116 calls STUPEN
274 443 624

0949z 16116 calls STUPEN
458 842 156 816 443 896

0959z 16116 calls STUPEN [replies, 16116 faint]
KONUS calls 16116 and tells him to pass the message to him

1000z [16116] 303 847 023 534 734 619 822 332
[with wrong read back of group three, corrected by 16116]

1002z 16115 call KONUS
138 534 005 964 312 147 443 896

1010z 16115 call KONUS
741 534 724 619 822 180 443 594

1020z 16116 calls STUPEN
478 815 023 534 071 955 117 957 084 305

1028z 16115 calls TABLITSA, then straight away calls STUPEN
138 1?5 [error?] 138 534 540 115 ??? 251 660 033 084 316
[garbled with a possible error]

1036z 16116 calls STUPEN and TABLITSA, STUPEN replies
303 815 023 534 671 612 842 768 084 544

1039z 16115 calls TABLITSA and STUPEN, STUPEN replies
741 534 671 619 246 768 023 084 544

1048z 16115 calls STUPEN
138 534 491 236 896 443 084 635

1050z 16116 calls STUPEN
478 815 023 534 635 233 107 219 084 615

The recording below contains the 1048z and 1050z messages

1112z 16116 calls STUPEN
452 635 084 125
[repeats third number twice]

1129z STUPEN calls 16116 twice – no answer

1132z STUPEN calls 16116 twice – no answer

1133z STUPEN send message
BLIND 553 028 533 ??1

1141z 16115 calls STUPEN
741 534 360 810 719 980 447 023 038 914

1144z 16116 calls STUPEN
303 875 023 534 106 673 980 719 038 914

1148z 16115 calls STUPEN
138 537 023 534 674 400 388 521 038 496

1159z 16115 calls STUPEN
741 537 023 534 940 441 388 441 038 896

1201z 16116 calls STUPEN
478 816 023 534 717 355 637 321 038 496

1210z 16115 calls STUPEN
138 537 023 534 600 902 955 462 038 844

1213z 16116 calls STUPEN
303 815 023 534 186 117 388 117 038 896

1217z 16115 calls STUPEN
741 537 023 534 981 980 356 789 905 149

1306z 16115 calls STUPEN
138 537 023 534 540 288 810 236 905 206

1318z 16115 calls STUPEN
352 315 544 243 942

1320z 16115 calls STUPEN
[4 calls, no answer]

1322z 16115 calls STUPEN
741 537 023 534 724 284 312 816 315 555

1325z 16116 calls STUPEN
457 187 905 844

1351z 16116 calls STUPEN
457 187 315 715

Then comes the interesting part of this…… the arrival on frequency of the “Pirate”.

At 1427z an open mike became present on the frequency, in AM mode. This was fairly brief, and at 1429z the Pirate started.

Mike Delta Kilo Romeo, Mike Delta Kilo Romeo
Mike Delta Kilo Romeo, Mike Delta Kilo Romeo Standby
Mike Kilo Delta Romeo, Mike Kilo Delta Romeo, Mike Kilo Delta Romeo Standby

Note his own error or change with the callsign

MDKR//MKDR

Image of carrier wave and transmissions of MDKR//MKDR. The Pirate is using AM mode, but as the recording was in USB only that half was captured.

This was followed at 1431z
Mike Kilo Delta Romeo
56822166095499102

The audio for the above is here:

At 1439z he was back but very faint, almost like it was a recording or live transmission of a Numbers Station. Shortly after this 16116 tries to call STUPEN and KONUS, getting stepped on by the Pirate who sends yet another attempt at an EAM/Numbers Station.

C78AAA5ACBCEA77D76FF33EAFAE63CF5A7AAAAFAF555A85CDBEEBBA5D6DFCCA – or something like that! It was hard to work out some of the digits due to the lack of phonetics. Each time I listen to it I get a different result!

Fake EAM/Number station message

The audio is below.

At 1446z, 16116 calls STUPEN, KONUS and TABLITSA but gets no response back.

The Pirate then attempts to jam the frequency again. First of all with an extract from a selcall system used by the Russian Ministry of Foreign Affairs given the name “Mazielka”, designated X06 in the Enigma Control list. See the end of the blog for analysis on this.

This was followed by a continuous tone at 1090 Hz for approximately 35 seconds. These are the last transmissions by the Pirate.

Again at 1459z, 16116 tries the ground stations until TABLITSA finally acknowledges his presence and a message is sent. 16116 is barely readable with me by this time, though TABLITSA was ridiculously loud.

1459z 16116 calls STUPEN
calls TABLITSA
calls STUPEN
calls TABLITSA answers [very strong]
452 730 969 463

1506z 16115 calls TABLITSA
590 375 143 986 196 233

1531z 16116 [very faint] calls TABLITSA
452 859 143 168

This was the end of all contacts on USB, with the last W marker coming it at 1520z (though these then did start up again at 1640z, though much weaker).

From various OSINT feeds, the approximate route of the Tu-160’s took them out over the Barents Sea having departed Olen’ya air base in the Murmansk Oblast and heading north before turning west once out over the sea. At some stage they were intercepted by Norwegian Air Force F-16’s and were escorted to abeam Bergen/NE of the Faroe Islands before turning for home. The Russian Air Force have stated that the flight lasted for ten hours which ties in with the seven hours or so of HF traffic, with the remaining 3 hours probably within range of Russian VHF communications.

Olen’ya is a common forward operating base for LRA missions, being one of the remaining Arctic Control Group (OGA) airfields available. The base itself hosts Tu-22M-3R Backfire-C of the Russian navy. These are Tu-22M3’s that have been converted for a navy reconnaissance role though it is unknown just how many are airworthy. The base has over 30 Tu-22’s in permanent storage.

Twitter feed for записки охотника (Hunter Notes) has a rough plan of the route flown, along with his intercept of the messages sent – he has few of the earlier ones, and there’s a couple of differences between his and mine.

So, who is this Pirate? It isn’t the first time he’s been around. He was also heard in September.

On this occasion he was a little bit more direct.

Russians we are watching you
Russians we know where you are
Russians, turn around and abort your mission

And later

We will blow you out of the sky
The Russians. We have you under observations [sic], stand down

Despite having what is clearly a South East England accent, he signed off using something along the lines of:
This is the United States BC36

No doubt he is trying to gain some sort of attention, and in a way he is succeeding – me writing this blog is proof of that. But what else is he trying to achieve? Is he hoping the Russians respond? I doubt they will. Apart from anything, I expect the radio operators, having had to listen to all the noise on HF for every flight, have learnt to ignore any calls which aren’t specific to their mission.

My initial thoughts were that he isn’t a radio amateur and hasn’t worked in any other field that involves speaking on the radio. His use of poor phonetics made me wonder this. However, with access to a transceiver and associated antenna this may not be the case – and amateur radio operators tend to make up their own phonetics rather than standard ones, and he may just not know them.

That said, he must have some interest in military aviation and possibly a member of a military aviation forum. These tend to have thousands of members that have not been vetted in any way or form and quite often have threads that give notice of flights are on their way, be it with an alert of a QRA launch or actual comms received on Bear net frequencies.

Twitter, of course, is another example of information being out there for anyone to then take action on.

One thing is for sure, if caught he will find himself in trouble with UK authorities with the possibility of a two year prison sentence and a heavy fine. He will most definitely lose his radio licence should he actually have one, and have all equipment confiscated.

Lets see if he turns up again in another LRA mission.

Analysis of the Mazielka (X06) transmission

It was obvious straight away that this was a recording of X06 – in this case the sub-variant X06b.

However there was something odd about it.

X06 is a selcall system used by the the Russian Ministry of Foreign Affairs to alert outstations of an upcoming message, normally on another frequency.

The system sends out 6 tones, each lasting 333 milliseconds, making each call 2 seconds long. Each tone represents numbers 1 to 6 making a total of 720 different selcall combinations available for use.

The tones are sent on slightly different frequencies:
1 – 840 Hz
2 – 870 Hz
3 – 900 Hz
4 – 930 Hz
5 – 970 Hz
6 – 1015 Hz

The image below is taken from a X06 call I intercepted in November 2017 and decoded using go2Monitor. This shows a selcall of 116611. In this case the tones, which are still 333 ms long, sound longer but this is because the digits join on the same tone.

Whilst you can use a decoder, for X06 it is easy enough to decode using other means, such as Adobe Audition or Signals Analyzer. With these you can measure the tone frequencies and lengths.

In Adobe Audition the Pirate transmission is shown below

Pirate_003Pirate_003a

What is unusual is that the tones are off by 60 Hz. Whilst 1 should be at 840 Hz, here it is at approximately 900 Hz, and 6 is at 1075 Hz rather than 1015 Hz. Whether this is because the Pirate was transmitting in AM rather than USB I’m not sure. Maybe it is something to do with his original recordings. My recording is below

It is likely the long tone sent after the selcall here is the usual long tone that is sent before the standard ones. This is sent at 1090 Hz.

Pirate_004Pirate_004a

Looking at it using Signals Analyzer (SA) you can see that it is definitely X06. With SA you can measure more accurately the frequency and length of each tone.

X06_005

Here you can see the two tones (actually 6). The total time for the selcall is 2.040 seconds with 1 marked at 896 Hz and 6 at 1074 Hz

X06_006

Measuring the length of an individual tone (though actually 3 joined together) gives a length just over 1 second or 3 tones at 333 ms each

X06_007

Finally, measuring the space between each call gives us 1.312 seconds which is the correct spacing for X06

The sub-variant of X06b is designated due to its format of six tones sounding like two. It is thought this is a test transmission.

Finally, just to confirm my theory, I ran a looped sound file through go2Monitor with the result confirming the selcall as 111666

X06_004

Advertisements

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. If you want to record and quickly analyse IQ data then I can’t think of anything else that does the job so well.

Coming up next…….

I’ve started using Harvester Signals Intelligence Software – Version 6 by SigintSystems and I’ll be running a series of blogs covering my progress with this excellent software as I learn how to use it to its full capabilities.

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.

An updated AIS system

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

A new antenna too

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

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

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

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

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

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

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

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

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

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

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

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

NOTES:

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

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

Fighting Ships 2017/2018

In the last month or so the latest edition of Jane’s Fighting Ships has been released. It’s available from the IHS online shop for the usual eye-watering price of £984.

One thing to note is that older editions of the yearbook are also available on the IHS website at much cheaper prices.

This is the last edition that Commodore Stephen Saunders RN will be the chief editor of, as he has decided to retire from the role after 17 years. Having been a contributor of JFS for the last five of those years it will be sad to see him go.

From now on there will be a multi-team of editors that will compile both the yearbook and the on-line version. I will be remaining a contributor, and will hopefully be getting more involved than I am already.

There could well be complications regarding contributing data and photographs and I suggest that if you do either of these then to contact the team at IHS as soon as possible. There is a strong likelihood that contracts will need to drawn up with regards to copyright usage of whatever you send in. The email address for the yearbook is JanesFightingShips@ihsmarkit.com

In the meantime, I wish Stephen all the best in his retirement – he’s done a great job editing the yearbook over the last 17 years.

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.