Great Scott Gadgets

Open source hardware for innovative people.

Stay up to date with the latest information from Great Scott Gadgets by subscribing to the GSG-announce mailing list

Free Stuff, July and August 2019

Julio y August

This summer we heard from two biomedical engineers. Juan Ignacio Cerrudo es nuestro receptor de julio. Él es el Jefe de Trabajos Prácticos en Laboratorio de Prototipado Electrónico y 3D en la Universidad Nacional de Entre Ríos (Argentina). He plans to use his HackRF One to assess security in medical devices and in classes to introduce students to signal processing.

Roy Morris with Gift of Life International asked us for a HackRF One in August. Roy travels throughout the developing world helping children with congenital heart defects receive the medical care they need. He’s going to use the HackRF One to troubleshoot the aging telemetry systems that send medical data to patient monitors.

If you’d like to be considered to receive free hardware from Great Scott Gadgets, please visit the Free Stuff page and send us a message with lots of details about your project.

Free Stuff, May and June 2019


Chris Kemp asked us for some Throwing Star LAN Tap Kits in May. Chris teaches Forensics at Chavez High School in Stockton, California. He is using the kits in his introduction to digital forensics class, and because he’s such a nice guy, he shared his loot with the computer science department.


Brooklyn Research is an interdisciplinary creative space focused on technological innovation. They provide a platform for established artists, technologists, and researchers to foster engaging discourse and experimentation. One of their groups is going to use their new HackRF One to experiment with finding a way to translate satellite signals to G-Code for a printer which will deposit nutritional paste for a slime mold culture. That slime mold culture will be a pretty artifact/visualization of the satellite signal as it grows and expands based on where the nutrients have been deposited. The shape of the slime mold growth then may be used for experimenting with new antenna shapes.

Tools of the KNOB Attack

This week at USENIX three researchers published information about a new attack against classic Bluetooth. Known as KNOB, the attack takes advantage of a weakness in the Bluetooth specification to force target Bluetooth connections to use 8-bit encryption keys instead of larger keys that would be resilient against brute-force attack.

This weakness in classic Bluetooth (not Bluetooth Low Energy) is a big one. I don’t recall seeing such a significant vulnerability in Basic Rate Bluetooth security since pairing was improved with the introduction of Secure Simple Pairing in Core Specification v2.1 in 2007.

One of the things that intrigued me when I heard about the KNOB attack this week was that it sounded very familiar. After chatting with Dominic Spill, we’re pretty sure we discussed the potential for this attack about ten years ago. I’m fairly certain that I had highlighted Encryption Key Size Request in a printed copy of the specification around that time.

What we didn’t have back then was a way to test for this vulnerability. The specification allows for devices to reject key sizes they consider too small, and I guessed at the time that vendors would enforce a more reasonable minimum key size than the smallest (1 byte) allowed by the specification. As demonstrated this week by Daniele Antonioli, Nils Ole Tippenhauer, and Kasper B. Rasmussen, I was wrong!

In order to test this attack it is necessary to modify the behavior of the Link Manager, the part of a Bluetooth chip that creates logical links with other Bluetooth devices. The Link Manager Protocol (LMP) is the low layer protocol that Link Managers use to communicate with one another and negotiate things including encryption for protection of higher layer protocols. LMP messages are not visible over the Host Controller Interface (HCI) that carries information between a Bluetooth chip and an application processor. If you only have the ability to control a Bluetooth chip by modifying an Operating System driver, you can alter behavior at the HCI level but not the LMP level. Ten years ago I was working on creating tools for monitoring Bluetooth signals, and I used off-the-shelf Bluetooth adapters for security testing, but I didn’t have any tools capable of active attacks below the HCI layer.

Last year things changed when Dennis Mantz released InternalBlue along with his award winning master’s thesis. Dennis reverse engineered the firmware of a popular Bluetooth chip and with InternalBlue provided a method to alter the firmware, enabling modification of Link Manager behavior for the first time. Since then Dennis and Jiska Classen have published a series of papers and presentations demonstrating powerful uses of this important tool.

It was InternalBlue that enabled the KNOB researchers to test attacks against key size negotiation for the first time. They used InternalBlue to implement a man-in-the-middle attack that inserted requests for a key size of one byte and successfully demonstrated the attack against nearly every Bluetooth device they tested. This weakness existed in the Bluetooth specification for twelve years, but nobody had tools to test it. Once a tool became available, KNOB was discovered within a year.

Another tool used by the KNOB researchers was Ubertooth One, the open source Bluetooth monitoring platform I designed almost a decade ago. They used Ubertooth One to eavesdrop on encrypted packets in order to prove the weakness of the encryption after forcing a key size of one byte. They correctly point out in their paper that Ubertooth One lacks an effective ability to follow the hopping sequence of classic Bluetooth connections (it is better at this with Bluetooth Low Energy, thanks to Mike Ryan), but they worked around that problem by capturing a single packet and then iterating over all possible clock values to interpret the packet. This ingenuity allowed them to use the low cost Ubertooth One instead of a Bluetooth analyzer costing tens of thousands of dollars.

The KNOB researchers demonstrated that Wright’s Law still holds true after all these years:

“Security will not get better until tools for practical exploration of the attack surface are made available.” –Josh Wright

Reverse Engineering Black Box Systems with GreatFET, Troopers 2018

In this presentation at Troopers 2018, Kate Temkin and Dominic Spill used GreatFET One and the Facedancer software framework to demonstrate techniques for reverse engineering embedded USB hosts.

It is often fairly simple to set up an environment for reversing a USB device; you just plug it into a host that you control. Then you can manipulate software on the host to test or monitor USB communications between the host and device. Even if the host operating system doesn’t provide a way for you to monitor USB (hint: it probably does), you can run it inside a virtual machine that runs on top of Linux and use Linux’s usbmon capability.

But how do you sniff USB if the USB host is an embedded platform that you don’t control? What if it is a game console or a photocopier with software that you can’t run in a virtual machine? Kate and Dominic show how you can use GreatFET One and a laptop to proxy USB between a device and a host without controlling software on either the device or the host. With the USBProxy solution they implemented in Facedancer, it is possible not only to monitor USB communication but also to modify USB data in transit.

Additionally they demonstrate how the Facedancer software for GreatFET can be used to emulate a USB device, allowing them to reverse engineer “black box” USB hosts and test them for vulnerabilities.

download video
download slides

Making USB Accessible, Teardown 2019

On Sunday, Kate Temkin and Mikaela Szekely presented Making USB Accessible: Developing Ultra-low-cost, Open USB Tools at Teardown 2019 in Portland. In this well-received talk, they debuted ViewSB, a USB analyzer that supports various capture backends including GreatFET, OpenVizsla, and usbmon.

In the days leading up to the talk, Kate went on a tear, developing ViewSB to complement the hardware solutions for USB capture that she and Mikaela had been working on. I asked, “Why do we need ViewSB when we already have tools such as PulseView and Wireshark?”

Her answer was that the existing open source software tools for USB analysis don’t present data in a way that is useful enough for USB developers. I recalled my past confusion about USB nomenclature and how the most essential thing I learned from Kate’s training class at last year had been an understanding of the differences between USB packets, transactions, and transfers. Thinking back to the tools we used in that class, I realized that she was right that a new tool was needed. In fact, the limitations of the existing tools were probably largely responsible for my confusion!

As you can see in this video, ViewSB presents low level USB packet data in a visual format that groups packets together into transactions, something that I had previously seen only in software for proprietary USB analyzers. It makes USB much easier to understand. I wholeheartedly agree with Mikaela and Kate that their work makes USB accessible!

Code used in the presentation can be found in the usb-tools organization on GitHub.

download video
download slides

GreatFET on Hak5

I recently sat down with Darren Kitchen to record a couple Hak5 episodes. First we introduced GreatFET One to his viewers and demonstrated using its Facedancer capability to emulate a USB device. Then we did some infrared hacking with Gladiolus, a prototype GreatFET neighbor we plan to release later this year. Thanks for having me on the show, Darren!

Introducing the GreatFET One Hacking Infrared with Mike Ossmann and the GreatFET One

Free Stuff, April 2019

More students! The TARDIS Team from Sapienza University of Rome, Italy was selected for the REXUS/BEXUS program. The German Aerospace Center (DLR) and the Swedish National Space Agency (SNSA), in collaboration with the European Space Agency (ESA), jointly allow students from universities and higher education colleges across Europe to carry out scientific and technological experiments on research rockets and balloons.

Their experiment, named TARDIS (Tracking and Attitude Radio-based Determination in Stratosphere), will be launched on a balloon in October from Kiruna (Sweden), reaching 30 km of altitude. The experiment’s main objectives are to determine the position and the attitude of the balloon by digital processing of VOR navigation system signals.

And, yes, their acronym, TARDIS, may have influenced our choice this month!

Free Stuff, March 2019

More students got free stuff in March. The University of Split - Flow Design Team makes autonomous drones and will use their new HackRF One to improve their score in competitions. They will be competing in the AUVSI SUAS again this year. They won the Most Stubborn Team Award last year!

Free Stuff, February 2019

HHSec received an Ubertooth One as the Free Stuff recipients for February. They are a group of students from the Hague University of Applied Sciences and plan to use it in their IoT research. They look like an enterprising team and we are happy to encourage them.

Free Stuff, January 2019

January was a strange month for the freestuff mailbox. We had some pranksters and people who never replied, so we didn’t send anything. Instead, we are going to reopen January for submissions. Starting… now!

If you’d like to be considered to receive free hardware from Great Scott Gadgets, please visit the Free Stuff page and send us a message with lots of details about your project. We have a GreatFET One just dying to escape the lab!

Free Stuff, December 2018

In December, we sent a HackRF One to Jærgruppen av NRRL Norsk Radio Relae Liga, an amateur radio group in southwest Norway. They run radio courses every year and work with their local scouting groups. They hope to use their new HackRF in this year’s JOTA (Jamboree on the Air).

GreatFET One Has Arrived

It’s happenning! We started shipping GreatFET One to resellers last week, which means that very soon (probably even today) it will be available for you to order online from your favorite reseller of Great Scott Gadgets products. Hint: if your shop of choice doesn’t carry it yet, let them know you’re interested!

It was January of 2016 when Mike Ossmann gave his firetalk at Shmoocon titled GreatFET: A Preview, in which he explained how he bought the GoodFET project from Travis Goodspeed in a Las Vegas bar for $5. That was the beginning of the project that came to be known (humorously, at first) as GreatFET. At that time, GreatFET One was known as Azalea, and was still in the development stage. Three years and countless hours of engineering, development, and manufacturing effort later, we have completed the first production run.


GreatFET One is a general purpose (and like all of our tools, open source) USB peripheral. When we say it’s general purpose, we mean that there are a whole lot of interesting things a hardware hacker, or maker, or tinkerer can customize it to do, especially through the addition of add-on boards called neighbors. But you don’t need to add anything on to start using this versatile this tool; there is plenty of USB hackery to be accomplished with GreatFET One on its own. Check out what Kate Temkin has been up to over the last year or so!

Very soon, we will also start offering a clear acrylic case and a solderless breadboard neighbor. To learn more about the GreatFET project and to see which resellers are already stocking GreatFET One, visit the GreatFET One product page.

Goodbye, Dominic

Just over ten years ago I sent my first email to Dominic Spill:

“We haven’t met, Dominic, but I hope you don’t mind being included on this message. I thought you two might be interested in some work I finally got around to writing up…”

I had been exploring the use of software-defined radio for Bluetooth monitoring and had found Dominic’s paper on the subject. He and I quickly began collaborating on the development of tools and techniques that improved upon the methods in his paper. Just three months later, we presented Building an All-Channel Bluetooth Monitor at ShmooCon 2009.

We met in person for the first time the day before our talk at ShmooCon, and we have been friends and research partners ever since.

Over the next two years I learned electronics and designed Ubertooth One, a low cost test tool that implemented some of the techniques Dominic and I had developed. Ultimately this me led to create Great Scott Gadgets as a way to put such tools into the hands of innovative people around the world.

When Great Scott Gadgets began to become too much work for me alone, Dominic was the first person I turned to for help. He took over development and support for the Ubertooth project as a remote contractor while I turned my attention to developing new tools and growing the company.

Eventually Dominic moved to the United States and joined the GSG team in Colorado as a full-time employee. He played a key role in research and development, provided technical support for our resellers and end users, led our software development efforts, mentored interns, kept our internal IT systems up and running, and even cleaned the refrigerator. His humor, creativity, and patience have been felt by every member of the team.

For ten years Dominic and I have continued collaborating on research and developing new tools. I’ve lost count of the number of conference presentations we’ve given together and of how many times one of us has turned to the other and said, “Here’s a crazy idea…”

Yesterday was Dominic’s last day at Great Scott Gadgets. Having decided that he needed a change, he will pursue new adventures.

We will miss Dominic greatly. He will always be a part of the GSG family.

Free Stuff, October 2018

The Free Stuff recipient for October is the Wave Farm. Wave Farm is a non-profit arts organization driven by experimentation with broadcast media and the airwaves. Wave Farm programs provide access to transmission technologies and support artists and organizations that engage with media as an art form. The Wave Farm Artist Residency Program is located on 29 bucolic acres in New York’s Upper Hudson Valley and supports new transmission art work by visiting artists from around the globe. Wave Farm’s WGXC 90.7-FM is a full-power non-commercial FM radio station committed to radio as a platform for community engagement and artistic experimentation. They do some really interesting stuff - their pond has its own station! Check them out!

Free Stuff, September 2018

Bridgewire Makerspace in Sparks, Nevada asked for a HackRF One to use in the Hamshack/wireless research station they are putting together in their electronics shop. Their space is open around the clock for members to create, learn and share. They are a member-funded and -run 501c3 organization that provides a space for working on projects and sharing ideas and knowledge. Check out their website here:

If you’d like to submit your project idea for consideration to receive free hardware from Great Scott Gadgets, please visit the Free Stuff page and send us a message!

Free Stuff, August 2018

Matthias Carneiro is a PhD student in Montpellier, France. He asked for a HackRF One to use in his research on SDR implementation in nanosatellite constellations. When he completes his PhD, he is going to donate the HackRF One to the university for the use of other students.

Crème Brûlée Camp

We decided to go big at Toorcamp this year and make a jar of crème brûlée for every single person that attended. Delicious? Yes. Too ambitious? Maybe. Open source? You got it.

Image via Patch Eudor

Harnessing the power of GreatFET, we were able to connect a temperature sensor, LCD screen, and some bucket heaters, and cook up a very large amount of crème brûlée inside an average sized cooler while at camp, and it worked… but there were some rough spots. The problem wasn’t necessarily in the cooking process, but in the preparation stage: the cooler was able to fit 120 4oz jars in it for a batch, so someone needs to be cracking 120 eggs and separating the yolks, someone needs to be washing/drying 120 jars and lids from the factory, someone needs to mix the egg yolks, cream, vanilla, and sugar into a huge jug, someone needs to pour the right amount of mix into 120 jars, and someone needs to tighten 120 jar lids to the correct tightness, all while 10 gallons of water heats up in a cooler. Once all this is done, the batch can be placed into the cooking cooler for about seventy-five minutes. Finally, jars can be pulled from the cooking cooler to be sugared and brûlée’d by a person with a blow torch one at a time. Repeat.

As you can imagine, this takes a considerable amount of time and effort for just one batch of 120 jars. Not only that, but there unsurprisingly was not a 100% success rate, as some lids were not tight enough before being cooked and jars were cracked during the blowtorch brûlée phase. Doing this back to back for a few days was a ton of work. We were able to make 695 crème brûlées in one weekend, and everyone that wanted one got at least one! But for anyone thinking about trying this, be prepared to get your hands dirty.

If you want to learn about the R&D process you can check out the talk we gave at Toorcamp or if you’re interested in the source code and set-up, check it out on GitHub.

Comments on the Recent USTR Tariff Action

In September I made the following public comment on the Office of United States Trade Representative’s (USTR) Proposed Modification of Action Pursuant to Section 301: China’s Acts, Policies, and Practices Related to Technology Transfer, Intellectual Property, and Innovation.

Thank you for requesting comments on the proposed supplemental action in response to China’s Acts, Policies, and Practices Related to Technology Transfer, Intellectual Property, and Innovation (USTR-2018-0026).

As the founder and owner of Great Scott Gadgets, a Colorado small business that puts open source tools into the hands of innovative people, I urge you to refrain entirely from imposing any new duty increases. Additionally I urge you to eliminate all recent increases made as a part of this action.

Due to the inclusion of multiple tariff subheadings in the proposal, I anticipate that Great Scott Gadgets will suffer a significant increase in the cost of products we sell. Ultimately the technological innovators who are the end users of our products will bear this increase. Instead of punishing China, the increased duties will harm American innovators who rely on tools such as ours. Innovators in China and elsewhere around the world will gain an advantage over Americans as a result of the action.

Great Scott Gadgets designs and manufactures open source hardware (OSHW). The OSHW community includes a rapidly growing group of companies committed to the ideals that end users have a right to fully control their own equipment and that anyone should be able to study, make, use, modify, and sell devices based on our published designs. OSHW makers recognize that, just as open source software has resulted in great advances in the software industry, open source hardware will enable future generations of hardware innovation.

The growth of Great Scott Gadgets and other open source hardware and software companies demonstrates that protection of intellectual property is unnecessary for commercial success in technological markets. This undermines the USTR’s argument that “China’s acts, policies, and practices that effectuate technology transfer burden and restrict U.S. commerce.”

I maintain that open source technology greatly enhances innovation and that the best way to foster rapid development of new technology is to encourage both the free exchange of ideas and free trade of tools, materials, and all goods.

In my opinion, the proposed supplemental action will have little effect on China’s acts, policies, or practices but will disproportionately harm Great Scott Gadgets, our employees, our American resellers, and the American innovators who depend on our tools.

Free Stuff, June and July 2018


El destinario de Cosas Gratis para junio es Gabriel Martín Miguel de Salamanca, España. Él quiere hacer una plataforma de radio asequible a los nuevos radioaficionados para acercarles las nuevas formas de hacer radio. Él tiene un grupo de Facebook sobre SDR para usuarios, programadores y radioficionados en español, tanto en España como en latinoamerica, aqui:


CTRL-H Hackerspace of Portland, Oregon asked us for a HackRF One. They plan to use it for SDR workshops and their Electronics Lab Radio Closet, where they'll be capturing and hosting as much data as possible through SDR. It looks like they have made some fabulous spaces for creating, learning and hanging — check them out here:

If you'd like to submit your project idea for consideration to receive free hardware from Great Scott Gadgets, please visit the Free Stuff page and send us a message!

Free Stuff, May 2018

We sent Oleksandr Tytko a HackRF One. He is studying at Lyceum No 1, Chernivtsi, Ukraine. He and his classmates plan to use the HackRF One to learn about SDR and to write and test their own code. He is also very enthusiastic about starting an open source project studying the influence of radio frequencies on plants and people. He sent us a picture of the greenhouse in his local Botanic Garden where he plans to do the research:

Dan Groeneveld is an instructor at Northland Pioneer College in Show Low, Arizona. He is going to be teaching net security and pentesting courses this autumn, so we sent him some Throwing Star LAN Tap Kits. He is looking forward to teaching his students LAN Tap principles and soldering basics. We can't wait to see pictures of them in their lab.

If you'd like to submit your project idea for consideration to receive free hardware from Great Scott Gadgets, please visit the Free Stuff page and send us a message!

Free Stuff, April 2018

April's Free Stuff recipient is EFF (The Electronic Frontier Foundation). EFF is a nonprofit organization that defends civil liberties in the digital world. From their website: Founded in 1990, EFF champions user privacy, free expression, and innovation through impact litigation, policy analysis, grassroots activism, and technology development. We work to ensure that rights and freedoms are enhanced and protected as our use of technology grows.

Andrés Arrieta, Technology Projects Manager, has asked for a HackRF One because: At EFF we are looking how technologies impact our rights in our daily lives. Research has already shown many vulnerabilities in the standards in implementation of mobile communications and we want to continue research in this space. Understanding how 2G-4G have really been implemented not only by Telcos but also in Baseband and how users' privacy is impacted by this. Beyond that we'd like to explore the possibilities of offering more secure communications to users and the different ways this could happen.

If you'd like to submit your project idea for consideration to receive free hardware from Great Scott Gadgets, please visit the Free Stuff page and send us a message!

Free Stuff, March 2018

The Free Stuff recipient for March is Jan van Katwijk, a hobby programmer from the Netherlands. He plans to use his new HackRF One to finish his work on DAB software by providing a library for HackRF, then for experimenting with wideband receiving issues. His current developments include software support for ACARS and ADS-B decoding.sdfsdfdsf A full overview of his work is available here and here.

If you'd like to submit your project idea for consideration to receive free hardware from Great Scott Gadgets, please visit the Free Stuff page and send us a message!

Free Stuff, January and February 2018

Drumroll, please! The free stuff recipients for January and February were:

Rushabh Vyas, who is a graduate student at the Purdue School of Engineering and Technology, IUPUI, is receiving four LAN Tap Throwing Star kits for use in his digital escape room projects and in his cybersecurity group, TheDen.

His current forensics class is using a bomb-defusal scenario. He reports: “End goal for the forensics students is to be able to get access to Arduino code (by completing various forensics tasks such as steganalysis, data decoding, and artifact analysis), analyze the code, and be able to cut the correct colored wire for defusal in ~60 minutes.”

Check out Rushabh’s links here:

We sent a HackRF One to the University of Toronto Aerospace Team, Space Systems Division. They are a team of 40 undergraduates who are working on an open source CubeSat for carrying out microbiology experiments in space! Their first satellite, HeronMk II, is slated to launch in early 2020.

One of their team leads, Siddarth Mahendraker, tells us:

“We plan to use the HackRF to build a programmatic interface to our radio communications system, in conjunction with GNURadio. This will make it significantly easier for us to test our on-board computer systems, downlink payload data, and integrate and test additional satellite subsystems”

HERON Mk II is a 3U Cubesat designed and built by the Space Systems division of the University of Toronto Aerospace Team to perform sophisticated microbiology experiments in orbit. The organism of interest is C. Albicans, a yeast that is commonly found in the human gut flora that may undergo changes in its virulence and drug resistance when experiencing microgravity.

Here is their website:

We also gave away two HackRF Ones in February:

One went to Brian Granby, a PhD student at Liverpool John Moores University. He is doing security research, conducting a study into emerging sensors technologies; with a particular focus surrounding network security of RF connected devices. His main focus is on the potential threats of residential and commercial gas supplier technologies found in smart meters.

The other we are sending to Sudip Kar of Bangalore. He is going to use his HackRF One to introduce SDR to small village schools by helping them to set up their own weather stations that can track NOAA satellites. He is going to send us pictures after the students finish their year-end exams and start using the HackRF later this spring.

2017 Free Stuff Update

In 2017, we read a whole bunch of requests for free stuff, and we were really impressed with the many excellent submissions we received. Since our last free stuff update, we have given away 16 HackRFs and several Throwing Star LAN Tap Kits to researchers, makerspaces, amateur radio groups, and educators. The 2017 free stuff receipients included:

  • Dr. Fernando Pena Campos — HackRF One for wireless communications education at the university undergraduate level
  • New Hampshire Hacker's Association (NEHA) meetup — HackRF One for SDR workshops
  • Reforge Charleston — Throwing Star LAN Tap Kits and a HackRF One for an education based non-profit makerspace
  • Cal Poly Amateur Radio Club — HackRF One (with a Clear Acrylic Case) for the equipment shack (special thanks for the T-shirts!)
  • University of Michigan Rocketry Team — HackRF One (and a Clear Acrylic Case) to help with the development and prototyping of a "from scratch" GPS receiver and other avionics systems
  • Fred Pelland — HackRF for an amateur radio group
  • Sebastien Mrozek, teacher at Elsa-Brändström-Schule, a secondary school in Elmshorn, Germany — HackRF One for the school's electronics lab
  • Juan Moreno, professor at Universidad Politecnica de Madrid — HackRF One to help develop an SDR focused Massive Open Online Course (coming soon:
  • Marco Manzoni/Skyward Environmental Rocketry — HackRF One for use in the development of the RF system of a student-made rocket
  • Make Riga Hackerspace — HackRF one to help this hackerspace's members accomplish interesting projects, like "aiming to reach 100km with a large model rocket + balloon (thus their own gps solution), and another member is rolling out his own gsm stack"
  • Bill — HackRF One for an SDR workshop given at the New Mexico Hamfest
  • Carlos Yero for Abertay University Ethical Hacking Society — HackRF One "to be available to all students working on the Ethical Hacking degree with aim to overcome fear of SDR complexities"
  • Fellow open source hardware designer Manuel Domke of — HackRF to use as a spectrum analyzer for EMC product compliance testing

Sometimes, free stuff recipients send us pictures, like this one from Elsa-Brändström-Schule in Germany (we love it when free stuff receipients send us pictures; it increases the general level of warm fuzzies):

We'll be doing more free stuff updates shortly, so check back soon! Also, please keep the free stuff requests coming. For information about how to request free Great Scott Gadgets hardware, please visit the Free Stuff page.

We Fixed the Glitch

Around the first of the year our contract manufacturer contacted us about an urgent problem with HackRF One production. They'd had to stop production because units coming off the line were failing at a high rate. This was quite a surprise because HackRF One is a mature product that has been manufactured regularly for a few years. I continued to find surprises as I went through the process of troubleshooting the problem, and I thought it made a fascinating tale that would be worth sharing.

The reported failure was an inability to write firmware to the flash memory on the board. Our attention quickly turned to the flash chip itself because it was the one thing that had changed since the previous production. The original flash chip in the design had been discontinued, so we had selected a replacement from the same manufacturer. Although we had been careful to test the new chip prior to production, it seemed that somehow the change had resulted in a high failure rate.

Had we overlooked a failure mode because we had tested too small a quantity of the new flash chips? Had the sample parts we tested been different than the parts used in the production? We quickly ordered parts from multiple sources and had our contract manufacturer send us some of their parts and new boards for testing. We began testing parts as soon as they arrived at our lab, but even after days of testing samples from various sources we were unable to reproduce the failures reported by the contract manufacturer.

At one point I thought I managed to reproduce the failure on one of the new boards, but it only happened about 3% of the time. This failure happened regardless of which flash chip was used, and it was easy to work around by retrying. If it happened on the production line it probably wouldn't even be noticed because it was indistinguishable from a simple user error such as a poor cable connection or a missed button press. Eventually I determined that this low probability failure mode was something that affected older boards as well. It is something we might be able to fix, but it is a low priority. It certainly wasn't the same failure mode that had stopped production.

It seemed that the new flash chip caused no problems, but then what could be causing the failures at the factory? We had them ship us more sample boards, specifically requesting boards that had exhibited failures. They had intended to send us those in the first shipment but accidentally left them out of the package. Because the flash chip was so strongly suspected at the time, we'd all thought that we'd be able to reproduce the failure with one or more of the many chips in that package anyway. One thing that had made it difficult for them to know which boards to ship was that any board that passed testing once would never fail again. For this reason they had deemed it more important to send us fresh, untested boards than boards that had failed and later passed.

When the second batch of boards from the contract manufacturer arrived, we immediately started testing them. We weren't able to reproduce the failure on the first board in the shipment. We weren't able to reproduce the failure on the second board either! Fortunately the next three boards exhibited the failure, and we were finally able to observe the problem in our lab. I isolated the failure to something that happened before the actual programming of the flash, so I was able to develop a test procedure that left the flash empty, avoiding the scenario in which a board that passed once would never fail again. Even after being able to reliably reproduce the failure, it took several days of troubleshooting to fully understand the problem. It was a frustrating process at the time, but the root cause turned out to be quite an interesting bug.

Although the initial symptom was a failure to program flash, the means of programming flash on a new board is actually a multi-step process. First the HackRF One is booted in Device Firmware Upgrade (DFU) mode. This is done by holding down the DFU button while powering on or resetting the board. In DFU mode, the HackRF's microcontroller executes a DFU bootloader function stored in ROM. The host computer speaks to the bootloader over USB and loads HackRF firmware into RAM. Then the bootloader executes this firmware which appears as a new USB device to the host. Finally the host uses a function of the firmware running in RAM to load another version of the firmware over USB and onto the flash chip.

I found that the failure happened at the step in which the DFU bootloader launches our firmware from RAM. The load of firmware over USB into RAM appeared to work, but then the DFU bootloader dropped off the bus and the USB host was unable to re-enumerate the device. I probed the board with a voltmeter and oscilloscope, but nearly everything looked as expected. There was a fairly significant voltage glitch on the microcontroller's power supply (VCC), but a probe of a known good board from a previous production revealed a similar glitch. I made a note of it as something to investigate in the future, but it didn't seem to be anything new.

I connected a Black Magic Probe and investigated the state of the microcontroller before and after the failure. Before the failure, the program counter pointed to the ROM region that contains the DFU bootloader. After the failure, the program counter still pointed to the ROM region, suggesting that control may never have passed to the HackRF firmware. I inspected RAM after the failure and found that our firmware was in the correct place but that the first 16 bytes had been replaced by 0xff. It made sense that the bootloader would not attempt to execute our code because it is supposed to perform an integrity check over the first few bytes. Since those bytes were corrupted, the bootloader should have refused to jump to our code.

I monitored the USB communication to see if the firmware image was corrupted before being delivered to the bootloader, but the first 16 bytes were correct in transit. Nothing looked out of the ordinary on USB except that there was no indication that the HackRF firmware had started up. After the bootloader accepted the firmware image, it dropped off the bus, and then the bus was silent.

As my testing progressed, I began to notice a curious thing, and our contract manufacturer reported the very same observation: The RF LED on the board sometimes was dimly illuminated in DFU mode and sometimes was completely off. Whenever it was off, the failure would occur; whenever it was dimly on, the board would pass testing. This inconsistency in the state of the RF LED is something that we had observed for years. I had never given it much thought but assumed it may have been caused by some known bugs in reset functions of the microcontroller. Suddenly this behavior was very interesting because it was strongly correlated with the new failure! What causes the RF LED to sometimes be dimly on at boot time? What causes the new failure? Could they be caused by the same thing?

I took a look at the schematic which reminded me that the RF LED is not connected to a General-Purpose Input/Output (GPIO) pin of the microcontroller. Instead it directly indicates the state of the power supply (VAA) for the RF section of the board. When VAA is low (below about 1.5 Volts), the RF LED is off. When VAA is at or near 3.3 Volts (the same voltage as VCC), the RF LED should be fully on. If the RF LED is dimly on, VAA must be at approximately 2 Volts, the forward voltage of the LED. This isn't enough voltage to power the chips in the RF section, but it is enough to dimly illuminate the LED.

VAA is derived from VCC but is controlled by a MOSFET which switches VAA on and off. At boot time, the MOSFET should be switched off, but somehow some current can leak into VAA. I wasn't sure if this leakage was due to the state of the GPIO signal that controls the MOSFET (!VAA_ENABLE) or if it could be from one of several digital control signals that extend from the VCC power domain into the VAA power domain. I probed all of those signals on both a good board and a failing board but didn't find any significant differences. It wasn't clear why VAA was sometimes partially charged at start-up, and I couldn't find any indication of what might be different between a good board and a bad board.

One thing that was clear was that the RF LED was always dimly illuminated immediately after a failure. If I reset a board into DFU mode using the reset button after a failure, the RF LED would remain dimly lit, and the failure would be avoided on the second attempt. If I reset a board into DFU mode by removing and restoring power instead of using the reset button, the RF LED state became unpredictable. The procedural workaround of retrying with the reset button would have been sufficient to proceed with manufacturing except that we were nervous about shipping boards that would give end users trouble if they need to recover from a load of faulty firmware. It might be a support nightmare to have units in the field that do not provide a reliable means of restoring firmware. We certainly wanted to at least understand the root cause of the problem before agreeing to ship units that would require users to follow a procedural workaround.

Meanwhile I had removed a large number of components from one of the failing boards. I had started this process after determining that the flash chip was not causing the problem. In order to prove this without a doubt, I entirely removed the flash chip from a failing board and was still able to reproduce the failure. I had continued removing components that seemed unrelated to the failure just to prove to myself that they were not involved. When investigating the correlation with VAA, I tried removing the MOSFET (Q3) and found that the failure did not occur when Q3 was absent! I also found that removal of the ferrite filter (FB2) on VAA or the capacitor (C105) would prevent the failure. Whenever any of these three components was removed, the failure could be avoided. I tried cutting the trace (P36) that connects the VAA MOSFET and filter to the rest of VAA. Even without any connection to the load, I could prevent the failure by removing any of those three components and induce the failure by restoring all three. Perhaps the charging of VAA was not only correlated with the failure but was somehow the cause of the failure!

This prompted me to spend some time investigating VAA, VCC, and !VAA_ENABLE more thoroughly. I wanted to fully understand why VAA was sometimes partially charged and why the failure only happened when it was uncharged. I used an oscilloscope to probe all three signals simultaneously, and I tried triggering on changes to any of the three. Before long I found that triggering on !VAA_ENABLE was most fruitful. It turned out that !VAA_ENABLE was being pulled low very briefly at the approximate time of the failure. This signal was meant to remain high until the HackRF firmware pulls it low to switch on VAA. Why was the DFU bootloader toggling this pin before executing our firmware?

Had something changed in the DFU bootloader ROM? I used the Black Magic Probe to dump the ROM from one of the new microcontrollers, but it was the same as the ROM on older ones. I even swapped the microcontrollers of a good board and a bad board; the bad board continued to fail even with a known good microcontroller, and the good board never exhibited a problem with the new microcontroller installed. I investigated the behavior of !VAA_ENABLE on a good board and found that a similar glitch happened prior to the point in time at which the HackRF firmware pulls it low. I didn't understand what was different between a good board and a bad board, but it seemed that this behavior of !VAA_ENABLE was somehow responsible for the failure.

The transient change in !VAA_ENABLE caused a small rise in VAA and a brief, very small dip in VCC. It didn't look like this dip would be enough to cause a problem on the microcontroller, but, on the assumption that it might, I experimented with ways to avoid affecting VCC as much. I found that a reliable hardware workaround was to install a 1 kΩ resistor between VAA and VCC. This caused VAA to always be partially charged prior to !VAA_ENABLE being toggled, and it prevented the failure. It wasn't a very attractive workaround because there isn't a good place to install the resistor without changing the layout of the board, but we were able to confirm that it was effective on all boards that suffered from the failure.

Trying to determine why the DFU bootloader might toggle !VAA_ENABLE, I looked at the documented functions available on the microcontroller's pin that is used for that signal. Its default function is GPIO, but it has a secondary function as a part of an external memory interface. Was it possible that the DFU bootloader was activating the external memory interface when writing the firmware to internal RAM? Had I made a terrible error when I selected that pin years ago, unaware of this bootloader behavior?

Unfortunately the DFU bootloader is a ROM function provided by the microcontroller vendor, so we don't have source code for it. I did some cursory reverse engineering of the ROM but couldn't find any indication that it possesses the capability of activating the external memory interface. I tried using the Black Magic Probe to single step through instructions, but it wasn't fast enough to avoid USB timeouts while single stepping. I set a watchpoint on a register that should be set when powering up the external memory interface, but it never seemed to happen. Then I tried setting a watchpoint on the register that sets the pin function, and suddenly something very surprising was revealed to me. The first time the pin function was set was in my own code executing from RAM. The bootloader was actually executing my firmware even when the failure occurred!

After a brief moment of disbelief I realized what was going on. The reason I had thought that my firmware never ran was that the program counter pointed to ROM both before and after the failure, but that wasn't because my code never executed. A ROM function was running after the failure because the microcontroller was being reset during the failure. The failure was occurring during execution of my own code and was likely something I could fix in software! Part of the reason I had misinterpreted this behavior was that I had been thinking about the bootloader as "the DFU bootloader", but it is actually a unified bootloader that supports several different boot methods. Even when booting to flash memory, the default boot option for HackRF One, the first code executed by the microcontroller is the bootloader in ROM which later passes control to the firmware in flash. You don't hold down the DFU button to cause the bootloader to execute, you hold down the button to instruct the bootloader to load code from USB DFU instead of flash.

Suddenly I understood that the memory corruption was something that happened as an effect of the failure; it wasn't part of the cause. I also understood why the failure did not seem to occur after a board passed testing once. During the test, firmware is written to flash. If the failure occurs at any time thereafter, the microcontroller resets and boots from flash, behaving similarly to how it would behave if it had correctly executed code that had been loaded via USB into RAM. The reason the board was stuck in a ROM function after a failure on a board with empty flash was simply that the bootloader was unable to detect valid firmware in flash after reset.

It seemed clear that the microcontroller must be experiencing a reset due to a voltage glitch on VCC, but the glitch that I had observed on failing boards seemed too small to have caused a reset. When I realized this, I took some more measurements of VCC and zoomed out to a wider view on the oscilloscope. There was a second glitch! The second glitch in VCC was much bigger than the first. It was also caused by !VAA_ENABLE being pulled low, but this time it was held low long enough to have a much larger effect on VCC. In fact, this was the same glitch that I had previously observed on known good boards. I then determined that the first glitch was caused by a minor bug in the way our firmware configured the GPIO pin. The second glitch was caused by the deliberate activation of !VAA_ENABLE.

When a good board starts up, it pulls !VAA_ENABLE low to activate the MOSFET that switches on VAA. At this time, quite a bit of current gets dumped into the capacitor (C105) in a short amount of time. This is a perfect recipe for causing a brief drop in VCC. I knew about this potential problem when I designed the circuit, but I guess I didn't carefully measure it at the time. It never seemed to cause a problem on my prototypes.

When a bad board starts up, the exact same thing happens except the voltage drop of VCC is just a little bit deeper. This causes a microcontroller reset, resulting in !VAA_ENABLE being pulled high again. During this brief glitch VAA becomes partially charged, which is why the RF LED is dimly lit after a failure. If VAA is partially charged before !VAA_ENABLE is pulled low, less current is required to fully charge it, so the voltage glitch on VCC isn't deep enough to cause a reset.

At this point I figured out that the reason the state of the RF LED is unpredictable after power is applied is that it depends on how long power has been removed from the board. If you unplug a board with VAA at least partially charged but then plug it back in within two seconds, VAA will still be partially charged. If you leave it disconnected from power for at least five seconds, VAA will be thoroughly discharged and the RF LED will be off after plugging it back in.

This sort of voltage glitch is something hardware hackers introduce at times as a fault injection attack to cause microcontrollers to misbehave in useful ways. In this case, my microcontroller was glitching itself, which was not a good thing! Fortunately I was able to fix the problem by rapidly toggling !VAA_ENABLE many times, causing VAA to charge more slowly and avoiding the VCC glitch.

I'm still not entirely sure why boards from the new production seem to be more sensitive to this failure than older boards, but I have a guess. My guess is that a certain percentage of units have always suffered from this problem but that they have gone undetected. The people programming the boards in previous productions may have figured out on their own that they could save time by using the reset button instead of unplugging a board and plugging it back in to try again. If they did so, they would have had a very high success rate on second attempts even when programming failed the first time. If a new employee or two were doing the programming this time, they may have followed their instructions more carefully, removing failing boards from power before re-testing them.

Even if my guess is wrong, it seems that my design was always very close to having this problem. Known good boards suffered from less of a glitch, but they still experienced a glitch that was close to the threshold that would cause a reset. It is entirely possible that subtle changes in the characteristics of capacitors or other components on the board could cause this glitch to be greater or smaller from one batch to the next.

Once a HackRF One has had its flash programmed, the problem is very likely to go undetected forever. It turns out that this glitch can happen even when a board is booted from flash, not just when starting it up in DFU mode. When starting from flash, however, a glitch-induced reset results in another boot from flash, this time with VAA charged up a little bit more. After one or two resets that happen in the blink of an eye, it starts up normally without a glitch. Unless you know what to look for, it is quite unlikely that you would ever detect the fault.

Because of this and the fact that we didn't have a way to distinguish between firmware running from flash and RAM, the failure was difficult for us to reproduce and observe reliably before we understood it. Another thing that complicated troubleshooting was that I was very focused on looking for something that had changed since the previous production. It turned out that the voltage glitch was only subtly worse than it was on the older boards I tested, so I overlooked it as a possible cause. I don't know that it was necessarily wrong to have this focus, but I might have found the root cause faster had I concentrated more on understanding the problem and less on trying to find things that had changed.

In the end I found that it was my own hardware design that caused the problem. It was another example of something Jared Boone often says. I call it ShareBrained's Razor: "If your project is broken, it is probably your fault.". It isn't your compiler or your components or your tools; it is something you did yourself.

Thank you to everyone who helped with this troubleshooting process, especially the entire GSG team, Etonnet, and Kate Temkin. Also thank you to the pioneers of antibiotics without which I would have had a significantly more difficult recovery from the bronchitis that afflicted me during this effort!

GSG Interns

Please welcome the Great Scott Gadgets summer interns, Ellie Puls and Jacob Graves. They joined us at the beginning of June, and we are thrilled to have both of these bright students on our team. Ellie is a junior at CU Boulder and Jacob is a senior at CU Denver, and they are both majoring in Computer Science. They plan to write a short blog post every couple of weeks over the summer to let you know what they've been learning and what kind of projects they've been working on. Here's what they've been up to in their first couple of weeks:

"We helped finish a project in Python that fetches information about wireless devices from the Federal Communications Commission's website. We were able to take the information and put it into the user's home directory as well as into a user-friendly database. Additionally, we learned how to use the Lasersaur laser cutter and cut packaging for the new HackRF acrylic cases. Finally, we learned how to test HackRFs to look for any firmware or LED issues on the boards."

Going forward, we want to involve Ellie and Jacob in several of our software and firmware development projects (including GreatFET). They will be mentored by Mike and Dominic, and we hope that their time with us will amount to a meaningful educational and professional experience that they can take with them into their future careers.

GSG is Hiring

Are you (or do you know someone who is) a match for our open position for a summer intern? See our new jobs page for details. Keep an eye on this page for future job opportunities at Great Scott Gadgets!

Free Stuff, January–June 2016

It's been a while since we've posted, but yes, we are still giving away free stuff! Even though we can't respond to each and every email, we do read and carefully consider all of them, and we choose at least one awesome group, project, or individual each month to send some free hardware to. Here are the free stuff recipients for the first half of 2016.

ADS-B Out Open Source Project

We gave a HackRF One to developer and pilot Christopher Young, whose latest development project is an in-flight ADS-B Out transponder. ADS-B Out allows pilots to broadcast position, ground speed, and altitude to air traffic controllers and aircraft that are equipped with ADS-B In. This project benefits general aviation pilots because NextGen, the FAA’s new plan to increase aviation safety, mandates that all aircraft be equipped with ADS-B Out by the year 2020. Christopher’s open source design is intended give pilots a more affordable means of complying with the new requirement (ADS-B out is a piece of avionics equipment that normally costs thousands of dollars). Chris is also the creator of the stratux project, an affordable open source aviation weather and traffic receiver solution based on low-cost SDRs, so we are excited to put a HackRF into his capable hands.

Visible Light Communication Research

We gave a HackRF One to Alexis Duque, a Phd candidate at INSA in Lyon, France. He is researching the possibilities of visible light communication, and wants to use SDR hardware and GNURadio for some tests. He plans to donate his HackRF to CorteXlab at INSA after the research is complete.

Fablab Hackerspace

We received a free stuff request for a YARD Stick One from Pedro, a high school student at a technical school in southern Brazil who has started a hackerspace called Fablab with a group of his friends. Their school has given them space to work in, but due to equipment costs and crippling taxes imposed on electronics equipment there, they have been unable to find the funds to stock their lab and are relying on donations from the community. We sent them a YARD Stick One so that their group can experiment with communications with a drone they received from a local university.

Argentinian Meetup Group

Speaking of South America, we gave a HackRF to Martin Gallo, coordinator of TandilSec, a meetup group in Tandil, Argentina who discuss infosec topics and learn about current trends. They have recently been experimenting with is SDR, and HackRF One was their hardware of choice.

Qspectrum Analyzer

We gave a HackRF One to the Qspectrumanalyzer open source project because it currently only supports rtl-sdr, and the developer of that program wanted to change that. He tells us that a popular request from users is that they would like to see support for HackRF One.

Amateur Radio Equipment Repair

Pavel is a ham radio operator, self-described tinkerer, and software developer. He is involved with a local amateur radio club, but lives in an area where good radio equipment is difficult to obtain, and the equipment they are able to get their hands on is usually in need of repair. Pavel asked us for a HackRF One to diagnose and test problems, which will help him repair the radio equipment of other amateur radio operators in his community.

Stay tuned; more free stuff updates are on the way! Visit our free stuff page to learn how to submit a request.

ANT700 Release

Today we are excited to announce the official release of ANT700, our new 300—1100 MHz telescopic antenna. Because this general purpose antenna was designed with YARD Stick One users in mind, it has a slim and lightweight form factor that works well with smaller devices. It has an SMA male connector to attach to your device of choice (including HackRF One) and can be extended from 9.5 cm to 24.5 cm.

We started distributing ANT700 last month, and it is already available for purchase from six of our authorized resellers on four continents. To find out where you can purchase yours, please visit the product page.

ANT700 photo

September 2016 Open House Invitation

Earlier this month, we packed our things and moved our lab and offices to a new location in Evergreen, Colorado. We are are very excited to be in a bigger space (it was time!) and to celebrate, we are hosting an open house on Friday, September 16th from 5 pm to 8 pm. We welcome our friends, associates, and neighbors to come and see our new lab and enjoy food and drink with us.

Our address is:
31207 Keats Way
Suite 101
Evergreen, Colorado 80439

Please let us know you are coming so we don't run out of provisions! RSVP by September 10th to

We hope to see you there!

Free Stuff, May–December 2015

The Great Scott Gadgets team has been hard at work sorting through all the Free Stuff requests for 2015, and now we are finally ready to announce the winners for May through December. We've had many interesting submissions, and we've enjoyed learning about all the ideas you have had for open source projects and education. After much discussion and some tough decisions, we've chosen the following seven individuals and groups to receive free hardware from Great Scott Gadgets.

Open Source Project: Universal Drone API Generator

Richard Doell wrote to us requesting a HackRF One for a project idea he is working on. We were intrigued by the project, and very excited to hear that it is going to be open source. Richard has a background in robotics and computer vision, and he wants to create a universal automatic drone API generator for hobbyists and robotics junkies that will allow remote control vehicles to be controlled from a computer using GNU Radio. His HackRF One will enable him to collect data from the RC vehicles' transmitters. Keep us updated about the progress of your project, Richard!

Information Security Workshops

Stefan Hessel (of the blog Causa Finita) is a security expert who works at the Department of Law and Informatics at Saarland University in Germany. After work, he gets involved in his community through an IT working group, offering free classes at a local clubhouse that help beginners develop skills and knowledge in the areas of Internet safety and security. Stefan asked us to donate a HackRF One to help him teach the basics of SDR to the people who attend his classes and to demonstrate ways that attackers could gain access to private data through hardware hacking. Thanks Stefan, for sharing your expertise and using your workshops to bring awareness to these issues.

Liquid Fueled Rocket Building

Let's Build Rockets is a talented group of young amateur engineers who are designing and building a flyable, liquid-fueled rocket. This has proved challenging because currently most of the commercially available model rocket engine systems and electronics components are designed for solid-fueled rockets. Therefore they have had to design, manufacture, and test all of the system's components themselves. They are planning to use their free HackRF One as a receiver in the downlink portion of the rocket's control system, the design of which is based on the Copenhagen Suborbitals Sapphire Telemetry System. The downlink transfers mission data from the accelerometer, gyroscope, altimeter, compass, GPS, pressure and temperature sensors of the engine and fuel tanks, and atmospheric temperature sensors to a ground control station. Eric Simms wrote to us on behalf of Let's Build Rockets, saying:

“The communication that the HackRF enables will help us recover the rocket after the launch and analyze potential failure points. After doing lots of research, the HackRF is the most accessible receiver we've found, requiring the least amount of additional hardware and providing opportunities for future expansion.”

Let's Build Rockets is publishing all of their design files, code, and test data on github so that others can benefit from their learning and experience. We're excited to support this awesome, educational, open source project. Rocket on!

Emergency Communications

The Wantagh-Levittown Volunteer Ambulance Corps is a dedicated group of paramedics and dispatchers who provide emergency services to their community by answering 911 calls. While each ambulance in their facility has its own radio, this small nonprofit organization has had a difficult time finding the funds to invest in a radio for communications training. Their free HackRF One will enable them to receive and decode multiple simultaneous transmissions on their county's radio system. Mark Tomlin, Chief of Operations, wrote to us saying,

“Communications are vital in EMS, just as important as the vital signs of the patient themselves. Missing information from an incomplete report can be devastating to a patients outcome. Presenting ones self to the doctor correctly on the other end of the radio can be the difference in getting the order for the medication or not. These are things that can only come with experience. We now have the opportunity to present our experience to those who were not physically present at the time of notification. This should greatly improve the time it takes a new provider to get up to speed on medical control notifications.”

We are happy to put a free HackRF into the hands of someone who can use it to make the world a better place. It's very satisfying knowing that somewhere in New York, a HackRF One is enabling communication that could save lives.

MIT Splash Program

Every November, high school students from around the country and even around the world come to MIT for a program called Splash. It is a weekend where they can engage in unique and valuable learning experiences that are unavailable in a normal classroom setting. Riley Drake wrote to us asking for a HackRF One for a Software Defined Radio course he is planning to teach at Splash 2016, which will cover topics such as Digital Signal Processing, Decibels, Data Types, Sample Rates, Negative Frequencies, Quantization Error and Complex Numbers in Digital Signal Processing (course structure mirrors Michael Ossmann's online lessons). Having a HackRF One available for the class will allow students to run their code on a real radio and promote a discussion of the legal and regulatory issues of SDR. Good luck with your class Riley, and please send us pictures! We'd love to know how it goes.

Soldering Workshops

Hacklab Almeria is a growing group of developers and enthusiasts in Spain that are learning and collaborating together. When they first wrote to us in October of 2015, they had 30 members, but when we contacted them last month that number had increased to 50. Jesus Marin Garcia asked for several Throwing Star LAN Tap Kits for a workshop the group are offering to their newer members on electronics fundamentals and soldering. Spread the word, and good luck with your workshop!

OpenWebRX Support

András Retzler is the developer of a remote spectrum monitoring solution called OpenWebRX that gives users access to multiple SDR receivers worldwide. We gave András a free HackRF One, which he is using to improve support for that project. If you haven't already seen OpenWebRX, you should certainly check it out—it's really cool. He also plans to use his HackRF One to serve as a test station for another of his open source projects, qtcsdr, an open source amateur radio transceiver design using a Raspberry Pi 2 as a transmitter and an RTL-SDR as a receiver. As a company that is built on open source principles, we are very enthusiastic about supporting open source projects, and we are especially happy to help András with OpenWebRX.

Thanks again to everyone who has sent us a free stuff request. We are almost all caught up now, and we will announce winners for the first few months of 2016 soon. If you have an idea for a project using Great Scott Gadgets hardware and could benefit from free stuff, don't hesitate to tell us about it. If you don't ask, we can't say yes!

Defeating Spread Spectrum Communication with Software Defined Radio, ToorCon 2013

Fortunately in this video you can't hear the jackhammers at work in the hotel lobby while I gave this presentation at the ToorCon San Diego seminars in October, 2013. Apart from having to talk over the construction noise, it was great to share SDR techniques that can be used to point out flaws in security claims made about spread spectrum communication technologies.

One of the things I showed in the talk was how Direct Sequence Spread Spectrum (DSSS) communications can be reverse engineered. I used SPOT Connect, a device operating on the GlobalStar satellite network as an example. A couple years later, Colby Moore did a more complete job of showing how the GlobalStar system can be attacked.

If you aren't familiar with the Pastor Manul Laphroaig, mentioned at the beginning of this talk, check out our PoC||GTFO mirror.

download video
download slides

Free Stuff, April 2015

My, how time flies! The Great Scott Gadgets team has been busy, but we haven't forgotten all of your requests for FREE STUFF! We are working towards getting caught up, so please bear with us as we sort it all out. April had a lot of good submissions, and we are excited to reward several of you with free open source hardware. And to make up for being so behind, we even awarded a YARD Stick One this time, and we shipped it when it was brand new! Read on to learn about April's winning Free Stuff submissions.

Damon Wascom wrote to us requesting a HackRF One to assist AMSAT in testing transmission lines and filters for the next FOX-1C and Fox-1D CubeSats. Damon gave many convincing reasons and compelling arguments as to why we should award him a HackRF One for his project, but perhaps most compellingly Damon wrote:

"It would be awesome to apply this legendary and revolutionary RF hacking tool of the decade into the hacking together of the next amateur built, amateur radio spacecraft!"

Yup! Damon, make it so.

Jesus Sanchez wrote to us on behalf of the Advanced Communications Research Laboratory he founded at his university last February. The Advanced Communications Research Laboratory encourages its members to conduct research in the wide field of SDR and to promote open source software and hardware. We are happy to support these goals by awarding the Advanced Communications Research Laboratory a free HackRF One!

Tamer Çelik is a member of Hackerspace Istanbul. Tamer plans to use his HackRF One to introduce SDR to his hackerspace as well as other hackerspaces in his area. Tamer, thanks for spreading the word and sharing SDR technology with your community!

David De La Hoz Joaquin is a student of Systems and Computer Engineering at Pontificia Universidad Católica Madre y Maestra in Santiago De Los Caballeros, Dominican Republic. David plans to use his HackRF One in his research. He will also be giving talks about SDR at his school and beyond. David is even planning to start a hackerspace at his school. Good luck David!

José Perez Junior is a graduate student at ABC Federal University in Santo André, Brazil. He plans to use his HackRF One to teach students at the university about RF and SDR. He also plans to use it for his own research on SDR and electronic motor control. Congratulations José, and let us know how your research goes!

Sean Semple wrote to us as president of the Association of Cyber Engineers (ACE) at Louisiana Tech University. ACE is an organization that was established a couple of years ago to promote the new Cyber Engineering degree program at Louisiana Tech, but also to help students learn about the cyber landscape as early in their career as possible. Great Scott Gadgets is happy to provide ACE with their very own YARD Stick One!

Once again, thanks to everyone that sent us a request. If you didn't send us a request, why not? It never hurts to ask. We look forward to seeing what you come up with next!

Low Cost SimpliSafe Attacks

Earlier this week, Dr. Andrew Zonenberg of IOActive published a security advisory and blog post describing weaknesses in the SimpliSafe home security system. He showed that components of the system, such as the keypad, transmit unencrypted radio signals that can be captured and replayed. He also pointed out the significant problem that SimpliSafe devices are physically incapable of being reprogrammed with improved firmware that might address such vulnerabilities.

I know Andrew and have great respect for his reverse engineering and hardware hacking talents. He implemented a replay attack by making small modifications to SimpliSafe devices, monitoring and controlling them from his own hardware platform. To demonstrate the impact of the technique, he showed how it could be used to replay a PIN that disarms a SimpliSafe system. While I found his attack very effective, I was intrigued by his inability to fully decode PINs. I wanted to take a crack at the problem myself, and I thought it would be worthwhile to confirm that the radio interface of the system can be attacked at a lower cost to the attacker, without any SimpliSafe hardware, and without physical proximity to the target system.

I borrowed a SimpliSafe system to use as a target system, and I took the approach I have demonstrated in my presentation, Rapid Radio Reversing, using a combination of Software Defined Radio (SDR) and non-SDR tools. The primary tool I used was YARD Stick One with RfCat software.

YARD Stick One and SimpliSafe keypad

First I used HackRF One to monitor transmissions from the SimpliSafe keypad. I visualized a captured radio waveform with inspectrum and quickly identified an Amplitude Shift Keying (ASK) signal being transmitted by keypad. Andrew labeled this On-Off Keying (OOK), but the difference between ASK and OOK is subtle and does not affect his findings.


After determining the frequency, modulation, and symbol rate of the transmission, I turned to YARD Stick One for further analysis. Within seconds I was able to decode raw symbols being transmitted by the keypad. It was easy to identify which packets were transmitted by the keypad after entering a PIN, so I entered a few different PINs and saved the resulting packets for analysis.

It took me a couple hours of staring at packets and fiddling with short decoding functions in Python before I was able to understand the encoding. This was the most difficult part of the project. The system uses a somewhat uncommon Pulse Interval and Width Modulation (PIWM) to encode data onto the ASK signal, and the order of bits was not immediately obvious. With a little time, however, I was able to implement real-time decoding of received packets and to recover the PIN entered on the keypad by another person at a distance. I was also able to replay keypad transmissions.

real-time PIN decoding, redacted

I could have implemented capture and replay even without fully decoding the packets. This is what Andrew was able to accomplish with his hardware hack. Full decoding, however, demonstrates that some additional attacks are possible. An attacker with a good antenna can monitor PINs from a great distance and can, without ever transmitting a radio signal, learn those PINs and later use them at the keypads. An attacker can craft packets with chosen PINs or other contents, so an automated brute force attack on a PIN is possible even if the attacker has not observed the valid PIN. The system uses 4-digit pins, so only 10,000 guesses are required for an exhaustive brute force attack.

I could have accomplished all of this with only HackRF One or only YARD Stick One, but I used the combination of the two for convenience. If I had to choose just one for a project like this, it would be YARD Stick One which, at $100, costs less than half of the equipment used by Andrew. It could be done with almost any 433 MHz ASK transceiver, including the covert TURNIPSCHOOL or my favorite children's toy, the IM-Me, but YARD Stick One with RfCat is the most convenient tool for the job in my toolbox.

Andrew included with his blog post a video demonstrating his attack over-the-air. In his video, he mentions that his hardware hack was the "quickest and easiest way" to accomplish his attack. That may be true for Andrew, but personally I found it easier to use radio tools. I wrote dozens of lines of Python compared to his hundreds of lines of C, and I never needed to crack open any SimpliSafe device. It took me about half a day, and most of that time was spent puzzling over the data encoding. I could have implemented a simple capture and replay within seconds of identifying the radio signal.

Andrew's video shows him disarming an alarm from only a few inches away which unfortunately could be interpreted as meaning that his attack is only effective at such close range. His attack, in fact, works from anywhere the keypad can operate. According to the manual, it works within 100 feet of the base station. Even greater range can be achieved easily with the use of low cost radio test tools instead of a modified keypad. I estimate that, for less than the $250 Andrew spent, an attacker can execute PIN replay from about a mile away.

Since Andrew's advisory, SimpliSafe has responded in predictable fashion while information security professionals filled their bingo cards. One of the things SimpliSafe has pointed out is that customers are notified whenever their systems are disarmed. Unfortunately this is only true for those customers who pay an extra $10 per month for SMS and email notifications. Moreover, in my testing, I verified that it is possible for an attacker to wirelessly command the SimpliSafe system to enter test mode even while the system is armed. This is something that normally can be done from the SimpliSafe keypad only while the system is disarmed. Alarms and notifications are disabled in test mode, but the documentation states that test mode is indicated in the online dashboard available to customers who pay for notifications.

Following Andrew's lead, I am not publishing any attack software developed during my testing. However, it is important to realize that I employed only tools and techniques that are well known and commonly used throughout the wireless security community. Effective attacks, including PIN replay, can be implemented without writing a single line of code. Passive monitoring attacks, such as the ability to learn a PIN at a distance, require somewhat more reverse engineering effort but can be implemented with even less expensive equipment such as off-the-shelf TV tuners that cost as little as $10.

Andrew's and my investigations only scratch the surface of the security of the SimpliSafe system. Andrew's key finding is not that PINs can be replayed but that the absence of basic cryptographic protections illustrates a total lack of wireless security engineering. Further weaknesses will very likely be discovered if anyone takes the time to look for them. For example, the cellular interface is an attack vector that remains unexplored as far as I know.

SimpliSafe is not alone in deploying alarm systems with vulnerable wireless interfaces. Sadly, almost every wireless alarm system I've ever looked at suffers from similar weaknesses. As we hurtle toward a future of ubiquitous digital wireless technology embedded in the objects of our daily lives, we would be wise to pay more attention to the security of those wireless interfaces. Burglar alarm systems seem like a good place to start.

P.S. Dr. Zonenberg's dissertation is fascinating.

Rapid Radio Reversing, ToorCon 2015

In this video of my presentation at ToorCon 2015, I demonstrate how helpful it can be to use a combination of both SDR and non-SDR tools for reverse engineering wireless systems. I use both HackRF One and YARD Stick One to reverse engineer a wireless cabinet lock.

download video

code from the presentation

Free Stuff, March 2015

We've fallen behind on shipping Free Stuff and even further behind on announcements, but we're catching up!

Tariq Ahmad wrote to us representing the M5 hackerspace at UMASS Amherst. M5 has several ongoing projects including their Experimental College where students can take as well as teach classes just for the sake of learning. Tariq, we hope you and everyone at M5 can learn some new skills with your new HackRF One!

Introducing YARD Stick One

This week we started shipping YARD Stick One, our latest test tool for radio systems operating below 1 GHz. The first thing you should know about it is that, unlike our popular HackRF One, YARD Stick One is not a Software Defined Radio (SDR) platform. Although we think that SDR is the overall best tool for the greatest number of wireless applications, sometimes it is beneficial to have a simpler tool for certain jobs.

YARD Stick One photo

The architecture of YARD Stick One is similar to Ubertooth One; it is a wireless transceiver IC on a USB dongle. The IC takes care of digital modulation and demodulation, giving you an easy-to-use interface for your own software running on the attached host computer. YARD Stick One is the quickest and easiest way to start experimenting with low speed digital wireless technologies including industrial control systems, wireless sensor networks, smart meters, home automation systems, garage door openers, and remote keyless entry systems.

The YARD Stick One story started when Travis Goodspeed introduced me to the IM-Me one snowy night at ShmooCon in 2010. He showed me how to use his GoodFET to program firmware on the IM-Me, and we successfully tested radio transmission from the IM-Me in the hotel bar. After returning home, I acquired an IM-Me, soldered up the GoodFET Travis had given me (which was the first surface mount PCB I ever assembled), and immediately set to work developing a spectrum analyzer application which, to this day, remains perhaps the most useful software available for the popular, hackable toy.

Months later, Travis and I presented Real Men Carry Pink Pagers in which we encouraged others to use the CC1110-based platform for testing and experimenting with digital radio communication systems. About a year after that, atlas started showing people how to use the CC1111, the USB-enabled version of the CC1110, to accomplish the same things with a dongle connected to a laptop. His RfCat software allowed people to do things in a few lines of Python that Travis and I achieved only by compiling C for the 8051 microcontroller inside the CC11xx.

RfCat made experimentation with low speed digital wireless systems easier than ever before, but it wasn't adopted as widely as I hoped it would be. Probably the biggest reason for that is the fact that, for a long time, the only way to get RfCat up and running was to buy a CC1111 development board, assemble a GoodFET yourself, and then use the GoodFET to write RfCat firmware onto the CC1111 board. It became apparent early on that we needed a device designed specifically for RfCat, one that ships with RfCat firmware and is ready to use. I designed the ToorCon 14 badge, which was a great success, but I wanted to make an even better platform available to the world.

YARD Stick One was intended to be the ideal platform for RfCat. In addition to shipping with RfCat firmware, YARD Stick One is designed to operate effectively over the entire frequency range of the CC1111. All of the previous CC1111 boards that I know of are designed to work in only one frequency band. For example, you can get a CC1111 development board for 900 MHz or one for 433 MHz, but, prior to YARD Stick One, you couldn't find a CC1111 board that worked well in both those bands.

Where previous development boards have had built-in antennas, YARD Stick One has an SMA connector that allows the use of higher performance external antennas. It also has receive and transmit amplifiers for improved RF performance. Like everything we make, YARD Stick One is open source hardware.

It took a long while to complete YARD Stick One and get it manufactured, but we are finally shipping. Over the past couple years I've been able to get pre-release boards out to atlas and a few other folks who are active in wireless security research. For example, Samy Kamkar used YARD Stick One for the remote keyless entry system research that he presented at DEF CON in August.

To get started with YARD Stick One, I recommend atlas's videos along with several blog posts written by early adopters of RfCat. You'll notice that, even though the users of RfCat tend to be well versed in SDR, they find RfCat useful to get hacking even faster on digital wireless communication systems.

Comments on the FCC NPRM on Equipment Authorization

Today I submitted the following comment on the FCC's Notice of Proposed Rulemaking (NPRM) on Equipment Authorization and Electronic Labeling for Wireless Devices.

Thank you for inviting comments on the proposed rules for Equipment Authorization and Electronic Labeling for Wireless Devices.

I am the owner of Great Scott Gadgets, a US company that makes open source test equipment primarily for the information security industry. As a designer and manufacturer of communications equipment, I commend the Commission for seeking to clarify and streamline the rules for equipment authorization. I believe that, on the whole, the updated rules will benefit the electronics industry. However, I am concerned that the rules regarding software control of radio parameters place an undue burden on device manufacturers and unnecessarily restrict the actions of end users.

My concerns arise from rules already in place for Software Defined Radio (SDR) devices. I am encouraged to see that the Commission is eliminating certain special rules for SDR equipment and seeks to treat SDR and non-SDR devices in the same way. However, while the Commission notes that "the existing SDR rules have proven to be insufficiently flexible," the proposed rules broaden the reach of those rules to non-SDR equipment.

The requirement to implement security measures preventing the modification of software has long been unpopular in the SDR community. Software security is difficult, expensive, and unreliable, and it undermines reconfigurability, a principal benefit of SDR. The proposed rules extend this absurd requirement to all radio equipment with any software control, encompassing most radio devices manufactured today.

Under the proposed rules, all radio device manufacturers would be required to devise software security mechanisms that do not exist today, and they would have to prepare for each new device software documentation that is currently not required. Makers of integrated circuits would have to develop entirely new product lines that provide device manufacturers with security mechanisms, killing off existing product lines that lack such controls.

These requirements seem particularly onerous when considering the fact that computer security is largely an unsolved problem. Where manufacturers have had limited success preventing modification of software in electronic devices (e.g. in mobile phones), it has been accomplished only through great effort and expense. The engineering effort required to devise effective security measures (not to mention the cost and power consumption of cryptographic controls) may exceed the effort required to design many digital radio devices made today. A likely outcome is that software security mechanisms implemented in compliance with the proposed rules will prove ineffective and a waste of effort.

Great Scott Gadgets designs and manufactures Open Source Hardware (OSHW). The OSHW community includes a small but rapidly growing segment of the electronics industry that is committed to the ideals that end users have a right to fully control their own equipment and that anyone should be able to study, make, use, modify, and sell devices based on our published designs. OSHW makers recognize that, just as Open Source Software has resulted in great advances in the software industry, Open Source Hardware will enable future generations of hardware innovation.

As an OSHW designer, I have often been troubled by the Commission's rules for SDR. Great Scott Gadgets manufactures and sells HackRF One, an open source SDR platform popular for research and education. HackRF One is sold as test equipment, making it exempt from equipment authorization. As Open Source Hardware, however, it is a design that may be modified and sold by anyone. If someone were to use HackRF One as the basis for more specialized open source radio equipment that is not subject to the test equipment exemption, this new equipment would require authorization and would be subject to software security requirements that are incompatible with the open source license. We cannot grant open source licenses to users while locking out those same users.

This fundamental incompatibility with open source licensing greatly concerns me. The software security requirements, now that they will apply to non-SDR devices under the proposed rules, will adversely impact not just designers and users of Open Source Hardware but anyone making or using Open Source Software with any radio equipment. Today innovation is stifled by rules that make it difficult or impossible to sell OSHW SDR devices that are anything other than test equipment. Under the proposed rules, even more innovation will be curtailed.

I urge you to eliminate the software security requirements for both SDR and non-SDR equipment.

Additionally I am concerned about the proposal to grant automatic long-term confidentiality to certain types of exhibits. The Commission's Equipment Authorization database is a great public resource that is better protected by the existing rule that grants long-term confidentiality only upon request.

PortaPack H1 at DEF CON 23

Jared Boone of ShareBrained Technology gave demonstrations of his new PortaPack H1 at the DEF CON 23 Demo Lab. I joined him at his table to help talk with people about the add-on for HackRF One.

Jared Boone at DEF CON Demo Labs

PortaPack H1 turns HackRF One into a portable SDR platform. With an LCD, navigation control, and audio input and output, the device can be used as a handheld spectrum analyzer and can implement a wide variety of useful radio functions. A microSD slot on the PortaPack can be used for waveform or firmware storage, and a coin cell keeps the real-time clock and a small amount of configuration RAM going while the device is turned off.

PortaPack H1

Of course, the hardware designs and firmware for PortaPack H1 are published under an open source license. Jared has done an amazing job of implementing SDR functions for PortaPack that run entirely on HackRF One's ARM Cortex-M4 microcontroller.

To use PortaPack H1, you'll need a HackRF One, and you'll probably want a USB battery pack to make it a fully portable solution. Another popular add-on is the beautiful milled Aluminum enclosure for PortaPack. Jared provides a ShareBrained Technology guitar pick with every PortaPack H1. It is the perfect tool for opening your HackRF One's injection molded plastic enclosure prior to PortaPack installation.

There was a wonderful moment at the Demo Lab when Jared tuned his PortaPack to a frequency being used by Ang Cui at a nearby table. Jared's PortaPack was plugged in to a small speaker, so we could all listen to the AM radio transmission originating from a printer at Ang's table. The printer was physically unmodified but was running malicious software that transmitted radio signals with a funtenna! For more information about Ang's implementation, visit

My First Look at rad1o Badge

Over the next several days, thousands of hackers will gather at the Chaos Communication Camp in Germany. An electronic badge for the event is being prepared, and it is based on my design for HackRF One!

At DEF CON over the weekend, I was fortunate to be able to meet up with Ray, one of the members of the Munich CCC group responsible for the rad1o badge. Ray was wearing one of the prototype units, so I was able to take a close look.

rad1o prototype at DEF CON 23

The design is a variation of HackRF One. It includes a small LCD and an audio interface, so it is a bit like having a HackRF One plus a PortaPack H1 on a single board. A slim, rechargeable LiPo battery is mounted on the back. The visual design of the PCB looks like a traditional AM/FM radio receiver complete with an antenna (which is not the actual RF antenna) and a dial (which is not really a dial).

There are some design modifications, especially in the RF section, that seemed strange to me at first. The reason for many of these changes is that the rad1o team was able to get certain chip vendors to agree to sponsor the badge by donating parts. By redesigning around donated components they were able to reduce the cost to a small fraction of the cost of manufacturing HackRF One, making it possible to build the rad1o badge for several thousand campers.

The firmware for rad1o is derived from HackRF One firmware but is in a separate repository. Because of the LCD and other differences between the two hardware designs, they are not firmware-compatible. When using rad1o as a USB peripheral, it is fully supported by existing software that supports HackRF One. Future rad1o firmware will use a USB product ID of 0xCC15 assigned from the Openmoko pool, but the shipping firmware will borrow HackRF One's product ID. This will ensure that any existing software for HackRF One will work with rad1o during camp. The new product ID (0xCC15) is already supported in libhackrf release 2015.07.2, so it should be easy for people to update to it in the near future.

If you are new to Software Defined Radio and are looking forward to using the badge as a way to get started with SDR, I recommend starting with my video series. You might want to download the videos before leaving for camp. Also take a look at Getting Started with HackRF and GNU Radio and the recommended software for rad1o. If you plan to do firmware or hardware hacking, be sure to clone the rad1o repositories. For examples of Digital Signal Processing (DSP) on the LPC43xx, I suggest studying Jared Boone's firmware for PortaPack H1. Also check out the video of Jared's Software-Defined Radio Signal Processing with a $5 Microcontroller at BSidesLV 2015.

As an open source hardware developer, it is extremely satisfying to see folks start with my design and do something amazing like the rad1o badge. I'm excited to be attending camp for my first time ever, and I can't wait to see the projects people will come up with!

Wassenaar Comments

Today I submitted the following comment on the Bureau of Industry and Security (BIS) Proposed Rule: Wassenaar Arrangement Plenary Agreements Implementation; Intrusion and Surveillance Items.

Thank you for inviting comments on the Wassenaar Arrangement Plenary Agreements Implementation for Intrusion and Surveillance Items. As a member of the information security community, I am concerned about the effects of the proposed implementation on my industry.

I'll keep this brief by voicing support for the comments made by other prominent members of the community: Google, Katie Moussouris, Robert Graham, and Sergey Bratus et al.

My greatest concern is clarity of the proposed rule. If you must provide an answer to a frequently asked question about what a rule means, it may be because the rule was not written clearly. I was particularly troubled by the publication of the FAQ regarding the proposed rule, partly because it indicated a lack of clarity in the rule but also because the answers didn't seem much clearer. Had the answers been clear, I would still be concerned that the text of the rule would not be interpreted in the future in the same manner as your present interpretation. The text matters, and it is overbroad and unclear even to well informed members of the information security community.

Unfortunately, computer security is an unsolved problem. The people who are working to improve the state of the art of computer security are diverse members of a global community of researchers. The proposed rule directly prevents the sharing of information among those researchers, and it will have a negative impact on the security of computing systems and software for the entire world.

Software is a form of information, and control of the flow of information is very different from control of the transport of physical goods. I urge you to remove software from the scope of the Wassenaar Arrangement at the annual meeting of Wassenaar Arrangement members in December 2015.

Black Hat Student Pass

If you are a full-time university student and would like a free ticket to this summer's Black Hat Briefings, send an email to today. We have two tickets to give away, and we would like to give them to students who share our interests. You must meet Black Hat's criteria, and you will be responsible for your own travel and lodging.

We'll be busy at Black Hat USA this year. I'm teaching two sessions of my Software Defined Radio class, and I will be giving a talk at the Briefings about the NSA Playset. Additionally, Taylor and I will show off a new project called YARD Stick One at the Black Hat Arsenal.

HackRF One at 1 MHz

We've decided to advertise the fact that HackRF One operates all the way down to 1 MHz, not just to 10 MHz. This isn't a change to the hardware design; it is simply an acknowledgment that the hardware has always worked at such low frequencies and that we support operation down to 1 MHz.

transmit power plot

In fact, HackRF One can even function below 1 MHz, but the performance drops considerably as the frequency decreases. The curve is reasonably flat down to about 1 MHz, so we consider that to be the lower limit for most uses.

Now that we've seen consistent low frequency performance across multiple manufacturing runs, we're comfortable changing the official specification: HackRF One operates from 1 MHz to 6 GHz. Try attaching a long wire antenna to listen to shortwave radio!

Although HackRF One has reasonable performance down to 1 MHz, it performs better at higher frequencies. To get the best possible performance down to 1 MHz and lower, I recommend using an external upconverter/downconverter such as the excellent Ham It Up, open source hardware designed by Opendous.

Open House Invitation

For the first time ever, Dominic, Taylor, and I will all be in the same place at the same time in June. We decided we should celebrate, and you are invited!

Please join us at our recently expanded lab in Evergreen, Colorado on 11 June 2015 from 17:00 to 19:00. You can see the lab, talk to us about our projects, check out our latest prototypes, and even learn to solder!

RSVP to by 4 June 2015 so we don't run out of refreshments.

Great Scott Gadgets
27902 Meadow Drive, Suite 150
Evergreen, Colorado 80439
(the Canyon Courier building)

Free Stuff, February 2015

Great Scott Gadgets is pleased to announce the recipients of our inaugural Free Stuff give-away. This being our first give-away, we got a little overexcited and ended up giving away 5 HackRF One units to people who made requests in February! We were excited to see so much interest in our Free Stuff program, and after much deliberation we were able to narrow the field down to these 5 entrants. Congratulations, and we can't wait to see what you do with your HackRF Ones!

Alex Page wrote to us representing the Interlock hackerspace in Rochester, New York, which has recently begun hosting SDR meetups. They have been encouraging those new to SDR as well as seasoned veterans, and they have made a space where they can all interact. We are awarding Interlock a HackRF One unit to encourage this sharing of knowledge. Thanks Alex, and keep up the good work.

JinGen Lim is a promising student and developer from Singapore. When HackRF One was released he used it as an inspiration to build his own open source device called CCManager. We awarded JinGen a HackRF One unit to see what he can come up with next. Thanks for making your ideas open source JinGen!

Rajesh Kannan is a licensed amateur radio operator and enthusiast as well as a rather successful amateur meteorologist. Rajesh has plans to use his HackRF One to help develop an HRPT satellite receiver with a group of students in India. Thanks Rajesh for igniting the RF spark in the next generation!

Taavi Laadung is a graduate student at the Tallinn University of Technology in Estonia. He is working on a nanosatellite project and plans to use the HackRF One that we give him to help build a ground station. Thanks Taavi for including the HackRF One in your research.

Chris Johns is a student at Spokane Community College in Spokane, Washington, and with the help of a few other members of their technology club Chris plans to use his HackRF One to start an amateur digital TV station. It's an interesting proposition, and we thank you for trying it out, Chris. Good luck!

Thanks to everyone that sent us a request. If you didn’t send us a request, why not? It never hurts to ask. We look forward to seeing what you come up with next!

subscribe to GSG feed