Great Scott Gadgets

open source tools for innovative people

Free Stuff - April 2023

The April recipient for the Great Scott Gadgets Free Stuff Program is Adnane. Adnane is a software development and cybersecurity student in SoliCode School in Tangier, Morocco. He is always looking for new tools and technologies to enhance his learning and explore new avenues in the field. Adnane is planning to use his HackRF One to learn more about wireless security testing, digital signal analysis, and software-defined radio. He will share his knowledge and skills in the SoliCode Cybersecurity Club. Good luck and have fun!

Development of a Universal Radio Test Instrument

The Great Scott Gadgets team is thrilled to announce our newest research and development project: a Universal Radio Test Instrument (URTI). We have decided to call this project URTI as a working title. With the support of ARDC in partnership with TAPR, we aim to develop an open-source SDR platform with an unparalleled set of radio investigation and experimentation functions in one versatile device. URTI will offer radio amateurs, researchers, educators, and professionals an affordable, compact RF test tool that could be used in place of multiple expensive pieces of traditional radio test equipment.

Design and Functionality

Our goal for URTI is to design a single hardware platform capable of serving as many popular types of one-port or two-port RF test instruments. We plan to build a directional coupler into a wideband, full-duplex SDR platform to enable URTI to function as a:

  • spectrum analyzer
  • vector network analyzer
  • vector signal generator
  • vector signal analyzer
  • antenna analyzer
  • power meter
  • frequency counter
  • full-duplex SDR transceiver

Incorporating these test equipment functions into a compact form factor with a handheld user interface will make URTI portable and convenient to use in the field. We also plan to develop a lower-cost variant that will provide the same test equipment functions but as a computer peripheral device without the handheld user interface, making the tool more accessible for every budget.

Development Plans

The Great Scott Gadgets engineering team will develop URTI in eight overlapping phases. These phases will include:

  • Mainboard component selection and sub-circuit evaluation
  • Initial mainboard hardware design
  • User interface board component and sub-circuit evaluation
  • Mainboard firmware and gateware development
  • Host software development to enable use of the mainboard as a USB peripheral
  • Final mainboard prototype design
  • User interface board hardware design
  • Handheld user interface firmware development

Once we have a complete and fully documented final design, we plan to assemble and distribute 50 prototypes of the USB peripheral version and 50 prototypes of the handheld version to select beta testers to promote feedback and community involvement. We have already started working on the first phase of development: mainboard component selection and sub-circuit evaluation. Our priority is selecting components that are widely available and cost-effective so the completed design can remain relevant and accessible for as long as possible.

All phases of the URTI project will be published concurrently with development in public repositories within the Great Scott Gadgets organization on GitHub. In keeping with Great Scott Gadgets’ commitment to putting open-source tools into the hands of innovative people, we will publish all hardware, software, firmware, and documentation for URTI under open-source licenses, making these resources available to all. You can view our current progress on URTI in the lab notes repository on GitHub.

Thank Yous and Getting Involved

We are excited to bring the URTI project to life over the coming year, and we hope it will transform how people experiment with radio. We thank ARDC and TAPR for supporting this project and contributing financial resources to make it happen!

We would love to hear your feedback on this project and invite you to join us on our Discord server to chat about this or other Great Scott Gadgets projects.

Free Stuff - March 2023

The March recipient for the Great Scott Gadgets Free Stuff Program is Jan. Jan is the author and maintainer of RadioLib, an open-source library for embedded devices controlling various wireless radio modules like SX1276, CC1101 or RF69.

We are sending Jan a HackRF One to aid in the development of RadioLib. Until now, Jan has been doing development using an RTL dongle. The lack of TX ability, and other issues, have made the dongle a bit less than practical. We hope the HackRF One helps, and we look forward to watching this project continue to evolve!

Cynthion Hardware Design Update

Note: This is a crosspost of a Cynthion update on Crowd Supply:

We’ve completed the Cynthion r0.6 design! As mentioned in previous updates we needed to modify the design to accommodate new components due to supply chain issues. In this revision additional changes were made to resolve some problems beta testers identified with both power input and power output.

Issues Found During Beta Testing

Power input issues: When you plug Cynthion into a host computer, it is expected that Cynthion powers up and that the host computer will recognize that a device has been attached. Our beta testers found a couple of situations in which those things would not happen reliably. These scenarios were caused by a confirmed issue with excessive reverse leakage through a diode and a suspected issue with loading of the CC pins on the USB Type-C connectors.

Power output issues: Cynthion can pass power from a host computer (either the control host or a target host) through to a target device. Although this worked reliably, there was a problem that caused excessive power consumption and another problem that could theoretically damage a component on Cynthion.

Rethinking Power Distribution

As we investigated various power input and output issues over the past year or so, we sketched solutions planned for r0.6. When it came time to design r0.6, however, we realized that those solutions were insufficient.

Additionally, we realized that older versions of Cynthion were vulnerable to damage from high voltage input on any of the USB Type-C connectors. Originally designed with Micro-B connectors, Cynthion was later updated with Type-C connectors, introducing a much greater probability of accidental high voltage.

Micro-B connectors are intended to carry 5 V power, but Type-C connectors were designed to support up to 20 V, later extended to 48 V. USB hosts and power supplies are supposed to supply only 5 V unless the device asks for a higher voltage, but a noncompliant implementation could supply up to 20 V without negotiation.

Partly out of concern for overvoltage, we had implemented very limited Power Delivery (PD) capabilities in previous hardware revisions, minimizing the probability of input voltages higher than 5 V. However, our PD implementation may have contributed to other problems, and it did nothing to protect Cynthion from overvoltage from a noncompliant power supply.

We decided to completely rethink both power input and power output. After multiple rounds of design, simulation, and test, we’re happy to report that Cynthion’s capabilities are better than ever before!

image caption: a prototype board, essentially a Cynthion with everything removed except power distribution and monitoring

What’s New in r0.6

The USB ports are now renamed:

  • CONTROL is the primary port for control of Cynthion. Both the FPGA and the on-board debugger are now controlled over this port, so a second connection to the control host is no longer required.

  • TARGET C connects to a target host.

  • TARGET A connects to a target device and is directly connected to TARGET C, passing through data signals and allowing USB analysis.

  • AUX is an auxiliary port that can be used for various purposes, including MitM or as a secondary control port for development.

Cynthion now supports power passthrough up to 20 V, the highest voltage allowed in PD’s Standard Power Range (SPR). Power can now pass through to the AUX port in addition to the TARGET ports. PD’s Extended Power Range (EPR) is not supported.

A 5 V power supply is still required on either CONTROL or AUX to power Cynthion itself, but the hardware now allows the user to select which port to use if 5 V supplies are available on both ports. Overvoltage protection automatically shuts off either input if it exceeds 5.5 V.

Power input and power passthrough are now two separate functions, no longer entangled with one another. All power output is strictly passthrough, not an output of an internal supply rail. Overvoltage shutoff of an input does not affect passthrough. There is no longer a diode drop reducing passthrough voltage.

All four ports now feature voltage and current monitoring, allowing Cynthion to measure passthrough power as well as its own power usage. The power monitoring capability can be used to implement flexible overvoltage, overcurrent, or reverse current protection for external hosts or devices, though with a slower response time than Cynthion’s internal overvoltage protection.

TARGET C and AUX now each have a Type-C controller implementing bidirectional PD communication on the CC pins. This significant improvement in PD capabilities was made possible in part by the power distribution redesign. The Type-C controller additionally allows VCONN output that can be used, for example, to power electronically marked cables.

A new USER button provides input to the FPGA, allowing direct interaction with gateware running on Cynthion.

The Pmod connectors are moved to the same edge of the board making Cynthion compatible with dual Pmods. A new mezzanine connector provides additional expansion capability.

Cynthion is now physically larger. The PCB dimensions increased from 48x48 mm to 56x56 mm. This will accommodate future revisions with physically larger FPGA packages or other components. During the r0.6 design phase we unexpectedly received some delayed components which we will use in the first production to reduce risk, but we need room to allow future use of alternative parts purchased during the shortage.

New mounting holes in the corners allow the PCB to be firmly fastened to an enclosure. 3D render of Cynthion r0.6

Next Steps

Prototypes of Cynthion r0.6 have been assembled, and we are testing them now. We anticipate one more hardware revision before production, but we expect it to include only minor updates. Initial testing of r0.6 is going very well, probably because we already prototyped smaller sections of it separately.

Taylor and Martin are now working hard on designing a test jig and software for factory testing. Much of this work couldn’t be done until the r0.6 redesign was complete, but we are now making rapid progress.

Timon has already completed an update of the enclosure design for new form factor, and we will have samples made very soon. Once we have samples that pass inspection we’ll be able to design packaging.

All of these steps will take time, and they were delayed by the r0.6 redesign effort. As a result, we expect to begin shipping LUNA in August 2023 instead of June 2023, but we think the many improvements in the latest revision will be worth the wait. We’re thrilled to be making steady progress after many months of waiting and wondering about component availability.

We greatly appreciate your patience and continued support!

Packetry: Building a High Performance Protocol Analysis Tool

In a previous update, we introduced our work on Packetry, our new front-end software for using Cynthion to capture and analyze USB traffic on the wire. In this update, we’re going to talk a bit more about the design of that software and explain some of the work we’re doing to make it as fast and easy to use as possible.

The Need for Speed

One of the most exciting features of Cynthion is its ability to serve as a protocol analyzer, letting you intercept and capture USB traffic on the wire, in the field, from real devices.

Cynthion device connection

Fully benefiting from this feature requires the help of some very efficient software on the capture host. A high-speed USB capture, including metadata, can generate over half a gigabit per second of raw data. To see what’s happening in real time as the capture progresses, all that data needs to be processed at least as fast as it’s captured, which is close to 50 megabytes per second.

In fact, real-time performance isn’t really enough in practice. When opening a saved capture from a file, the software needs to process packets many times faster than real time. At real-time decoding speed, a busy minute-long capture would also take a whole minute to load. So we need a solution that can process USB packet data many times faster than real-time speeds, which means a throughput of hundreds of megabytes per second at least.

Because of these requirements, we’ve designed Packetry from the ground up to achieve the fastest possible decoding speeds and to scale seamlessly to captures of unlimited size, bounded only by disk space. We’re also thinking ahead: Packetry has been developed for USB 2.0 analysis with Cynthion, but in the future we may want to use it to analyze higher speed protocols.

All these factors have made performance critical to success: so how did we achieve it?

Laziness as a Virtue

To achieve the speed and scalability we need, we must do the minimum work necessary for each packet at capture time. We don’t need to fully interpret all traffic as it’s captured: we just need to follow each packet’s effect on the protocol and store things in a form we can efficiently access later.

Rather than constructing individual data structures to represent packets, transactions and other protocol elements, we simply write all captured packets out into a flat bytestream in order. In this form, the capture can be very efficiently written to a file as it progresses.

As we do so, we build a set of indexes which describe where to find the start of each packet, the start of each transaction, and so forth. Those indexes are how we describe the protocol structure. They are designed to provide just enough information for the UI to later look up any part of the capture, decode it on demand, and display it.

Cynthion Indexing

Each index is a monotonically increasing sequence of integers. Because of that, we can store them very efficiently. We use a simple compression scheme to minimize the storage overhead of the indexes. To ensure scalability, these indexes are also streamed to files themselves. As such, capture size is limited only by available storage, never by available memory. All data structures in memory have a bounded size which is independent of the size of the capture.

In this approach, we gain scalability by giving up a little speed at display time. This is a good tradeoff to make, because, unlike capturing or loading data which may happen at extremely high speeds, displaying data is constrained by the bandwidth of the human user. There can only be so many things on screen at once, and the user can only browse through them at human speeds. We do not have to make rendering the display very fast for it to feel instantaneous.

Traffic Display

USB is a highly structured protocol: packets are grouped into transactions, transactions into transfers, and transfers are attached to specific endpoints on devices. Our UI displays traffic hierarchically according to that structure, making captures easy to understand and explore. A similar design approach was pioneered in ViewSB, but in Packetry we’ve now made it fast and scalable to large high-speed captures.

Cynthion Traffic Display

Our GUI has been built on GTK 4, which has built-in support for displaying large lists and trees by lazily loading only the parts currently visible on screen, recycling UI widgets for efficiency, and preloading ahead of scrolling. When you scroll through the traffic view in Packetry, the packets required are loaded on demand using the capture indexes, decoded on the fly, and used to generate the summaries you see of packets, transactions and transfers. All this happens live, too: if you’re running a capture, you’ll see new traffic appear, and the descriptions of existing items may be updated as further packets come in. When you load a capture from a file, you can start exploring it immediately, even while the packets later in the file are still being indexed.

Threading Model

It’s been a while since individual CPU cores got significantly faster; these days performance gains usually come from parallelization to take advantage of multiple cores. However, some tasks just can’t be parallelized, and the only option is to make them as fast as possible on a single thread.

When analyzing packets captured on the wire, every packet matters to the overall state of the protocol. The need to deal with invalid packets and protocol errors means it’s not possible to make assumptions about structure. Interpreting traffic correctly requires looking at every packet one by one, in order, and updating the protocol state at each step. That means our packet decoder has to run as a single thread and be highly optimized for throughput.

We can, however, move everything else out to separate threads so that the core decoder can run as fast as possible. Packetry runs as three threads, each feeding data to the next:

  1. The capture thread deals with streaming captured packets from a Cynthion device over USB.

  2. The decoder thread processes captured packets, stores them and builds the capture indexes.

  3. The UI thread runs the user interface, reading from the indexes and stored packets to display the captured traffic in a human-readable view.

Cynthion Threading

A key feature of the design is that all the interactions between these three threads are lock-free: they cannot block each other. The capture thread supplies packets to the decoder thread through a FIFO queue. The decoder and UI threads use our own lock-free stream implementation, which allows a single writer and any number of reader threads to efficiently share a growing data stream whilst it is being buffered and written out to storage, then mapped back into memory as needed.

Keeping these threads decoupled from each other helps us ensure that capture will always continue to run at a consistent throughput, no matter how complex the the traffic is or what analysis is being done in the UI.

Head to Head

So how fast is it? To give a quick illustration, here’s Packetry and Wireshark loading the same file, side by side. The file is a 300MB capture in pcap format of a HackRF in use.

Packetry finishes loading the file 10x faster — but you don’t even need to wait for that to happen to start exploring the capture. The view is ready to interact with as soon as the first packets are decoded. That happens almost instantly, and you’re up and running immediately with a fully hierarchical, human-readable view of the traffic.

Trying it out

Packetry is still in active development and we don’t have releases or binary downloads yet. If you’re really keen to play with Packetry you can build it from source and try it out with the example capture files that are included in the repository for testing. Build instructions are in the repository.

HackRF One Availability Update

In December of 2022, we published a post about the HackRF One shortage and the hardware revision our engineering team completed so that we could continue manufacturing HackRF One. This hardware revision was necessary because we had difficulty sourcing critical components during the global chip shortage, mainly MAX2837- the RF transceiver IC used in every revision of HackRF One before r9. At the time of that post, we had a significant backlog of orders, and we were uncertain about how long production would take with COVID-19 slowing down operations at the factory in China. Today, we have good news: production of r9 went very smoothly, and the finished HackRF Ones started shipping to our warehouses in late February. As of now, all of the backorders for HackRF One have shipped to our resellers.

With over half of this last production sold and shipped due to the backlog, we are already preparing for a second 2023 production run in quick succession. Some lessons we learned from this HackRF One shortage are to invest in components early for products we know we want to keep producing and that components on the shelf are preferable to components on order if we can find them in stock at a reasonable cost. Fortunately, we found more MAX2839s (the substitute component for MAX2837 in r9) with good date codes and purchased them for a second production of HackRF One r9. We have also already purchased production quantities of several other HackRF One components that have very long lead times, like the clock generator chip, the CPLD chip, and the microcontroller. These components are on the shelf and ready for us to use in the upcoming production, so we don’t have any immediate concerns about unreliable chip distributor lead times impacting our production schedule. Most likely, it won’t be as easy to find more MAX2939s for future productions because that part is obsolete. That means there will only be one more production of r9, and subsequent hardware revisions will use MAX2837.

We are already ordering components with long lead times for HackRF One productions as far out as 2024. Before the chip shortage, it was entirely realistic to acquire all the components needed for HackRF One and complete a production run within six months. That is no longer practical because even though purchasing conditions are improving for some components, chip destributors are still quoting lead times of up to a year for several key HackRF One components. MAX2837 availability in particular remains scarce; the average lead time has tripled and the manufacturer price has nearly doubled. The MAX2837s we ordered in 2021 for Fall 2022 production have yet to arrive, although we do expect them to be delivered finally this summer. We plan to use those in a third 2023 production near the end of this year. We don’t know when (or if) things will return to normal with the chip market. So to prevent future production bottlenecks caused by one or two missing essential components, we will continue to plan manufacturing schedules and component orders further ahead of time.

We appreciate our resellers for their cooperation while we navigated the challenges presented by the global chip shortage, and their customers who waited patiently (some for months) for their HackRF One orders to be delivered. Thank you for being so supportive! We can’t understate this: you are the reason we are still here!

Free Stuff - February 2023

The February recipient for the Great Scott Gadgets Free Stuff Program is Mihajlo. Mihajlo is a student in Serbia who will be studying Electrical Engineering in college. He plans to use the HackRF One we are sending him to teach people in his community about SDR, RF, LRPT images from NOAA, and other fun signals. Mihajlo is also an open source contributer to projects focused on providing simple scripts and instructions to set up low-cost base stations. We are proud to support Mihajlo in his projects as he gives back to his community in so many ways!

Free Stuff - January 2023

The January recipient for the Great Scott Gadgets Free Stuff Program is Guillermo. Guillermo is from Spain. He had a career in computer security about ten years ago before switching to another career. He’s back now and excited to use the HackRF One we are sending him to explore interesting topics like RF, Lora, Zigbee, and BLE. We are happy to support Guillermo on his journey back into computer security.

Renaming LUNA Hardware to Cynthion

Note: This is a crosspost of a Cynthion update on Crowd Supply:

Until now, the name LUNA has referred both to our USB multitool hardware platform and to the USB gateware framework that supports it. From now on, we want these projects to have separate names. We’ve decided to name the hardware platform Cynthion. The gateware framework will continue to be called LUNA.

Why are we making this change?

This renaming is happening because we have often had conversations, both internally and with external folks, in which we’ve had to say, “Wait. Are you referring to LUNA hardware or LUNA gateware?” Additionally, we’ve repeatedly fielded questions from folks who have been confused about different features supported by the gateware framework vs. the hardware platform. One common point of confusion in conversation is that LUNA gateware supports SuperSpeed USB while the Cynthion hardware does not. Lastly, projects like ORBTrace and Amalthea use the LUNA gateware framework to drive their projects, but they do not benefit from the association with Cynthion. It would be nice for these projects if they could indicate that they are supported by LUNA gateware without making them seem like add-on boards for Cynthion. Meanwhile, Cynthion is no longer just a development platform for the LUNA gateware, it is its own product and we need a name to refer to just the hardware while in conversation.

What happens next?

In the next few weeks, you can expect to see the hardware design files move from the LUNA repository into a new Cynthion repository we will create in the Great Scott Gadgets organization on GitHub. Following that, you will see the hardware documentation migrate into a folder in the Cynthion repository. Before you receive your hardware, Cynthion, its enclosure, packaging, and marketing materials will be updated to reflect the new name.

All LUNA gateware framework materials will remain as they are in the LUNA repository. There should be no need for existing projects to change how they are interfacing with LUNA.

Why the name Cynthion?

When choosing a name for this hardware platform, we wanted to pick something moon-related like LUNA. As we scrolled lists of moon-related words, “apocynthion” and “pericynthion” stood out to us. We played with subwords like “pericynth” but as a team, we eventually settled on Cynthion. The word Cynthion means “related to the moon” and is derived from Cynthia, an alternative name for Selene, the Greek personification of the moon.

Free Stuff - December 2022

The December recipient for the Great Scott Gadgets Free Stuff Program is Shiva. Shiva is new to hardware and IoT. We have sent Shiva a GreatFET One so they can do some research on devices they have in their own home. We are looking forward to hearing about their results!

subscribe to GSG feed