Inmarsat L-Band signals from both CONUS and POR need to be routed to various receivers and SDRs, this distribution system is a pretty simple solution (as shown below).
Inmarsat Antenna Distribution.
It’s based on taking an L-Band signals from a dish, where pre-amplification at the feed is already done and then feeding it to another L-Band amplifier, followed by a band-pass filter (since the previous amplifier is rather wide) and then finally to an L-Band splitter. Various receivers and SDRs are then connected to the output of the splitters. The amplifiers, band-pass filters and splitters are all from mini-circuits. Another view is shown below.
Inmarsat Antenna Distribution.
The two L-Band amplifiers require 12V for proper operation. Control of the supply voltage is feed through a “web relay” for remote control. The web control relay is a compant called KMtronic – thet are available on Ebay. Below is a closeup of the web relay.
Web Control Relay.
There is some built in web server application that you can access from ant browser as shown below.
Web browser interface.
While it’s convenient to have access via a web browser I prefer to use a standalone application, so that will be my next project, stay tuned.
New spacecraft and new dish were tested this weekend. The spacecraft is the Chinese Chang’e 5-T1, an experimental unmanned lunar mission that was recently launched by the CNSA. The dish is a 1.8m Prodelin offset and is inverted for ease of mechanical clearance. The first signal ever received by this dish is that from the Chang’r 5-T1 spacecraft @ 2210.8 MHz (S-Band). The signal is shown below.
After some work it is now possible to fully support HackRF One with my Inmarsat Aero decoder. In the past, the Inmarsat Aero decoder used two SDRs (each covering 2MHz) to cover up to 4MHz of L-Band spectrum as well as an expensive communication receiver. All this has been replaced by one HackRF One SDR/receiver. The diagram below shows the old setup and the new setup.
A sample screenshot showing the Aero Call Log (upper left), Single AMBE Voice decoder (upper right, 6 channels running, but only one shown), Overall Status of all 9 decoders (not including linked Aero-I channels) and finally the streamer application that is responsible for interfacing the HackRF One over USB and then streaming multiple channel of IQ over Ethernet to other decoders.
I am so happy with the HackRF One that I have ordered another for some more applications.
The HackRF One SDR is a great value but it’s frequency stability leaves something to be desired. Using the Si5338 clock generator from Silicon Laboratories is an easy way to address the problem (if it’s really a problem for your application). The Si5338 is a programmable clock generator that can take an input reference clock (like a 10MHz sine wave from a GPS) and then generate any output frequency with a variety of different output driver types. Ironically in this case, we are simply generating a 10MHz output; but this output is “locked” to the input and so will behave with the same frequency changes, which luckily for us is very minimal if you are using an external GPS as the reference. Another advantage is that the output of the Si5338 is square wave and this is precisely what the HackRF needs (in some cases if you sine wave is at the appropriate voltage levels, you can feed this directly to the CLKIN of the HackRF). The output levels of my GPS are not correct for the HackRF. It’s not clear if the sine wave would be an issue or not.
Below you can see the HackRF One and beside it the Si5338 Evaluation Board. I am using an Evaluation Board to make sure everything works and then I will attempt to make a PCB with the exact configuration and programming that is needed.
Si5338 Clock Generator.
I am using my very inexpensive Rigol DS-1102D digital oscilloscope to ensure the output has correct voltage requirements for input into the HackRF One. In this case, I have programmed the Si5338 to use 3.3V CMOS output for the clock.
HackRF One with Si5338 board.
After a quick reset to the HackRF the SDR automatically switches over to the external clock. You do need to ensure you have the latest firmware and CPLD code (at one point there was a bug that prevented the automatic swith over).
So, now we just need to check the frequency accuracy. To do that I am comparing the “center frequencies” of an Inmarsat Aero decoder. This is a good test because the signals have very little drift since they are used by Aircraft that need to adjust for doppler. I removed the previously determined static error correction of -4250 Hz and Voila! Also, in addition to the static correct there was dynamic drift as well, that is gone too. All that is left is that of the satellite itself. I know this because i have another system that is completely locked to external reference and delta is +- 1 Hz. Not bad!
Below is screenshot from Aero decoder, the highlighted area in yellow is the real time delta from decoder PLL.
I’m always looking for opportunities to reduce the costs associated with high quality decoding tasks. The HackRF One is intriguing because it’s not very expensive, has a wide band receiver (10MHz – 6GHz) and an SDR that is capable of sample rates of 2-20 MS/sec (albeit with only an 8-bit sample size). The only way to find out how good (or bad) this SDR was to order one and test it out. Below is my new HackRF One wide band SDR.
Normally, I would hook up an SDR to the IF output to a communication receiver, but this little SDR has a wide band front end that supports 10MHz to 6GHz. So, I hooked it up directly to the Inmarsat POR L-band splitter that feeds many of the receivers here at USA-Satcom.com.
L-Band Splitter for Inmarsat POR.
The next step was to just do a quick test to ensure things works. So, I used SDR-Console V2 to get the HackRF One up and running on windows, tuning to the Inmarsat POR L-Band. It’s quite amazing to see almost the entire satellite transponder space on one screen! Again, using the SDR-Console-V2 I set it up for USB demodulation and directed the audio output to one my really old soundcard based decoders. Below you can see the old-school Inmarsat Standard-C decoder running without any immediate issues.
Decoding Std-C using HackRF One.
Soundcard based decoding is error prone for many reasons, so now that we have gotten this far, I went ahead and made a quick modification to my Aero-P multi-channel decoder to see how well things would work. This time I took advantage of the UDP Broadcast feature to steam IQ samples to my decoder. Below you can see 3 channels of Aero-P being decoded, again without any immediate issues.
HackRF One is set to the minimum sample rate of 2MHz for this test. As you know, the HackRF One uses just 8-bit samples and so there is some concerns about having adequate dynamic rage. But so, far with the fairly strong Aero-P signals there are no problems, it was running for about 4 hours without a single frame being lost or even a single CRC error.
While the testing so far has been successful I still want to do some additional modifications to allow full Aero decoding, which requires 4MHz of BW and 9 total channels. Voice channels can be weak and 8-bit sampling could introduce problems.
Two issues exist so far; The frequency stability is not so good (i had to correct for 4.5KHz out of the box), however, once set, it’s OK. This should be easily fixed by getting a more precise clock source – but there appears to be a HackRF One firmware bug preventing switch over to external clock source. The other issue is while 2MHz sample rate looks pretty clean, 4MHz has some spurs and images – this could be problematic for wide band use for my applications.
So, next steps are firmware upgrade to fix clock issues, more accurate clock source and finally some modifications to Aero decoder to allow 4MHz of spectrum as input.
If all this is successful, the HackRF One will replace one communications receiver and two SDR (that are limited to 2MHz sample rate). That would be quite amazing.
The diagram below illustrates the current Aero coverage that is possible here at USA-Satcom. As you can see there is quite a bit of IQ bandwidth to deal with and consequently at least two i7 hex core machines are needed to handle all the filtering and demodulation techniques. The industry really needs some multi-channel SDRs to avoid the needless transfer of so much spectrum. Multiple channels at the SDR would reduce CPU utilization, network traffic etc.
CONUS and POR Aero Coverage.
Protocols currently supported are:
Aero-H and H+
SDRs that are currently supported are:
The decoders just interface to the SDRs, so the communication receivers are not too important. However, we are currently using the following:
It’s that time of year again! Regular science crew transportation missions to and from Antarctica using US Air Force aircraft. Communications occur via Military Satcom in the Pacific Ocean Region. Below are a few recent satcom intercepts as well as ACARS from AERO-I via Inmarsat. I will post more intercepts to this thread as they occur.
Photo by afrc.af.mil. C-17 offloading in Antarctica.
Currently there are 9 AERO-I 600 Baud GMSK channels on POR. Quite a bit of ACARS and CPDLC traffic along with the usual Call Management signaling units. These signals are huge as you can see from the “tightness” of the phase diagram shown below. The AERO-I decoder shown below is simultaneously decoding all channels using just one SDR. There are also some 1200 Baud AERO-I channels present on POR, something to look at next.
Finally found an Aero H/H+ call that was encrypted. Supported crypto services on Aero are US-STU-III (Secure Telephone Unit), STE (Secure Terminal Equipment), FNBDT (Future Narrow Band Digital Terminal). Not clear which service this actually is but I suspect it’s STE. Nice to see encryption being used appropriately. This particular aircraft is a Gulfstream and is registered to Bank of Utah.
This call was not likely intended to be routed via the AMBE voice path. The AMBE codec bandwidth is not sufficient to run crypto.