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!
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.
Note: This is a crosspost of a Cynthion update on Crowd Supply: https://www.crowdsupply.com/great-scott-gadgets/cynthion/updates/updated-cynthion-enclosure
About a year ago, we announced an FPGA substitution on the Cynthion project due to supply chain issues. Since then, the Great Scott Gadgets team has redesigned and enlarged the Cynthion board to accommodate the larger FPGA, and Timon has adapted the enclosure to fit the larger board.
The updated Cynthion enclosure measures 60 mm (2.36 inches) in width, 72 mm (2.83 inches) in length, and 15 mm (.59 inches) in height. The weight of the enclosure with a Cynthion inside and all hardware, comes to 99.5 grams. In comparison to the previous enclosure, the new one is 8 mm wider, 7 mm longer, 1 mm taller, and 3.5 grams lighter due to extra milling for Pmod connectors and other small changes.
Once I received the 3D model files from Timon, I got to work designing the final graphics for the Cynthion enclosure, which are shown in the image below.
In this image, the black lines are the edges of the enclosure, connector holes, and hardware holes. The blue text and images are the graphics and labels that will be etched into the case. Once etched, these graphics will appear white-grey in colour. A rendering of the case is below:
The differences from our early enclosure design include a complete change in graphics on the top of the case, moving the port labels to the edges, adding labels for the Pmods, and a debossed (not etched!) Great Scott Gadgets logo on the back.
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!
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.
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:
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.
The Great Scott Gadgets engineering team will develop URTI in eight overlapping phases. These phases will include:
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.
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.
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!
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.
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.
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
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
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.
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?
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.
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.
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:
The capture thread deals with streaming captured packets from a Cynthion device over USB.
The decoder thread processes captured packets, stores them and builds the capture indexes.
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.
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.
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.
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!
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!
subscribe to GSG feed