As mentioned in a previous post last week, UUGear have recently released their VU GPSDR expansion board for their Vivid Unit single board computer with touchscreen. Together, this combination results in a handheld Linux system, with built-in RTL-SDR and upconverter.
The VU GPSDR has some interesting features, including:
We won't repeat the assembly steps as the instructions show everything clearly, but we can say that the assembly steps were clear, and the assembly itself was easy. It was simply a case of plugging in a few jumper wires between the Vivid Unit and VU Extender board, screwing down the extender board, and then slotting in the VU GPSDR into the Extender boards mini-PCIe slot, before finally screwing down the GPSDR. Assembly took less than 10 minutes.
The system is put together like a sandwich. You have the screen and Vivid Unit on the top, then the Extender board, and finally the VU GPSDR on the bottom.
The Vivid Unit and GPSDR are essentially bare PCBs that connect to one another via the PCIe slot on the Vivid Extender board. This means that there is no enclosure, and you are essentially handling PCB parts in their raw form. In the future, we would like to see an optional enclosure to protect the unit better.
The exposed design results in some flaws that we have to point out. The shielding cans on the VU GPSSDR unit sit on the rear of the system, and during operation, they get very hot to the touch. So much so that handling the unit requires a bit of care to avoid the hot spots. Most of the heat appears to be coming from the AMS1117 LDO on the rear, which gets up to 80 °C, so be careful not to touch it accidentally. From the photos you can see that the RTL2832U and R860 are heatsunk to the shield. This is a good idea to keep the chips cool, but it also means that the metal gets quite hot to the touch. So handling the unit only from the edges is recommended.
Secondly, because the Vivid Unit does not have a built-in battery, you need to power it separately via its USB-C port on the side. This makes the ergonomics of handling the unit a little trickier as you also have a cable sticking out. UUGear has noted that they are working on an 18650 battery pack, so this issue may be resolved in the future.
Finally, the "GPS" in the GPSDR comes from the fact that there is a GPSDO with a built-in GPS patch antenna on board. When active, a GPSDO provides excellent frequency stability, meaning that signals will be on frequency and will not drift.
Indoors, of course, no GPS fix is possible. But the uBlox NEO-M8N GPS module used in the GPSDR also has a fallback TCXO, so even without any GPS fix, the frequency accuracy of the system is good. UUGear also noted that the GPSDO automatically activates once a GPS fix is achieved, so no action is needed when you take the unit outdoors.
Realistically, the design issue with the GPS patch doesn't really matter anyway. For most use cases in handheld operation, the built-in TCXO will be sufficient. Any use case requiring extreme GPSDO precision will probably involve the device being mounted upside down and used remotely.
The screen is clear and bright, the two encoder wheels are non-indented and are in a good spot, and so is the SMA antenna port, although the VU Extender's USB-C plug can block the antenna SMA port if a really fat plug is used (normal-sized USB-C plugs fit OK). The screen is large and has a high resolution, making it possible to use the onscreen keyboard. However, it is still a little fiddly for typing and clicking, so we ended up plugging in a small wireless keyboard.
You will need to connect your system to a network to download the software and update the system time. Unfortunately, we encountered an issue with the older WiFi module used in the VU Unit. The WiFi module does not support 5 GHz or WPA3 security, and our test WiFi setup is relatively modern with WPA3 security enabled. Initially, we just connected an Ethernet cable to get going, but later UUGear suggested some terminal commands that forced a WPA2 connection to our WiFi, and that got it working.
sudo nmcli connection add type wifi ifname wlan0 con-name mywifi-wpa2 ssid "your_ssid" sudo nmcli connection modify mywifi-wpa2 wifi-sec.key-mgmt wpa-psk sudo nmcli connection modify mywifi-wpa2 wifi-sec.psk "your_password" sudo nmcli connection up mywifi-wpa2
Once connected the instructions for software setup are simple, involving just a few commands to download the software for the extender, and for gpsdrpp, their SDR++ fork. They also provide a one line command to activate GPU acceleration on the unit, which makes gpsdrpp run a lot smoother.
However, despite the system time being up to date, we found that we had to run "sudo update-ca-certificates" to update certificates first. This was necessary before any apt commands would work, and it was not mentioned in the instructions.
Initially, we encountered an issue where sometimes the GPSDR unit was not detected by the Vivid Unit. We eventually discovered this was because we were using the wrong power button to turn on the system. When the VU Extender board is connected, the user must use the power button on the VU Extender board to power up the system. If the power button on the Vivid Unit is used, then the Extender board, and hence the VU GPSDR will not be powered. Once we figured this out, we were able to connect to the VU GPSDR every time successfully.
A second issue we encountered was with battery testing. UUGear recommends powering the system via the VU Extender's USB-C port. However, when powering from a battery pack, the VU Extender's USB-C port would not work.
Connecting to the USB-C port on the Vivid Unit itself also proved inconsistent with a battery. Notably, in roughly 50% of cases, launching gpsdrpp while operating on battery power caused the entire system to power off unexpectedly. We suspected that our 5V, 3A battery pack couldn't provide the initial inrush current that occurs when the GPSDR is booted, which happens only when gpsdrpp is loaded. UUGear confirmed with us that the peak current can indeed exceed 3A sometimes. As mentioned previously, UUGear is working on an official battery pack which may solve this issue.
Everything worked fine when powering it from a plug-in USB-C PD pack.
UUGear have created their own open source fork of SDR++ called gpsdrpp. The fork adds a few features, such as the ability to switch modes between the GPSDR features, such as standard SDR mode, ADS-B Mapper, GPS, and clock-out signal generator.
We started gpsdrpp and we were immediately able to receive and listen to broadcast FM once we tuned to a signal and set the demodulation mode to WFM. Sensitivity was good, on par with a standard RTL-SDR, and the audio from the speaker was clear, though it sounded a bit tinny.
We then switched to ADS-B mode and immediately started seeing data flashing by in the sidebar. The ADS-B mode also has a built-in map, based on OpenStreetMap (requiring an internet connection to download tiles). Because we were inside while testing, the GPS center button did not work and we had to use the +/- zoom buttons and drag the map to find our location. Doing so was a little tricky because there is no pinch-to-zoom, and every zoom button press moved the map around.
We then switched to GPS mode and went outside to see if satellites could be received. After a few minutes with the screen facing us and the GPS antenna face down, we were pleasantly surprised to see that the patch antenna still worked in this configuration. Several satellites were received with average signal strength, which was enough to obtain a fix. Upon tilting the patch antenna towards the sky, several more satellites were received, and all with green signal strength.
Finally, we tested the HF upconverter. In gpsdrpp the software automatically activates the upconverter when a frequency of less than 30 MHz is selected. We first activated the built-in "VU GPSDR" drop-down setting in Offset, and then tuned to 1 MHz to look for broadcast AM stations. Unfortunately, we were unable to receive any of the same stations that a Blog V4 could. It seems that there is some filtering of signals being done below 2 MHz as we found that when using a signal generator, we were able to receive from about 2 MHz onwards. However, the spectrum was plagued by strong LO spikes, which we talk about further down under the Spectrum Quality heading.
The gpsdrpp software also makes use of the built-in encoder wheels, which by default are set to zoom and frequency tuning functionality. By pressing down the button next to each of the encoders, you can change the encoder functionality. Frequency tuning can be a little slow when a narrow bandwidth is selected, as it takes many turns to move across the spectrum. In the future, we would perhaps like to see an acceleration or non-linear tuning function added.
SDR++ is not really optimized for small screens; however, in the UUGear fork, they have added larger controls for RTL-SDR gain settings and the demodulator, which are easy to press. But changing more advanced settings involves opening the standard SDR++ sidebar which has very small controls. Oddly, the High-DPI scaling option doesn't seem to work in this version.
We also installed and tested rtl_tcp and rtl_433 to make sure that other programs can access the RTL-SDR on the Vivid Unit. We had no problem running different software. We note that it is necessary first to open gpsdrpp, then close it, before running other software. The reason is that opening gpsdrpp activates the VU GPSDR hardware, making it available to be used.
We did encounter a few bugs when testing the system.
The first bug involved gpsdrpp. After moving through the different modes that gpsdrpp has (Tuner/GPS/ADSB etc), we sometimes ended up in a state where the tuning bar, and demodulation modes would disappear from the UI, hence making us unable to receive any signals. The only fix we found was to delete the data in ~./config/gpsdrpp.
The second bug was that the hardware acceleration that the instructions have you activate when installing GPSDRPP would often revert back to softpipe after a reboot (using the CPU instead of the GPU). When softpipe is used, gpsdrpp is very sluggish. The fix was to rerun the one-line installation step to activate GPU acceleration.
The VU GPSDR appears to have sensitivity about on par with a standard RTL-SDR for wideband signals. However, we did encounter two relatively significant issues with narrowband signal quality.
The first issue is that the 28.8 MHz local oscillator spikes are pretty significant. On an RTL-SDR, small spikes at intervals of 28.8 MHz are common and are caused by harmonic leakage from the 28.8 MHz local oscillator. However, on the VU GPSDR these spikes are much larger than we expected, and they contain a lot of surrounding phase noise. This is probably because the VU GPSDR uses a Si5351 and GPSDO module as the oscillator, and we suspect that the LO signal level and leakage are much larger. So on the VU GPSDR, you have to expect fairly large spikes every 28.8 MHz, which could interfere with legitimate signals.
The second related issue is that the high LO drive level, along with other factors, introduces significant phase noise visible with narrowband signals. This phase noise increases the noise floor around the signal, reducing the SNR of that signal and any nearby signals in the frequency spectrum, too.
UUGear has acknowledged this issue and is actively working to determine if there is a way to reduce the LO drive level in software. However, a hardware change might also be required.
We're glad there is innovation happening in the SDR + computing combination space, and the Vivid Unit is a great first entry for UUGear. Having an easy-to-use RTL-SDR with a built-in computing device is a game-changer for those who love experimenting with RF in the field. There is a wealth of RTL-SDR software out there for almost any application, so making it easier to run various decoders in the field is always a win.
However, we definitely found some issues with the design and performance, so we hope UUGear can address these problems through software updates and a newer revision of the hardware.
It will also be interesting to see if other mini-PCIe based SDRs like the LimeSDR XTRX and Sidekiq Mini PCIe will work on the Vivid Extenders mini-PCIe slot.
At the moment, for portable SDR devices for RF experimentation, the HackRF H4M Portapack is still the king with its easy-to-use UI and click wheel interface, built-in battery, and TX capability. However, the H4M Portapack is limited to the firmware installed, and so of course, misses out on the wealth of RTL-SDR software available for Linux.
In the future, when it is in stock, we will also be testing the uConsole RTL-SDR extension board, which is another attempt at an RTL-SDR addon board for a portable computing device. The uConsole itself appears to be quite a solid device, as it is based on the Raspberry Pi CM4/CM5 and includes a built-in physical keyboard, mouse trackpoint, and enclosure, so it will be interesting to compare it against the Vivid Unit.
Disclaimer: This was a free review unit provided to us by UUGear for an honest review. We have no financial or other interests in UUGear products or any of the other third-party products mentioned in this post.