Now, I still have my doubts about it being deployed here, and my first impressions were that it was just propaganda, but it still needs analysing to see what it could produce.
The article, sourcing a “Military-industrial complex”, mentions that the system is to cover the whole of Europe, including Great Britain.
This is, in itself, interesting as most of Europe is actually already covered by the system at Kovylkino. The mention of Great Britain specifically also is interesting as another Konteyner OTHR to cover this country would really only give an extra few seconds of warning that anything was coming from this direction. Moreover, I suspect that the Kovylkino system does actually cover Great Britain anyway, especially with the pulse rates of the system that I’ve analysed myself.
Looking at the image below you can see that if a system was placed at the rough centre of the Oblast, then only France, Spain and Iceland – along with GB – would be the extra countries that would be covered. The east of France is already covered as it is.
Personally, I wonder if – whilst GB might get extra coverage – the true targeting of the system would be to the North.
The Russian military have long been saying that they want to cover the Barents Sea and up to the North Pole with an early warning radar – specifically Konteyner – so this could be it.
If we adjust the predicted coverage to the North in an image then you get the following.
So, depending on the azimuths of the arrays used, we can see that GB, Iceland, East Greenland, North Sea, Norwegian Sea, Barents Sea, Norway, Sweden, Finland, Svalbard archipelago and the Noveya Zemlya archipelago (Severny Island and Yuzhny Island) could be covered by a four array system.Norway and Sweden are already partially covered by Kovylkino.
To me, this is the more likely coverage that will be created SHOULD a Konteyner system be placed in the Kaliningrad Oblast. And it is a should!
The TASS article states that multiple sites are being considered. The system at a minimum requires two sites. And the Oblast is not very big.
In all reality, the city of Kaliningrad itself is just 30 km from the Polish border. It would not take very long for a strike from a foreign land based missile site to reach a Konteyner site in the centre of the Oblast. It is because of this fact that I have my doubts about one being sited here, but who knows?
But say they do choose the Oblast for system two, where’s the likely spot?
If anything is to go by, with their previous sites, near an airfield seems to be a good choice, be it one in service, or one that could be quickly reinstated.
There’s a number of abandoned sites, including:
Chernyakhovsk at 54°36’7.12″N 21°47’29.07″E
Nivenskoye at 54°33’48.13″N 20°36’13.02″E
Marienkhof at 54°51’57.25″N 20°11’0.92″E
Chernyakhovsk has a large military presence – as does the whole of the Oblast to be honest! – and some work has been started at 54°39’1.12″N 21°48’24.77″E that I’ve been monitoring since mid 2019. Here there have been a number of small buildings about 3 metres wide since at least 2005 but I think these are something to do with oil or gas extraction – as is the new development. Moreover, the shape isn’t right for Konteyner as can be seen below.
Marienkhof (Dunayevka) is the location of a Voronezh-DM Early Warning radar that is situated to the SE of the old airfield. There is plenty of land around here for extra development. Moreover, out to the west coast is Yantarny which is home to the 841st Independent EW centre, and to the north is a SIGINT site at Pionersky that houses one of the new Sledopyt satellite signal interception systems amongst others.
Nivenskoye certainly has a lot of land available, but it is the nearest site to the Polish border and certainly not top of my list.
My favourite area would have to be near to Marienkhof due to the location of other Russian systems of this “type” – radio/radar/SIGINT based systems. The area is almost as far as you can get from any land based threats, though of course anything from the sea would not be that far.
I guess we’ll just have to wait and see what develops. One thing is for sure, the system stands out once you have an area of interest and this area is not that big to continually monitor.
There has also been mention of another Konteyner site already in construction in the far east. At this time nothing has been found of any construction site that looks to be a Konteyner OTHR and I have my doubts about this. It was first muted in 2010, then again in 2018, and I would have expected something to be there by now.
Well, thanks to a contact on Twitter – Krakek – this has been proven not to be the case!
He was able to point me to the location of the receiver site, though it is very clear that the system has either been abandoned, or it has been postponed.
Located at 53°43’16.27″N 127° 4’29.63″E, the site appears to have been started sometime between 23rd August 2015 and 6th September 2017 according to Google Earth imagery. The site has just been cut through a forest and it appears that no antenna arrays have ever been sited there.
The latest GE imagery available, dated 7/7/19, is shown below with the site not changing since September 2017.
The site is located 9 km west of the town of Zeya. There appears to be no other real military presence, with the region being mainly involved in open pit gold mining. The large dam nearby is also a big employer – an ideal source for the large amount of electricity required to power an OTHR.
At this time I have been unable to locate any sign of the Transmitter site, though it is like looking for a needle in a haystack. I went along the same lines of the other site and looked within a nearby radius and discovered nothing of real significance.
Using the GE imagery, I’ve taken a look at the potential coverage the Far East system would provide. As there isn’t a transmitter site available, I’ve based it on a three array system, rather than the four at Kovylkino.
The image below shows the site with added arrows for the direction the antenna arrays would appear to be planned in covering. The rough bearing for each is: 077 (Green), 137 (Red) and 197 (Blue).
The Green and Blue directions are definite as you can also see the areas cut out of the trees into what would be the ground plane that is placed in front of each array. This is not visible with the Red arrow and there isn’t a second ground plane visible for an array pointing to the West. This currently points to a three array system, but should there be a fourth array, my thoughts are that it would be back to back with the Green array. My reasoning for this? The second cut through the trees that extends in front of the Red (197 degrees) proposed array and around to the rear of the Green (077 degree) is the potential extension for the ground plane.
The next image depicts the potential coverage based on the same dimensions from the Kovylino system. The quadrants are colour coded the same as the previous image. The inner ring is at approximately 900 km and shows the skip area, whilst the outer ring is at approximately 3000 km. The lines in each coloured quadrant are extend from the planned arrays to the bearings of 077, 137 and 197 degrees.
As you can see, the OTHR is perfectly placed to cover SE China, North and South Korea, Japan and anything launched from the West coast of the USA. Three of those countries have ICBM capability. Major cities and naval bases such as Vladivostok are covered, as is a lot of the sea areas to the east of Russia.
You can also see that if a fourth transmitter array was to be built and it was put back to back with the 077 (Green) system, that it would point in the direction of India and Pakistan – both countries are ICBM capable.
It will be very interesting to monitor this site, to see if any further development takes place. I wonder whether they are waiting on how well the Kovylkino site copes in a live environment before continuing with any work here.
Krakek was also able to provide me with some further data on the Konteyner system as a whole. The data, shown below with some of the information translated in a separate table, is from the procurement datasheet produced by Радиотехнические и Информационные Системы (Radio Engineering and Information Systems JSC). The paper is further sourced from Oружие Oтечества (Weapons of the Fatherland) – a fantastic site on all things Russian military. Unfortunately, I couldn’t find the direct link to the page.
This data confirms much of that already known, in particular the range (min and max) of Konteyner and the maximum number of aircraft that can be tracked simultaneously. Of note is the pulse length – 6 to 8 ms as I was able to ascertain through my analysis.
Multifunctional Radar Station with increased range of detection of air objects
Main Technical specifications
3 and 4
Wavelength Range : Decametre
5 and 6
Antenna Type : Phased Array
Area of Responsibility
Maximum Range – 2700 km
Minimum Range – 1000 km
Azimuth Width in Degrees – 60
Within Area of Responsibility
Number of continuous monitoring zones – 4
Range size – 450 km
Azimuth Width in Degrees – 15
Standard errors of measurement
Range for single target – 18 km
Range for single target in degrees – 2
Radial speed (pulse rate) – 6 to 8 milliseconds
Number of simultaneously tracked targets – 350
Service life – 15 years
Relocated (note – presumed mobile)
The positional error information highlights the issues with OTHR. The plot for each track could be anything up to 18 km and/or 2 degrees out. This shows why the system can not be used for weapons targeting, and can only be used in an information or rough intercept/search area purpose for aircraft or another air defence system.
The title of the paper also alludes to the fact that Konteyner will only be used for air targets and not maritime surface targeting. This explains why there are no ship targets in the video for the Kovylkino activation.
I’d like to thank Krakek again for all the information as this has helped not only in locating the Far East site for further observations, but also for the datasheet that has proven a lot of the analysis already carried out.
I’ll be working with Jane’s, keeping a close eye on the site to catch any further work that may start here in the future.
Thanks to SDRplay, I was sent both their new RSPdx and older RSPduo SDRs at the end of January.
The main reason was to get them integrated into Procitec’s go2MONITOR and go2DECODE software, to increase the number of SDRs that the company’s products are compatible with.
This I’ve been successful in doing with the RSPdx – I’m still to unbox the RSPduo at this time of writing.
First of all though, I’ve been extremely pleased with the RSPdx in its own right. The SDRuno software works really well, is pretty easy to use – and it looks good too.
The fact that you can have up to 10 MHz of bandwidth is brilliant, and it isn’t too bad on the CPU usage either – running at around 25% with 10 MHz bandwidth on my ancient PC. Used with SDRConsole you can cover a good number of frequencies at once, and can record them if necessary. Of course, you can do this with SDRuno too, but at the moment only IQ – you can’t record individual frequencies.
Saying that, I’ve seen the SDRuno Roadmap for future releases and not only will recording of individual frequencies be possible, a more advanced scheduler is to be included. This is something I feel SDRConsole – amazing though it is – is lacking when it comes to single frequency recording. There is also the issue with SDRConsole that you are limited to recording only 6 hours worth of wav file per frequency.
Anyway, I digress. Back to the RSPdx and go2MONITOR.
To get the SDRs to work correctly with any of the go2 products means creating a configuration file and adding a ExtIO DLL file to the software. This is reasonably easy to do once you get use to it and it enables a GUI to become active so that you can control the SDR through go2MONITOR.
One interesting aspect with the RSPdx GUI is that regardless of what you enter as some of the parameters in the configuration file, the ExtIO file overrides these. Effectively, I just left some of the data as found in a basic configuration template and let the GUI do all the work for me.
So, below are some of the results with today’s first test.
First of all I went into the VHF/UHF side of things and targeted the local TETRA networks. These were found easily and after messing around with the GUI, I was able to get go2MONITOR set up to nicely find all the emissions within the 1.6 MHz bandwidth I’d chosen to use
From there, all I had to do was to select one of the found emissions and let the software do its thing.
Next I moved on to HF where there’s a plethora of data to choose from to test out the SDR. There was quite a large storm going through at the time and my Wellbrook loop and coax feed were getting a bit of a bashing with some considerable interference being produced with the really strong gusts, as can be seen below – the interference between the two HFDL bursts is one such gust.
I’ve frequently mentioned the Results Viewer that’s part of go2MONITOR and with things such as HFDL and TETRA, that process data quickly from lots of signals, this part of the software comes into its own.
The image below is two minutes of HFDL monitoring. All the red blocks is received data that scrolled through the Channel window too quickly to read live. In the viewer you can select any of the signals and you’ll be shown the message as sent. In this case, it is one sent by an Open Skies Treaty observation flight OSY11F.
By looking at the Lat/Long and comparing it to the flight history from FlightAware and its location at 1313z it ties in nicely. This flight was carried out by the German Air Force A319 1503 specially kitted out to make these flights.
go2MONITOR has a basic map function within the Result Viewer function so if there’s any Lat/Long position within any message it will plot it – as shown below for OSY11F at 1313z.
Within the General tab of Result Viewer you can get all the parameters of the signal.
One final test that I carried out was how well everything coped with a bigger bandwidth. In HF I can use up to 3 MHz of bandwidth with the licence I have – going up to 10 MHz once into VHF/UHF. In HF then, I selected 3 MHz in the GUI and then ran an emissions search.
My PC is nearing the end of its life but it coped easily with the amount of data found despite only having 4 GB of RAM with a 3.6 GHz AMD processor – a new PC is in the pipeline that is going to give me much better processing power.
Despite having 3 MHz available, not everything was identified. Most of this was at the fringes of the bandwidth, but some of the weaker signals also failed. That doesn’t mean you can’t then process them further, you can, it’s just the Emissions scan hasn’t quite been able to ID them. Saying that, the software managed to ID things within 2.2 MHz of the 3 MHz bandwidth.
I picked one of the weaker signals to see how both the RSPdx and software coped and they did very well, pretty much decoding all of the CIS-50-50 messages that were coming through on 8678 kHz.
So, overall, pretty pleased with how the RSPdx works with go2MONITOR.
Once I get a better PC I’ll be able to test at bigger bandwidths but even with 3 MHz here I was able to achieve the same, if not better, results than I have with the considerably more expensive WinRadio G31 Excalibur I have been using previously (running with the G33 hack software).
Not that I’m likely to really use go2MONITOR at big bandwidths – 1.6 MHz is probably fine for me – but for Pro’s there’s no doubt that having these “cheaper” SDRs would make absolutely no difference over using an expensive one such as those in the WinRadio range. In all honesty, I don’t think I’ll be holding on to the WinRadio for much longer – I’m more likely to get another RSPdx to cover this area of my monitoring.
On its own, as an SDR, the RSPdx is worth the money I’d say. I like it just as much as I do the AirSpy HF+ Discovery – the only real difference I can see between these two SDRs is the max bandwidth available.
I recently completed an article for Jane’s Intelligence Review magazine on the activation in December 2019 of the Russian Over-the-Horizon Radar system (OTHR) 29B6 Konteyner near Kovylkino in Mordovia.
Like all of the articles I write for them, many parts and imagery are removed due to space constraints in the magazine – for example, see my previous blog on the Murmansk-BN EW system where I have been able to add a substantial amount of extras that couldn’t be published. So, whilst I can’t publish here the actual article on Konteyner, I can show some of the extras that were removed.
How OTHR works
I could go into how OTHR works, but it’s been covered elsewhere in extreme detail. One of the best places for a basic overview is Wikipedia, where the image below is taken from.
Officially designated Object 5452, construction work of the original transmitter and receiver sites commenced in 2000, taking two years to complete.
The Konteyner receiver site, with one array, was situated 6 km to the South West of Kovylkino, whilst the transmitter site – also with one array – was located 5 km north of Gorodets in Nizhny Novgorod Oblast. The system covered airspace to the west of Russia with a central bearing of 275 degrees, arcing out in a fan, with an approximate range of 3000 km (depending on radar pulse rates – covered later). Due to Ionospheric bounce a null area is created that is approximately 900 km in depth from the transmitter site. Here, nothing would be picked up by the Konteyner systems, and other OTHRs such as Resonans-N and standard Air Defence radar systems are used to fill in these gaps.
However, the Gorodets site is no longer in use, despite many blogs and expert publications saying otherwise – Jane’s included (until my article). Located at 56°41’34.1″N 43°29’11.3″E, this site has been dismantled since at least 6/2/18 according to Google earth imagery. All the concrete footings remain, but the antenna array is no longer there.
The receiver site at Kovylkino is still there, and from June 2016 construction had begun on two other receiver arrays, creating a triangle. Array one continued to cover a 275-degree bearing whilst the new arrays covered 155 degrees and 215 degrees.
Each receiving array contains 144 masts, all approximately 34 metres in height. They are split into three sections where the two outer ones – consisting of one group of 23 masts and the other of 24 – is between 300 and 310 metres wide. Each antenna here has 14 metres of spacing between them. The inner section contains the remaining 97 masts with 7 metres between each. The total length of the array is over 1.3 km.
Matching these receiver arrays was a new transmitter site just 15km to the South East. Imagery on Google Earth from 29/6/16 shows that there are three arrays being constructed in a Y pattern, each with the same three bearings as the receiver site. By 18/8/17 it is clear that the southern array originally thought to be covering 275 degrees instead covers 095 degrees. A second array is visible being built back to back with the 095 array to cover 275 degrees. Moreover, this meant that the original 275 degree receiver array was also being used by both transmitters.
The closeness of the transmitter site to the receiver site for long range OTHR systems is a strange one. In general they are a good 100 kilometers apart – the Australian JORN system is good example of this. Moreover, putting all the arrays so close to each other – at both sites – opens the whole system up to being destroyed, or put out of action, by just one air strike!
Each transmitter array has up to 11 generator buildings located to the rear of the antennas. Four of these buildings are also located at the original 095/275 degree receiver array. Google Earth imagery from 24/2/18 shows both sites still under construction. From 1st December 2018, combat testing of Konteyner had started and satellite imagery shows all four arrays to have generators in place by November 2018.
The transmitter site consists of 44 masts in a line, 500 metres in length. The masts themselves are of differing height with the 22 tallest ones approximately 34 metres tall. The remaining 22 are approximately 25 metres in height. The masts are split up into groups of 11 of each kind.
With ranges of over 3000 km for each transmitter – effectively there are four OTHRs in use – the number of radar tracks that are captured will be in their thousands, many of which are civilian. Moreover, static features such as large buildings are also captured, showing as background noise or unknown tracks.
There are two methods used to eliminate the background noise. Firstly, during testing many of these will show through time and are deemed static and can be filtered out. Secondly, this type of OTHR – known as OTH-B or Over-the-Horizon Radar (Backscatter) – employ a Doppler effect to distinguish between static and moving targets requiring fast computers with high processing power. Doppler uses frequency shift created by moving objects to measure their velocity and so can track targets travelling at any speed, even down to 1 or 2 knots for ship traffic. Whilst older Russian OTHRs – and likely Konteyner in its early days – would have struggled in this area, modern computers can cope with the Doppler methodologies used. Anything deemed not moving by the Doppler effect can be eliminated as a potential threat or track, and are also filtered out.
To further eliminate any overloading caused by unwanted tracks, areas of interest are set up within the radar coverage which are then further split into smaller areas or “search boxes” where radar returns outside of these are ignored. These search boxes can be moved by operators as required.
The radar system is unable to determine any height parameters therefore each track is just a target at an approximate GPS position, and could be on the ground or anywhere up to 100 km in altitude! In other words, it is the equivalent to a primary track in the standard radar world. Moreover, each track could be displayed at an operators console with a radar return that depicts the target to be kilometres in size! This further complicates determining the actual location of the track.
Finally, OTHR technology does have another drawback that is much harder to filter out. Just by looking at the images below you can see that a substantial number of aircraft tracks are still captured within the search boxes, particularly in busy airspace such as around airports and heavily used civil ATC airway systems.
One thing that OTHR doesn’t have is an Identification Friend or Foe (IFF) capability. Without IFF, this then makes it even harder to determine who is friendly, who is just an airliner or who is a potential threat.
Each of these tracks needs to individually interrogated and the routes plotted to eliminate the potential threat. For instance, all traffic into Istanbul pictured above tends to fly the same routes in and out of the airport there, so whilst the track can’t be fully removed from the display (or filtered out) it can be “ignored”. If IFF was an OTHR capability – and this is the same for other OTHR systems, not just Konteyner – then known transponder codes allocated to airports/airway systems etc. could then be filtered out. This happens in everyday ATC operations where certain transponder codes can be filtered out to remove clutter at the press of a button.
This then can make OTHR monitoring reasonably labour intensive for operators covering areas of high aviation activity despite modern computer technology being there to help.
OTHR range capabilities are controlled by the pulse rate of the signal sent by the transmitter site. In general, Konteyner operates at 50 pulses per second (pps) giving a range of approximately 3000 km. This pulse rate is also used by many other OTHRs such as the Australian JORN system (Jindalee Operational Radar Network).
OTHR has a potential advantage over standard radar systems in that it can track stealth aircraft such as USAF B-2s and F-35s. JORN reportedly tracked a USAF F-117 Stealth in the 1990’s that was on a round the world flight proving it couldn’t be picked up by radar! The Royal Australian Air Force (RAAF) were so confident they’d tracked it, they gave the details of positions the F-117 took to the USAF. I couldn’t find any confirmation on this from USAF documentation but it is possible.
By using the Ionospheric HF bounce, the radar is effectively looking down on top of the aircraft rather than at a very low angled Microwave radar signal head on to the target. This creates a larger return and using Doppler frequency shift is able to establish whether the track is moving, and at what speed. An early heads-up of a potential stealth bomber attack on Russia gives them the advantage of knowing where to send intercept aircraft and set up other defence methods. In the case of an ICBM strike, extra vital minutes warning can be provided. But, as previously mentioned, the position isn’t 100% accurate and can only provide an approximate location of the target – the system can not be used for any weapons fire control.
As previously mentioned, in general Konteyner uses a 50 pps radar signal sent as frequency modulation on pulse (FMOP) using an approximate 12 to 14 kHz of bandwidth. However, through analysis of the Konteyner signals other pps rates of 25 and 100 have been recorded giving ranges up to 6000 km and 1000 km respectively. The manufacturer of Konteyner, NPK NIIDAR (Scientific and Research Institute for Long-Distance Radio Communications), has confirmed the 3000 km range, along with an altitude coverage of 100 km.
One find in my analysis of Konteyner signals was quite interesting.
Quite often when analysing OTHR signals closely, you can see weak Back-scatter return signals between the main pulses. These weak signals travel in the same radar sweep direction as the transmitted ones in either a down-sweep mode from a high frequency to a low one, or in an up-sweep mode from to low to high.
In the image below though you can see another, weaker, radar pulse emanating from the point the first down-sweep pulse ends, travelling up in frequency range and creating a V. If you look closely you can also see a very weak back-scatter signal from both.
My conclusion from this is that the up-sweep pulse is from the 095 degree Konteyner transmitter array, whilst the stronger down-sweep one is from the 275 degree array – the stronger signal is in theory pointing at my antenna in the UK and hence would be emanating from the 275 degree array.
The fact that this signal comes from the 095/275 arrays is a guess of course but I think I’m right. I am also going to guess that the complete radar pulse for the 095/275 transmitters starts at one end of one array, travelling along the 44 masts. When this pulse ends the other array starts in the opposite direction. Moreover, with this method there should be zero interference between the two arrays as they wont be transmitting at the same time.
In the image above, taken from from a screen grab of Procitec’s go2DECODE, you can see that each pulse is every 25 ms, therefore confirming a rate of 40 pps – the software also determines this automatically as shown in the table to the right. Also of note is the analysed signal in the frequency window (Hz) at the bottom. Here you can clearly see the V created by the two pulses.
When we look at the Time display window in go2DECODE (shown below) we can see that I’ve measured the total length of both pulses to be around 6.5 ms. But on closer inspection I think I’ve cut that short a little and it should be 8 ms. This would mean each pulse lasts 4 ms and ties in nicely with the 25 ms per pulse gap as there’s a 21 ms spacing between the end and start of each individual pulse.
I also wonder, that with a gap of 17 ms between the end of the second pulse and the beginning of the first one again, in theory there’s enough of a gap to fit two more 4 ms pulses between these from the the two remaining Konteyner arrays transmitting at 40 pps. Even at a higher 50 pps rate, the 12 ms gap is enough to allow the two remaining pulses to take place with a 4 ms buffer.
This then means that all four Konteyner transmitter arrays can be operational at the same time without causing any potential interference to each other, whether they use the same frequency or different ones. In this case, I’ve been lucky to capture two of the arrays using the same frequency – well, I think I have 🙂
Nevertheless, monitoring the Konteyner signals should bring some further interesting finds, especially if they are using the same frequency occasionally for different surveillance areas. Moreover, it would also be interesting to find all the various pps rates so that system ranges can be established.
Whilst for many, OTHR signals are a pain, wiping out other signals, they still have a lot to give when it comes to SIGINT gathering.
And it may not end at just the one Konteyner system. On the 1st December 2019 it was also announced that a further system would be activated to cover the Arctic region. At the moment, any potential sites have not been mentioned or found, but a likely site would be near Severodvinsk in the Arkhangelsk Oblast, or near Severomorsk in the Murmansk Oblast. Both of these are close to the 1st Air Defence Division headquarters located in Murmansk. My only negative thoughts on this would be that these sites are too close to areas of interest because of the ionosphere skip created, and also probably too far north – ionospheric bounce is not so good towards the poles.
As the original Konteyner transmitter site seems to be being maintained still, be it without any antennas, it also has the interesting aspect of being around 900 km south of the White Sea and areas of coverage needed – perfect for the ionospheric skip. Could this site be changed in aspect so that a transmitter array points to the north to cover the White Sea, Barents Sea and the northern Island? There’s certainly enough room to do this at the Gorodets site.
There has also been mention of another Konteyner site already in construction in the far east. At this time nothing has been found of any construction site that looks to be a Konteyner OTHR and I have my doubts about this. It was first muted in 2010, then again in 2018, and I would have expected something to be there by now.
I highly suspect that this plan has been abandoned, and the 095 degree OTHR of the Kovylkino Konteyner site has taken over the far east coverage.
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??
If you follow me on Twitter you’ll see that in the last month or so I’ve been sending out images of classification and decoder software go2MONITOR working with a number of my SDR’s.
go2MONITOR is part of the go2SIGNALS range of software solutions created by PROCITEC GmbH operating from Pforzheim in Germany, themselves part of the PLATH group. PLATH Group is the leading European-based solution provider for communication intelligence and electronic warfare (EW) with worldwide government customers. The group covers all aspects of signal interception and analysis split between a number of companies such as PROCITEC. EW, COMINT/SIGINT, Jamming and Decoding are just a small part of what the group specialises in.
go2MONITOR is advanced high-performance, automatic HF, VHF and UHF monitoring software capable of recording, SDR control, wideband and narrowband classification and multichannel signal decoding.
It isn’t for the faint hearted, but once you get used to using it, it really does make gathering information on networks extremely easy. And it decodes many modes other software can’t.
In a series of blogs I’m going to show you the capabilities of this amazing software, though I must stress now, it is aimed at Professional SIGINT gathering and it comes with a Professional price tag.
Saying that, it doesn’t mean it isn’t available to the non-professional. It is open to all and to cover this it comes in various versions starting with the Standard package progressing to a full Military package – which gives you the full range of HF, VHF and UHF classification and modem recognition decoders available, including PMR and SAT (Inmarsat AERO). The Standard version isn’t to be sniffed at, it still gives you an amazing range of decoders, though you could easily argue that many of these are available in other free – or near to free – decoding software like MultiPSK or Sorcerer. A full list of decoders available can be found here. Note, this list is broken down into the various packages and not all are available with the Standard option. Confirm what belongs to what if you’re thinking of purchasing.
So what’s the difference in what go2MONITOR can do with other software available? That’s the idea of these blogs, to answer just that question. It will take quite a few blogs – mainly because there isn’t just one answer.
Here then, is a brief overview of what can be done, what SDR’s it works with – in fact, not just SDR’s but all receivers that can produce a recording – and any other things I can think of.
As, I’ve said then, it can decode pretty much any data signal out there. Obviously, some signals are encrypted so it wouldn’t fully decode unless you had the key, but you can get the encrypted messages. It can also classify voice signals, not just data. So, if you wanted to hunt out various voice networks, go2MONITOR can assist you in doing this.
Here is where it excels. Classification – and doing it very quickly.
Imagine being on your SDR (SDR1) and you can see a whole load of data signals on the waterfall/spectrum and you quickly want to know what they all are. With go2MONITOR operating another SDR (SDR2) you can dial in the centre frequency of the bandwidth shown on SDR1 into the go2MONITOR/SDR2 combo, click one button – Find Emissions – and within seconds the whole bandwidth has been analysed and every signal classified.
I’ll go back a step though here. You don’t need two SDR’s. One will do. SDR1 – as long as it is a compatible SDR – can be controlled through a GUI by go2MONITOR. The software includes a waterfall/spectrum display. Like all SDR software, these displays are fully adaptable to how you like to see the signals.
Either way, you now have a list of every emission that go2MONITOR has received within that bandwidth. This list includes Modulation type, Frequency, Bandwidth, Symbol (Baud) rate and SNR. It also shows which SDR you have used for interception (useful if you’re using go2MONITOR with more than SDR at the same time, but also with other advanced features such as network control), and it also shows if the frequency is already stored within the frequency database – yes, you can create this too; or import ready made databases in a CSV format.
Already then, you have built up a picture of what these signals are. One thing to note. If the signal type is not one of those included within the package you have, it will be classed as unknown. Example – a STANAG 4285 will show as unknown in the Standard and PMR/SAT package, but will be classified correctly in the MIL package.
OK, those of us that are looking at SDR’s all the time can pretty much tell what the signals are just by looking at them, so there’s no great advantage here is there? Except, now go2MONITOR has logged these in its database which can be searched through at a later date – handy if you’re looking for potential schedules for example.
However, the next step is where things get interesting. By putting one of these emissions into a “Channel” you can carry out an advanced classification, recognition and decode. You have multiple choices here, but I generally start off with a Classification. Whilst the software has already decided what the emission type is, by doing this it double checks just this one channel and produces a choice of decoders that it is likely to be.
By using STANAG 4285 as an example, it will put this into the list of choices, but it may put other PSK signals there too. By clicking on another button, this puts the channel into Recognition mode and it reduces the hundreds of decoders down to just those in the classification list produced. The software then calculates which is the best decoder and starts to decode the signal.
If you think about STANAG 4285 in other software, you generally have to try all the various potential Baud rates – is it Long Interleaving? is it Short? etc etc. Well go2MONITOR does this automatically. It checks the alphabet and protocol and will decode it if known. More often than not it can’t calculate the alphabet, but every now and again it does and it will produce encrypted data – don’t forget, if it’s encrypted it won’t decrypt it without the correct key.
This further Recognition and Decoding is also stored in the database for later analysis, along with a recorded wav file for playback and deeper signal analysis.
Seriously, it is harder describing it in text than it is doing it so I’ve created a video that’s at the end of this blog.
I mentioned previously that the software works with receivers that aren’t SDR’s. That’s because, as long as you can create a wav file recording – Narrowband as it’s known in go2MONITOR – it can be analysed. There are things missing, the actual frequency for instance (though this can be typed into a text box so that you can then have the right information – this i’ll show in a later blog). Time stamps aren’t naturally there but again you can add these by telling the software to use the time the recording was started.
I’ve used recordings made on my Icom IC-R8500 as an example of this but it is literally the bandwidth of the mode used by the receiver that is shown on the go2MONITOR spectrogram.
You don’t actually need to own a receiver of your own. Use an online SDR such as a KiwiSDR, record the IQ as a wav file and play it back through go2MONITOR for analysis. I’m doing just that for a Jane’s Intelligence Review magazine article.
If you use SDRConsole, then you may have also tried the File Analyser function that I blogged about in August last year. The File Analyser in SDRC is excellent, there’s no doubt about it, but it has one drawback. Once you’ve carried out your recording you have to create a run through of the recording, making an XML file that effectively joins all the wav files up. If you’ve made a wide and long IQ recording this can take quite some time. With most of my overnight recordings – normally 7 hours long, with a 768 kHz bandwidth – this takes around 45 minutes to complete.
With go2MONITOR you can also record the bandwidth IQ data. With this you can do two things. Firstly you can run it through as a normal playback, classifying and decoding as you go. Secondly though, you can open the Results window which gives you a time based view of the whole recording allowing you to immediately see any transmissions. Unlike SDRC Analyser, the signals have already been classified, and more importantly, this is done straight away without any need to create an XML file first. The Results window will be covered in greater detail in a blog of its own.
However, there are no decodings here. With just an IQ recording you need to play it back and run an emission search etc. There are some basic automation tasks available, such as setting up an emissions search every 10 seconds.
But, if you have the Automated Monitoring and Tasking package, you can also have the software automatically record, recognise and decode a single emission type – or all emissions types within the bandwidth, a set frequency, between two frequencies or any other parameters you may wish to set up.
The list of SDR’s that can be used with go2MONITOR is pretty good, though due to the target audience, many of them are high end, “government/military” receivers. But, it does work with Perseus, SDRplay RSP1 & RSP2, RFSpace NetSDR and SDR-14, and of course AirSpy R2 – and now the AirSpy HF+ and AirSpy HF+ Discovery.
Supported receiver list:
Max. Rx bandwidth
Grintek GRX Lan
IZT R3xxx series
Up to 3 channels spectrum
IZT R4000 (SignalSuite)
1 channel only
Limited USB 3.0 compatibility
narda® NRA-3000 RX
narda® NRA-6000 RX
narda® IDA 2
VITA 49 support. Only 1 MHz and no receiver control at LINUX
PLATH SIR 2110
LINUX recommended. External receiver control only
PLATH SIR 2115
External receiver control only
PLATH SIR 5110
16×768 kHz subbands External receiver control only
PLATH SIR 5115
40×768 kHz subbands External receiver control only
No gain control available
R&S EM100 / PR100
External receiver control only
Experimental support. Continuous signal up to 2.4 MHz
SDRplay RSP1 & RSP2
Up to 2 channels + spectrum
Generic VITA 49 receiver support
Max. receiver bandwidth
Can be configured in a wide range for different receiver types
Other generic “Winrad ExtIO” supported receivers
Max. receiver bandwidth
As you can see, there is a huge difference in bandwidth capabilities for each receiver. I use my WinRadio G31DDC quite often with go2MONITOR, but the AirSpy HF+ Discovery (not listed as i’ve only just got it working) isn’t much worse with it’s full 610 kHz bandwidth.
When you think that the G31 has a much better operational bandwidth than 800 kHz when you use it on its own, it’s obvious which is better value if you were buying an SDR solely for using it with go2MONITOR. It is this kind of thing that many Government agencies are looking at when it comes to funding operations aimed at large scale monitoring.
That then is a very basic overview of go2MONITOR. The quick video and images have hopefully shown you a little of what is possible.
Outside of a Professional SIGINT operation, why would an amateur radio monitor need something like go2MONITOR? And would they pay the price?
I think they would. After all, most of us have spent a fair amount on radio monitoring over the years, so why not on software that would make their monitoring not only quicker and easier, but potentially open up new areas of monitoring.
Many of us specialise in certain monitoring areas – Russian military, particular the Navy and Strategic aviation for me for example. With go2MONITOR I have already used it to hunt out potential Russian Northern Fleet frequencies by running an automated 10 second CW emission scan overnight within a bandwidth block. By doing this, and then analysing data found in the results window, I was able to target certain frequencies to see what activity there was on subsequent nights.
Whilst there are other decoders available – some of which are plugins in software such as SDR#; some of which are free – it is the quickness and ease with which it can be done that makes go2MONITOR attractive. The big question is, would you pay for this?
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  303 847 023 534 734 619 822 332
[with wrong read back of group three, corrected by 16116]
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
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
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.
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
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
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.
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.
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
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
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