Another imagery update of Sevastopol provided by Capella, this time dated 7 June 2022.
Not too many changes but there is one strange occurance.
Overall, most of the Russian navy ships remain the same. On the north side of the bay, a couple of civilian merchant vessels were collecting grain/wheat from the terminal. Project 02690 Floating crane SPK-54150 had been operational on the southern side but was back next to the grain terminal at the time of the collection.
The remaining ships are same as those in the 31 May 2022 update – except one Project 1239 Dergach class had departed on 5 June 2022.
On the south side in Pivdenna Bay, very little change. Project 02690 Floating crane SPK-46150 was present but had been operational – to then depart a few days later on 8 June 2022 (more on this later).
The submarine pen was open and one Kilo class SSK was no longer present. This was to be found in the maintenance bay 2 km northeast of Pivdenna, on the south side of Sevastopol Bay.
Even stranger was that, along with the Capella imagery here, others showed the Kilo balancing on the deck of a small floating crane. @GrangerE04117 on Twitter concluded it was Project 877V Alrosa – which I agree with.
The remaining Kilo in Pivdenna Bay was confirmed later on by @Capt_Navy
Alrosa balancing on the deck of the floating crane in such a way is something I haven’t seen before. There are floating docks available, but these are in use. Moreover, potentially this method is a faster way of carrying out the work they need to do on the Kilo. How they got it up on the deck is another question!
SPK-46150 left at 1205 UTC on 8 June 2022, probably for Snake Island. The Floating crane had two Tor-M on its deck. The last position on S-AIS came in at 1422 UTC, northwest of Sevastopol. It appears to be following the same route SPK-54150 took previously, so at 6 knots would take approximately 22 hours from that position to reach Snake Island. A rough ETA would be 1230 UTC on 9 June 2022 if it isn’t there already.
The use of the Floating cranes as a Tor-M delivery method to Snake Island is certainly a strange one. I said on a Twitter thread that it may be a “one ship fits all” reasoning, rather than using small landing craft or other vessels that may then need a crane to lift the SAM systems onto the jetty. I can’t see any other reason why they’d do it. Unless there are issues with using the Serna class ships at the ramp at the harbour?
It’s certainly a big risk. As I said on the thread. It’s just an idea as to why they might be using the floating cranes but “I’m not saying they’re correct in their methods“.
An early morning collection by Capella Space of Sevastopol on 31 May 2022 showed that Project 02690 Floating crane SPK-54150 was possibly back at the base. It had recently been spotted at Snake Island in imagery from Maxar and Planet.
It can be confirmed that the crane is certainly not SPK-46150 as this has been operational all day on the south side of Sevastopol bay according to AIS data from FleetMon.
Also present was a single Project 11356M Admiral Grigorovich class FFGH, two Project 1135 Krivak class FFMs and several Project 775 Ropucha class LSTMs.
Two Kilo class SSKs are in the submarine pen, whilst two Project 1239 Dergach class PGGJMs are north side – these are Bora (615) and Samum (616) though identifying which is which is not possible. SPK-46150 was still at its mooring at the time of the pass.
One of the Dergach class was captured on video in the last few days, though again, with no pennant/hull number, it can not be identified.
In my last blog, I tried to highlight the issues with analysing imagery and videos with only half a story.
I also tried to draw the attention to how fake videos can make one look at others with a lot of doubt as to whether they are real or not.
I concluded that more evidence was needed – in particular high resolution imagery from Maxar or Planet.
The good news is, that not long after the blog was posted, I was anonymously sent an image dated 7th May 2022 taken from either Maxar or Planet – the source didn’t say.
This clearly showed the wreck of the Project 11770 Serna class landing craft in the Snake Island harbour. It also showed the concrete blocks I wanted to see. This was useful as had the image been collected from before the attack, and there been no wreck, then at least the location was pretty much confirmed.
Even the blocks would have been enough then to conclude that the video was legitimate.
It wasn’t long after I received the image that it was published by AP, and shown on Twitter.
For those that don’t have Twitter access – Jon’s account is locked – here’s the image.
I also received a notification from a friend, Scott Tilley – well worth following on Twitter if you don’t. His satellite tracking capabilities and knowledge is fantastic.
His notification pointed me to a website that contained photographs of Snake Island – some of which depicted the concrete blocks used as the sea defences. A great find – and one that had slipped through my rushed searches.
So, hopefully this shows how information can take it’s time to get through to carry out a full analysis.
There’s reasons why the Intelligence services take their time over gathering data on incidents such as this.
Now, as further videos are coming through thick and fast of attacks on Snake Island, more confidence can be had over their legitimacy.
The wingman in this attack is probably very lucky not to have been taken out by the explosion created by the flight leader.
One has to question why the Russian forces are intent in staying at Snake Island. Their losses, I’d say, are greater than those taken by Ukraine.
My friend Capt(N) provided some information on the island in a recent Twitter thread. I’ve taken screenshots here as, again, not everyone uses Twitter.
Whilst there is no doubt there have been several attacks on Russian equipment on Snake Island, in the last few days, some dubious video footage has been “leaked” on Twitter showing Russian ships under attack.
These videos do put into question those that do appear to be genuine.
For example, yesterdays – 6/5/22 – “news” that Project 11356M Admiral Grigorovich class FFGH Admiral Makarov was struck by multiple Neptune missiles immediately reminded me of the same claim against Project 22160 Corvette Vasily Bykov at the beginning of March, be it with MLRS weapons rather than the Neptune missiles.
I personally wasn’t convinced about the Makarov attack, and once further ridiculous Tweets materialised using ADSB data from FlightRadar24 (FR24) showing NATO aircraft “monitoring the situation” as proof that “something was going on” – well, I definitely didn’t believe it.
This is just poor “analysis” by people who haven’t got a clue what they’re talking about and should just not bother saying anything. Two examples below.
Unfortunately, the Ukraine war has brought out a substantial number of idiots that are suddenly “experts” in warfare, aircraft tracking, ship tracking and satellite imagery analysis. In reality, they are just plain fools.
And as Ben Kenobi says in Star Wars – “Who’s the more foolish? The fool or the fool that follows him?”
This is the problem with social media. These people have a “show” that they’re experts, and then they get thousands of followers that believe everything they come up with.
Personally, I don’t trust anyone with OSINT in the username.
This idiocy was highlighted when a video appeared, apparently from a TB2, showing Admiral Makarov on fire. This was clearly fake and taken from a video game – later identified as ARMA 3. One account on Twitter was able to recreate pretty much the same “video” in a matter of minutes.
So, whilst evidence of attacks are a good thing to have to assess whether losses have been taken or not – fake videos tend to sway people in the other direction.
Going back a few days, I believed the Project 03160 Raptor fast patrol boat attacks video from the 2nd of May – but the above now has me thinking otherwise. I did find it a little strange that the second Raptor hung around the area for so long, and didn’t really make much attempt to evade a potential strike. This highlights the problems with creating fake videos for propaganda – once one fake video appears, it makes others seem fake too – whether they are not.
Todays video of the Project 11770 Serna class landing craft being attacked at the Snake Island harbour area certainly got my “fake video” senses twitching when I saw it. Mainly because, by sheer coincidence, I’d obtained imagery of Snake Island from Capella Space, collected on the 4th May, and I’d taken a good look at the harbour area to search for any evidence of ship activity there.
Coupled with the potential fake videos from previous “attacks” one can start to see inconsistencies in this video.
One thing – I always say this regarding my analysis work – I can’t always be right. I like to be, and I take my time on it, but errors will creep in every now and again.
So let’s look at what I see in the imagery versus the video and I can lay my cards on the table with my thoughts – and as always, I’m open to any comments.
First of all, one link to the video on Twitter. It is also available on YouTube I believe.
A number things immediately grabbed my attention. It is visible even in the Twitter image above. All those blocks of squares and rectangles. They look like CGI – too perfect. That area gets pummelled by the sea most of the time. Granted, they could be containers just dumped into the sea, but I’m not convinced at this.
Also, the ramp to the sea looks too perfect – very straight lines, no sea lapping over it. The wall that runs along it, into the sea, is new.
Let’s look at some close-ups from the video.
This one above shows yet more blocks east of the ramp, and strange grooves, much like seating areas. No sea lapping over them.
The next two shows the same area from nearly directly above. Note the near perfect lines of the walls, and more importantly, these blocks again. What are they? Not containers. Maybe concrete block sea defences??
The next image gives an overall view of the harbour area. Note the blocks again, and the coastline itself.
Now let’s look at the Capella imagery.
Whilst not perfect – typically the worst part of the imagery is the harbour – the blocks in theory would stand out. There doesn’t appear to be any. The quality is enough to show the jaggedness of the rocks along the coast, but not much else. There does not appear to be a wall out to sea along the ramp – but this is inconclusive in this imagery.
We can move onto some hi-res imagery from Maxar, though I’m afraid to say I have no contract with them and so I have had to use images from elsewhere. Ideally, we could do with someone that does have a Maxar account – or Maxar themselves – to provide us with the high-res imagery.
The first is taken from a CNN article dated 14th March 2022 and states the image was collected on the 13th. I’ve had to zoom in a little for the screen grab.
Not ideal quality, but does it look like there’s been much of an upgrade to the harbour area? It doesn’t look like there has been. It’s hard to determine whether there are any blocks there.
The following image is reportedly from Planet, collected in the last few days, and published by Associated Press – AP. Whilst I couldn’t find a direct link, there’s plenty out there – for instance.
Moreover, searching in the Maxar archive, there has been a collection on 7th May 2022 which shows smoke coming from the building as shown above, just on the left edge. Note also the ship activity to the west of the island.
With these two images nearly aligning, we can conclude that the top image is very recent.
In my view, whilst there are small buildings near the harbour, one of which in the area east of the ramp – there appears to be no large blocks present. The wall into the sea by the ramp does appear to be present, but hard to determine whether it matches that in the video. It is still too hard to conclude from the imagery currently available whether the blocks are there or not.
Ideally now, then, we need that hi-res imagery that Maxar clearly has (note they’ve redacted the archive imagery of the island). Then we can put this one to bed once and for all.
Analysis isn’t just about seeing what is immediately in front of you. It is much, much deeper than that. Below sums it up nicely.
Just because it looks like Snake Island harbour in the video, doesn’t necessarily mean it is. You have to look at more than just the shape and the jetty.
Ironically, one proven event – the sinking of Moskva – is still to produce any video evidence that a missile attack led to its demise.
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.
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.
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.
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.
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.
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!
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.
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.
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/Picketdesignation 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
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:
St. Eval transmitter site
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.
Here then is my conclusion:
USS Gridley = 2_o and the NCS
Thor Heyerdahl = 71_o
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??