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
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 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.
Over on our forums one user luc4sss has been discussing a method for using RTL-SDR's and perhaps other SDR dongles remotely which does not rely on rtl_tcp, SpyServer or other SDR specific server software. Using an SDR remotely is advantageous because it can allow you to position the SDR closer to the antenna, which results in less signal loss from long runs of lossy coax cable.
Instead of rtl_tcp, luc4sss uses a program called VirtualHere, which is a server that can work with any USB device. It essentially allows you to use USB devices over a network with the remote device acting as if it was plugged directly into your remotely operated PC. The server can run on single board Linux computers like the Raspberry Pi and luc4sss has been using an $8 Orange Pi Zero 256 MB as his server.
With the VirtualHere software and RTL-SDR running on his Orange Pi Zero, he's able to connect to a remote RTL-SDR over his network. He writes that data usage is about 5 - 6 MB/s so a wired Ethernet connection or high quality WiFi connection would be required. In comparison rtl_tcp should use about the same amount of data, but server software with some compression and data saving techniques implemented like SpyServer use much less data and is efficient enough to be used over the internet.
We can see the VirtualHere software being very useful for use with RTL-SDR compatible programs that don't have rtl_tcp support, which is most of them. It should also be useful for other SDRs that don't have streaming server software available.
VirtalHere is not free as a license costs $49. But it does have a 10-day trial period which supports 1 device being shared at a time.
VirtualHere USB Network Server
Luc4sss has also uploaded a video on YouTube that shows him running the VirtualHere server and client, and connecting to the remote RTL-SDR with GQRX and dump1090. He also shows the data usage which is about 6 MB/s when running the RTL-SDR at 2.8 MSPS. Operation appears to be problem free and with almost entirely no latency as well.
RTL-SDR over Ethernet with VirtualHere Client/Server
Rtl_433 is an RTL-SDR compatible command line based tool for monitoring various 433 MHz ISM band devices, such as temperature sensors, weather monitors, TPMS, energy meters etc. A full list of support devices can be found on the rtl_433 Github.
Over on his blog “raspberrypiandstuff” mentions that he’s been using rtl_433 and an RTL-SDR on a remote headless Raspberry Pi to receive and monitor temperature and humidity from his weather station. From the data he’s able to produce some nice graphs that show changes over time.
However, one problem that he ran into was that the USB controller on the Raspberry Pi would sometimes hang. The only solution he’d previously found to fixing it was to physically disconnect and then reconnect the RTL-SDR. But now “raspberrypiandstuff” writes that he’s found a new solution which is to use a small C-program called usbreset.c. Combined with a bash script that detects which device the RTL-SDR is on the bus, this tool helps to automatically reset the USB on the Pi if it fails to keep the RTL-SDR logging 24/7 without physical intervention.
This may be a solution to look into if you’re experiencing similar issues with 24/7 monitoring on the Raspberry Pi. If you’re also interesting in rtl_433 monitoring, “raspberrypiandstuff” also has a post on creating a simple GUI for rtl_433.
NOTE: Recent changes to WordPress seem to have broken the audio on this page. Please use the newSignal Identification Wikiwhich has many new signals. Anyone can edit and improve the information on the pages on the wiki.
A guide to help you identify some amateur and utility digital radio signals and sounds which you may find on the frequency spectrum. Most of these have been received with an RTL-SDR software defined radio. I will be slowly adding more to this list over time. If you enable stereo mix and pass the sample audio to an appropriate decoding program the sample audio should be decodable for most samples.
If you would like to suggest a modification or contribute a sample, please send a sample, waterfall image and information about the signal to [email protected], or post in the comments. (Note I am currently backlogged with contributed signals, if I haven’t replied or added your signal yet it will be done within a month or two).
Description:Terrestrial Trunked Radio (TETRA), also know as Trans-European Trunked Radio is a professional mobile radio and two-way transceiver (walkie-talkie) specification. Modulated with π/4 DQPSK. Audio sample recorded in NFM mode.
Common – 87.5 to 108.0 MHz OIRT – 65 to 74 MHz Japan – 76 to 90 MHz Consumer Wireless Devices – ~860 MHz
Mode: WFM
Bandwidth: 30000 Hz
Description: Stereo Wideband FM signal. Used for typical broadcast radio, and in some wireless headsets and speakers. This particular signal is from an AKG headset.
Top signal is WFM transmitted with low amplification. Bottom signal is WFM transmitted with high amplification.
Description: Single side band, specifically upper side band. Used in the HF band by amateur radio hams and aircraft weather reports. Single side band saves bandwidth.
Description: (Previously Unidentified Signal 5). Numbersstations are thought to transmit encoded information for various spy agencies around the world. They are recognized by a voice reading a sequence of numbers or words. This is a Cuban Numbers Station which has a data portion and a voice portion. Sound sample recorded in AM mode.
Thanks to Andrew from the comments section for the ID.
Description: (Previously Unidentified Signal 2). An Aircraft Communications Addressing and Reporting System (ACARS) data link that aircraft use to communicate short messages over long distances using HF signals.
Thanks to Andrew from the comments section for the ID.
Description: (Previously unidentified signal 10). Identified in the comments section by Ronen as an Asynchronous Frequency Shift Keying (AFSK) pager link. It is easier to transmit the FSK pager signal to the transmitter site as AFSK.
Description: Previously unidentified signal (11). Identified in the comments by various contributors as multiple overlapping RTTY signals sent by ham radios.
Voice Frequency Telegraph
Sample Audio:
Typical Frequency: 7453.50 KHz USB
Description: Previously unidentified signal (13). VFT or Voice Frequency Telegraph is one of several systems for sending multiple RTTY signals over one voice-bandwidth radio channel.
Portable Traffic Lights
Sample Audio:
Found Frequency: 154.463 MHz
Description: Previously unidentified signal (17). Identified by Peter via email as being signals sent from portable traffic lights that are often used at roadworks.
X2 on iDEN
Sample Audio: –
Found Frequency: 154.463 MHz
Description: iDEN is an acronym for Integrated Digital Enhanced Network and is a technology developed by Motorola. It is a type of trunked radio with cellular phone benefits.
If you know what any of these signals are please write in the comments. You can also submit any unidentified signals you would like to be added to [email protected]
(1)
Sample Audio:
Found Frequency: 171.3 MHz
Description: Recognized by DSD as a NXDN96 signal, but is disputed in the comments section. (Possibly a bug in DSD).
(3) – ALE?
Sample Audio:
Found Frequency: HF Band
Description: Sound sample recorded in USB mode. Potentially some sort of 2G ALE signal. Similar signal shown in balints HF tour video. Possible a weather map transmitted from Tokyo as noted in the comments section by Syd, or 4xFSK from China as identified by K2RCN in the comments.
(4)
Sample Audio:
Found Frequency: HF Band
Description: Periodic pulses. Sound sample recorded in USB mode. Possibly a GlobeWireless signal as identified in the comments section by K2RCN.
(6)
Sample Audio:
Found Frequency: 152.652 MHz
Description: Continuous signal. Audio sample recorded in NFM.
(7)
Sample Audio:
Found Frequency: 162.863 MHz
Description: Continuous bursts. Audio sample recorded in NFM.
(8)
Sample Audio:
Found Frequency: 457.168 MHz
Description: Audio sample recorded in NFM.
(10)
Sample Audio:
Found Frequency: 452.325 Mhz
Description: Sent in over email. Sounds like Motorola Type II smartnet, but Unitrunker does not recognize.
(12)
Sample Audio:
Found Frequency: 154.646 MHz
Description: Sent in over email. Repeats every minute.
(14)
Sample Audio:
Found Frequency: 433 MHz
Description: Sent in over email.
Hello! I was listening in the 433MHz band and saw this blip (about 1-2sec) on the waterfall on 433.873 (Millville, MA). It repeats about every 30-50 seconds, though doesn’t seem to be the same every time. Maybe a wireless instrument of some type (weather or something?). The only clear sound of it I could get was with AM, about a 4.2kHz wide filter (rtl-sdr, gqrx linux). Any ideas? Thanks!
(15)
Sample Audio:
Found Frequency: 455 MHz
Description: Sent in over email.
(16)
Sample Audio:
Found Frequency: 173.262 MHz
Description: Sent in over email.
(18)
Sample Audio: None
Found Frequency: ~856 MHz
Description: Sent in over email.
The antenna has a Yagi pointed to West from 23.5° South latitude, 47.46° West longitude. The signal can be local or from the sky. The signal is horizontal polarized.
(19)
Sample Audio:
Found Frequency: ~409.6 MHz
Description: Sent in over email. Recorded in NFM mode.
