Wild hardware flex for a garage project. Reverse-engineering the Pi 5's MIPI to push 5.6 Gbps from custom MASH sigma-delta ADCs to a Lattice ECP5 FPGA to the Raspberry Pi is serious engineering. The idea that the RF receiver looks like a "camera" to the Pi while the transmitter is a "display" is super creative. Getting a 1.5 kW, 240-antenna EME array for $2,499 is actually cheap for something like this.
Their standalone 4-antenna tiles (https://moonrf.com/updates/) show off some killer apps, like 30 fps spatial RF visualization and NEON-optimized drone video interception.
I'm rolling my eyes at the "Agentic Transceiver" part, though. It is highly doubtful that an onboard AI casually writes, debugs, and compiles a real-time C app with analog video color sync recovery and decode in ten minutes.
> Reverse-engineering the Pi 5's MIPI to push 5.6 Gbps from custom MASH sigma-delta ADCs to a Lattice ECP5 FPGA to the Raspberry Pi is serious engineering
Using video interfaces to transfer arbitrary data at high speeds is becoming a common trick for cheap boards with limited interfaces. Video inputs and outputs are generally highly mature and optimized to avoid dropping frames because everyone wants reliable video. Putting arbitrary data into video IO pipelines is a cheap way to get high speed IO through standard interfaces.
There is a cool project that uses cheap HDMI to USB capture devices for high speed data transfer out of cheap FPGA boards that have HDMI output [ https://github.com/steve-m/hsdaoh ]
In a perfect world, using PCIe directly would be a much better solution for a project like this. Having access to PCIe DMA support directly without relying on video IO peripherals is helpful for high speed ADC/DAC applications like this. It would also make the board more portable to other SBCs.
The ECP5-5G can do PCIe 2.0 x2 or PCIe 1.0 x4 which would provide around 8Gbps of data transfer. The problem is that the Raspberry Pi 5 only exposes a single PCIe lane to the user. The other 4 PCIe lanes of the Raspberry Pi 5 SoC are routed to the RP1 chip, which has the MIPI and CSI interfaces that are used in this project. So the data is going through a convoluted path instead of being connected to PCIe directly.
I would have to look at the details more closely, but even using the PCIe 2.0 x1 port (around 4 Gbps after overhead) on the Raspberry Pi would be close in bandwidth to the 5.6 Gbps number they give for their custom MIPI solution.
I think the Raspberry Pi 5 is a good first choice for most projects because it is widely support and has the largest community, but for a project like this the benefits of moving to a different SBC with PCIe 2.0 x2 would have been helpful. Keeping the project semi-independent of the SBC has a lot of benefits.
> Using video interfaces to transfer arbitrary data at high speeds is becoming a common trick for cheap boards with limited interfaces.
There is a line in the book Accelerando about how evolution did this with biological vision.
It's basically the highest bandwidth sense we have and evolved AFTER smell (chemical based) and auditory (gas pressure based) senses.
unfortunately the ECP5-5G FPGA (with the SERDES/PCIe option), costs way more than the ECP5 (without SERDES). The Pi-5's MIPI interfaces gives you 8 parallel LVDS lanes that can run at 640 MHz each which is manageable for a cheap FPGA.
While true I do worry that it's mandating a pi 5 for each tile? And who knows how specific it is to the 5. Doesn't seem very open relative to something like a usb superspeed, pcie, or 10gbe. USB could be maybe done with the LIFC-33U depending on I/O limitations. PCIe can be done on various FPGAs in the lattice lineup and others.
If you use PCIe, theoretically you don't need to reverse engineer how they implemented because you're not at the edge of the spec like they are here.
That said, I've thought about doing what they're doing countless times and it is nice to see it would work.
> While true I do worry that it's mandating a pi 5 for each tile? And who knows how specific it is to the 5.
In the multi-tile array it apparently still only needs one Pi [1] as the FPGAs do the heavy lifting.
[1] https://moonrf.com/updates/
correct, one Pi-5 for the MoonRF. The beamforming computation is done digitally "on the fly" in round-robin across the sixty QuadRF boards.
> Getting a 1.5 kW, 240-antenna EME array
It says 1W TX power per antenna. So the 240 antenna array which draws 1500W has a transmit power of 240W.
EIRP. There's some gain involved.
I think they're claiming the actual transmit power is 240W (23.8 dBW), and the EIRP is 63.1 dBW.
I am sort of skeptical of the claimed gain... even at 6GHz, you need a 2-meter parabolic reflector to get 40dB, the array is 1/10th that diameter. EDIT: Ignore this second paragraph I misread the spec page.
The MoonRF array is a full 1 meter diameter as shown on the page
I'm asleep and I misread that as 10cm. Thanks.
I'm struggling to understand the signal chain or antenna architecture here. If those two MAX chips are 2829s this would be 2x2 mimo per tile but I'm not super familiar with that product line and the PCB layout looks like a 4x4 setup.
And yeah, the agentic stuff is dumb, I've played a ton with doing low level SDR work on Opus 4.6 and it's truly ass.
Also, the "can't radar, plz don't ITAR" is horseshit. Some basic fw tweaks and you could get this to be, at the very least, a sweet FMCW setup.
MAX2850/2851 4x4. Also, large radar stuff is more nuanced than "just some fw tweaks" as you claim. Same as Facebook is not just some PHP scripts...
I used to work radar systems. The point being that the hardware is fully capable. The software side is quite well understood at this point. There will be plenty of repos floating around in a year to turn this into an airborne drone SAR or whatever. Functional range resolution will be around 4m but that's plenty for most shenanigans.
At a functional range resolution of 4M would it even qualify as violating ITAR even if it was tweaked to do so?
> Also, the "can't radar, plz don't ITAR" is horseshit.
My assumption is that they're trying to avoid crossing a legal line, as opposed to being personally invested in the idea of preventing radar use by a determined hobbyist.
ITAR feels a lot like Bernstein v. US all over again. Until very recently, everyone who can do anything that would be covered by ITAR was a giant corporation that likes the moat that regulations create, so it's unthinkable to challenge it. But that is changing, just like cryptography was in the early 90s.