Great Scott Gadgets

open source tools for innovative people


Free Stuff Program Refresh

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

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

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


Free Stuff, October 2021–December 2021

October

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

November

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

December

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


Free Stuff, July 2021–September 2021

July

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

August

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

September

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


Free Stuff, April 2021–June 2021

April 2021

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

May 2021

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

June 2021

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


Free Stuff, January 2021–March 2021

January 2021

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

February 2021

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

March 2021

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


LUNA Now Uses Amaranth HDL

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


Testing a HackRF Clone

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

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

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

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

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

maximum output power vs. frequency

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

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

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

received signal power vs. frequency

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

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

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

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

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

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

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

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

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

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


Shutting Down GSG Project-Specific Mailing Lists

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

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


LUNA Delayed

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

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

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

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

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

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

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


Pmod Host Ports Added to Encased LUNAs

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

LUNA General-Purpose Digital I/O

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

Pmods and Pmod Host Ports

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

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

LUNA and Pmods

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

Physical changes to LUNA and case

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

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

References

[0] https://digilent.com/blog/where-to-plug-in-your-pmod-fpga/

[1] https://digilent.com/blog/digilent-pmods-an-introduction/

[2] https://www.digikey.ca/htmldatasheets/production/2033310/0/0/1/pmod-interface-specification.html

[3] https://github.com/greatscottgadgets/luna/pull/112


subscribe to GSG feed