After my last blog – Weather Fax from Honolulu – I decided I’d drop the Weather HF Operations in Honolulu an email to see if they could confirm whether it was them that I received or not.
After a few hours I got back the following response from one of their Ops staff:
Aloha Tony! In reviewing the schedules looking for that particular chart (Honolulu’s 24 hr Wind/Wave), I believe that is only transmitted from Hawaii. While there are Wind/Wave charts sent on all of the stations, the 24 hour Wind/Wave that is produced by WFO Honolulu is only broadcast on the Hawaii frequency.
From this, I’m happy to say it was Honolulu that I received and have noted it as such.
At the time they replied I was actually listening out on one of the NOAA Boston frequencies to see if I could get anything from them.
It was static on 9108.1 kHz (9110 kHz) when I started and was about to give up, when all of a sudden a transmission started part-way through a chart – just like they’d flicked a switch on that frequency transmitter. As you can see below, the chart just started.
I received a further two charts before the end of that days charts and the service stopped.
Quality not too bad, 4880 km away from here.
Again, all received on my Icom IC-R8500 and Wellbrook Loop, using JWX 3.0 software.
I’ve been tinkering with Marine weather radiofacsimiles recently. I do this from time to time, especially when the weather is good here and I want to know when it is likely to end – more often than not, very soon, though I’ll have to admit the weather has been amazing in recent weeks.
I’ve used a number of decoders over the years and they have all produced some pretty good results, and each have their different features. Some work with SDRs whilst some don’t – or rather my set up doesn’t let them work with SDRs as I run everything through a M-Track 8 mixer.
Some of the decoders i’ve tried include – Sorcerer, MultiPSK and fldigi. fldigi has been my favourite for some time until recently.
The only receiver I don’t run through the mixer is my trusty Icom R-8500 receiver connected to the PC via the microphone-in input using a mono cable from the record-out on the Icom. I have to say this gives the best results with all the software tried. This is probably because it is less susceptible to PC jitter – when the processor skips due to lag – and the image is put out of alignment. I find, probably because my PC is getting past it, that the processor requirements to run the SDR software is enough to make this happen.
Any misalignment requires some Photoshop manipulation, often quite a few just to rebuild the image. Sometimes this is required anyway to recreate a split image – if the phasing was not automatically detected, the modem could not deduce the beginning of an image causing an an image which is horizontally shifted. This is very easy to fix with Photoshop if this happens.
Some of the software available does the rebuilding for you, but some don’t. Each can control slant error and suchlike, but each is different in doing this. And each Fax sender – Northwood (GYA), DWD and NOAA for example – generally works with a different slant requirement.
The latest software I’ve used – and I think the best to date – is JWX 3.0. I still haven’t managed to get this to work with an SDR but I have tried. But I do know it does work with the AirSpy HF+ Discovery as one of my contacts on Twitter – Gerhard Schweizer – has managed it after I pointed him to JWX.
Anyway. This is all leading to a search I was making for GYA’s fax’s on the 9th May. I wanted to get the 24, 48, 72 and 120 hour surface prognosis charts and had set everything up on 4608.1 kHz USB – the true frequency is 4610 kHz but you have to step down 1.9 kHz in USB mode for a proper decode.
Unusually I didn’t get anything, so after a while I decided to try the other frequencies used by GYA. This included 11084.4 kHz (11086.5 kHz) which I’ve never found anything on before, and even has a question mark next to it in the Wordwide Marine Radiofacsimile Broadcast Schedule produced by NOAA.
On going to 11084.4 kHz, to my surprise, I could hear a very faint signal though I realised quickly that the frequency was off a little. I wondered then if the GYA frequency noted in the NOAA document was incorrect. Turning the dial on 8500 it settled on 11088.1 kHz where a clear-ish image was coming through on JWX.
But the chart didn’t quite look right for a GYA one, it looked more NOAA like, and as it was at the end of the chart, the senders information and chart title box was starting to come through – along with a NOAA badge.
As well as the badge, the ID started to become visible and I was amazed to see NOAA/National Weather services Honolulu – 24 HR Wind/Wave Forecast – pictured below.
The transmitter site for Honolulu (KVM70) is located at 21°25’34.82″N 158° 9’12.36″W – next to an impressive weapons storage bunker area – on O’ahu. From my shack this equates to a range of 11,132 km! The schedule states that KVM70 uses a 4 kW transmitter.
In the NOAA schedule it does say many of these charts also broadcast from Pt. Reyes, CA and Kodiak, AK but even so this would be 8118 km from Point Reyes; or 7133 km from Kodiak. However, the Honolulu frequency isn’t listed under their entries in the schedule so I’m not certain whether they are sent in parallel from these transmitter sites at the same time or not. Certainly, the charts aren’t listed under either Point Reyes or Kodiak.
In all honesty, I expect that it is one of these stations that I received, but I’d like to say it was KVM70 🙂
Below are the charts received. As you can see, from the 0856z chart, the signal starts to disappear and they become barely readable – eventually just noise.
I did set up the R8500 and JWX the next night to see if I received anything and it drew a blank, but another try today, on the 11th, did produce some weak results. The chart below is the best out of the bunch, received at 0715z. It also shows a good example of phasing error and cpu jitter – the vertical black line should be on an edge so the far left of chart should be on the right; the lower portion has jumped a little due to cpu usage.
The frequency is now stored in CSVUserlist so I’ll revisit it every now and again to see whether I’m able to get some more charts.
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?
After receiving quite a few requests on information about the Enablia TitanSDR and it’s capabilities, I decided it would be good a good idea to create a demonstration video that would hopefully show just how good an SDR it is. The video is at the end of this blog.
I think that a lot of people can’t understand just why the two versions are the price they are, especially when it seems that a new dongle SDR is being evolved every day at a ridiculously cheap price. Yes, they are expensive but when you compare the price of these SDR’s to a top end desktop receiver, such as the Icom IC-R8500 for example, then it is fairly comparable.
But you must consider the fact that the Titan is really more than one receiver. The Pro version is 40 receivers, the standard is eight. You can’t record independently using the Icom, you need some additional software or a digital voice recorder plugged in to the receiver; and even then you can only record the one frequency – the Pro can record 40 frequencies, the standard can record eight.
The TitanSDR Pro can monitor up to 40 frequencies at the same time. Here, 10 frequencies are being monitored, mainly Oceanic ones.
Then, you can’t really record any bandwidth to play back using the Icom, but both versions of the Titan can record up to three separate bandwidths. These can then be played back, either through the SDR itself, or on another PC using the supplied USB dongle that carries a second version of the software – and if you did this you could be listening to, or recording, further frequencies or bandwidths. And all these separate bandwidth recordings can, of course, be played back multiple times, with multiple recordings being made within them; or data can be decoded; or signals analysed – what ever you require from an SDR.
This image shows the Titan monitoring 12 frequencies, 6 of which are decoding ALE using PC-ALE. This can take place in the background, while listening to the other frequencies on the SDR.
But, of course, this is just standard for any SDR isn’t it?? But is it?? Can you think of another SDR that has the capability to monitor/record 40 frequencies at once? I can’t.
The nearest SDR I found to the Titan in quality of not only recording capabilities but in quality of filters etc. meant that I would need to buy around 13 SDR’s of this model and spend over €30,000. Yet, just one of this model costs pretty much the same price as the Titan. Now, with that knowledge, the price of the TitanSDR’s really doesn’t seem that bad after all.
Don’t forget, the TitanSDR is a Military spec. SDR, designed originally for agencies to monitor multiple frequencies for analysis and data collecting. It already has top specifications but Enablia are still willing to listen to the users and add requested features if they can. They have already done this with quite a few ideas that myself and other users have suggested.
You’d think that the Titan would be a CPU guzzler wouldn’t you? Well it isn’t. Here the SDR is running 31 frequencies, whilst making multiple decodings using MultiPSK and PC-ALE. The CPU is running at only 27%, and that was it’s max reading.