Great Scott Gadgets

open source tools for innovative people

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

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 and if you want to talk with other Amaranth users you can join the #amaranth-lang IRC channel on

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!

Shutting Down GSG Project-Specific Mailing Lists

Thank you to everyone who has been a part of the GSG project mailing lists. We at Great Scott Gadgets appreciate all of the conversations and friendships that have been forged on these lists. Over the last few years we have not given our project-specific mailing lists the attention they deserve; instead we have been focusing our efforts on Discord and GitHub. As such, we will be disabling all the mailing lists except for GSG-announce. Links to the mailing list archives for Ubertooth, YARD Stick One, GreatFET One, and HackRF will all remain available on their individual product pages. Current links to the archives are here:

We hope to see all of you on Discord and GitHub soon!

LUNA Delayed

LUNA is delayed. All of us at Great Scott Gadgets are sad to have to give this news, but the global chip shortage and supply chain chaos has impacted our LUNA manufacturing and delivery timeline more deeply than anticipated. Unfortunately, LUNA is now expected to start shipping December 2022 because the lead time for the ECP5 FPGA chip we use on LUNA doubled between July and September. There isn’t a suitable substitute component for the ECP5, so our timeline depends on Lattice’s production schedule for this chip. Please know that getting LUNA into your hands as soon as possible is our highest priority, and has been since before the Crowd Supply campaign was launched.

During our Crowd Supply campaign planning, we did a lot of prep work to make sure we had the most accurate estimate of LUNA time to delivery possible. Our planning involved getting seven quotes and lead times from four different contract manufacturers in the time leading up to the campaign. One of these manufacturers stood out to us and we have now requested quotes and lead times from them twice. We received the first quote from this manufacturer on July 10th, which was prior to the campaign, and the second on September 17th, which was just after we got the the funds from the campaign.

The July 10th quote indicated that the microcontroller (ATSAMD11) on LUNA would be the component with the longest lead time at approximately 52 weeks. This was unsatisfactory as we did not want to wait over a year to get LUNA to you. We started looking for substitutions and alternative component sourcing methods immediately. We found an alternative source for the ATSAMD11 very quickly but did not know how many to order since our crowdfunding campaign hadn’t ended and we didn’t yet have the funds to order components. The day the campaign ended we put our order in for the microcontroller. We are happy to say that we received these components at the end of September! Our next step is to ship these parts from our office to our manufacturer.

The component with the next longest lead time on the July 10th quote was the ECP5, which is the main FPGA on LUNA. Our manufacturer gave us a 30-week lead time on this component in that quote, which is what we based our LUNA timeline on. When we got the September 17th quote, the lead time jumped from 30 weeks to 60 weeks. The ECP5 is now the LUNA part with the longest lead time. Until recently, the longest we typically have had to wait on any one part for a Great Scott Gadgets product was 16-20 weeks so many of these lead times are outside of our usual expectations.

Since receiving the bad news about the ECP5 lead time, we have made efforts to reduce the time to delivery. First, we attempted to shorten the ECP5 lead time by contacting Lattice directly to see if they could work with our manufacturer to supply ECP5s for LUNA. This attempt led to a dead-end and did not improve our timeline. Next, we worked with our manufacturer to source the ECP5s from another parts distributor; we had some success there as the manufacturer was able to find another source of ECP5s with a 50-week lead time. We have asked them to put an order in for these ECP5s. At the same time we found another parts distributor that was able to sell us ECP5s quoted 36 weeks, and we ordered them immediately. The next day we received an email from the distributor of the second round of ECP5s we ordered and they updated their lead time from 36 weeks to “to be determined”. Neither of these ECP5 orders are cancellable so we’ve invested heavily in getting LUNA to you as soon as we can. We hope that one order or the other will come in sooner than the 50-week lead time. We will keep you updated!

While we are disappointed that we’ve had to revise our estimated ship date to account for the component delays caused by the global chip shortage, we do have some good news. The delay gives our small team even more time to hone the LUNA software and experience before getting it into your hands. We will use this time to collect and address more feedback from our beta testers, create extra demos and training material, and continually improve our documentation.

If you have any questions, thoughts, or suggestions please reach out to the Great Scott Gadgets team through GitHub or Discord at any time. We would especially welcome any leads about ECP5s!

Pmod Host Ports Added to Encased LUNAs

In one of our updates on CrowdSupply we asked you all for feedback about whether populating the optional Pmod host ports would be a welcome addition to LUNA, and whether they should be added to bare board LUNAs, encased LUNAs, or both. We got many comments through our Discord, direct messages, email, and GitHub. The feedback was overwhelmingly in favour of adding Pmod host ports to encased LUNAs only, so we are going ahead with that change!

LUNA General-Purpose Digital I/O

Our main goal in adding the Pmod host ports/footprints to LUNA was to add general-purpose digital I/O functionality to the board. This functionality can be used, probably most importantly, as trigger inputs or outputs that are synchronous with USB operations on LUNA or a device connected to LUNA. We’ve already used this I/O ourselves to test a circuit option that is now included in the latest LUNA design! Mike Walters has also used the Pmod host ports to stream data from a proprietary thermal camera interface.

Pmods and Pmod Host Ports

Pmod stands for “Peripheral Modules”. Pmods are external boards that can be plugged into Pmod host ports on a host board to add functionality to a microcontroller or, in LUNA’s case, an FPGA on that board.

“This functionality includes audio amplifiers, GPS receivers, USB to UART interface, seven-segment displays, accelerometers, H-bridges with input feedback, analog-to-digital converters, and much more” [1]. Pmod host ports are made of 6-pin sections where one pin is for power, another is for ground, and the last four provide digital I/O [2]. These 6-pin sections can be used for plugging in Pmods, or they can be used as needed for general-purpose digital I/O. Digilent has blog posts and videos that dive into Pmods a lot further if you want to learn more.

LUNA and Pmods

While LUNA’s Pmod host ports are intended to be compatible with Digilent’s specification for Pmods [2], we do not have plans to provide dedicated software support for any particular peripherals. Fortunately, the flexibility of the LUNA framework and nMigen enables you to write your own I/O functions for Pmods that you’d like to use with LUNA. Tom Keddie has already provided an example of this [3]. We suspect that the Pmod host ports will likely be most useful to USB device developers, testers, and security researchers.

Physical changes to LUNA and case

The only visible difference to encased LUNAs will be a 12-pin Pmod host port face on either end of the case. If removed from the case, each Pmod host port will extend 8mm out from either end of the previously encased LUNA. This will make previously encased LUNAs 16mm longer than bare board LUNAs that don’t have the Pmod host ports populated. The Pmod host ports will only extend 5mm above the board, which is not as high as the USB Type-A connector already present.

Pmod footprints will remain on bare board LUNAs so Pmod host ports can be soldered on later by those that wish to have them.






Second LUNA Enclosure Update

Enclosure Update

We have an update on the enclosures! We have received 10 enclosures from our manufacturer and we are impressed.

Luna in a case

A LUNA in a case measures 2 inches by 2.5 inches and weighs 103 g with the hardware and lightpipes installed. I’ve been carrying mine around constantly like a pet rock since it has such a comfortable weight. The case has held up really well, regardless of the wine, pesto, sesame oil, and other sauces I’ve gotten on it while cooking. The USB-C ports have a satisfying amount of hold which means that any cables won’t get knocked out easily.

Enclosure Modifications (?)

The members of the Great Scott Gadgets Discord did get a preview of the LUNA enclosure a couple weeks ago and have already given us some feedback, which we greatly appreciate. If you have any opinions on the suggestions made, or have suggestions of your own, we’d love to hear them. We make our devices for you all and this is your chance to bring up any enclosure design or usability concerns before we start production.

One enclosure design choice that is currently being debated is whether we should populate the Pmod connectors on LUNA, shown on the left edge of the enclosure in the picture below.

Luna in a case with a Pmod face showing

In the case, the Pmod connectors don’t change the form factor, but on the bareboard LUNA the Pmod connectors would extend 5 mm above the board (which is not as high as the USB Type-A connector), but they would each add 8 mm of length to the board.

Bare board LUNA with Pmods installed

Please let us know whether you would like to see LUNA come with Pmod headers pre-installed on both LUNA in a case and bareboard LUNA, one or the other, or neither by voting with emoji on the relevant question posted in the feedback channel in our Discord server.

Case Contest Winner

To wrap up this post on the LUNA case design, we are happy to congratulate Rémy on winning the case contest with their design. Rémy will receive the only LUNA case with his winning design etched in the case:

Winning LUNA case etching design Winning LUNA case etching design on case

AMA on CrowdSupply

On August 18th we held an “Ask Me Anything” session where anyone interested in LUNA could ask us questions in real time. The full transcript of this AMA is available to view in the #luna-ama channel in the CrowdSupply Discord server.

The History of LUNA

Starting Great Scott Gadgets

Ten years ago this summer I quit my day job at a radio research lab and made Great Scott Gadgets (GSG) my full-time job. I dedicated myself and the company to our mission: to put open source tools into the hands of innovative people. One of the first things I did at that time was to make a list of products I was interested in making. That list included “USB swiss army knife”. I didn’t know how to make such a thing at the time, but it was something I had in mind from the start. I soon started referring to the concept as “usbstar” in my private notes and envisioned that it would be shaped something like a three-pointed version of the Throwing Star LAN Tap. I wanted it to have three points with one USB port each for implementing Meddler-in-the-Middle (MitM) or active monitoring. One port would be connected to a target host, another to a target device, and the last to the monitor/control host.

2011 GSG product ideas

A year later I hired Dominic Spill. Around that time Travis Goodspeed released his Facedancer software along with hardware based on his GoodFET project. Facedancer was exciting because it allowed rapid development of USB devices in Python, making it highly useful for security testing of USB hosts.

In 2013, Travis, Dominic, and I had a chat in a pub where we discussed ideas for next-generation Facedancer hardware similar to the usbstar concept. We thought that we could make a microcontroller-based platform similar to GoodFET with two or three USB 2.0 ports that would be faster and more capable than the target USB port on Facedancer. In that conversation, one of us (Dominic, I think) first proposed the name “GreatFET” for a Great Scott Gadgets variant of GoodFET, although we imagined at that time that GreatFET and Facedancer would be two different hardware platforms.


After releasing HackRF One, we had expanded the usbstar idea into a greater vision that became Daisho. This project had an FPGA-based mainboard with pluggable modules, each for a different high speed communication technology: one for SuperSpeed USB 3.0, one for Gigabit Ethernet, and one for HDMI. It was a big project, but, thanks to some outside funding, we were able to hire help.


With Daisho we implemented SuperSpeed USB MitM capability, demonstrated by Jared Boone who designed both the mainboard and the USB module. It was only just working in time for the demonstration, but it was an effective proof-of-concept of FPGA-based USB MitM.

When our funding for Daisho ran out, however, we realized that we had created a good tool for our research but hadn’t created a viable product. We felt that Daisho was too big and expensive to have much hope of commercial success in our community. It was an overly ambitious project, but we learned a lot in the process.

One nice thing that came out of the project was the Daisho USB 3.0 device core developed by Marshall Hecht. This was the world’s first open source USB device core for FPGAs, and it has since been ported to other platforms and used in actual products.

Around the end of the Daisho project, Dominic visited the GSG lab in Colorado for some project planning. In a brainstorming session, he, Taylor Streetman, and I sketched out a usbstar design together: It had an FPGA in the middle, surrounded by three USB 2.0 PHY chips. The idea was to take what we had learned from Daisho but to scale its USB capabilities down to a single board that was simpler and more affordable.

We wanted to start working on it immediately, so I ordered an FPGA development kit to arrive during Dominic’s visit. By the time the kit arrived, however, we had talked ourselves out of the project!

One reason we didn’t pursue the usbstar concept at that time was that neither of us had very much FPGA experience. Without external funding to hire folks like those who had helped us with Daisho, we felt our progress would be slow. We also weren’t excited about building an open source product that relied on proprietary (and in some cases expensive) FPGA development tools. We liked the idea, but we prioritized GreatFET instead.


Another reason we abandoned usbstar was that we had expanded our vision for GreatFET. Instead of the minimal microcontroller I had used in my initial prototype, we chose the LPC43xx series that we had used in HackRF One. With this part we were able to place two USB interfaces on GreatFET One with potential for a third USB port on an add-on board (called “neighbors” in honor of Travis). By making GreatFET “greater” in this way, we tried to enable the most important capabilities of the usbstar concept without having to additionally pursue the FPGA-based project. While GoodFET and the original Facedancer hardware were two different platforms, GreatFET combined those functions into a single board.

While we were developing GreatFET, Dominic started collaborating with Kate Temkin on some USB projects. Kate single-handedly ported/rewrote Travis’s Facedancer software for GreatFET One and other platforms, and the two of them worked on GlitchKit and USBProxy. We hired her as a contractor to develop USB training courseware and GreatFET software, and she eventually joined us as a GSG employee.

Not long after joining the GSG team, Kate started developing Rhododendron, a GreatFET neighbor for High-speed USB analysis. Rhododendron was designed to be the simplest, lowest cost circuit for passive monitoring of High-speed USB. Kate and Mikaela Szekely demonstrated Rhododendron at Teardown 2019 along with ViewSB, their new USB analysis software.

LUNA Hardware

In the months following that demonstration, we worked toward manufacturing Rhododendron, but Kate started questioning whether or not it was really the best approach. Rhododendron was designed to be ultra-low-cost, but it additionally required purchase of a GreatFET One. She began thinking about making a much more sophisticated and capable tool in the same price range as the combined cost of GreatFET One and Rhododendron.

We didn’t see Kate at the lab for a couple weeks late in 2019, and then one day she appeared and announced that she had designed a new USB multitool. LUNA was born! She showed us the design, and I immediately recognized the FPGA-based usbstar concept that Dominic and I had sketched several years prior. Design work we thought would have taken us months Kate had accomplished in two weeks! Additionally she had included a fourth pass-through port for passive monitoring, making LUNA a hybrid of usbstar and Rhododendron.

One of the exciting aspects of Kate’s initial design was that LUNA was based on the ECP5 FPGA which had only recently become supported by an open source toolchain thanks to gatecat and other members of the open source FPGA community. We felt that, with the availability of open source tools, the time was finally right for GSG to make an FPGA-based design. The ECP5 was a perfect choice for LUNA as it has the performance necessary for multiple High-speed USB interfaces at a low cost.

Another thing that excited us about LUNA was Kate’s vision for gateware based on whitequark‘s nMigen, combining the flexibility and power of FPGAs with the rapid development of Python.

The Impact of COVID-19

Sadly, at about this same time the SARS-CoV-2 virus that causes COVID-19 first infected humans. We didn’t know about it until January of 2020 when it quickly became a major concern for us at GSG. We learned on the 24th of January that due to the lockdown in China we had lost access to a warehouse containing thousands of our products, the first of several pandemic-related supply chain problems that have affected us over the past year and a half.

Although we suffered a dramatic loss of revenue in the first quarter of 2020, we were able to continue paying our staff thanks to pandemic relief loans from the US government. Applying for loans was a stressful and lengthy process due to high demand and to the government and our bank having to rapidly develop new policies and procedures. We took on debt, some of which has been forgiven, but we felt that it was worth it to continue supporting our team of eight through the pandemic.

We began requiring remote work in early March. With everyone working at home and with supply chain issues limiting our hardware sales, we made LUNA development our top priority. We felt that investing in our team was the best use of pandemic relief funds and that LUNA was the best focus for the team’s efforts.

Team and Community Contributions

Kate focused on the all-important gateware and software development. She wrote code to quickly bring up her initial prototypes and validate basic functions, and she has since built the framework to support more advanced LUNA capabilities.

I took over as hardware designer after Kate’s r0.2 design. My work was made easier by the fact that Kate’s initial two designs were (incredibly!) fully functional almost without modification. Over the last year I still found enough things to refine that I ended up rerouting every trace on the PCB.

Mike Walters contributed to LUNA by developing hardware and gateware for Amalthea, an experimental Software-Defined Radio platform based on LUNA. This is important work because we see LUNA not just as a USB multitool but also as the basis for diverse future USB-connected GSG projects.

Mikaela worked on ViewSB and Facedancer software, providing the user-facing tools that will allow folks to do powerful things with LUNA.

Taylor focused on mechanical aspects of the design, such as creating a prototype enclosure. He also coordinated with contract manufacturers and component suppliers to ensure manufacturability at our target price.

Elizabeth Hendrex planned this Crowd Supply campaign while maintaining business operations and keeping everyone employed throughout the pandemic.

Straithe took the lead on technical support and documentation for all GSG products and projects, including LUNA. She also assumed responsibility for community communication such as these updates, Twitter, and Discord.

We engaged Timon Skerutsch to design the milled aluminum enclosure and help us with sourcing.

Meanwhile several members of our open source community contributed code to LUNA and related projects, and we launched this campaign as a way for the community to ensure that we will be able to put LUNA into the hands of innovative people. It has been wonderful to witness the team and the community come together to make LUNA a reality!

Thank You

With this campaign we’ve begun a new chapter in LUNA’s history. Kate and Mikaela have recently resigned from their roles at GSG and will no longer be a part of the project. We thank them for the outstanding work they’ve done to make LUNA what it is today, and we look forward to continuing our team effort to bring LUNA’s exciting capabilities to the community. Thank you all so much for your support. We couldn’t do this without you!

subscribe to GSG feed