Back in August we posted how Albert Lederer had created a RTL-SDR interface for the LabVIEW visual programming language which could be run on a host PC. LabVIEW is a visual programming language which is used commonly by engineers and scientists to quickly build applications for things like product testing, system monitoring, instrument control etc.
In his latest post/tutorial uploaded a few days ago he shows how to run the RTL-SDR RF acquisition on a myRIO, which is a development processing board that can run Linux and has an on board FPGA. LabVIEW can then be used to control the RTL-SDR from the host PC.
The whole point of running the RTL-SDR on the myRIO is to eventually make use of the on board FPGA. In future posts he hopes to show us how to use the on board FPGA to offload digital signal processing (DSP) tasks, which would significantly speed up applications.
Data flow for offloading RTL-SDR DSP tasks onto the FPGA
Over on hackaday.io there is a project blog for the “Distributed Ground Station Network”. This is essentially an idea to build a large network of distributed RF receivers which automatically receive signals from sources like cube satellites and other beacons. The project mainly uses RTL-SDR dongles at the moment for their RF receivers. In some ways it appears to be similar to the SatNOGs project which won the hackaday prize two years ago but the DGSN appears to be more focused on “reverse GPS” which allows the detection and tracking of the location of small satellite signals through distributed receivers.
They write:
The Distributed Ground Station Network (DGSN) is a novel network concept of small ground-stations and connected via the internet for performing automatic scans for cubesats and other beacon signals. By correlating the received signal with the precise, GNSS synchronized reception times of at least 5 ground stations, it enables the positioning of the signal’s origin. Thus a global tracking of small satellites becomes possible in this “reverse GPS” mode. It allows mission operators to position and track their small satellites faster after piggy-back commissioning, when the final orbit is yet undefined and could differ from the specified orbit. Furthermore it allows permanent communication in “data-dump” mode. In this mode, DGSN ground-stations relay the received data to the servers and thus to the operator. Let’s track everything, together!
The thing I like most is that I can replay past transmissions by clicking in the waterfall history. Using other SDR software, when a new transmission pops up, I feel like I’m in a race to tune to it before it ends so that I can at least hear some of it, but in my software, I don’t even have to pay attention to what’s happening now, and so I seldom do. Usually I don’t notice transmissions on new frequencies until they’ve ended, but I still get to listen to them.
I also put some effort into trying to make sure AM and FM transmissions were equal in volume, as well as at the correct volume according to how well they were modulated, in that I aimed for 100% modulation leading to audio output that’s 6 dB below the ceiling. It seemed as if it was quite random in other software, as switching from AM to FM might cause a huge jump or drop in audio volume. I don’t like to play with my volume controls, so I did my best to make it so that I don’t have to. I’m also not at all fond of the “click the numbers” method of changing the center frequency which seems to be so common. So in mine, I just type in the MHz on the number keypad and press enter.
I’m also much more fond of my waterfall coloring scheme than any other I’ve seen. It seems much smoother and more informative, at least to me anyway. I suppose that’s rather subjective.
…but it’s rather hard to compare it to other software given that I only got to use other software for two or three days. I rather soon knew I wanted to write my own, and I wanted to use the V4L2 API (that dvb_usb_rtl28xxu module you have to blacklist to use rtl-sdr is an SDR driver, not a video driver), but I had to upgrade to Linux Mint 18 to get access to it since it’s a new API, and after doing so, I haven’t been able to get any of the existing SDR software to both compile and work after it’s compiled. So I just focused on writing my own, since I was wanting to do so anyway. (No support for that V4L2 API though, as it turns out its buggy and offers no way to control the dongle’s gain, so it’s basically unusable.)
Recently a new Linux based tool called RFTap has been released. RFTap acts as a bridge between GNURadio flow graphs and Wireshark. GNU Radio is a visual based programming environment for digital signal processing applications, such as RF signal decoders. GNURadio supports many different SDR’s including the RTL-SDR. Wireshark is a network packet analyzer/dissector that aides with troubleshooting and analysis of network protocols. RFTap also supports other DSP languages like Pothos, liquidsdr, LuaRadio as well as other packet analyzers like TShark, tcpdump, Scapy.
NOTE: This tutorial is no longer valid as Outernet discontinued their L-Band service in late 2017. Please consult www.outernet.is for news on their latest delivery methods.
Outernet is a relatively new satellite service which aims to be a "library in the sky". Essentially their service is going to be constantly transmitting files and data like news and weather updates from geostationary satellites that cover almost the entire world. Geostationary means that the satellites are in a fixed position in the sky, and do not move over time. By simply pointing a small patch antenna at the sky (with LNA and RTL-SDR receiver), it is possible to download and decode this data from almost anywhere in the world. Their aim is to provide up to date information to users in locations with little to no internet (rural, third world and sea), or in countries with censored internet. It may also be of interest to disaster preppers who want an "off-grid" source of news and weather updates. It can kind of be thought as a kind of one-way download-only internet service.
Currently the L-band service is being tested, and while they are not yet sending actual Outernet files, they are already sending several daily test files like small videos, images and text documents as well as GRIB files for mariners. At a maximum you can expect to receive up to about 20 MB of data a day from their satellite. Previously they had C-band services but these required large satellite dishes. The C-band service is due to be discontinued at some point in the future.
In this guide we'll show you how to set up an Outernet L-band receiver with an RTL-SDR dongle. If you enjoy this guide then you might also enjoy our Inmarsat STD-C EGC Decoding Tutorial which has similar hardware requirements.
Back in August we posted how Albert Lederer had created a RTL-SDR interface for the LabVIEW visual programming language which could be run on a host PC. LabVIEW is a visual programming language which is used commonly by engineers and scientists to quickly build applications for things like product testing, system monitoring, instrument control etc.
In his latest post/tutorial uploaded a few days ago he shows how to run the RTL-SDR RF acquisition on a myRIO, which is a development processing board that can run Linux and has an on board FPGA. LabVIEW can then be used to control the RTL-SDR from the host PC.
The whole point of running the RTL-SDR on the myRIO is to eventually make use of the on board FPGA. In future posts he hopes to show us how to use the on board FPGA to offload digital signal processing (DSP) tasks, which would significantly speed up applications.
Data flow for offloading RTL-SDR DSP tasks onto the FPGA
Over on hackaday.io there is a project blog for the “Distributed Ground Station Network”. This is essentially an idea to build a large network of distributed RF receivers which automatically receive signals from sources like cube satellites and other beacons. The project mainly uses RTL-SDR dongles at the moment for their RF receivers. In some ways it appears to be similar to the SatNOGs project which won the hackaday prize two years ago but the DGSN appears to be more focused on “reverse GPS” which allows the detection and tracking of the location of small satellite signals through distributed receivers.
They write:
The Distributed Ground Station Network (DGSN) is a novel network concept of small ground-stations and connected via the internet for performing automatic scans for cubesats and other beacon signals. By correlating the received signal with the precise, GNSS synchronized reception times of at least 5 ground stations, it enables the positioning of the signal’s origin. Thus a global tracking of small satellites becomes possible in this “reverse GPS” mode. It allows mission operators to position and track their small satellites faster after piggy-back commissioning, when the final orbit is yet undefined and could differ from the specified orbit. Furthermore it allows permanent communication in “data-dump” mode. In this mode, DGSN ground-stations relay the received data to the servers and thus to the operator. Let’s track everything, together!
The thing I like most is that I can replay past transmissions by clicking in the waterfall history. Using other SDR software, when a new transmission pops up, I feel like I’m in a race to tune to it before it ends so that I can at least hear some of it, but in my software, I don’t even have to pay attention to what’s happening now, and so I seldom do. Usually I don’t notice transmissions on new frequencies until they’ve ended, but I still get to listen to them.
I also put some effort into trying to make sure AM and FM transmissions were equal in volume, as well as at the correct volume according to how well they were modulated, in that I aimed for 100% modulation leading to audio output that’s 6 dB below the ceiling. It seemed as if it was quite random in other software, as switching from AM to FM might cause a huge jump or drop in audio volume. I don’t like to play with my volume controls, so I did my best to make it so that I don’t have to. I’m also not at all fond of the “click the numbers” method of changing the center frequency which seems to be so common. So in mine, I just type in the MHz on the number keypad and press enter.
I’m also much more fond of my waterfall coloring scheme than any other I’ve seen. It seems much smoother and more informative, at least to me anyway. I suppose that’s rather subjective.
…but it’s rather hard to compare it to other software given that I only got to use other software for two or three days. I rather soon knew I wanted to write my own, and I wanted to use the V4L2 API (that dvb_usb_rtl28xxu module you have to blacklist to use rtl-sdr is an SDR driver, not a video driver), but I had to upgrade to Linux Mint 18 to get access to it since it’s a new API, and after doing so, I haven’t been able to get any of the existing SDR software to both compile and work after it’s compiled. So I just focused on writing my own, since I was wanting to do so anyway. (No support for that V4L2 API though, as it turns out its buggy and offers no way to control the dongle’s gain, so it’s basically unusable.)
Recently a new Linux based tool called RFTap has been released. RFTap acts as a bridge between GNURadio flow graphs and Wireshark. GNU Radio is a visual based programming environment for digital signal processing applications, such as RF signal decoders. GNURadio supports many different SDR’s including the RTL-SDR. Wireshark is a network packet analyzer/dissector that aides with troubleshooting and analysis of network protocols. RFTap also supports other DSP languages like Pothos, liquidsdr, LuaRadio as well as other packet analyzers like TShark, tcpdump, Scapy.
NOTE: This tutorial is no longer valid as Outernet discontinued their L-Band service in late 2017. Please consult www.outernet.is for news on their latest delivery methods.
Outernet is a relatively new satellite service which aims to be a "library in the sky". Essentially their service is going to be constantly transmitting files and data like news and weather updates from geostationary satellites that cover almost the entire world. Geostationary means that the satellites are in a fixed position in the sky, and do not move over time. By simply pointing a small patch antenna at the sky (with LNA and RTL-SDR receiver), it is possible to download and decode this data from almost anywhere in the world. Their aim is to provide up to date information to users in locations with little to no internet (rural, third world and sea), or in countries with censored internet. It may also be of interest to disaster preppers who want an "off-grid" source of news and weather updates. It can kind of be thought as a kind of one-way download-only internet service.
Currently the L-band service is being tested, and while they are not yet sending actual Outernet files, they are already sending several daily test files like small videos, images and text documents as well as GRIB files for mariners. At a maximum you can expect to receive up to about 20 MB of data a day from their satellite. Previously they had C-band services but these required large satellite dishes. The C-band service is due to be discontinued at some point in the future.
In this guide we'll show you how to set up an Outernet L-band receiver with an RTL-SDR dongle. If you enjoy this guide then you might also enjoy our Inmarsat STD-C EGC Decoding Tutorial which has similar hardware requirements.
At this year’s hacker themed Eleventh Hope conference, Stefan “Sec” Zehl and Schneider gave a talk which discusses their latest work on decoding data from Iridium satellites using SDR’s. Iridium is a truly global satellite service which provides various services such as global paging, satellite phones, tracking and fleet management services, as well as services for emergency, aircraft, maritime and covert operations too. There are currently 72 operational satellites operating.
In their talk they discuss how Iridium security is moderate to relaxed, pointing out that Iridium claims that the majority of ‘security’ comes from the complexity of the system, rather than actual security implementations. They then go on to discuss how the Iridium system works, how to receive it with an RTL-SDR or HackRF/Rad1o, how the gr-iridium decoder implementation works, and how to use it to actually decode the data. Later in the presentation they show some interesting examples such as an intercepted Iridium satellite phone call to a C-37 aircraft.
A few days ago we posted a review on the Outernet LNA which can can be used to help receive their new L-band service signal. Their LNA uses a filter which restricts the frequency range from 1525 – 1559 MHz as this is the range in which the Outernet signals are located.
Additional Note Regarding the Downconverter: Also, it appears that the Outernet downconverter prototype that we posted about back in May has unfortunately been discontinued indefinitely and will not enter mass production. For now the LNA is the best option for receiving their signal.
The Geostationary Operational Environmental Satellite (GOES) is a weather satellite placed in geosynchronous orbit (same position in the sky all the time) which is used for weather forecasting, severe storm tracking and meteorology research. It transmits full disk images of the earth on its Low Rate Information Transmission (LRIT) signal, and weather data images and text on its Emergency Managers Weather Information Network (EMWIN) signal. EMWIN is a service for emergency managers that provides weather forecasts, warnings, graphics and other information in real time.
In his post devnulling writes about receiving GOES:
GOES LRIT runs at 1691.0 MHz , EMWIN is at 1692.7 MHz and is broadcasted from GOES-13 and GOES-15. GOES-14 is currently in a backup position to take over in either fails.
For the hardware side, it is recommended to use roughly a 1.2m or larger dish, depending upon how far north you are, you may need a 1.8m dish (larger the better). Repurposed FTA or C-band dishes are easy to come by and work well.
I made a 5 turn helical feed with some 12ga copper wire and a piece of copper plate, and used this calculator to design it – https://jcoppens.com/ant/helix/calc.en.php
I have a short run of coax into the LNA/Filter box. The first LNA is a TriQuint TQP3M9037 which has a very low noise figure (0.3 dB NF and 22 dB gain at 1.7 GHz).
That is ran into a Lorch 1675 MHz filter (150 MHz pass band), then a LNA4ALL and another Lorch before going over a 30ft run of RG-6 to the SDR.
I am using @usa_satcom (twitter.com/usa_satcom, usa-satcom.com)’s LRIT Decoder and that feeds into XRIT2PIC to produce the images and other data streams. By default the decoder only works with the Airspy, but with a custom GNU Radio UDP block, it can be fed with other SDRs like the BladeRF/USRP/SDR Play. A regular R820T(2) RTL probably won’t work because of the higher frequency (rtls tend to not work above 1.5 GHz) and 8 bit ADC. I’m going to try and use the Outernet e4k to see if I can pickup the EMWIN signal in the near future.
EMWIN is broadcasted on 1692.7 MHz, along with being encoded in the LRIT stream at 1691 MHz. The 1692.7 MHz signal is stronger and narrower, so it is easier to pickup. For decoding EMWIN I used @usa_satcom’s EMWIN decoder that piped data into WxEmwin/MessageClient/Weather Message Server from http://weathermessage.com.
LRIT will contain the full disk images from GOES-15, and relayed images from GOES-13 and Himawari-8. It will also included zoomed in pictures of the USA, and northern/southern hemispheres. The images will be visible light, water vapor and infrared. The full disk images are transmitted every 3 hours, with the other images more often. EMWIN will contain other weather data, text, charts, and reports.
It seems as though it may be possible to receive LRIT and EMWIN signals with an RTL-SDR since the signals are at 1690 MHz, which should be covered by cooled R820T2 and E4000 dongles. The only hardware requirements would be a 1m+ dish, 1690 MHz L-band feed, and an LNA + filter.
In 2017 these satellites are due to be replaced by new ones that will use a HRIT signal, which will be about 1 MHz. New software to decode this signal will be required then, but we assume the same hardware could still be used as the frequency is not due to change significantly.
Please note that the decoding software is only available by directly contacting usa-satcom, and devnulling writes that you must have the proper equipment and be able to show that you can receive the signal first before attempting to contact him.
GOES Full Disk ImageOne of several received EMWIN images
