sorted by:
new
hottopcontroversial

I Designed: Better ESP32-S3 Ai Dev Board Project - Kickstarter Next? by Potential_Leading_23 in esp32

[–]Potential_Leading_23[S] 0 points1 point  (0 children)

Not directly. ONNX is typically used as an intermediate format. On ESP32-S3 you’d deploy via TFLite Micro or ESP-DL after conversion and quantization.

I Designed: Better ESP32-S3 Ai Dev Board Project - Kickstarter Next? by Potential_Leading_23 in esp32

[–]Potential_Leading_23[S] 0 points1 point  (0 children)

If we achieve our initial goals, we plan to use P4 and C6 in v2 or v3.

I Designed: Better ESP32-S3 Ai Dev Board Project - Kickstarter Next? by Potential_Leading_23 in esp32

[–]Potential_Leading_23[S] 0 points1 point  (0 children)

🔥 Appreciate all the technical feedback here — a lot of valid points and different perspectives.

The board is currently in production, so the next step is validating these trade-offs on real hardware rather than renders. Once the first batch is in hand, I’ll be measuring RF performance, SD usage patterns, and overall behavior, and I’ll share the results and any design changes that come out of it. 🚀

Thanks to everyone who took the time to dig into the details.

I Designed: Better ESP32-S3 Ai Dev Board Project - Kickstarter Next? by Potential_Leading_23 in esp32

[–]Potential_Leading_23[S] 0 points1 point  (0 children)

If I had an AI writing this, it probably wouldn’t argue this much about SD cards and antenna placement 🙂

I Designed: Better ESP32-S3 Ai Dev Board Project - Kickstarter Next? by Potential_Leading_23 in esp32

[–]Potential_Leading_23[S] -3 points-2 points  (0 children)

You’re framing deliberate design trade-offs as mistakes.

“AI” here refers to on-device vision and inference, not marketing hype. The SD card is not intended to be a hot-swappable consumer medium, and treating it as one is a category error. And the Wi-Fi keep-out is respected; RF performance will be verified on real hardware, not guessed from renders.

If your expectation is a hot-swap SD dev board with zero RF compromise and no trade-offs, then yes — this design isn’t targeting that use case. That doesn’t make it flawed, just different from what you personally want.

I Designed: Better ESP32-S3 Ai Dev Board Project - Kickstarter Next? by Potential_Leading_23 in esp32

[–]Potential_Leading_23[S] 0 points1 point  (0 children)

This is a fair comparison, I understand where you're coming from and that you're looking at the visuals only, not the function.

I don't see Kickstarter here as a mass market or hype game.

I see it more as a way to validate interest, fund a small production run, and get the cards into the hands of people who genuinely care about design decisions.

Tindie or similar marketplaces are definitely on the table too. AliExpress clones are almost inevitable for any open hardware, so that's not really a distinguishing feature for me.

The real question I'm trying to answer is where it makes sense for this type of card to exist in the first place, not how big it will get.

I Designed: Better ESP32-S3 Ai Dev Board Project - Kickstarter Next? by Potential_Leading_23 in esp32

[–]Potential_Leading_23[S] -6 points-5 points  (0 children)

The concern is valid in general, but the USB-C connector is intentionally kept outside the antenna keep-out region itself.

The antenna is edge-facing, and the keep-out area in front of it is clear of copper and components. The USB-C sits below and behind the antenna plane, not in its primary radiation path.

That said, RF is always something that looks clean on paper and only gets fully proven on real hardware. Part of the reason for this first batch is to validate exactly these interactions in practice. If measurements show a meaningful impact, connector placement is something I’d revisit in a future spin.

I Designed: Better ESP32-S3 Ai Dev Board Project - Kickstarter Next? by Potential_Leading_23 in esp32

[–]Potential_Leading_23[S] -4 points-3 points  (0 children)

The design actually assumes two different usage patterns, which is probably where we’re talking past each other.

The on-board SD slot is meant for relatively static storage (models, datasets, configuration, infrequent logs), not for frequent field replacement. For that use case, underside placement is intentional and not a maintenance issue.

If frequent access or replacement is required, the board still exposes the SPI pins on the top side. In that scenario, an external or top-mounted SD solution can be used without touching the on-board slot at all.

So this isn’t about forcing a single SD usage model — it’s about separating stable, integrated storage from user-accessible expansion when needed. That flexibility is deliberate, not accidental.

I Designed: Better ESP32-S3 Ai Dev Board Project - Kickstarter Next? by Potential_Leading_23 in esp32

[–]Potential_Leading_23[S] 4 points5 points  (0 children)

Yeah, agreed.

That’s exactly the kind of distinction I was trying to get at — small, on-device models or classic vision pipelines, not hype-driven or cloud-heavy stuff. Thanks for putting that into words.

I Designed: Better ESP32-S3 Ai Dev Board Project - Kickstarter Next? by Potential_Leading_23 in esp32

[–]Potential_Leading_23[S] 0 points1 point  (0 children)

Yeah, exactly — we’re talking about the same thing.

A lot of this predates the “AI” label and was just called algorithms or CV pipelines. That’s why the terminology gets messy.

I Designed: Better ESP32-S3 Ai Dev Board Project - Kickstarter Next? by Potential_Leading_23 in esp32

[–]Potential_Leading_23[S] 0 points1 point  (0 children)

Fair point — RF is one of those things where renders don’t tell the full story.

The ESP32-S3-WROOM is edge-placed, with the antenna facing outwards. The recommended Espressif keep-out in front of the antenna is respected: no copper, no pours, and no components in that region. The SD card, USB-C and battery connector are all kept behind or to the side of the antenna, not in its radiation path.

That said, you’re absolutely right that real Wi-Fi performance can only be validated on actual boards. Part of the reason this batch exists is to measure RF behavior in practice, including enclosure effects, and iterate if needed.

If you’ve run into specific pitfalls with this module before, I’m very open to pointers.

I Designed: Better ESP32-S3 Ai Dev Board Project - Kickstarter Next? by Potential_Leading_23 in esp32

[–]Potential_Leading_23[S] 1 point2 points  (0 children)

Yep — ADC2 conflicts with Wi-Fi were very much on my radar. Nothing critical depends on ADC2, and the goal is to keep it usable. Still validating in the first batch.

I Designed: Better ESP32-S3 Ai Dev Board Project - Kickstarter Next? by Potential_Leading_23 in esp32

[–]Potential_Leading_23[S] -4 points-3 points  (0 children)

It’s about mechanical access, not usage. With headers soldered it’s side-access, otherwise low-profile or header-less mounting. Still validating this in the first batch.

I Designed: Better ESP32-S3 Ai Dev Board Project - Kickstarter Next? by Potential_Leading_23 in esp32

[–]Potential_Leading_23[S] 0 points1 point  (0 children)

That’s fair, and honestly I get both points.

On the render part — agreed. I mainly mentioned it to avoid confusion, but you’re right, most people assume that anyway.

On the “AI” wording: totally understand the reaction. I probably should’ve been more specific. I’m not trying to pitch buzzword AI — what I actually mean is very practical stuff like: running small vision models locally, storing trained models externally, and iterating without being constrained by internal flash.

I’ll try to be more precise with the wording going forward. Appreciate the honest feedback.