Note: This is a crosspost of a Cynthion update on Crowd Supply: https://www.crowdsupply.com/great-scott-gadgets/cynthion/updates/cynthion-hardware-design-update.

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!

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.

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.

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.

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.

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.

Note: This is a crosspost of a Cynthion update on Crowd Supply: https://www.crowdsupply.com/great-scott-gadgets/luna/updates/renaming-luna-hardware-to-cynthion.

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.

We are happy to say that hardware revision 0.5 for LUNA has been completed and that revision 0.6 is well under way! Some highlights from revision 0.5 are an upgrade to using KiCAD 6, adding some of our planned part substitutions, and improving labeling. Full details of hardware revision 0.5 can be viewed in the GitHub pull request for that task https://github.com/greatscottgadgets/luna/pull/190. As for hardware revision 0.6, our current set of tasks can be seen in this GitHub issue: https://github.com/greatscottgadgets/luna/issues/185. Progress has been made on almost every item in the r0.6 checklist and we will check the items off as they have been finalized and put through our review process. We look forward to giving you more updates soon!

This is a cross post from our LUNA project page on Crowd Supply.

Global supply chain issues continue to be difficult to traverse, but once in a while we do get a little bit lucky! In a previous update [1] we mentioned that Lattice had pushed out the lead time on our FPGAs for LUNA from 30 weeks to 60 weeks. Well, the expected delivery date for those FPGAs got pushed out again. Thankfully, we were able to purchase another ECP5 part for the first batch of LUNAs from an authorized Lattice distributor in a 381-ball package rather than a 256-ball package. We already have the 381-ball FPGAs in hand, so we don’t have to worry about those lead times changing again. We are still waiting on other components though, so with this FPGA substitution our estimated shipping date for LUNA will still be December 2022.

Changes to LUNA

Both FPGAs are from the same manufacturer and are part of the same line. The firmware and software we are creating will work the same regardless of which of the FPGAs is present on a given LUNA board. The primary difference impacting LUNA is that the substitute FPGA is slightly bigger than the original FPGA we had picked out. The original FPGA was 14x14 mm and the substitute FPGA is 17x17 mm. To accommodate this change in size we expect to increase the board area of LUNA to 51x51 mm instead of its original 48x48 mm.

This change adds 297 millimetres squared of available space. 93 millimetres squared of the extra space will be taken up by the bigger FPGA which leaves 204 millimeteres squared to use. The Great Scott Gadgets team has not yet settled on what we will be doing with the extra space but we will update you all as soon as we finalize our decisions. If you would like to make requests for or share your thoughts on what to use this space for, please come discuss in our Discord server.

[1] https://www.crowdsupply.com/great-scott-gadgets/luna/updates/luna-delayed

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.

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!

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

Enclosure Update

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

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

Enclosure Modifications (?)

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

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

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

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

Case Contest Winner

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

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

Starting Great Scott Gadgets

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

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

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

Daisho

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

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

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

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

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

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

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

GreatFET

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

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

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

LUNA Hardware

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

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

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

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

The Impact of COVID-19

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

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

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

Team and Community Contributions

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

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

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

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

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

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

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

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

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

Thank You

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

Open source is at the heart of everything Great Scott Gadgets does. When we design hardware, we publish the KiCad design files, firmware, and software under open source licenses. We try to ensure the documentation, tutorials, research papers, and videos we publish are openly licensed as well. It is the GSG way. While preparing for this Crowd Supply campaign, we took our commitment to open source even further by ensuring the music used in our campaign video is openly available too.

As we started thinking about our campaign video, we began to wonder what music we should use. While electronica is a traditional choice, I thought we might consider a more diverse set of options, including classical or acoustic music. I started my search by investigating music inspired by the moon.

I looked through a list of moon songs for ideas but decided it would be too much of a hassle to get rights for a popular song. Then I looked at a classical list and realized I had sheet music for some of the pieces. I sat down at my piano and tried to play a few. Straithe was listening, and when I started playing Debussy’s Clair de Lune she immediately said, “Use that one.”

Shortly thereafter, I suggested Clair de Lune in a planning meeting with Elizabeth and Kate. They both thought the idea had some merit, but neither was excited about it. Elizabeth ended the debate by volunteering to take on the challenge of editing the video and making the final music selection.

A few weeks later, Elizabeth shared a draft video with us, and I was pleasantly surprised she had used Clair de Lune for the music! She said she had investigated a number of other options but kept coming back to Debussy. Although she didn’t favor Clair de Lune for the video at first, it was a piece of music she had always loved. The idea of accompanying LUNA with beautiful music inspired by moonlight grew on her. Unfortunately, we didn’t have rights to use the recording in that draft. We looked around for royalty-free options but couldn’t find any we liked.

At this point we briefly entertained the option of making our own recording. At least three of us in the company were theoretically capable of doing so, but it would have taken a lot of work. Practicing, tuning a piano, acquiring recording equipment, and setting it up would have required several days of effort before even starting the actual recording and editing. We felt it was more important to spend our time focused on LUNA development and preparation for production.

Then it occurred to me: We could hire my brother, David O. He’s a professional musician who could probably record the entire piece in one day. Normally most of his work is in musical theater, but during the pandemic musical theater hasn’t been a thing. Small gigs like this are more important to him now than they have been in the past, and we liked that our project would help support an artist. Additionally we realized we could pay him to release the recording for others to use! Great Scott Gadgets is not in the music business, but, as long as we were producing music, we wanted to do so in the most GSG way possible.

David considered recording with an acoustic piano but decided to use a digital keyboard instead. This process allowed him to edit nuances of his performance such as the timing or velocity of a single keypress and to share his work as a MIDI file. This appealed to the Great Scott Gadgets team as it is in the spirit of the Open Source Hardware Definition which requires design files to be published “in the preferred format for making changes”.

Please enjoy and use his recording, a portion of which is used in our video. In addition to the audio track, he has released the MIDI file that can be edited in sequencing software. When you listen, imagine the beautiful light of the moon or of the LEDs on LUNA!

Hi, friends!

As community manager for Great Scott Gadgets, one of my favourite tasks is finding answers to questions that come in through email, Twitter, GitHub, and Discord. Thankfully you all are great at asking questions, especially about the USB Type-C connectors on LUNA! In this blog post Michael Ossmann responds to most of the USB Type-C queries I’ve received (and asked) about LUNA in the last few weeks.

Community Question: Old pictures of LUNA feature Micro-USB connectors but the latest pictures show USB Type-C connectors. Why the change?

Kate’s original LUNA design used Micro-USB connectors, but we decided to switch to Type-C connectors a couple of revisions later. Based on the USB specification, Micro connectors may be the best choice for LUNA, but I don’t know anyone who actually likes them. They can be difficult to insert properly and they are less reliable than other USB connectors. Maybe the best thing about them is that the cable that tends to wear out and not the receptacle.

Straithe Question: So other than likeability, are there other reasons USB Type-C connectors were chosen?

Type-C connectors are more robust and easier to insert than Micro-USB, particularly since they function when inserted in either orientation. They have become quite common, so we think folks are likely to already have cables. Significantly, Type-C is the only connector specified for the recent USB 3.2 and USB4 standards, so we see it as the most future-proof option in regards to cable acquisition.

Straithe Question: Were there any concerns about switching to USB Type-C connectors?

Our biggest concern about switching to Type-C connectors was that it might give a false impression that LUNA supports SuperSpeed USB, often referred to as USB 3.0. We’ve noticed more and more USB 2.0 devices with Type-C connectors over the past couple years, so our hope is that few people would be confused by this.

Type-C connectors also cost more than Micro connectors, which was an important consideration for us since there are three of them on LUNA. One of the ways we have tried to make LUNA accessible is by making it affordable. Fortunately, we were able to find USB 2.0 Type-C connectors that cost less than USB 3.0 Type-C connectors that include SuperSpeed signals.

Community Question: Will LUNA be able to support SuperSpeed with software changes?

No. A Type-C connector can be used on a USB 3.0 device for SuperSpeed, but it can also be used on a USB 2.0 device such as LUNA at Low-speed, Full-speed, or High-speed. Although the LUNA software framework includes some experimental support for SuperSpeed USB on alternative hardware platforms, the LUNA hardware platform is a low-cost device supporting only USB 2.0 speeds.

Straithe Question: You’ve mentioned a number of different USB speeds. To recap, what are the different USB speeds and what USB versions do they line up to?

There are four speeds in the USB 2.0 and USB 3.0 specifications:

(Additionally there are extensions of SuperSpeed in USB 3.1 and above.)

Although the USB 2.0 specification updates previous specifications and includes both Low-speed and Full-speed, a lot of folks refer to High-speed USB as “USB 2.0”. Similarly, people often refer to SuperSpeed USB as “USB 3.0”, even though it can be found in various versions of the specification higher than 3.0. The USB 3.0 specification supplements USB 2.0, adding SuperSpeed signals on additional wires while following the USB 2.0 specification on other wires within the same cable.

Community Question: Does LUNA come with any cables?

Partly because of our switch to Type-C connectors and partly to save cost and packaging, we have decided not to include cables with LUNA. One of the reasons for this is that it is difficult to predict what cables folks will need for different applications. As an illustration, I used LUNA recently in-line on a connection between a PC and a HackRF One. This required four cables:

• A-to-C cable between the PC and LUNA’s Target C port
• A-to-Micro between LUNA’s Target A port and the HackRF One
• C-to-C cable between my laptop and LUNA’s Host port
• A-to-C cable between my laptop and LUNA’s Sideband port for programming

This particular selection of cables depended on the available ports on the laptop, the PC, and the HackRF One. In order to accommodate most of the combinations we anticipate, we would have to include at least half a dozen different cables, making LUNA needlessly expensive and its packaging overly bulky. Instead we decided to keep LUNA small and affordable by relying on LUNA users to acquire their own cables for their individual needs.

Community Question: Does LUNA pass through SuperSpeed signals when used as a USB analyzer?

To use LUNA as a USB analyzer, you use one cable to connect a USB host to LUNA’s “Target” Type-C port and another cable to connect a USB device to LUNA’s “Target” Type-A port. Both of those ports on LUNA are USB 2.0 connectors, so they only pass through the USB 2.0 data signals. LUNA does not pass through SuperSpeed signals or any of the ancillary signals supported on some Type-C devices such as those used for Power Delivery (PD) communication.

Community Question: I guess LUNA doesn’t have any PD capabilities then?

Although we don’t pass Power Delivery signals through LUNA, the hardware is designed to have some ability to transmit and receive PD signals:

We added these capabilities to the hardware design when switching to Type-C connectors, but we currently do not have a plan to implement gateware for PD. If you have a specific use case for which you would like software support, please let us know. At a minimum it will be possible to implement your own PD solution in nMigen. Note that LUNA’s Type-C ports are not tolerant of voltages above USB’s standard 5 V, so some PD experiments could put your LUNA in danger of overvoltage.

For more sophisticated PD testing and experimentation, including passive monitoring, I recommend checking out Rod Whitby’s USB-PD Add-On for Glasgow currently in development. Rather than adding similar circuitry to LUNA (and making LUNA larger and more expensive), we think this is a great application for a special-purpose design such as Rod’s board.

Community Question: Does LUNA support any USB Alternate Modes?

LUNA’s hardware design also permits 3.3 V I/O on the SBU1/SBU2 signals of all three Type-C connectors. This should enable experimentation with some lower speed Alternate Modes such as those used by some serial debuggers, but it will not support video modes.

Straithe Question: Thank you for answering our questions today. Do you have any last comments?

Thanks for curating these great questions! I just want to give a big thank you to everyone who is supporting LUNA on Crowd Supply. We truly appreciate each and every one of you!

Background

Initially, we planned on creating a laser-cut acrylic enclosure for LUNA. We had started sketching out a design when Michael Ossmann saw the beautiful design work Timon of Diodes Delight did on the milled aluminum case for Glasgow. Mike contacted Timon right away to ask for his design help as we knew a milled aluminum case would be a high quality option, more durable and protective than our original layered acrylic idea. Soon after, Timon accepted our request and started working on a case.

Progress

We have worked with Timon on the case design over the past few months, which has been a delight. He did a nice job of shaping the interior to maximize mass and give the case a comfortable (yet light) weight while still accommodating all of LUNA’s components. Timon even found light pipes that suit LUNA’s tightly spaced LEDs, which are less than 2 mm apart! Recently, Timon sent us the following 3D renders, and we knew we had our design.

A little over two weeks ago we approached our manufacturers with the case design to get the first prototypes made. In the time since the campaign launched, we have received pictures of the freshly milled top pieces of the enclosure.

Once milling is finished, these prototypes will be sandblasted, anodized, and laser etched. Sandblasting will remove the tool marks from the interior of the cases, anodizing will coat the aluminum and turn it black, as shown in the 3D renders. Laser etching will add the labels, GSG markings, and other symbols to the case.

We really look forward to receiving these prototype cases soon, testing them, and uploading pictures/updates for you shortly after!

Today marks the day that our campaign to fund LUNA launches on Crowd Supply! Over the next six weeks (from July 15th to August 26th) anyone will be able to pre-purchase a LUNA and support our goal of bringing this low-cost multi-tool for building, analyzing, and hacking USB devices to market. If you want to learn more about LUNA, we have a detailed writeup of the device on our Crowd Supply campaign page that we hope you will read!