Great Scott Gadgets

open source tools for innovative people

Free Stuff - August 2023

The August recipient for the Great Scott Gadgets Free Stuff Program is The Factory, a student-run hardware design lab at McGill University in Montreal, Canada. The Factory aims to give students access to advanced tools for their hardware projects, space to work on their projects, and support in developing technical skills.

The Factory has previously offered workshops on VIM, VHDL, C, and PC building. They also run a Hackathon called The Forge. In one instance of The Forge students formed teams and built a line tracing robot to race against the other teams. In non-event related times, students in this lab have completed projects such as an IoT system for the trash cans on the McGill campus to alert the cleaning teams when a trash can is full, custom video game controllers, and an automated watering system for plants. About 40-50 students currently frequent The Factory, and they are all passionate about electronics, hardware, and related research.

We are sending The Factory a HackRF One so their lab members can fulfill their hopes of offering workshops and creating materials on wireless systems, satellite communication, and spectrum analysis. Good luck and have fun!

Great Scott Gadgets is now on Mastodon

Great Scott Gadgets is on Mastodon! You’ll get a lot of the same information as you get on our other social media profiles, but if Mastodon is your platform preference, we now have you covered.

GSG on Mastodon

Free Stuff - July 2023

The July recipient for the Great Scott Gadgets Free Stuff Program is Joona. Joona plans to use the YARD Stick One we are sending him to develop and test radios. He will be writing documentation and creating tutorials on his projects.

Free Stuff - June 2023

The June recipient for the Great Scott Gadgets Free Stuff Program is Daniel. Dan is planning to use the HackRF One we are sending him to run workshops in his school and with his amateur radio group. He will also be creating videos with his new HackRF One on his YouTube channel “Radio Dan ZL2DTL”. Please welcome Radio Dan to the software-defined radio community!

Free Stuff - May 2023

The May recipient for the Great Scott Gadgets Free Stuff Program is the UCLA IEEE Wireless, RF, and Analog Project (WRAP). Participants in this club have the opportunity to learn hands-on radio engineering skills by designing, building, and testing a 2-way radio system capable of operating in the 100s of MHz. Through this project, students can learn digital and analog radio techniques like implementing filters and a mixer from discrete diodes and using coils for up/downconversion. WRAP asked for a HackRF One to aid in debugging wireless links, where they will use the HackRF One both as a modulated waveform generator for receiver testing and a real-time spectrum analyzer for transmitter and device debugging. We really look forward to seeing their end projects.

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.

subscribe to GSG feed