Great Scott Gadgets

open source tools for innovative people


Free Stuff - February 2022

The February recipient for the Great Scott Gadgets Free Stuff Program is Matthew Hilts! Matthew is a student at the University of Dayton who will be spending his Spring semester learning about and using GNU Radio. To help enhance his studies we have sent Matthew a HackRF One. We look forward to hearing about what he learns!


HyperRAM controller for USB analysis

Note: This is a crosspost of a Cynthion update on Crowd Supply: https://www.crowdsupply.com/great-scott-gadgets/luna/updates/hyperram-controller-for-usb-analysis.

One of LUNA’s core features is the ability to perform protcol analysis of USB 2.0 low-speed, full-speed, and high-speed. For most target devices, LUNA can endlessly stream the capture directly to a host PC over its own high-speed port. However, for high-bandwidth target devices that can’t be streamed in real-time, LUNA has 8 MiB of memory on board to buffer captured data before sending it upstream.

On LUNA we’re using HyperRAM, a type of pseudo-static RAM, which is capable of achieving relatively high speeds while being much simpler to work with than DRAM as it handles refreshing of the memory array by itself. Recently we’ve been working on our Amaranth gateware that interfaces with the RAM, implementing support for memory-space reads/writes and speeding it up so that we can keep up with USB analysis.

Speed

For USB analysis, we need to be able to stream data through the RAM at a nominal 480 Mbit/s but, since the ram is half-duplex, we need to hit at least double that. We also need to allow for some overhead for the RAM protocol. In our controller we run the RAM at 120 MHz DDR for a nominal rate of 1920 Mbit/s, which gives us plenty of margin to keep up with high-speed USB.

The Lattice ECP5 FPGA used on LUNA has a nifty feature in the I/O cells called gearing, which serializes/deserializes data to allow the I/O pin to run at a high speed without requiring the FPGA fabric to match it. For our HyperRAM controller we use the IDDRX1 and ODDRX1 cells, which take a 2-bit signal and read from/write to I/O pin at double the speed.

Timing challenges

A challenging part of interfacing with HyperRAM is the wide range of data-valid timing. The datasheet specifies that the data lines can be valid anywhere between 1 ns and 7 ns after a clock transition, and become invalid anywhere betwen 0.5 ns and 5.5 ns after the next clock transition. Running at 120 MHz the time between clock edges is only 4 ns, so this means that there is no fixed window in which to sample! The diagram below shows some examples of how the data-valid window could be shifted relative to the clock:

We solve this by using the ECP5’s I/O delays to shift the data-valid window and align it with a clock edge. These delays are variable so we can adjust them during operation to find the range of values that result in successful memory reads, then pick the value in the middle for the ideal sampling point.

Debug tooling

For projects like this, it’s important to have good tools for debugging! As part of this work we wrote a HyperRAM decoder for glscopeclient, an open source frontend for oscilloscopes. This makes it easy to interpret waveform captures from the real hardware, and verify that everything is working as expected. The decoder has been merged upstream, so it’ll be available with any recent glscopeclient install.




Free Stuff - January 2022

The January recipient for the Great Scott Gadgets Free Stuff Program is Rüzgar Erik and the Sivas Science High School Science and Tech Club! The club has about 35 students who meet weekly to learn about various topics and develop their own projects. We will be sending this club their very own HackRF One so they can upgrade from their current SDR which they made from an old tv tuner SDR and Rüzgar Erik’s Baofeng radio.

Once they have received their HackRF One, the club will try to receive images from NOAA, find number stations, and dive into the world of RF.


Free Stuff Program Refresh

Free Stuff is a program where we at Great Scott Gadgets give free hardware to a person or group once per month. We’ve been running this program since February 2015 by having interested parties email us their free stuff requests.

Starting now, Great Scott Gadgets has a new Free Stuff Program application process where, instead of emailing us, anyone interested in getting free hardware from Great Scott Gadgets can apply using our new application link. The application link and extra details on the Free Stuff Program are available on our Free Stuff page.

Free Stuff recipients are chosen once per month out of all applications we have received over the last twelve months. We typically give out one piece of hardware free of cost, pay for shipping, and feature Free Stuff recipients on our blog. With this refresh of the Free Stuff Program we are currently at zero applications so now is the best time to apply. We look forward to seeing your applications!


Free Stuff, October 2021–December 2021

October

Charles, a computer science student in the UK, asked us for a HackRF One because he wants to learn about device interactivity and to search for potential vulnerablities in his own devices.

November

The Free Stuff recipient for November is UW Orbital, a new student design team at the University of Waterloo (Canada) with over 40 active members. They are developing a 3U CubeSat for the Canadian Satellite Design Challenge (CSDC). They say, “The team is working on an imaging payload that will allow amateur SDR radio operators from around the world to request an image of their location from orbit, with the goal of attracting beginners to ham radio as a hobby and providing education in communications systems. The HackRF One will be crucial to the team’s prototyping phase to test uplinks and downlinks to the CubeSat, and could potentially even be used as the team’s ground station transceiver.”

December

Noah in Kentucky asked us for an Ubertooth One for his son Saul to use in an upcoming STEM night at his school. Saul wants to help other kids learn about wireless technology, so he’s planning to demonstrate something exciting.


Free Stuff, July 2021–September 2021

July

July’s recipient is Nick with Urban Rivers. This organization is building a floating park in the Chicago River that has been getting a lot of bird layovers. Nick wants to integrate a HackRF One into Motus Wildlife Tracking System to study migratory patterns and capture a more complete picture of avian travel.

August

Kevin runs the Roanoke Robotics Club and asked us for Free Stuff to teach kids about electronics, etc. We sent a box of Throwing Star LAN Tap Kits so they can practice soldering.

September

Tandin is a person of many talents, technical and artistic, in Bhutan. They asked for an Ubertooth One for fun, experimentation, and learning.


Free Stuff, April 2021–June 2021

April 2021

Eric wrote to us on behalf of the Chaffey High School (Ontario, CA) Tech Club, asking for a HackRF One. He’ll be graduating from the University of Tulsa soon and as a past president of the club, he zooms into the club’s meetings to offer help with computer science and cybersecurity topics. Now he’ll be able to help the students use a HackRF One for their own projects. They’ll also be holding workshops on RC Car Hacking, Listening to and Broadcasting AM/FM Radio Signals, and Mapping Planes with ADS-B Signals.

May 2021

The Free Stuff recipient for May is João Pedro Polito, a student at the Universidade Federal de São João del Rei, Brasil. He needs a HackRF One for a ground station for nanosats and stratospheric balloons.

June 2021

In June, Amy asked us for a HackRF One to explore the intersection of radio and cybersecurity. She’s studying for her CISSP certification and is the only woman in her local Amateur Radio club, so she wants to mentor and encourage others to join the community.


Free Stuff, January 2021–March 2021

January 2021

The first Free Stuff recipient of 2021 is Christos Voutichtis, an artist in Gemany who asked for a HackRF One for his project, Order of Sound. He tells us, “This is an arrangement of five complex antenna receivers which make the electromagnetic waves that permanently surround us audible. This data, which we perceive as sound, is processed in a program (VVVV) that I have designed which enables the analysis to translate them into graphical elements, which are then rendered as an abstract architecture in the form of a real-time projection. The viewer enters an immersive megastructure of abstract data landscapes in a highly aestheticized, scenographic context. The visualization is created as a 3-D virtual Space and allows the participant to wander through emerging data structures.”

February 2021

In February, we received a HackRF One request from Anil Karki, the president of Innovative Ghar Nepal, a non-profit for the development of innovative products and services in Nepal.‘Ghar’ in Nepali means ‘Home’and their organization is a home for students, developers, makers, technologists, and artists to gather to promote, educate, explore, create and share their skills and curiosity. They need their new HackRF One for their autonomous medical drone project.

March 2021

Mike in New Jersey asked us for an early graduation present: a YARD Stick One to develop an app for use in his new job.


LUNA Now Uses Amaranth HDL

Note: This is a crosspost of a Cynthion update on Crowd Supply: https://www.crowdsupply.com/great-scott-gadgets/luna/updates/luna-now-uses-amaranth-hdl

Over the next while we will be updating the LUNA project to use “Amaranth HDL”, which is the new name whitequark and other maintainers have chosen for their project. Amaranth is the hardware description language used in LUNA. The Amaranth gateware provided with LUNA enables you to create USB devices in gateware, firmware or both. Amaranth also enables LUNA to customize itself to the task at hand, which gives it access to unique features like user-defined hardware triggering and simultaneous capture of additional external or internal signals. The GitHub location for the Amaranth HDL project is https://github.com/amaranth-lang/ and if you want to talk with other Amaranth users you can join the #amaranth-lang IRC channel on http://libera.chat.


Testing a HackRF Clone

Like every open source hardware company, we’ve seen clones of our products for sale on the Internet. These clones arguably provide a valuable service to the community, making our designs more widely available and at a price more people can afford. However, they also have negative effects such as an increase on our technical support burden without a corresponding increase in revenue to pay our staff. When the quality of a clone is poor it may also degrade the reputation of our products.

Our most frequently cloned product is HackRF One. While we have every reason to believe that some of the HackRF clones on the market are perfectly functional, we’ve seen users struggle to get others to work at all. Some of the clones have been completely dead on arrival or have had other hardware problems. In general, it seems that few of the clones have been tested by their manufacturers. This can be particularly problematic if returns are not accepted.

We recently decided for the first time to order a HackRF clone and test it to see how well it performs. We chose this particular clone because it has an updated design claimed to improve upon our own design. We’re interested in potential improvements we can make to our own product, and it seemed that the easiest way to test these modifications would be to simply buy the modified clone.

When we plugged the clone in, it appeared to function normally. It had shipped with firmware built from the Havoc repository. This makes some sense as the seller also sells a clone of Jared Boone’s excellent PortaPack. If someone were to purchase both products, the PortaPack would work out-of-the-box with the installed firmware. We weren’t testing with a PortaPack, so we did some initial tests with the installed firmware and then replaced the firmware with a fresh build from our repository.

After confirming basic functionality, we executed a sweep to test the maximum output power across the entire 6 GHz frequency range. We did this by scripting a sequence of hackrf_transfer transmit commands while the device was connected to a spectrum analyzer. The results were troubling.

maximum output power vs. frequency

The clone clearly suffered from performance problems above 1 GHz, generally getting worse at higher frequencies. At 6 GHz, this culminated in a whopping 22 dB of loss compared to the GSG HackRF One. (That means that the GSG device produced more than 150 times the output power of the clone.)

It is important to realize that we tested just one sample clone, so our results may not be representative of the average performance of this model. On the other hand, although these results are compared to a single Great Scott Gadgets HackRF One, we know that every GSG HackRF One is factory-tested to ensure that it meets our performance standards.

Next we tested the receive performance by using QSpectrumAnalyzer with the hackrf_sweep backend. We set the gain to 40 in QSpectrumAnalyzer which results in moderate values for the two internal RX gain stages but leaves the RF amplifier off. We connected the device to a signal generator producing a -30 dBm signal, slowly swept across the 6 GHz frequency range.

received signal power vs. frequency

The receive results were even worse than the transmit results. While the transmit test indicated performance problems above 1 GHz, the receive test revealed problems across the entire frequency range. Above 5 GHz the received signal was buried in the noise floor, completely undetectable above 5.6 GHz by QSpectrumAnalyzer with these settings. Note that the RF amplifier was disabled in the receive test but had been enabled in the transmit test.

At this point we ran the clone through our factory test procedure which, in agreement with the previous results, indicated multiple failures at both high and low frequencies. This unit would not have passed our quality control.

We suspected that there may have been multiple reasons for these failures including problems with the design changes as well as manufacturing defects. We didn’t think it would be worth our time trying to isolate every problem, but we did want to explore the effect of the most interesting modification to the design, a protection circuit purported to reduce susceptibility to damage in the RF front end. The simplest way we thought of to test the performance impact of the modification was to remove it and retest the board without the protection circuit in place.

maximum output power (with and without protection circuit) vs. frequency

A repeat of the transmit test allowed us to see how the protection circuit affected signal power at various frequencies. As we suspected, a significant portion of the loss at higher frequencies was eliminated by removing the protection circuit. However, the average performance below 5 GHz was little changed, suggesting the presence of additional design or manufacturing flaws.

10 dB of loss at the high end of the frequency range seems to us like a steep price to pay for some protection. HackRF One is already weakest at 6 GHz. If it were that much weaker, I’m not sure we would be comfortable advertising 6 GHz capability.

We are interested in increasing the robustness of the HackRF front end, but any changes we make would need to maintain acceptable RF performance. Perhaps some performance loss in exchange for protection could be acceptable if the protection were proven by test results. We have not seen any test results for the effectiveness of the protection circuit on this HackRF clone, but it is clear from our tests that its effect on RF performance is not acceptable.

HackRF One has an RX input rating of -5dBm. To the best of our knowledge, it is not possible to damage the front end without exceeding this level. We are working on identifying reproducible scenarios that can cause damage to the RF front end so that we can set up reliable and repeatable tests for front end protection. This will enable us to test changes that might increase the RX input rating and reduce the chance of damage in the field.

We’re able to continue supporting and developing HackRF One and other tools thanks to the many people who choose to purchase genuine Great Scott Gadgets products. Every GSG HackRF One is tested for quality at the factory. We provide technical support for our products, and we accept returns of faulty units through our authorized resellers.

Hopefully some of the HackRF clones on the market perform better than the one we tested. The best way we know of to ensure delivery of a working HackRF is to buy it from one of our resellers. If you’ve bought hardware from us for this reason or just because you want to support our ongoing open source development, thank you very much!


subscribe to GSG feed