Рубрика «Блоги»

cuSignal: Easy CUDA GPU Acceleration for SDR DSP and Other Applications

The RAPIDS cuSignal project is billed as an ecosystem that makes enabling CUDA GPU acceleration in Python easy. Scipy is a Python library that is filled with many useful digital signal processing (DSP) algorithms. The cuSignal documentation notes that in some cases you can directly port Scipy signal functions over to cuSignal allowing you to leverage GPU acceleration.

In computing, most operations are performed on the CPU (central processing unit). However, GPU's (graphical processing units) have been gaining popularity for general computing as they can perform many more operations in parallel compared to CPUs. This can be used to significantly accelerate DSP code that is commonly used with SDRs.

In particular the developers have already created a notebook containing some examples of how cuSignal can be used with RTL-SDRs to accelerate an FFT graph. There are various other DSP examples in the list of notebooks too. According to the benchmarks in the notebooks, the GPU computation times are indeed much faster. In the benchmarks they appear to be using a high end NVIDIA P100 GPU, but other NVIDIA graphics cards should also show a good speedup. 

The cuSignal code is based on CUDA, so for any GPU acceleration code to work you'll need to have an NVIDIA based GPU (like a graphics card) with a Maxwell or newer core.

We note that in the future we'll be investigating how this could be used to speed up the passive radar algorithms that are used in the KerberosSDR. It may also be useful for running DSP code quickly on a $99 NVIDIA Jetson Nano single board computer.

NVIDIA Tesla P100. A high end $3000+ GPU.
NVIDIA Tesla P100. A high end $3000+ GPU.

Creating An Automated Raspberry Pi and RTL-SDR Based NOAA Weather Satellite Station

The nootropicdesign blog has recently uploaded a comprehensive tutorial showing how to create an automated NOAA Weather Satellite ground station using an RTL-SDR V3 and an Raspberry Pi 3. The project also makes use of an Amazon S3 bucket, which is a cheap web storage platform that allows you to store and access the downloaded images.

The tutorial starts by showing you how to set up your Amazon AWS credentials and bucket on the Raspberry Pi, and how to host a simple webpage that can be accessed publicly. The second stage shows how to set up the RTL-SDR drivers and wxtoimg which is used to decode the images. Finally, the third stage shows how to create the automation scripts that automatically schedule a decode, and upload images to the AWS bucket.

Flowgraph for an automated NOAA satellite weather image station.
Flowgraph for an automated NOAA satellite weather image station.

Using an RTL-SDR and Speech To Text to Create Alerts on Specific Phrases

Atlassian Opsgenie Engineer Fahri Yardımcı has recently written up an interesting post that details how he's using Opsgenie and Amazon Transcribe to automatically create alerts when specific voice phrases are mentioned on a radio channel. For example, if the words "blue team" are heard on the radio, the system can automatically issue an alert with the spoken words to members of the blue team in an organization. Amazon Transcribe is a cloud based speech to text service and Opsgenie is a platform that is used for managing and delegating alerts from multiple IT or other computer systems.

The system works by using an RTL-SDR and the ham2mon software to scan, receive and record voice from multiple voice channels. Fahri notes that he modified ham2mon slightly in order to allow it to upload the .wav files to an AWS S3 server which then runs the Amazon Transcribe service to convert the voice into a text file.

To make an interesting use case, we have imagined this scenario: When we detect a phrase in predefined words, like “Help”, “Execute Order 66”, “North outpost is compromised”, “Eggs are boiled”, we want to create an alert in Opsgenie. Opsgenie can send notifications to users via various ways such as push notifications and calls.

Amazon Transcribe uses advanced machine learning methodologies, to convert an audio stream to a text. As mentioned before, ham2mon uploads to .wav files to S3 and a Lambda is triggered from S3 Events. Lambda calls Transcribe API and depending on the result, Lambda creates an Opsgenie Alert through API.

Fahri writes that his system also filters out small files that may just be noise, and files with voice less than 3 second long. He's also added a custom vocabulary to Amazon Transcribe with words commonly heard on the radio, as this improves the transcription algorithm, especially in the presence of radio noise.

The rest of the post goes into further detail about the specific cloud services used and the flow of the system.

Flow Graph of the Radio to Transcription System
Flow Graph of the Radio to Transcription System
An example alert from Opsgenie when the phrase "red team" was heard.
An example alert from Opsgenie when the phrase "red team" was heard.

Investigating Problems with the Tesla HomeLink RF Signal with a HackRF and GNU Radio

Tesla vehicles have a feature where they can copy and mimic a garage door remote via a built in transmitter on the car itself. This frees you from having to carry around a garage door key fob, and you can simply open your garage door by pressing a button on the car's LCD screen.

However, some people have reportedly been having a little trouble with this feature as in some cases the garage door would begin opening, and then suddenly stop opening as if the keyfob button had been pressed twice.

Over on YouTube CWNE88 decided to investigate this problem using his HackRF and GNU Radio. From a simple waterfall he was able to determine that the Tesla actually transmits the mimic'd garage door signal for a full two seconds.

As a keypress from the original keyfob would typically result in a much shorter transmission, CWNE88 believes that the long two second transmission could in some cases be seen as two transmissions by the garage door, resulting in an open, and then close command being detected. 

Tesla HomeLink RF Signal

QRUQSP – Receiving Weather Sensors via RTL-SDR and Sharing over APRS

Thank you to Andrew Rivett for writing in and sharing news about his project called "QRUQSP" which is aiming to provide an easy to set up system for allowing amateur radio operators to put weather sensors on the APRS network and log the weather data. Andrew writes:

For that last 2 years I've been working on QRUQSP.org, a system to receive weather sensors via a RTL-SDR.com V3 on a Raspberry Pi and then beacon that data over Amateur Radio APRS. I've also developed a dashboard that can be used on iPad 1 and old tablets, and soon will have the ability to sync data between Pi's and to the cloud.

For more information, please check out https://qruqsp.org/ , we have roadmaps under Software and Hardware.

The QRUQSP website also explains:

Amateur Radio offers many opportunities to receive digital messages, decode them and make use of the data contained within those messages. Our primary goal is to store and organize those messages in a database in a way that improves the operator's ability to analyze, assess importance, and relay messages as appropriate for his or her amateur radio service.

The service makes use of his hardware kits that are currently available for preorder on his website, with the basic kit starting at $80. Purchasing a kit or $10 monthly subscription to the cloud service software allows you to participate in the closed beta, which is currently only available for amateur radio operators.

The QRUQSP Hardware
The QRUQSP Hardware

In terms of software Andrew has also created a web application that can be used to collect and display the weather data collected over APRS or rtl_433. The service can be hosted directly on the systems Raspberry Pi, or online on the cloud via the QRUQSP subscription service.

QRUQSP Dashboard and Weather Data Log Display
QRUQSP Dashboard and Weather Data Log Display

First YouTube Reviews of the SDRplay RSPdx

SDRplay recently released news about their upcoming RSPdx software defined radio, which replaces the RSP2 as the top of the line unit in the SDRplay lineup. The RSPdx is not yet on sale, but a few YouTube reviewers have already received their units. The first review comes from Mile Kokotov who is known to have reviewed several SDRs in the past. Mile's impressions are that the receiver works very well. He writes on his video blurb:

Today i have received the new SDR receiver from SDRplay, the RSPdx and was eager to turn it on and do some tests receiving on HF and VLF. Although at the moment my mini-whip antenna is not operational, I have connected some 20 meters wire as an antenna and start listening on VLF, LW, MW and HF...

I have to say that SDRplay team did a good job with this SDR-receiver, putting better filters and redesigning front-end to improve dynamic range and enhance overall performance in relation to its predecessors RSP2 and RSP2pro. The new RSPdx is very good indeed. Especially on HF and below.

The RSPdx has new features like HDR (High Dynamic range) mode for reception within selected bands below 2 MHz. HDR mode delivers improved intermodulation performance and less spurious responses for those challenging bands.

The New SDRplay RSPdx receiver - First Impression: Excellent!

The second review is by SevenFortyOne who runs through the various features of the SDRplay and also tests it on various HF signals.

SDRplay RSPdx Overview and SDRuno V1.33 Demo

The third video isn't exactly a review, but here TechMinds shows us how to run the RSPdx as a panadapter on his FTDX-3000.

FTDX-3000 Panadapter Setup With SDRPlay RSPdx

The Malachite-DSP: A $195 Russian Made Portable Wideband SDR with Touch Screen

Over on the SWLing.com blog we've seen news about the release of a new Russian designed and made portable software defined radio called the "Malachite-DSP". The Malachite-DSP is an "all-in-one" portable SDR that is controlled via a touch screen and two control knobs. It covers 0.1 MHz to 1000 MHz with a bandwidth of up to 160 kHz, and the custom software supports all common modulation types. The whole device consumes 300mA and is powered by a Li-ion cell. It's marketed as a modern DEGEN and TECSUN replacement, so it appears to be targeting the HF short wave listening (SWL) customer.

Production appears to be small, with purchasing currently done by contacting RX9CIM, one of the project creators, directly at his email address (details on this forum post). The cost for a fully assembled unit is 12500 Russian Rubles which is 195 USD (not including international shipping). You can also purchase just the PCB without components for 1100 Rubles (17 USD). Importantly the forum post notes to watch out for scammers, who appear to be trying to take fake preorders for the device.

From the components list we can see that this SDR runs on the MSI001 tuner chip, which is the same tuner chip used in the SDRplay line of units. However, unlike the SDRplay units which use a wideband MSi2500 ADC, the Malachite-DSP uses an audio chip as the RF ADC. This provides a 16-bit ADC, resulting in high dynamic range, but at the expense of the available bandwidth which is only 160 kHz. A STM32H743VIT6 with ARM Cortex A7 processor runs what appears to be custom DSP and GUI software. The software doesn't seem to support DRM, but AM, WFM, NFM, LSB, USB are all supported.

The main place for news and discussion on the Malachite-DSP appears to be on a Russian ham radio forum thread. Judging by the fact that the schematic, software and BOM is all freely released, the project appears to be open source. There is also a group on the Russian Facebook clone vk.com where some discussion is occurring.

The YouTube videos below are by a Russian reviewers. Be sure to turn on the YouTube closed captioning and auto translation feature if you want to follow along in English.

😲ПРИЕМНИК КОТОРЫЙ ЛОВИТ ВСЁ!!!💥🔝 ЭТО ВАМ НЕ Degen и Tecsun ВСТРЕЧАЙТЕ НОВЫЙ МАЛАХИТ DSP V2💯🆕

SDR приемник МАЛАХИТ DSP

The Malachite-DSP reminds us a bit of the unreleased PantronX Titus II SDR, which is supposed to be a low cost (aiming for less than $100 USD) 100 kHz - 2 GHz tablet screen based SDR that was supposed to make DRM reception more popular. However the Titus II hardware has never eventuated since it's initial news in 2016, and at this time appears to be a dead project.

Video About Receiving The Othernet Satellite Data Service: Free APRS, News, Weather

The Othernet project aims to bring live data such as news, weather, video, books, Wikipedia articles and audio broadcasts to the world via cheap receivers and a free satellite service. Although an internet connection provides the same data, Othernet's satellite broadcast is receivable in remote areas, will continue working in disasters, and costs nothing to continually receive roughly 100-200 MB of data a day. The trade off is that the service is downlink only, so the data that you get is only what is curated by the Othernet team. Currently the service is only available in North America and Europe, but service to other areas in the world may eventuate in the future.

We've posted about this project a few times in the past, as previously they used an L-band satellite service that was received by RTL-SDR dongles. However, these days they operate using LoRa hardware chips on the Ku-band.

Over on YouTube the TechMinds YouTube channel has just uploaded a video that demonstrates the Othernet service being received from the UK via their Dreamcatcher hardware. In particular he shows off the APRS feature which sends any APRS message containing the string "OUTNET" to the Othernet satellite stream. Later in the video he also shows the news articles, weather data, Wikipedia and audio data that was received.

OTHERNET - Free Data Anywhere - For everyone!

Measuring Traffic in a Neighborhood with KerberosSDR and Passive Radar

KerberosSDR is our four tuner coherent RTL-SDR product made in collaboration with Othernet. With KerberosSDR applications like radio direction finding and passive radar are possible, and our free open source demo software helps to make it easier to get started exploring these applications. In this post we explore how a simple passive radar setup can be used to measure how busy a neighborhood is in terms of vehicular traffic.

KerberosSDR is currently available from the Othernet store for US$149.95, and the setup guide is available at www.rtl-sdr.com/ksdr.

Passive radar makes use of already existing strong 'illuminator' signals such as broadcast FM, DAB, digital TV and cellular. When these signals reflect off a moving metallic object like an aircraft or vehicle, it distorts the signal slightly. By comparing the distorted signal to a clean signal we can determine the distance and speed of the object causing the reflection. Wide reaching digital signals like DVB-T and DAB are often the best illuminators to use. Wideband cellular signals can also be used to detect more local targets.

In a simple passive radar system we use two directional antennas such as Yagi's. One Yagi points towards the broadcast tower and receives the clean non-distorted reference signal. This is known as the reference channel. A second Yagi points towards the area you'd like to monitor for reflections, and this is called the surveillance channel.

In our setup we point the reference channel Yagi towards a 601 MHz DVB-T transmitter roughly 33 km away. A second Yagi is placed on a vantage point overlooking a neighborhood. The Yagi's used are cheap DVB-T TV Yagi's that can be found in any electronics or TV retail store (or on Amazon for ~$30 - $60 USD).  In the software we used a bandwidth of 2.4 MHz and adjusted the gains for maximum SNR.

It is important that the surveillance channel is isolated from the reference signal as much as possible. We improve the isolation simply by placing a metal sheet next to the surveillance Yagi to block the reference DVB-T signal more. Note that putting the antennas outside will obviously result in much better results. These walls and windows contain metal which significantly reduce signal strength. We also added our RTL-SDR Blog wideband LNA to the surveillance channel powered by a cheap external bias tee to improve the noise figure of the surveillance channel.

KerberosSDR Passive Radar Setup
KerberosSDR Passive Radar Setup
Surveillance Antenna View
Surveillance Antenna View

The resulting passive radar display shows us a live view of objects reflecting. Each dot on the display represents a moving vehicle that is reflecting the DVB-T surveillance signal. In the image shown below the multiple colored objects in the left center are vehicles. The X-Axis shows the distance to the object, and the Y-Axis shows the doppler speed. Both axes are relative to the observation location AND the transmit tower location.

Vehicles on the Passive Radar Display
Vehicles on the Passive Radar Display

When there are more moving cars on the road during the day and rush hours, there are more blips seen on the passive radar display. Larger vehicles also produce larger and stronger blips. By simply summing the matrix that produces this 2D display, we can get a crude measurement of how busy the neighborhood is, in terms of cars on the road since reflections are represented by higher values in the matrix. We logged this busyness value over the course of a day and plotted it on a graph.

The resulting graph is as you'd intuitively expect. At 6AM we start to see an increase in vehicles with people beginning their commute to work. This peaks at around 8:30AM - 9am with parents presumably dropping their kids off to the neighborhood school which starts classes at 9AM. From there busyness is relatively stable throughout the day. Busyness begins to drop right down again at 7PM when most people are home from work, and reaches it's minimum at around 3am.

Traffic Busyness detected with KerberosSDR Passive Radar
Traffic Busyness detected with KerberosSDR Passive Radar

One limitation is that this system cannot detect vehicles that are not moving (i.e. stuck in standstill traffic). Since the doppler speed return will be zero, resulting in no ping on the radar display. The detection of ground traffic can also be distorted by aircraft flying nearby. Aircraft detections result in strong blips on the radar display which can give a false traffic result.

It would also be possible to further break down the data. We could determine the overall direction of traffic flow by looking at the positive and negative doppler shifts, and also break down busyness by distance and determine which distances correspond to particular roads. In the future we hope to be able to use the additional channels on the KerberosSDR to combine passive radar and direction finding, so that the the blips can actually be directly plotted on a map.

If you want to try something similar on the KerberosSDR software edit the RD_plot function in the _GUI/hydra_main_window.py file, and add the following simple code before CAFMatrix is normalized. You'll then get a log file traffic.txt which can be plotted in excel (remember to convert Unix time to real time and apply a moving average)

CAFMatrixSum = np.sum(CAFMatrix)
trafficLog = open("traffic.txt", "a")
logString = str(round(time.time())) + "," + str(round(CAFMatrixSum)) + "\r\n"
trafficLog.write(logString) 
trafficLog.close()

Running an RTL-SDR On up to 100 Meters of USB Ethernet Extension Cable

Over on Aliexpress and eBay there are now multiple USB2.0 extenders that work using Ethernet cable. These extenders advertise that is is possible to use up to 100m of Ethernet cable. Extending the USB connection rather than using coax cable is desirable as coax cable introduces signal losses the longer it is. Extending the digital side of the SDR (the USB cable) results in no signal being lost.

However, the USB2.0 specification notes that the maximum limit of the length of an extension cable is only 5 meters. We can go beyond 5 meters by using active repeater cables, but even this has limits of up to 30 meters maximum only.

So how can these USB2.0 Ethernet extenders advertise a length of up to 100m? These devices essentially convert the USB signal into an Ethernet network signal. Ethernet cable for network connections has a limit of 100 meters. Using this Ethernet extender is quite similar to using a Raspberry Pi and running the RTL_TCP software over an Ethernet cable, except that the network connection is handled entirely by the hardware.

We purchased a $45 USB2.0 extender from Aliexpress to test (there is also a cheaper $32 unit that we saw recently that should work too). The extender comes with a 1.5m USB Male to Male cable, a transmit box, a receive box and a 5V plug pack. The transmit side plugs into the PC via the USB Male to Male cable. The receiver end is placed up to 100m away, and this side must be powered by the 5V plug pack. In between you can run up to 100m of Ethernet CAT cabling.

USB2.0 Ethernet Extender from Aliexpress
USB2.0 Ethernet Extender from Aliexpress

In our testing we purchased a 50m CAT6 cable and tested to see if the extender would work with an RTL-SDR Blog V3, Airspy and SDRplay. Initially we had trouble getting SDR# to connect to the RTL-SDR. Eventually we found out that the provided USB Male to Male cable provided was of poor quality. After replacing it with a higher quality cable the extender began working properly. We also found that some USB ports on our PC wouldn't run the unit. The USB3.0 ports on the back of the PC connected directly to the motherboard worked best.

USB2.0 Ethernet Extender
USB2.0 Ethernet Extender Test

Using SDR# the RTL-SDR Blog V3 worked exactly like it was connected directly to the PC. There was no lag noticed at all, with tuning being instant. Sample rates up to 3.2 MSPS worked fine, although of course 2.56 MSPS was the limit without drops. As the receiver box is powered by a 5V plug pack, there was plenty of power available to power a 100 mA LNA via the V3's bias tee as well.

Reliability was a bit of an issue. Sometimes we'd need to replug the USB port several times before it would connect to the RTL-SDR. But once running everything appeared to be stable, and we left it running overnight at 2.56 MSPS without any problems.

Unfortunately the lower bit rate and sample rate of the RTL-SDR appears to be the limit of what the extender can handle. The Airspy with it's higher data transfer requirements due to it's 12-bit ADC didn't work properly, with audio stuttering from dropped packets (even at the lower 3 MSPS sample rate with packing enabled). The SDRplay also wouldn't work, with the SDRUno software being unable to detect the RSP1A. Even using a shorter 2M Ethernet cable did not help for these SDRs. In theory it should work since Ethernet can support a much higher data rate, but perhaps the converter chipset used in the cheap extender unit that we have isn't fast enough.

If you want to try this out, be very careful of what you purchase on Aliexpress/eBay/Amazon. There are some very very cheap USB to Ethernet extenders out there that are advertised as USB2.0, but not all of them are truly USB2.0. The very cheap ones under $5 won't work. Those cheap units actually degrade USB2.0 down to USB1.1 which will not work for an RTL-SDR or any other common SDR. The extender units that will probably work properly are all priced over $30.

It's also possible that some of the more expensive units available on Amazon (e.g. [1][2][3]) may be implemented better and might work with the Airspy and SDRplay. If you've tried one of the pricier units please let us know in the comments if it works. In particular this $156 KVM unit which claims a high data rate and also supports PoE may work (although PoE may cause switching noise). For extreme extensions of up to 250m, USB2.0 fiber optic extenders such as this $359 unit, or this $459 fiber optic unit which can go up to 5km (3.1 miles) might also work. If you've tried any of these please let us know in the comments.

Перевод
Рубрики
Архивы
Ноябрь 2019
Пн Вт Ср Чт Пт Сб Вс
« Окт    
 123
45678910
11121314151617
18192021222324
252627282930