Thanks to everyone’s amazing support we were able to fund in less than 24 hours from release! Now, thanks to funding, we can move on to the job of finalizing our batch manufacturing and accelerating development of our codebase.
Please keep in mind we’ve sold almost half of the first batch of 1000 units! So, if you have been hesitating, please get your order in soon since subsequent batches could be susceptible to manufacturing delays.
The design of the KrakenSDR enclosure is coming along nicely and we expect to be cutting the new prototype soon. The image below shows a 3D rendering (the blank space in the middle will contain the logo). The enclosure is a critical part of the KrakenSDR as it helps add thermal mass and cooling ability. Phase drift can occur when the tuner chips experience temperature fluctuations, so adding thermal mass helps to dampen ambient temperature changes significantly. The PCB is thermally connected to the enclosure via a thermal pad. The enclosure, of course, also helps block signals from directly entering via the PCB, which could skew results.
Arrow Antennas Update
Unfortunately Arrow Antennas have recently informed us that delivery of their five-element, fixed-site, dipole array we mentioned in the campaign text is going to be delayed due to the aluminum shortage crisis in the USA. We’re holding out hope this will be resolved early next year by the time we ship. Please note that this has no impact on the $99 set of five magnetic mount antennas offered directly by us through the campaign.
Support for KerberosSDR
There have been some concerns that the release of KrakenSDR means support for new developments on our previous product KerberosSDR is abandoned. We have stopped development on the older KerberosSDR code, but we want to clarify that KerberosSDR is fully supported by our new KrakenSDR code, which is a massive improvement.
The new code is designed to be compatible with x-channel Kerberos/Kraken style receivers. So it can support the four-channel KerberosSDR and the five-channel KrakenSDR as well as any DIY system with x-channels. The only change required will be setting the RX channel count in the configuration. The main disadvantage with the older KerberosSDR hardware is that even with the new code, you still will need to manually disconnect the antennas when calibrating (e.g., at startup or frequency retune).
If you have a KerberosSDR, you can try this code out right now by cloning and installing heimdall_daq_rx and krakensdr_doa. Everything, including install instructions and documentation, is in the development branches of our GitHub repo (please note this setup may be a little involved at the moment as the code is evolving rapidly). When the code is fully released, the ready-to-use Pi4 SD card will be usable with KerberosSDR simply by changing the RX channel count.
We have also considered the Android App and are happy to announce that all our previous KerberosSDR customers will receive a license for the upgraded app when it is released too. KerberosSDR customers, please keep an eye on the email address you used with your order for updates on that in early 2022.
Testing & Development
This week, the 4.5V bias tees were put through a stress test by powering five wide-band LNAs. This is working beautifully with a 5V, 3A power supply. A 3A supply will be required if you are intending to power an LNA on each port, as the KrakenSDR itself draws 2.2A maximum load when all tuners and the noise source is active.
We have also been testing how the KrakenSDR could be coupled with a small, low power, 10dBm 433 MHz ISM band CW beacon based on the Heltec WiFi Lora 32 hardware, but modified to run the LoRaFox fox hunting beacon software. The range of this low power beacon at 10dBm seems to be roughly three kilometers/two miles with the beacon obscured inside the glovebox of a car. We plan to provide more info on these tests in the next few weekly updates as we think there is an application for similar low power beacons combined with KrakenSDR for local asset, pet, or wildlife tracking.
We are also beginning work on our network mapping solution, which will allow users to run multiple KrakenSDRs in an area with all units uploading data to a central server over the internet. The server will run a web-based version of our Android app, collecting and plotting all bearing data on the same map, and determining a likely TX position. We hope to have a working beta out by the time we ship early next year.
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.
KrakenSDR is a five-channel, RX-only software-defined radio (SDR) based on the RTL-SDR and designed for phase-coherent applications and experiments. Phase-coherent SDR opens the door to some very interesting applications, including radio direction finding, passive radar, and beam forming. You can also use KrakenSDR as five separate radios.
KrakenSDR is an upgraded version of our previous product, KerberosSDR. It provides a fifth receive channel, automatic phase-coherence synchronization capabilities, bias tees, a new RF design with cleaner spectrum, USB Type-C connectors, a heavy-duty enclosure, upgraded open source DAQ and DSP software, and an upgraded Android app for direction finding. We are constantly working on new software and sample applications, so keep an eye out for future updates!
We expect to ship the first 1000 KrakenSDR units to backers before the end of March, 2022. And by the time that happens, we’ll have published a full range of in-depth tutorials to help you get started.
KrakenSDR Promotional Video
Some of our previous KerberosSDR and KrakenSDR posts might also be of interest.
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.
On this weeks Frugal Radio YouTube video, Rob explores how to decode Fire, Ambulance and Hospital pager data using SDR++ and PDW. In the video Rob first explains what applications pagers are used for in 2021 and how they're typically received with pager or MDT hardware terminals mounted in fire and ambulance trucks.
He then goes on to show how we can receive and decode these pager messages using an RTL-SDR, SDR++, VB-Cable and the PDW pager decoder. The tutorial shows how to set up SDR++ settings for pager reception, how to install and setup PDW and how to interface the two programs with VB-Cable. Finally Rob explains how to fully understand some of the messages that you might receive.
Decoding Fire & Ambulance MDT data & hospital pages with a $10 SDR Radio