Replies: 23 comments 1 reply
-
|
Hi @gitmodimo, what about using USB3 to LAN adapter as a first milestone and after developing and validating the code changes, we proceed with a V2 board? What do you suggest? |
Beta Was this translation helpful? Give feedback.
-
|
Not sure what you mean. Correct me if i am wrong - Radar is USB device. USB3 to LAN adapters are for host. At least most of them. |
Beta Was this translation helpful? Give feedback.
-
|
Hi @gitmodimo...Are you able to make all the changes? (Schematics, Layout, HDL and GUI).... |
Beta Was this translation helpful? Give feedback.
-
|
If you're going to add a lan port you may as well make it a POE port. |
Beta Was this translation helpful? Give feedback.
-
That would mean whole Radar would have to fit ~71W power budget. Accoring to Power Management we are at 61W electronics + 80W Stepper motor.
Well yes although I never did design pcb in eagle. I am familiar with Altium and KiCad. Given open source nature of this project have you considered migration of PCB documents to KiCad? Eagle free does not allow more than 2 schema sheets. When I imported current files into KiCad the result was decent although design looks not finished. I have few questions:
Find attached FPGA comparison table. I think everything needs to be considered including budgeting- but given the price of analog I don't think digital should be the place to cheap out. Answering potential follow-up questions: I can help with setting up yocto linux etc. |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
Perhaps one idea to consider is to use a "Raspberry PI 5" type of mini PC (if sufficient capacity) to foward the raw feed of data via LAN/WIFI/5G when deployed in a more permanent location outside that doesn't require direct simple connection during test/research. |
Beta Was this translation helpful? Give feedback.
-
|
@jorgeacf nice suggestion...could you explain in more details? |
Beta Was this translation helpful? Give feedback.
-
Per port. You could split the stepper motor off onto its own board, which would also allow you to more easily isolate any rf problems you might have messing with the motor control. Anyway, just a thought. |
Beta Was this translation helpful? Give feedback.
-
|
@NawfalMotii79 looking at protocol transition to UDP should be pretty straightforward. If you ever decide to revisit adding LAN or pivoting to SOM in next generation let me know I am happy to take part in it. |
Beta Was this translation helpful? Give feedback.
-
|
@gitmodimo thank you. How much time do you need to make the appropriate changes to the Schematics and Board Layout, the verilog modules and the GUI script? |
Beta Was this translation helpful? Give feedback.
-
|
@NawfalMotii79 it depends which version we follow. If we switch to kicad schematic +PCB should not take long to just add rgmii. Need to identify exact IC and connection is straight forward. For eagle there might be steeper learning curve for me as I never used it. For xaui it's more work - different fpga is needed. |
Beta Was this translation helpful? Give feedback.
-
|
@gitmodimo I contacted @JJassonn69 about the changes he made to the FPGA verilog modules, I asked him to add a pull request to this repository. I'm waiting for his feedback. Concerning the Hardware, I'm receiving plenty of offers from people and institutions that are interested in funding some prototypes to be sent for free (hopefully) to beta testers |
Beta Was this translation helpful? Give feedback.
-
|
Why not something like a m23 cable? |
Beta Was this translation helpful? Give feedback.
-
|
Before discussing what type of interface is needed for the device, we should probably get a better idea of the data needed to be transmitted across the interface. Like what kinda of specifications we want to target for it (data size, latency, power specs if you wanna use POE). Some of this can probably already be answered, but its worth making sure everything is written down. Just changing the interface without a exact reason other than its more optimal (it probably is necessary) ain't great. Also this does feel like a unnecessary change for a product demonstration though, but I'm unsure what is necessary. |
Beta Was this translation helpful? Give feedback.
-
I'm throwing in the question of a potential sensor fusion use case, where several units and other sensors may be networked and controlled remotely. I'm not sure what kind of time synchronization such algorithms actually would need. Does anybody know? - I, naively, assume they generally can pattern match with some latency/jitter window just fine. In such kind of deplomynet scenarios Ethernet+PoE just seems the most available wiring, regardless of actual plug termination (RJ45 / M12-A / M12-X). Component availability seems a high ranking requirement for the project overall, regardless of actual transmission requirement. As for the actual data stream, I guess at the upper boundary it's downstream coordinates & vectors at sample frequency. I, naively again, assume packet loss is generally not a problem in sensor fusion (hence e.g. UDP) - even upstream, e.g. for stepper motor setpoints, no big deal. If the remainder problem now is the stepper motor, I'd rather think in terms of solar panel / battery module / long DC/AC wire rather than overconstraining PoE selection. Agreed: not for a tech demonstrator. But maybe there's a pathway for preparatory work. And if it turns out smooth going, adoption ahead of schedule. Question: would anything in the radio frontend benefit from the higher line voltage on PoE (48V)? |
Beta Was this translation helpful? Give feedback.
-
|
Hi @gitmodimo, Thank you for your detailed analysis and generous offer. You have clearly thought deeply about this, and your proposal to add a LAN interface (RGMII for 1GbE or XAUI for 10GbE) is technically sound. Let me respond to your key points and propose a path forward. Where I Stand
Proposed Path Forward
Answers to Your Specific Questions1. Timeline for PCB spin?
2. USB protocol description? Yes, see attached 3. FPGA selection – are we fixed on XC7A50T-2FTG256I? For V1, yes. For V2, I am open to changing the FPGA. Your SOM suggestion (Zynq or Kintex) is compelling and would enable standalone operation with web GUI. However, this is a significant pivot that would delay production by months. Proposal: Keep V1 as-is for Crowd Supply. Develop V2 with SOM in parallel. 4. Migration to KiCad? I am open to this. Eagle free has limitations. If you (or someone in the community) can migrate the PCB files to KiCad, I will accept the pull request. Response to Other Comments
Request to YouYou asked: "Is there timeline for when hardware will be available?"
If you are willing to lead the V2 design (schematics, layout, Verilog, GUI), I will support you. I can provide:
Would you be open to this? Summary
Thank you again for your technical depth and willingness to contribute. This is exactly how open-source hardware should evolve. Best regards, Nawfal Motii PS: In order to use multiple AERIS-10s in a synchronized way, I'm considering the add of a fiber optic sub-module to the main board. I will dedicate the next week to studying the theory behind this topic |
Beta Was this translation helpful? Give feedback.
-
|
Hi @NawfalMotii79, before we commit to anything I think we need to align on what we actually expect from V2. @jpaj77062-glitch raised good questions, and my position is that the current V2 framing isn't the right direction — let me explain why. The connectivity question 1GbE and 2.5GbE are popular in consumer hardware but neither covers our 400 MB/s (~3.2 Gb/s) target. 5GbE is theoretically enough but has become niche — it's actually easier to source 10GbE hardware than 5GbE. So the realistic options collapse to two:
The hardware question Two paths here as well:
Why I think SOM + 10G is the right call Layout-wise, fanning out two B2B SOM connectors is actually easier than routing a discrete FPGA with high-speed Ethernet. There are reference designs available — AMD's own licensing for derivative boards is murky, but Antmicro publishes an Apache-licensed Kria K26 devboard (https://github.com/antmicro/kria-k26-devboard) we can trim down. Trimming an existing design is much easier than creating one from scratch, and we get USB 3.1 + 1GbE out of the box. Adding 10G as a second port becomes straightforward: the full K26 has capable transceivers on the second connector, and with MCDMA IP there's a full Linux kernel stack available. The high-speed datapath would mux between DMA (to ARM/Linux) and a raw UDP streaming path out the 10G port — so consumer users get 1GbE compatibility, and advanced users get a 10G interface that's both Linux-aware and capable of raw UDP streaming. On top of that we get a quad-core ARM that eliminates the STM and roughly 5x the FPGA resources. By contrast, FPGA swap + 1GbE doesn't justify the effort given the bandwidth ceiling, and FPGA swap + 10GbE isn't meaningfully less layout work than the SOM pivot but comes with real downsides: no Ethernet stack in the FPGA (we'd integrate or license a MAC), limited FPGA resources, additional MCU load, and open questions about whether MCU coordination becomes a bottleneck. Answering your questions directly
|
Beta Was this translation helpful? Give feedback.
-
Real-Time Signal Processing: FPGA vs. Python for Radar SystemsOverviewRadar signal processing demands low latency and deterministic timing. This report compares two approaches: FPGA (hardware-accelerated) and Python (software-based on CPU/GPU). Performance Comparison
Radar Pipeline: Where Each Excels
Latency Breakdown (AERIS-10X Example)
Result: FPGA is approximately 200x faster for real-time processing. Can Python Be Used?Yes, but with caveats:
Hybrid Architecture (Recommended)
This is exactly the architecture used in AERIS-10. Typical Resource Usage (FPGA)
When to Choose Each
ConclusionFPGA is the right tool for real-time radar signal processing. Python cannot match the latency, determinism, or throughput required for high-performance radar. However, Python remains valuable for post-processing, visualization, algorithm prototyping, and non-real-time applications. The AERIS-10 approach – FPGA for the real-time pipeline, STM32 for tracking, Python for GUI – offers the best of all worlds. Therefore, the idea of sending raw ADC data to a SOM or a CPU for RADAR processing is not viable. Best regards, Nawfal Motii |
Beta Was this translation helpful? Give feedback.
-
@gitmodimo I wondered, as well, how FPGA latency targets should be made obsolete. Did you think in the direction to complement with a SoM instead of STM to have PHY and compute without the need for deep redesigns? And linux real time OS for ease of software defined capabilities? - Depending on the cost delta, that might be an interesting capability for the ecosystem, imo. |
Beta Was this translation helpful? Give feedback.
-
I am not sure it is clear from my proposal. Kria som is an mpsoc that is fpga +arm highly integrated in one chip. The fpga (PL) is roughly 5 times more capable then current fpga and arm (PS) to PL interface gives direct fpga access to ddr memory from fpga and arm. Versatility of kria som is highly underrated especially in this scenario. |
Beta Was this translation helpful? Give feedback.
-
|
Throwing my hat in here again, and perhaps an SFP+ port might be the right call. This will give you the bandwidth necessary plus allow people to even use a fiber module if they wanted, which could also alleviate common mode current issues on standard wired network cable. |
Beta Was this translation helpful? Give feedback.
-
This would also add the option of running a DAC Cable for shorter runs or Fiber for those that seek galvanic isolation without the loss of bandwidth. |
Beta Was this translation helpful? Give feedback.
-
|
In addition to making repairs easier. By offloading network management to the SFP+ module if/when something goes bad it's a matter of plugging a new one in, not replacing an entire board. If someone were to permanently mount one on a mast this would also alleviate lightning issues whereas a standard ethernet cable would just transmit the doom straight into your computers/switch gear. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Have you considered adding LAN interface? USB is kind of limiting factor here - radar has to be outside and USB cabling usually cannot be to long. I've had good experience with implementing https://github.com/alexforencich/verilog-ethernet/. Artix-7 seems to be supported(two example designs). With XAUI it should even be possible to achieve 10GBE and stream samples over UDP. Is hardware design locked at this point?
Beta Was this translation helpful? Give feedback.
All reactions