The international space station (ISS) is currently testing transmission of a DVB-S digital video signal. At the moment only a blank test pattern is transmitted, but one day they hope to be able to transmit live video properly for the purposes of making live contact with astronauts, and possibly to stream video of scientific experiments, extravehicular activities, docking operations, or simply live views of the Earth from space.
I have been able to receive DVB-S broadcasts from the ISS (known as HamVideo or HamTV) with a high-gain 2.4 GHz WiFi antenna ($50), a custom downconverter ($65), a R820T2 dongle, and a software demodulator (Edmund Tse’s gr-dvb). I used to think this could only be done with much more expensive SDR hardware.
It is commonly known that rtl-sdr dongles do not have enough bandwidth to capture mainstream satellite TV broadcasts, but the ISS happens to transmit DVB-S at only 2Msymbols/s in QPSK with FEC=1/2, which translates to 2 MHz of RF bandwidth (2.7 MHz including roll-off).
Before anyone gets too excited I should mention that:
This was done during a favourable pass of the ISS (elevation 85°)
With a fixed antenna, only a few seconds worth of signal can be captured
Demodulation is not real-time (on my low-end PC)
Currently the ISS only transmits a blank test pattern.
I now believe the BoM will be less than $50 by the time the ISS begins broadcasting interesting stuff on that channel.
Pabr uses a 2.4 GHz parabolic WiFi antenna to receive the signal. He writes that ideally a motorized antenna tracker would be used with this antenna to track the ISS through the sky. Also since the DATV signal is transmitted at around 2.4 GHz, a downconverter is required to convert the received frequency into one that is receivable with the RTL-SDR. The DATV decoder is available on Linux and requires GNU Radio.
When Tom Taylors home heating boiler was replaced the builders also replaced the old wired rotary thermostat with a digital wireless one. It sounds good, but Tom soon discovered that the thermostat UI was terrible and that the buttons were horrible to press, making him prefer to shiver in the cold. So Tom decided to see if there was a smarter way to control the heating.
When Tom investigated the thermostat, he discovered that the wireless unit transmitted in the unlicensed 433 MHz band and that the thermostat only transmitted two commands, turn on or turn off. By using his RTL-SDR and the CubicSDR software on his Mac he was able to detect the short blip of the thermostat wireless signal. Next he recorded the on and off signals and opened the sound files in Audacity, an audio processing software tool. In Audacity he was able to compare the sound waveforms of the on and off signals.
From his analysis he discovered that each signal consisted of a preamble and then an on or off command which is repeated twice, presumably to reduce the likelihood of interference. Tom also discovered that the commands were encoded with pulse width modulation.
From this knowledge Tom was then able to use a cheap 433 MHz transmitter together with an Arduino microcontroller board and a short script to create identical on or off transmissions that control the boiler. Tom writes that his next steps are now to create a heating schedule based on his families shared calender, make a thermostat control loop and create a web connected interface with a Raspberry Pi.
The 433 MHz thermostat on/off signal detected with an RTL-SDR in the CubicSDR software
The Spyverter is a new high performance upconverter that is being developed by the team behind the Airspy software defined radio and the SDR# software. It is designed to be used together with the Airspy, but it should also be compatible with other SDRs as well. The main claimed advantages over other upconverters will be it’s low loss and high IIP3 performance, which means that the Spyverter will not saturate in the presence of strong signals as easily as other upconverters.
Recently W9RAN, who is involved in the design and testing of the Spyverter uploaded some demo videos of the Spyverter + Airspy combo in action. The first video shows how the Spyverter when used together with the Airspy and SDR# allows for seamless tuning between VLF, HF through to VHF/UHF (no need to set any offsets).
Seamless tuning of SDR# with AIrspy & Spyverter
The next video shows the Spyverter + Airspy combo working during a RTTY contest on 40M with very densely packed signals, some of which were very strong.
W9RAN demo of Spyverter in 40 meter RTTY contest
W9RAN (ranickel on YouTube) also has additional Spyverter + Airspy videos on YouTube for viewing if you are interested.
Bus sign: Wireless bus telemetry updates this sign.
A similar reverse engineering of bus telemetry was performed before by Oona Raissan in Helsinki, Finland. Oona found that in Helsinki bus telemetry was transmitted as a DARC subcarrier embedded in regular broadcast FM radio. In many countries bus telemetry runs through GSM or TETRA communications as well, which are encrypted and would be very difficult to decode.
However in Paderborn, Germany Bastian discovered that the bus telemetry system used a different protocol which he discovered by noticing that some very strong signals appeared on his spectrum at 150.9 MHz whenever a bus drove by his flat.
After making a recording of this signal in GQRX, bastian analysed it in Audacity and discovered that the binary data bits were encoded by the presence or absence of a half sine wave. After discovering the encoding he was then able to determine the bit rate and build a decoder in GNU Radio. His post goes into further detail about concepts he used in his GNU Radio program such as frame detection, bit stuffing and error detection.
Finally, with all his decoder program written he was able to gather lots of data from each packet such as the bus ID, line, bus stop, distance from last bus stop, delay, position and even the orientation of the bus. Bastian has also uploaded a video showing everything in action, which we have embedded below.
Bus position heatmap from data obtained via the RTL-SDR
A reader of our blog, EBC81, has written in to let us know about a new RTL-SDR based AIS decoder that he has written for the Android OS. AIS stands for Automatic Identification System and is used by ships to broadcast their GPS locations, to help avoid collisions and aid with rescues. An RTL-SDR with the right software can be used to receive and decode these signals, and plot ship positions on a map.
EBC81’s program is called rtl_ais_android and can be downloaded from this GitHub link. It decodes the AIS data into NMEA messages, which can then be sent via UDP to mapping programs in Android or a program like OpenCPN on your PC. To use the app you will need a USB OTG cable to connect your Android device to the RTL-SDR.
In the future EBC81 hopes to create a second app which will display the ship positions on a map.
Inmarsat is a communications service provider with several geostationary satellites in orbit. They provide services such as satellite phone communications, broadband internet, and short text and data messaging services. Geostationary means that the satellites are in a fixed position in the sky and do not move. From almost any point on earth at least one Inmarsat satellite should be receivable.
Inmarsat transmits in the L-band at around 1.5 GHz. With an RTL-SDR dongle, a cheap $10 modified GPS antenna or 1-2 LNA's and a patch, dish or helix antenna you can listen to these Inmarsat signals, and in particular decode one channel known as STD-C NCS. This channel is mainly used by vessels at sea and contains Enhanced Group Call (EGC) messages which contain information such as search and rescue (SAR) and coast guard messages as well as news, weather and incident reports. More information about L band reception is available at UHF-Satcoms page. See the end of this post for a tutorial on modifying a GPS antenna for Inmarsat reception.
Some examples of the EGC messages you can receive on the STD-C NCS channel are shown below:
Military Operations: Live Firing Warning
STRATOS CSAT 4-AUG-2015 03:21:25 436322
SECURITE
FM: RCC NEW ZEALAND 040300 UTC AUG 15
COASTAL NAVIGATION WARNING 151/15
AREA COLVILLE, PLENTY
CUVIER ISLAND (REPUNGA ISLAND), BAY OF PLENTY
1. LIVE FIRING 060300 UTC TO 060500 UTC AUG 15 IN DANGER AREA NZM204.
ANNUAL NEW ZEALAND NOTICES TO MARINERS NUMBER 5 REFERS.
2. CANCEL THIS MESSAGE 060600 UTC AUG 15
NNNN
Armed Robbery / Pirate Warning
NAVAREA XI WARNING
NAVAREA XI 0571/15
SINGAPORE STRAIT.
ARMED ROBBERY INFORMATION. 301845Z JUL.
01-04.5N 103-41.8E.
FIVE ROBBERS ARMED WITH LONG KNIVES IN A SMALL UNLIT HIGH SPEED BOAT APPROACHED A BULK CARRIER UNDERWAY. ONE OF THE ROBBERS ATTEMPTED TO BOARD THE SHIP USING A HOOK ATTACHED TO A ROPE. ALERT CREW NOTICED THE ROBBER AND RAISED THE ALARM AND CREW RUSHED TO THE LOCATION. HEARING THE ALARM AND SEEING THE CREW ALERTNESS, THE ROBBERS ABORTED THE ATTEMPTED ATTACK AND MOVED AWAY. INCIDENT REPORTED TO VTIS SINGAPORE. ON ARRIVAL AT SINGAPORE WATERS, THE COAST GUARD BOARDED THE SHIP FOR INVESTIGATION.
VESSELS REQUESTED TO BE CAUTION ADVISED.
Armed Robbery / Pirate Warning
NAVAREA XI WARNING
NAVAREA XI 0553/15
SINGAPORE STRAIT.
ROBBERY INFORMATION. 261810Z JUL.
01-03.6N 103-36.7E.
DUTY ENGINEER ONBOARD AN UNDERWAY PRODUCT TANKER DISCOVERED THREE ROBBERS IN THE ENGINE ROOM NEAR THE INCINERATOR SPACE. THE ROBBER THEIR BOAT. A SEARCH WAS CARRIED OUT. NO ROBBERS FOUND ON BOARD AND NOTHING REPORTED STOLEN. VTIS SINGAPORE INFORMED. COAST GUARD BOARDED THE TANKER FOR INVESTIGATION UPON ARRIVAL AT SINGAPORE PILOT EASTERN BOARDING AREA.VESSELS REQUESTED TO BE CAUTION ADVISED.
CANCEL 0552/15.
Submarine Cable Repair Warning
NAVAREA XI WARNING
NAVAREA XI 0569/15
NORTH PACIFIC.
SUBMARINE CABLE REPAIRING WORKS BY
C/V ILE DE SEIN. 05 TO 20 AUG.
IN VICINITY OF LINE BETWEEN
A. 21-37.3N 156-11.5W AND 25-03.6N 148-43.2E.
CANCEL THIS MSG 21 AUG.
Search and Rescue - Missing Vessel
ON PASSAGE FROM LAE (06-44S 147- 00E) TO FINSCHHAFEN (06-36S 147-51E), MOROBE PROVINCE. VESSEL DEPARTED LAE AT 310500Z JUL 15 FOR FINSCHAFFEN WITH ETA OF 310800Z JUL 15 BUT FAILED TO ARRIVE.
ALL VESSELS REQUESTED TO KEEP A SHARP LOOKOUT AND BE PREPARED TO RENDER ASSISTANCE. REPORTS TO THIS STATION OR MRCC PORT MORESBY VIAEMAIL: ******@****.***.**, TELEPHONE +*** *** ****; RCC AUSTRALIA VIA TELEPHONE +*********** INMARSAT THROUGH LES BURUM (POR ***,IOR***), SPECIAL ACCESS CODE (SAC) **, HF DSC *******
NL BURUM LES 204 4-AUG-2015 03:23:14 773980
AMSA_ER 23150928
PAN PAN
FM JRCC AUSTRALIA 030858Z AUG 15 INCIDENT 2015/5086
AUS4602 CORAL AND SOLOMON SEAS
23FT WHITE BANANA BOAT WITH BROWN STRIPES, AND A 40HP OUTBOARD AND 5 ADULT MALES IS OVERDUE ON PASSAGE FROM LAE (06-44S 147- 00E) TO FINSCHHAFEN (06-36S 147-51E), MOROBE PROVINCE. VESSEL DEPARTED LAE AT 310500Z JUL 15 FOR FINSCHAFFEN WITH ETA OF 310800Z JUL 15 BUT FAILED TO ARRIVE.
ALL VESSELS REQUESTED TO KEEP A SHARP LOOKOUT AND BE PREPARED TO RENDER ASSISTANCE. REPORTS TO THIS STATION OR MRCC PORT MORESBY VIA EMAIL: *******@****.***.**, TELEPHONE +*** *** ****; RCC AUSTRALIA VIA TELEPHONE +************ INMARSAT THROUGH LES BURUM (POR ***,IOR ***), SPECIAL ACCESS CODE (SAC) **, HF DSC *********, EMAIL: ******@****.***.** OR BY FAX +************.
NNNN
Scientific Research Vessel Drilling - Request for wide clearance
NL BURUM LES 204 4-AUG-2015 02:29:41 709950
AMSA_ER 23153978
SECURITE
FM JRCC AUSTRALIA 040224Z AUG 15
AUSCOAST WARNING 202/15
SPECIAL PURPOSE VESSEL JOIDES RESOLUTION CONDUCTING DRILLING OPERATIONS IN POSITION 28 39.80` S 113 34.60` E
2.5NM CLEARANCE REQUESTED.
NNNN
Weather Warning
PAN PAN
TROPICAL CYCLONE WARNING / ISSUED FOR THE NORTH OF EQUATOR OF METAREA
XI(POR).
WARNING 050900.
WARNING VALID 060900.
TYPHOON WARNING.
TYPHOON 1513 SOUDELOR (1513) 930 HPA
AT 19.9N 133.2E WEST OF PARECE VERA MOVING WEST 12 KNOTS.
POSITION GOOD.
MAX WINDS 95 KNOTS NEAR CENTER.
RADIUS OF OVER 50 KNOT WINDS 80 MILES.
RADIUS OF OVER 30 KNOT WINDS 240 MILES NORTH SEMICIRCLE AND 210 MILES
ELSEWHERE.
FORECAST POSITION FOR 052100UTC AT 20.1N 130.6E WITH 50 MILES RADIUS
OF 70 PERCENT PROBABILITY CIRCLE.
935 HPA, MAX WINDS 90 KNOTS NEAR CENTER.
FORECAST POSITION FOR 060900UTC AT 20.8N 128.1E WITH 75 MILES RADIUS
OF 70 PERCENT PROBABILITY CIRCLE.
935 HPA, MAX WINDS 90 KNOTS NEAR CENTER.
JAPAN METEOROLOGICAL AGENCY.=
Although this isn’t directly SDR related, this story may still be of interest to some readers. The Outernet project have just put on sale their first receiver which is called the Lighthouse. The standard Lighthouse consists of custom hardware, but there is also a DIY option in the store which consists of a HDStar DVB-S2 receiver board and a Raspberry Pi with custom software. You also need a satellite dish antenna and LNB which can be bought from their store, or found locally.
The Outernet project aims to be a “library in the sky” satellite based service that will provide free one-way access to daily downloads of data such as books, news, videos and other information. Its goal is to provide people who may not have easy physical or uncensored access to the internet an easy way to access daily information.
The currently available Outernet services cover almost the entire globe and use Ku-band (12 – 18 GHz) and C-band (4 – 8 GHz) geostationary satellite links, which is what the Lighthouse is capable of receiving when used with an appropriate dish antenna (the Ku-band service requires a 90cm dish, while the C-band service requires a much larger dish). The Lighthouse receives data from the satellites and then allows users to view the downloaded data by connecting to it via a WiFi enabled device such as a PC or smartphone. They currently broadcast 1 GB of data per day to most of the world, and 100 GB per day to sub-saharan African countries.
In the future Outernet is hoping to release their “Lantern” receiver, of which one prototype is based on a modified RTL-SDR design. The Lantern will receive their upcoming L-band (1-2 GHz) transmissions which will only require a small patch antenna and LNA’s to receive. A standard RTL-SDR with appropriate antenna and LNA’s should also be capable of receiving this service when it is released.
The RTL-SDR software defined radio is often used to receive signals from NOAA APT weather satellites. Once decoded these signals produce a freshly captured image of the earth over your current location. We have a simple tutorial on setting this up here.
However, recently Marco Johansson wrote into RTL-SDR.com to explain an alternative method to the one described in our tutorial. His method uses rtl_fm as the receiver instead of the GUI based software SDR# and uses several other pieces of software to automate the whole process. Marco believes that his method may be useful for some people and his tutorial is presented below. Also, if you are interested Marco has a WxtoImg generated webpage which shows all his recently received images here wxsat.haastaja.net.
A composited weather satellite image made up of several images received from NOAA satellites by Marco Johansson
Note that the following tutorial is written by Marco Johansson.
Marco’s NOAA APT Decoding Tutorial
As a Windows user I had some serious problems using an RTL-Dongle as a receiver for WxtoImg. Signal drops, CPU load, and no receiver control. I had to use 5 different pieces of software to get automatic reception to work and every day one of the programs had some weird problems causing the whole system to stop working. I read several forum posts about similar problems. A huge bit of help came from WxtoImg’s own forum where a user told how he was able to use rtl_fm as a receiver. His system was Linux based, so I was not able to use his scripts, but it gave me enough information to find a Windows based solution.
I stumbled on to a software program that solves my problem totally. It is originally made to control Windows MCE (Media Center), but since it’s release it has been enhanced to work as a universal remote control for the Windows system.
In WxtoImg I selected “Baykal” receiver, port COM1 and 2400baud. The protocol for remote control is very easy to understand and after every command WxtoImg sends CR/LF to receiver, which is mandatory to get commands to work.
Control commands are handled with MCE controller. It listens to COM2 (bridged with COM1) and when it hears a valid command string (A Magic ‘word’) it activates a task. Tasks are .bat files, one for every satellite and a “kill” to stop receiver after the satellite pass.
When satellite is coming (one minute before it is over head) WxtoImg sends a command “MUA” that triggers “kill.bat”. Then WxtoImg sends a command “RF0xxxxxxx” where xxxxxxx is the frequency of the satellite, “1371000” for NOAA19 – this triggers “rec-noaa19.bat”. When the pass is over, Wxtoimg sends again “MUA” to kill the receiver program.
Now I can control recordings directly from WxtoImg without any other software (Orbitron, SDR#, DDE client etc).
.bat files and other configurations are provided below for others to use. I ended up to have separate .bat to start the tasks as in that way I can set the system start and stop recording in the background without a command prompt popping around my desktop every 90 mins 🙂
My system is Windows 8.1, I have not tested this in 7, 8 or 10 but I believe it should work without any modification. The HW ID of the RTL-Dongle I use for wx_rtl_fm.exe is “3” (‘-d 3’ in script). If you have only one RTL-Dongle, then this should be set to “0”. I use the bandwidth of 55 kHz that seems to be enough for good APT reception including doppler error as in this method the doppler error is not corrected in the receiver at all (no AFC).
NOTE! I have copied the original ‘rtl_fm.exe’ to ‘wx_rtl_fm.exe’ to be able to start other rtl_fm.exe instances without the risk that WxtoImg kills my other receiver accidentaly. And of course, remember that these are from my system and the correct path used in scripts will be different for you 🙂 Also, the original ‘sox.exe’ is copied to ‘play.exe’ as instructed in the SoX’s manual for Windows user. And because I’m lazy, I copied rtl_fm and SoX binaries to same directory so that I do not have to put so long path strings into my .bat scripts 🙂
Final words:
.bat’s used in this are very dirty hacks and there are lot’s of improvement available for sure – but it works! Also, the remote protocol for Baykal receiver actually sends two more commands, one is used for telling the modulation of the transmission (RM NFM) and second to do something I do not know (MUF).
The whole communication in my system goes like this:
1) “MUA” => Kill all wx_rtl_fm.exe processes currently running (if any). This happens one minute before satellite pass starts.
2) “RF0xxxxxxx” => Start wx_rtl_fm & SoX, xxxxxxx=frequency of the satellite and is used to select correct .bat for different satellites (see MCE Control XML-file for details). This happes when satellite pass starts.
3) “RM NFM” => Not used in my system. Could trigger something fun if needed :). This happens right after ‘RF0xxxxxxx’ command.
4) “MUF” => Not used in my system. Could trigger something fun if needed :). This happens right after ‘RM NFM’ command.
5) “MUA” => Kill all wx_rtl_fm.exe processes currently running. This happes right after satellite pass.
SoX is a very powerfull tool for audio manipulation. There are options that could greatly improve the audio quality of the received signal – denoice, better dynamics etc. I am not that keen to try everything SoX could do as the results are already very good in my system, but if there are someone who knows better ways to handle SoX then please do not hesitate to comment!
Used .bat Files
“Kill the receiver”:
kill.bat is triggered by MCE control and calls kill-wx_rtl_fm.bat to do the actual killing.
kill.bat
cd C:\Users\Mac Radio\ownCloud\SDR\rtl_fm_sox
start /min kill-wx_rtl_fm.bat ^& exit
This triggers;
kill-wx_rtl_fm.bat
taskkill /IM wx_rtl_fm.exe /F
“Start recording”:
Recording is started after MCE Control gets the correct ‘word’ from WxtoImg. For every satellite there are separate ‘words’ and separate .bat files.
rec-noaa15.bat
cd C:\Users\Mac Radio\ownCloud\SDR\rtl_fm_sox
start /min noaa15.bat ^& exit
This triggers;
noaa15.bat
cd C:\Users\Mac Radio\ownCloud\SDR\rtl_fm_sox
play -r 55k -t raw -e s -b 16 -c 1 "|wx_rtl_fm -d 3 -M fm -f 137.62M -s 55k -l 0" -t waveaudio
rec-noaa18.bat
cd C:\Users\Mac Radio\ownCloud\SDR\rtl_fm_sox
start /min noaa18.bat ^& exit
This triggers;
noaa18.bat
cd C:\Users\Mac Radio\ownCloud\SDR\rtl_fm_sox
play -r 55k -t raw -e s -b 16 -c 1 "|wx_rtl_fm -d 3 -M fm -f 137.9125M -s 55k -l 0" -t waveaudio
rec-noaa19.bat
cd C:\Users\Mac Radio\ownCloud\SDR\rtl_fm_sox
start /min noaa19.bat ^& exit
This triggers;
noaa19.bat
cd C:\Users\Mac Radio\ownCloud\SDR\rtl_fm_sox
play -r 55k -t raw -e s -b 16 -c 1 "|wx_rtl_fm -d 3 -M fm -f 137.1M -s 55k -l 0" -t waveaudio
And finally, the MCE Control magic ‘words’. By default, MCE Control understands over 200 separate commands originally meant to remote control Windows MCE (Media Center). Fortunately, one can create their own commands and get MCE Control to do much more – control Wx-system!
MCE Control uses an XML configuration file for these extra commands. The file is located in the same directory where the main executable is located. My system uses following XML file to be able to control ‘wx_rtl_fm.exe’:
<?xml version="1.0" encoding="utf-8"?>
<MCEController xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<Commands xmlns="http://www.kindel.com/products/mcecontroller">
<!-- Place command definitions here -->
<!--
==================================================================
StartProcess Commands
File: The full path to the executable you want to start.
==================================================================
-->
<StartProcess Cmd="RF01376200" File="C:\Users\Mac Radio\ownCloud\SDR\rtl_fm_sox\rec-noaa15.bat"/>
<StartProcess Cmd="RF01379125" File="C:\Users\Mac Radio\ownCloud\SDR\rtl_fm_sox\rec-noaa18.bat"/>
<StartProcess Cmd="RF01371000" File="C:\Users\Mac Radio\ownCloud\SDR\rtl_fm_sox\rec-noaa19.bat"/>
<StartProcess Cmd="MUA" File="C:\Users\Mac Radio\ownCloud\SDR\rtl_fm_sox\kill.bat"/>
</Commands>
</MCEController>
