Over on Facebook Job Geheniau has posted results from his latest radio astronomy experiment which involves imaging the Cygnus-X star forming region at 1424 MHz with a 1.9m radio telescope, an RTL-SDR and some additional filtering and LNAs. In the past we've posted about Geheniau's previous work which involved imaging the entire Milky Way at 1420 MHz, and measuring the basis for the dark matter hypothesis with a similar process and the same equipment. His latest post reads:
Cygnus-X is a massive star-forming region in the constellation Cygnus at a distance of 1.4 kiloparsecs (4600 light-years) from the Sun.
Cygnus-X has a size of 200 parsecs and contains the largest number of massive protostars and the largest stellar association within 2 kiloparsecs of the Sun. Cyg X is also associated with one of the largest molecular clouds known, with a mass of 3 million solar masses. [Wikipedia]
The idea: To take a radio picture of the Cygnus complex (Cygnus A + Cygnus X) with my 1.9 meter radio telescope. Equipment: 1.5 - 1.9 meter radio telescope Mini Circuits LNA ZX60-ULN33+ Bandpass filter 1200-1700 MHz 2nd LNA RTL-SDR VirgoSoft
Implementation: Multiple 4-hour drift scans of the Cygnus complex and beyond. In order not to be affected by HI at 1420 MHz, measurements were made at 1424 MHz. At this frequency there is Synchrotron radiation and no neutral hydrogen emission. To be sure that no Milky Way synchrotron radiation is measured there would be no or hardly any measurable power change outside the Cygnus complex during the drift scan. This was also observed in these measurements and also confirmed earlier in test measurements.
A total of 7 drift scans of 4 hours were made at 1424 MHz. Because the start of the driftscan generates a lot of wrong data (the 'cooling down/warming up' of the RTL-SDR), this has been removed in the measurements. The measurement starts at 2000 seconds and is always aborted at 12000 seconds in post-processing.
7 shots from RA 19 to RA 22. The declination varied each observation from DEC 36 to 43 degrees.
Because not every driftscan was perfect (heavy clouds gave worse results anyway as well as wind/rain or rfi) a total of 15 measurements were done, of which 7 were thus acceptable enough for editing.
In the end JRT performed measurements from 24 September to 9 October. Patience is a good thing.
Results: By editing the driftscan data in Excel with Conditional Format (giving color to the data) the final result is a 'radio photo' of the complex.
Of course, in view of the dish diameter, the beam is 8 degrees and thus a somewhat rough image of the Cygnus complex is sketched here.
The idea behind the attack is that ethernet cables can act as an antenna, leaking signals at frequencies which can easily be sniffed by a SDR. The specific technique in the paper does not decode normal network traffic, instead it requires that malicious code which modulates a custom signal over the ethernet cable be installed on the PC first. The technique used appears to be similar to what the Etherify software by SQ5BPF uses, which modulates data in morse code by turning the network card on and off.
Thank you to Tomasz Lemiech for writing in and sharing with us the release of his new software "dumphfdl". Tomasz is the author of dumpvdl2 and also maintains RTLSDR-Airband. Regarding dumphfdl Tomasz writes:
dumphfdl is a multichannel HFDL decoder for Linux. HFDL (High Frequency Data Link) is a protocol used for radio communications between aircraft and a network of ground stations using high frequency (HF) radio waves. Thanks to the ability of short waves to propagate over long distances, HFDL is particularly useful in remote areas (eg. over oceans or polar regions) where other ground-based communications services are out of range. While many aircraft carriers prefer satellite communications these days, HFDL is still operational and in use.
Available HFDL decoding applications typically run on Windows and take an audio signal on input. The signal has to be delivered to the decoder via a physical cable from an external shortwave receiver or via a virtual cable from an SDR. This makes these apps inherently single-channel. This shortcoming does not apply to dumphfdl which interfaces directly with the SDR, so no pipes or virtual audio cables are needed. The program can decode multiple HFDL channels simultaneously, up to available CPU power and SDR bandwidth (there is no fixed channel count limit).
dumphfdl uses SoapySDR library (https://github.com/pothosware/SoapySDR) to communicate with the radio. Any HF-capable receiver for which a SoapySDR driver exists, should work. I have tested it briefly with an RTL-SDR v3 dongle in direct sampling mode. While I had a bit of a success with it, HFDL signals are often quite weak, so a real HF radio (like SDRPlay RSP1A or Airspy HF+) gives much better results (more decoded messages).
The program may log decoded messages to a file or send them over the network for external processing and storage.
HFDL messages often contain diagnostic data accompanied with aircraft position information. The program may extract this data from decoded messages and provide a positional data feed for external plane tracking apps (eg. Virtual Radar Server). An example screenshot from VRS is attached - taken after about 2 hours of decoding eight HFDL channels spread across three HFDL subbands: 6.6, 8.9, and 10.0 MHz with two dumphfdl instances on two radios - RSP1A and Airspy HF+. Definitely a nice way to expand the coverage of a home ADS-B radar :-)
Refer to the README.md file in the project repository for more details. The program is still under development, so new features and further improvements might be expected in subsequent releases.
DragonOS is a ready to use Ubuntu Linux image that comes preinstalled with multiple SDR software packages. The creator Aaron also runs a YouTube channel showing how to use the various packages installed. In his latest video Aaron shows how to use the SDR4space.lite application to automatically log the spectrum with an RTL-SDR, as well as with an ANTSDR (PlutoSDR clone).
This video shows how to setup DragonOS Focal to detect spectrum activity with the SDR4space.lite application, RTLSDR, and ANTSDR/PlutoSDR. I then show how to setup both InfluxDB and Grafana, which are both used to accept and log incoming detected frequencies from the SDR4space.lite application and RTLSDR.
InfluxDB is an open-source time series database and Grafana is the open source analytics & monitoring solution. The two solutions combined allow a user to log activity from as many receivers as they'd like and then near time display incoming results in custom dashboards and panels.
This first video goes over the initial setup, to include creating a cron job for repeated frequency detection surveys, how to link the database and visual front end, and then how to create and customize your first dashboard and panel. Information to populate the database comes from two separate receivers in this demonstration, both from a remote RTLSDR connected to a laptop and from an ANTSDR locally connected to the Intel NUC.
Everything needed to get started is either already included in DragonOS Focal or is easily installed as shown in the video. A key part is the included SDR4space.lite application, however, a newer version with updated features is expected soon.
FutureSDR is an experimental open source SDR framework (similar to GNU Radio) that is being developed by Bastian Bloessl. The idea behind the framework is that it is implemented in Rust, which is a programming language that supports async (asynchronous) code. The end result to the user should be faster, more portable and lower latency digital signal processing (DSP) code. The framework is still in the early stages with there being very few DSP blocks available, but as per his blog new blocks are slowly being implemented by contributors.
Bastian has created a presentation introducing the framework. It will only be interesting to programmers, and DSP coders, but it shows the possible software engineering improvements that we could see applied to SDR DSP code in the future.
Features An experimental asynchronous SDR runtime for heterogeneous architectures that is:
Extensible: custom buffers (supporting accelerators like GPUs and FPGAs) and custom schedulers (optimized for your application).
Asynchronous: solving long-standing issues around IO, blocking, and timers.
Portable: Linux, Windows, Mac, WASM, Android, and prime support for embedded platforms through a REST API and web-based GUIs.
Fast: SDR go brrr!
Overview FutureSDR supports Blocks with synchronous or asynchronous implementations for stream-based or message-based data processing. Blocks can be combined to a Flowgraph and launched on a Runtime that is driven by a Scheduler. It includes:
Single and multi-threaded schedulers, including examples for application-specific implementations.
Portable GPU acceleration using the Vulkan API (supports Linux, Windows, Android, …).
User space DMA driver for Xilinx Zynq to interface FPGAs.
Over on YouTube Dr. Diep N. Nguyen has posted a video showing work done to create a Real Time spectrum database by his team at University of Technology Sydney. The project involves the use of multiple RTL-SDR dongles and Android mobile devices to monitor the spectrum and make it accessible to requestors in real time. They write:
In view of the escalating demand for higher mobile data (from IoT, industry 4.0 applications), there is a growing world-wide interest to improve the radio spectrum utilization. Effective management of the wireless spectrum requires knowledge of the available bandwidth at any given time and location, which necessitates expensive recording equipment and labour cost at various locations. A number of countries, including the USA, are opening up TV and radar bands for sharing with other applications. Google has taken the lead by opening its spectrum database for TV whitespaces. Our solution goes beyond the state-of-the-art Google spectrum database by providing the world’s first real-time radio spectrum database.
Radio Spectrum Database at UTS The UTS’s Global Big Data Technologies Centre team has developed advanced sensing capability to deliver a low-cost, yet more robust radio spectrum database. By leveraging big data science, edge computing power, crowdsourcing, and low-cost SDR (software defined radio) adaptors, a real-time snapshot of the wireless spectrum can be recorded on any Android device. The spectrum data is aggregated and visualize onto a web dashboard, allowing industry stakeholders and regulators to better facilitate dynamic radio spectrum monitoring and sharing.
• World’s first real-time spectrum database • Fast deployment and can cover a wide range of frequency • Provide spectrum on-demand to IoT, industry 4.0 applications • Rich datasets from millions of mobile users across various locations • 24/7 cost-effective and real-time radio spectrum monitoring system • Economical: $20 RTL-SDR adaptors and labor-free versus costly sensing equipment • Scalable: Cloud deployment allows infrastructure to be scaled as user base grows (millions of users) • Easy to use and install via Android Play Store • User-friendly interface with Google Map embedded system
The Raspad 3.0 is a portable tablet enclosure for the Raspberry Pi 4B. It comes with a high resolution 1280 x 800 10.1 inch touch LCD screen, built in speakers, built in battery and a plastic enclosure that houses the LCD driver board and Raspberry Pi. Accessible on the side of the enclosure are the USB, HDMI, ethernet and audio ports which connect via the LCD driver board. They also include an accelerometer shim which allows the screen to autorotate.
A few months ago SunFounder, the company behind the RasPad 3.0 reached out to us and asked if we wanted to review the product with a free sample. Normally we don't review products unrelated to SDR like this, but given the amount of RTL-SDR software available for the Raspberry Pi, and what appeared to be sufficient internal space, we were curious if there was a way to turn this into a portable RTL-SDR tablet...
A few weeks ago the Raspad 3.0 arrived, well packed and with all the advertised components. Note that the Raspad 3.0 does not come with a Raspberry Pi 4B, this is something you will need to provide on your own.
Inside was a mains power cable, 15V DC power brick, two HDMI jumpers, a USB jumper, accelerometer shim, SD card ribbon, small 5V fan, heatsinks for the Pi, screwdriver and mounting screws, a manual and the RasPad LCD screen itself.
Assembly is straight forward. You unscrew the enclosure using the provided screw driver, insert the Pi 4B, screw it down, connect all the cables from the Pi to the LCD driver board and SD card slot, then reassemble. After inserting the Raspberry Pi 4B and attaching all the cables this is what the inside looks like.
Now we could have reassembled the enclosure here, but we wanted this to be a portable RTL-SDR tablet, with the RTL-SDR and an SMA antenna port built in.
It turns out that the best way to fit in an RTL-SDR Blog V3 is to directly connect it to the spare USB port on the Pi. You might also consider using a micro style RTL-SDR which would fit more easily, but those do tend to get quite hot in a small package, and can be quite bad with internal noise. Also good shielding is probably quite critical in this application due to the dongles proximity with the LCD driver board which could be an RFI source.
The SMA side of the RTL-SDR Blog V3 rests nicely on top of the USB port of the LCD driver board providing some stability, and when the bottom lid is assembled there is plenty of clearance and no squashing.
Next we drilled a hole on the rear wall of the bottom half of the enclosure for the SMA female port, and tightened the SMA connector down with a nut. In the future we'll be upgrading this to a long barrel style SMA female connector, as a regular SMA female connector is a bit short. Then a short well shielded SS405 coax cable was used to connect to the RTL-SDR dongle.
ProTip: Do take care to remember to remove the SD card when disassembling the RasPad! If you don't you'll end up with the SDcard slot getting ripped from it's ground traces. This happened to us, but we were able to easily solder it back on. There is a sticker on the backside of the enclosure warning about this.
Software & Testing
SunFounder provide a custom Raspbian distribution designed specially for the RasPad. However, we decided to instead install the DragonOS Pi64 Distro which is an Ubuntu distribution for the Raspberry Pi 4B that has many built in SDR programs. We burnt the image to a SD card, inserted it on the side, plugged the Raspad in to the power connector, and held the power button down for a few seconds to turn it on. Despite a few initial error messages saying it cannot enable the USB ports, everything eventually booted just fine.
We then plugged in a cable going to one of our multipurpose dipole antennas mounted just outside the office window, and tested both SDR++ and GQRX. In both cases we were immediately able to connect to the RTL-SDR and receive signals with signal strength equivalent to that received by our desktop PC, indicating that LCD interference was not a problem.
The resolution of the screen is high enough and images and text are clear. The screen is also decently bright, and brightness can be adjusted using the buttons on the side.
DragonOS Tablet Compatibility Issues & Fixes
As DragonOS is not designed for a tablet setup, there were a few bugs. It should be noted however that these issues are not a reflection on the Raspad hardware, as obviously the official Raspad OS will not have these issues as it's designed specifically for tablet use.
We initially had no sound in SDR++ from the built in speakers. After some troubleshooting we managed to get sound by disabling the headphone jack in the audio mixer settings, which appears to be the default output in DragonOS. To do this, click on the speaker icon on the bottom right task bar and click on Mixer. Then go to the Configuration tab and uncheck the second Built-in Audio entry. Close it, and open SDR++.
In DragonOS the touch screen works fine, although it is difficult to click on small buttons. There is no onscreen keyboard available by default. We couldn't find a way to enable a tablet mode in DragonOS, so instead opted to install an onscreen keyboard called 'onboard' via 'sudo apt install onboard'. The accelerometer is also not enabled in DragonOS. We did not attempt to fix this as we have no need for screen rotation.
LCD screens are well known to be sources of RF interference, and putting an SDR in close proximity to one could result in the spectrum being very noisy. However, without an antenna connected we did not notice any interference across the spectrum from the LCD screen. It appears that the LCD RFI noise levels are not too bad, and the shielding on the RTL-SDR Blog V3 and the coax jumper cable is good enough to prevent any being received. When an antenna with a few meters of coax was connected (such as a magwhip or our portable dipole) we also didn't notice any LCD interference.
However, when a SMA telescopic antenna was connected directly to the SMA port we did start noticing the telltale spikes across the spectrum that are typically generated from LCD screens. If the magwhip or dipole was also moved within 2-3cm of the LCD screen, we also saw these interference spikes appear.
So it would be recommended to use a magwhip or dipole that has a coax run that can sit a few centimeters away from the screen. This limits the handheld ability of the RasPad a little, but you'd probably want a magwhip, dipole or other antenna over a directly connected telescopic whip for better reception anyway.
We tested a worst case scenario, with the RasPad running the RTL-SDR and SDR++ continuously at the brightest screen setting. With this test the battery lasted 2 hours and 10 minutes from a full charge. Presumably if the screen was dimmed and turned off for some periods of time, it would easily last 3-4 hours.
The total weight of the Raspad including our mods is just under 1 kg (2.2 lbs). About double the weight of a modern tablet, but still light enough to be easily carried.
The small 5V fan provided in the kit is unfortunately a bit noisy, and it's cooling ability is seems limited. We've seen these small fans on other Raspberry Pi cooling accessories and found that they are next to useless at cooling. It would be good to see a slightly larger and quieter fan, or perhaps a better passive cooling heatsink.
The power brick output is 15V, 2A. Ideally we would be able to charge the RasPad via a car/boat 12V connection as well. We're awaiting a response to see if this is possible. Update: Unfortunately 12V seems to be a no-go, quoting SunFounder "the 12v supply may cause the Raspad to fail to charge, as the minimum is 15v".
The RasPad 3.0 in our opinion overall a good product. It allows you to easily go portable with your Raspberry Pi 4. While it was designed for other projects, there was just enough hackability left in it for us to fit a RTL-SDR Blog V3 and antenna port into the enclosure, yielding us a clean and portable SDR solution.
With at least 2 hours of battery life when running an RTL-SDR and software, we can easily see this being taken out in the field for spectrum analysis, decoding with rtl_433, or for portable listening to the airband, trunking etc. However, some customization of DragonOS or the RaspadOS is going to be needed to get the most out of the touchscreen.
There are also alternative LCD screen products designed for the Raspberry Pi where you sit the Raspberry Pi on the back of the screen. But it's unclear if there would be enough space inside to fit an RTL-SDR, and not to mention the lack of a battery. We also previously reviewed the Elecrow CrowPi which is somewhat similar, but a lot more clunky if you're just after a pick up and go portable SDR tablet solution. There are also higher end higher priced laptop style enclosure products for the Pi, like the Pi-Top but we're unsure if they're likely to fit the RTL-SDR internally this easily.
Disclaimer: We do not receive any compensation for this review apart from a free Raspad 3.0.
We also recently came across this review from German YouTuber Manuel Lausmann who installed and ran SDR++ on the Raspad with an SDRplay RSP SDR.
While these WiFi grids are relatively cheap, Marcus tests an order of magnitude cheaper solution based on a tall metal "Maple-Sap" bucket which are commonly found in Canada. A horn antenna is constructed out of the 24cm diameter bucket simply by attaching a feed (wire) connected to a type-N connector, fitted ~8.8cm from the bottom of the bucket. This results in a signal almost as strong as the 60cm WiFi grid. A second test with a larger 30cm bucket fitted onto an existing 24cm horn antenna yielded results on par with the WiFi grid. A third test was done with a 6-turn Helix antenna, however it resulted in poor performance.
Marcus notes that almost anything that is shaped like cone could be modified into a horn antenna with a little DIY construction. He mentions that one alternative to the maple-sap bucket which could be hard to find outside of Canada might be a "French Style" steel floral bucket.