The August recipient for the Great Scott Gadgets Free Stuff Program is Trevor! Trevor is working on a project called Hack365 where he is attempting to blog about one hack (or make or break or fix or learn) each day until next DEF CON. We are excited by how enthusiastic Trevor is about documentation, sharing his experiences with the community, and learning new things. One of the projects Trevor plans to take on is learning about his ceiling fan’s RF receiver, which is an excellent place to start when you are learning about RF. Trevor plans to share his progress with the DEF CON group DC612 as he progresses. We wish Trevor happy hacking and hope he continues to share what he learns so all of the community can benefit!

Back in 2019 over on Hackaday, Mike Szczys wrote a piece called “Hands-On: GreatFET is an Embedded Tool That Does it All”. This article covers:

• a review of the GreatFET One hardware,
• our matching GreatFET One sticker,
• the wiggler,
• a test run of GreatFET One and an I2C OLED display,
• Facedancer and USB emulation, and
• how to do a quick recovery using DFU.

We hope you check it out!

The July recipient for the Great Scott Gadgets Free Stuff Program is Manoj Kumar Mondal from India! Manoj requested a HackRF so he could take some security courses at his university; having a HackRF is a pre-requisite for the course. We look forward to hearing from Manoj as he progresses through the course!

The June recipient for the Great Scott Gadgets Free Stuff Program is Kyle from SkullSpace. SkullSpace is a hackerspace located in Winnipeg, Manitoba, Canada. Kyle plans to put together a group of SDR and wireless enthusiasts. This group will put on classes, host labs, and lead projects that help the community learn more about SDR and wireless. If you are ever in Winnipeg on a Tuesday evening we hope you take advantage of SkullSpace’s open night and check out their hackerspace!

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

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

The May recipient for the Great Scott Gadgets Free Stuff Program is C.J. who is a Broadway tour sound engineer that works backstage with wireless RF microphones. Every week the tour moves to a new location and C.J. has to re-coordinate wireless frequencies for the show. He’s hoping to use the HackRF we are sending him to improve his RF monitoring and create more precise RF layouts for the travelling shows.

The April recipient for the Great Scott Gadgets Free Stuff Program is Anmol, a high school student in India! Anmol learned about Great Scott Gadgets after watching Michael Ossmann’s video on complex numbers, which is part of his Software Defined Radio with HackRF training video series. Anmol is the IT president of their school and is excited to use the HackRF we will be sending them to share the world of Software Defined Radio with other students.

The March recipient for the Great Scott Gadgets Free Stuff Program is Katerina Autumnrain! Katerina had such an enthusiastic and detailed application to the Free Stuff Program that we just had to send her the HackRF One she requested. In her application she had this to say:

“I believe that the HackRF could enable me to open up the oft more confusing aspects of radio, particularly modulation modes like QAM and digital systems like satellites and P25/DMR. I’d also like to try and promote the higher frequencies (33cm and beyond). Once the bandwidth and frequency limitation is lifted I can more or less apply that knowledge I’d gain from those systems and make both learning experiences and some pretty neat tech for people to explore, utilize, and build themselves. I ultimately believe I could cultivate a sort of resurgence in radio geekery in my area, as it unfortunately seems to be on the downturn somewhat, and promote higher levels of curiosity.”

It’ll be really exciting to follow Katerina’s updates on her HackRF-fueled radio journey!

The February recipient for the Great Scott Gadgets Free Stuff Program is Matthew Hilts! Matthew is a student at the University of Dayton who will be spending his Spring semester learning about and using GNU Radio. To help enhance his studies we have sent Matthew a HackRF One. We look forward to hearing about what he learns!

Note: This is a crosspost of a Cynthion update on Crowd Supply: https://www.crowdsupply.com/great-scott-gadgets/luna/updates/hyperram-controller-for-usb-analysis.

One of LUNA’s core features is the ability to perform protcol analysis of USB 2.0 low-speed, full-speed, and high-speed. For most target devices, LUNA can endlessly stream the capture directly to a host PC over its own high-speed port. However, for high-bandwidth target devices that can’t be streamed in real-time, LUNA has 8 MiB of memory on board to buffer captured data before sending it upstream.

On LUNA we’re using HyperRAM, a type of pseudo-static RAM, which is capable of achieving relatively high speeds while being much simpler to work with than DRAM as it handles refreshing of the memory array by itself. Recently we’ve been working on our Amaranth gateware that interfaces with the RAM, implementing support for memory-space reads/writes and speeding it up so that we can keep up with USB analysis.

Speed

For USB analysis, we need to be able to stream data through the RAM at a nominal 480 Mbit/s but, since the ram is half-duplex, we need to hit at least double that. We also need to allow for some overhead for the RAM protocol. In our controller we run the RAM at 120 MHz DDR for a nominal rate of 1920 Mbit/s, which gives us plenty of margin to keep up with high-speed USB.

The Lattice ECP5 FPGA used on LUNA has a nifty feature in the I/O cells called gearing, which serializes/deserializes data to allow the I/O pin to run at a high speed without requiring the FPGA fabric to match it. For our HyperRAM controller we use the IDDRX1 and ODDRX1 cells, which take a 2-bit signal and read from/write to I/O pin at double the speed.

Timing challenges

A challenging part of interfacing with HyperRAM is the wide range of data-valid timing. The datasheet specifies that the data lines can be valid anywhere between 1 ns and 7 ns after a clock transition, and become invalid anywhere betwen 0.5 ns and 5.5 ns after the next clock transition. Running at 120 MHz the time between clock edges is only 4 ns, so this means that there is no fixed window in which to sample! The diagram below shows some examples of how the data-valid window could be shifted relative to the clock:

We solve this by using the ECP5’s I/O delays to shift the data-valid window and align it with a clock edge. These delays are variable so we can adjust them during operation to find the range of values that result in successful memory reads, then pick the value in the middle for the ideal sampling point.

Debug tooling

For projects like this, it’s important to have good tools for debugging! As part of this work we wrote a HyperRAM decoder for glscopeclient, an open source frontend for oscilloscopes. This makes it easy to interpret waveform captures from the real hardware, and verify that everything is working as expected. The decoder has been merged upstream, so it’ll be available with any recent glscopeclient install.