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 shack, finally operational after a few months off.
With the rebuild of my shack complete I’ve been able to start testing out all my radios, new connections etc.
The Mini-Circuits components all come well packaged in anti-static bags
A whole bundle of new cables from Mini-Circuits arrived last of all and have helped tidy up the back of the radio 19″ rack considerably. I’ve previously installed quite a few Mini-Circuits components, including 0.141″ diameter Hand-Flex interconnect cables, and so it was more of these that I opted for. The bonus with these cables is that they are hand formable meaning you can shape and bend them into pretty much any area that you want to. The 141 series (which I use) are capable of a 8mm bend radius, whilst the thinner 086 series can be bent to 6mm.
Being able to manipulate the cables certainly helps in tight spaces, and when you don’t want them to hang down
Previously I used hand-made cables with RG58U coax, but in order to have a 19″ rack that can slide out from under the desk, the cables needed to be longer than actually required. Because of this the cables would drop down into all the others attached to the PC and in some cases cause a little interference. With the Hand-Flex cables I’ve been able to use the same length of coax to allow me to move out the rack, but be able to bend them up and out of the way of the PC cables.
They’re also very good for the radios on the rack, being able to bend them and hold in place around the radios and other cables. They are near lossless too with a quoted insertion loss of 0.01 dB in the HF band to 0.55 dB at 18GHz. I normally run tests of the Mini-Circuit components when I receive them and find that the figures quoted are near spot on. I highly recommend these cables if you’re looking to upgrade your systems, and are available from the Mini-Circuits website, along with lots of other goodies that will tempt you.
Measurement of insertion loss of the Mini-Circuits ZF3RSC-542B-S+ Power Splitter/Combiner I also purchased as part of my plans for satellite communication monitoring. This is connected to the AirSpy SDR and takes feeds from two SatCom connections (currently deactivated) and a WinRadio AX-71C Discone Antenna. Mini-Circuits quote an insertion loss of around 19.5dB at 130 MHz which is confirmed here with a signal generated at -20dB being less than 1dB out at -40.48dB when passed through the combiner.
This image shows how the cables can be held in place without cable ties
The radio setup now includes two new SDR’s – an AirSpy HF+ and a standard AirSpy with the HF+ replacing the Enablia TitanPro. I’ve also reinstated my WinRadio G31DDC which had been in storage for a year or so. I really do like the TitanPro, and have put it into storage for the time being. The recording capabilities in particular are great with it being able to select 40 frequencies at once spread over numerous bandwidths, but I have had issues with the power supply – one being it caused interference. I attempted to make one of my own but it has a 6v(+/-1v)/2.5 Amp current requirement and no matter how many different methods of building my own supply using a 12v feed downgrading to 5, 6 or 7 volts, it just wouldn’t work in a stable manner. In the end it was easier to remove it and slot the G31DDC back in its place.
As it is, I’d forgotten how good the G31DDC is and I don’t really feel like I’m missing much thanks to the ability to use the other SDR’s with SDR Console V3 and it’s SDR Analyser.
The three 19″ racking units from Penn Elcom, along with all the shelves, have been very useful and certainly makes things easier when it comes to changing radios and connections over. I can just disconnect a few things and slide the whole unit out. I also obtained a 19″ Project box from them which I used as my main 12v switch unit. This is connected to two regulated desktop power supplies that act as master switches.
Although the SDR Console website page for the Analyser states it isn’t available yet, this is incorrect and it is downloaded with the latest version of the main programme.
If you’re a current user of V2 or have been in the past then you won’t notice much difference. You can have up to 24 parallel demodulators operating within the SDR’s bandwidth that you have chosen, all of which can run independent of each other in receive and record. You can also run each demodulator through a decoder such as MultiPSK independently and decode these in parallel with each other. This capability has taken that step towards those of the TitanPro, especially when being used with the Elad FDM-S2 that can provide a Maximum DDC bandwidth of 6144kHz’s.
Unfortunately, whilst you can schedule recordings of IQ data, you still can’t do this for individual channel recordings. This is a real shame as it would be a fantastic addition to the capabilities of SDR Console.
Getting back to the analyser though this does, in theory, cancel out the lack of channel recording scheduling.
When you record IQ data it is saved as WAV files, split into multiple ones depending on how long a recording you make . All of these files can be individually played back through the incorporated SDR Console player but even better is the use of the File Analyser.
With this you get a visual “image” of the complete recording, whereby after opening the analyser you get it to combine all the files into one XML file. For the image below I used the FDM-S2 with a selected bandwith of 768kHz centred on 4425kHz, hoping to catch calls to Russian Naval base Severomorsk in CW(RJD99) from ships operating in the region. I set the scheduler up to record from 0000z to 0700z which worked perfectly, giving me 78 files totalling 78GB – obviously, the bigger the bandwidth, the larger the total file size.
After clicking on New in the analyser and browsing to the relevant folder the WAV files are saved in, the analyser finds the first one and gives this as an option to open – it automatically adds the remaining WAV files and starts the process. This can take quite some time to extract, around 45 minutes for the example shown. But you only need to do this once because once it has finished you can save it as an XML file and open it at any time – in this case it was a 28MB XML file.
A note here – do not then delete the WAV files as the analyser still needs them.
As you can see, I was successful in locating calls to RJD99, and I have highlighted some of the others that I took a look at – this is just a screenshot of two hours out of the seven recorded.
All you then need to do is find any signal of interest, and after clicking on select and start in the top ribbon, click on the signal. This will then start playing the file from that location in the main SDR Console window. You don’t need to stay on that frequency, you can use the Console as if you were listening live and move around the frequency range you dictated in the bandwidth of the recording.
And, as it is basically a live screen you can do additional things such as record and use decoding software.
RJI92 calling RJD99 on 4416 kHz during playback of the Analyser
When using the Analyser I run this through a separate PC meaning SDR Console itself can carry on working on the main radio control PC. This is also handy if you’re away but have time to go through the IQ data using a laptop. Just copy over the original WAV files to a portable hard drive/memory stick and carry on as described above.
There are numerous other functions available for you to use with the main part of SDR Console, some I still haven’t had the chance to play with completely. I’m still exploring things such as the Signal History function which can store up to 48 hours of data. Here you can export data in CSV format to third-party programs such as QtiPlot. Signal history can also be used within the Analyser
This is useful as it can give you a quick overview into single frequency use, signal strengths, fading and such like. Definitely something I need to spend more time on.
It’s been a long time coming, but Version 3 of SDR Console has been well worth the wait.