Design options: consider an S3?

[robertlipe]

This is awesome!

I'm on mobile, so reading the .Sch is hard, but I think i see esp32-wroom-32d which is the legacy module.

If you would change to ESP32-S3 (exp. With more PSRAM) you'd have a more capable board. You could also eliminate serial bridge and get jtag with no extra pads or buffers. The USB could be used as any USB type (like a disk) or as a host (attach a keyboard). You might be able to get the 8MB PSRAM/16 MB Flash modules for not a lot more than the bom cost of the serial/USB bridge and needed additional transistors to make reset work on trailing edge of dtr and pulse EN. The CPU is also more efficient per clock and has more powerful instructions handy in this world doe FFT, like doing beat detection, as well as offering better memory model with less goofy fragmentation and fewer restrictions on where you can DMA to and from.

Element

Atomic14 has a YouTube video showing a super minimal S3 build it was a USB socket, lvdo, maybe one cap for the ENable signal on power up and ... not much more. (Edit: https://youtu.be/tQ0dL_9M1wI?si=FmXgR3vD-N_fcYg2 - and I'll admit that for a production board, I probably wouldn't chip quite so deeply. Decouplers actually DO have a purpose, but his underlying point that you can make a S3 with USB from almost nothing is legit.)

As disclosure, you could go S2 and get most of those benefits, but only on a single core. C3 is dirt cheap, but only single core and has a completely different arch, being 160Mhz RISC-V instead of 240Mhz XTENSA. While that may sound slower, they're more of a draw but some projects may not support single cores.

As a stuffing option, allow the external WiFi version and, for crazy talk, some screw terminals and a few diodes to stop people from using both, allow external DC from a random DC source that's bucked to power the esp32 and passed through to the rails of the strip. Same board, populated different ways, no real cost unless it results in fewer boards per panel.

If your chosen buck/boost could get to 24V (or your PD was so equipped, which seems likely in laptops and less so in a phone charger) you'd have an advantage of being able to run longer power runs without needing injection. Budget a GPIO, resistor, led to help figure out if their random USB-C source actually has PD and at the requested wattage combination. The industry has done a terrible job of teaching consumers what voltage any given USB source will actually source.

Without seeing the schematic,. I'll say that this is pretty close to a board I've considered building. Usb-c is just the way to go. I'm glad to see you tackling this! (So I don't have to. 😉)

This isn't meant to be terrifying feedback and when I'm near a computer again,. I can perhaps even help with some of the above as it's hopefully clear that I've already been thinking about this for a while. I'm not an EE, but I may have some helpful skills.

Even if you ignore everything I've just typed, I'm likely to buy/build at least a few boards in this space this year, so I really do think you're onto something here!

[ale1800]

Hello @robertlipe, thanks for your your great feedback!

I uploaded the pdf file of the schematic. The module is the ESP32-WROOM-32E, that should still be in production. I know it's quite old, but it's still the only ESP32 to support Wifi and both Classic Bluetooth and BLE and it provides fully compatibility with the most important open source firmware like ESPHome and WLED. On the other hand the advantage of removing all the serial parts is relevant, as the fastest processor that maybe could help for some effects or something similar. Honestly I don't know if it will be a commercial product or not, at the moment is a personal project. in that case I will seriously consider the switch (maybe the s3 mini?)

In the same case i will try to provide more power at the output, and the power injection is a thing I should keep in mind. I can see that a lot of people use really long strips, so pushing the PD to 24V would be really useful.

I think that the external DC is a good catch, just as a "classic" alternative to the USB-C. Maybe I could also add another terminal for a second independent strip led?

Thanks very much for your advices!

[robertlipe]

In NightDriverLED, we use all the compute power we can get. (I'm not terribly proud of that - we just do...) OTOH, it's pretty hard for us to saturate even the LX6 on a single strand unless we're doing something like doing 60Hz frame updates over WiFi as WiFi alone on these can pretty much eat one core. For that, the better DMA can be a real help. Having large (working) flash and sram is pretty nifty for keeping traffic OFF WiFi as much as we can. I've pretty much settled on the YD-ESP32-S3 for all my ESP development as I love 8MB/16MB combo and having a trainload of remappable GPIOs. It's hard to find breakout boards in 44 pins, though.

If you build some, buzz me and I'll help land the code in NightDriverLED to support these.

Additional strand outputs sound tempting, but if people are mounting them in remote locations, two (one each direction) is about the most you can really use without adding massive distance to the next strip. Similarly, more than two is probably pushing your luck with USB power. If you chase that idea, see if something like a txb0102 can replace your hermetic level shifter.

You're right that they made a mess of BT in the later parts. In NightDriverLED, we drive commodity remotes from IR instead of BT, though I have some WIP to support the WIZmote over ESP-NOW.

Oh. adding (potentially unpopulated) pads for audio in might be handy. On Mesmerizer, we have two 3.5mm jacks; one for the IR remote and one for audio in where we do beat detection and sound sync.

Additional DC in, whether from a screw terminal or a DC5521 jack would be spiffy! YOu just have to do some clever EE stuff (probably more than the backflow diodes I mentioned) to be sure that 24VDC in doesn't land in the output of your PD chip. Maybe that's a jumper/switch. .100 jumpers are dirt cheap, but I don't know how well they'll handle @.***

Would a ch32x035 or CH224/236 or CH543 (WCH has an embarrassment of PD riches) be cheaper than the STUSB4500? Digikey shows that as an expensive part. ST burned so many of us during chipageddeon that we're mostly leaving them. Seems like we should be able to find SOMETHING to do with the mostly spare RISC-V core. :-)

The only other item I'd really lean into on that list is an LED showing the USB-C power status. People ARE going to connect their mutant-ass QC chargers or battery packs and be mystified when Power Delivery doesn't magically appear. A visual indicator from the PD sensor that shows "this isn't PD" or "this is PD, but it's too wimpy to provide the 5/12/24V that you chose from the jumper settings (oh, you might need that, too...) may save some awkward support issues.

It might sound like I'm suggesting a kitchen sink of complexity, but most of the suggestions so far have the strong advantage that they can be simply depopulated for a cost-optimized model. Something like Tindie can help blur the line between project and product if you're interested in that.

Lipe Pro tip: before you have any appreciable quantity of these made, ship the design to https://www.espressif.com/en/contact-us/circuit-schematic-pcb-design-review

• they offer free design reviews to help ensure that your use of the Espressif parts are within guidelines. I've seen the outupt of some of those reviews and they're really impressive. A few minutes of skimming a schematic from a FSE helps you make their parts look good!

Feel free to close this or ignore it at any time. I know I can talk too much. :-) I just wanted you to know that at least one person read your project page and cared. I know that initial silence can be tough.

Good luck!

On Mon, Apr 15, 2024 at 2:40 AM ale1800 @.***> wrote:

Hello @robertlipe https://github.com/robertlipe, thanks for your your great feedback!

I uploaded the pdf file of the schematic. The module is the ESP32-WROOM-32E, that should still be in production. I know it's quite old, but it's still the only ESP32 to support Wifi and both Classic Bluetooth and BLE and it provides fully compatibility with the most important open source firmware like ESPHome and WLED. On the other hand the advantage of removing all the serial parts is relevant, as the fastest processor that maybe could help for some effects or something similar. Honestly I don't know if it will be a commercial product or not, at the moment is a personal project. in that case I will seriously consider the switch (maybe the s3 mini?)

In the same case i will try to provide more power at the output, and the power injection is a thing I should keep in mind. I can see that a lot of people use really long strips, so pushing the PD to 24V would be really useful.

I think that the external DC is a good catch, just as a "classic" alternative to the USB-C. Maybe I could also add another terminal for a second independent strip led?

Thanks very much for your advices!

— Reply to this email directly, view it on GitHub https://github.com/ale1800/USB-C-PD-Led-Controller/issues/1#issuecomment-2055912398, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACCSD32W5YGXKRMPBDDPCZ3Y5N765AVCNFSM6AAAAABGGPDF3GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANJVHEYTEMZZHA . You are receiving this because you were mentioned.Message ID: @.***>

[ale1800]

Sorry, when you say "If you build some", do you mean the 44 pin breakout board or my board with the S3?

Regarding the input, a DC5521 would be absolutely useful, but I think that if someone need a board with that input, should go with the Quinled boards. They are made for that. I think mine would be more expensive and "without reviews" compared to the others.

I checked the WCH board and are quite interesting! My only concern is about if these IC would be reliable as the STUSB4500?

I really appreciate your time to provide valuable suggestions!

[robertlipe]

I was speaking of the PD/S3 board. I'd like to be sure you're well supported in NightDriverLED. I'm a regular contributor there.

I've tried to bait Freenove to update their https://www.aliexpress.us/item/3256805693341149.html to support the 44-pin boards to no avail. That board is close enough to one I've already built that I could probably spin that up if I got really motivated. My fear is that I'd go crazy adding level shifters for 16 WS2812 lines and add a jack for HUB75 and add analyzer pod connectors and otherwise turn it into a $100 board that's useful only to me. I design hardware in the same rambling style as I type here. :-). I totally get that's not the board you're trying to build. I just mentioned that prototyping with the YD-ESP32-S3 can be a bit awkward as some of the grounds dangle off the end of 40-pin test fixtures; they're fine on breadboard or on PCBs designed around that.

Fair point on the additional DC inputs. It does add complexity to ensure that if powered from two sources (maybe someone plugs it into their computer with a powered USB hub for a quick firmware update...) that bad things might happen.

I get that some people think the QuinLED boards are the end of all boards. They're nifty and I won't be unkind, but I think there's space for other products in this niche market.

I can't speak to MTBF on the relative chips. There are probably data sheets that cover that, but for PD circuits, it seems likely that external causes (e.g. power sources that don't ramp down their voltage to 5V upon seeing the trailing edge of a connection, so the next data-free connection gets 20V dumped into it. (Thanks, Benson Lueng...and may his destroyed Chromebook RIP!) I just mentioned them because WCH - which is a very Chinese company, for better and worse, though they DO typically have pretty good English doc - is a master of "tiny MCU + a little bit of specialized I/O" chips, whether that's a USB/Serial bridge (famous CH340 family), bluetooth, ethernet, whatever. They also have a family of really nice RISC-V mcus ranging from a $.10 RV32E part (!) that's quite nice for what it is up to a part with 84 GPIOs, ethernet, etc. They've said that all parts going forward would ditch their beloved 8051 cores (sigh) and use RISC-V core families from Quingke. There's a nice Discord group for their families with good discussions and semi-official presence from the company itself. PM me (my gmail is the same as my name here) if you're interested and can't find it. They have an official store on Aliexpress and there are plenty of inexpensive boards and driver sources for all their chips so you can evaluate driver code via dupont cables to a $4 board before you order SMT boards and try to prototype with those. (Their driver quality is all over the place between products. Projects like cnlohr's CH32V003Fun make a really nice SDK for those $0.10 RV32E MCUs that just embarrasses WCH's own.) Unlike another RISC-V company, their parts perform really well with stock GCC and you can ignore their extensions and still have an awesome part - it doesn't rely on goofy extensions to perform well.

Back to the original point, I think that a small board that can drive one or two WS2812 chains that includes level shifting as you've provided (is that cheaper than the part I mentioned?) and is powered by commodity USB bricks and batteries could solve a lot of problems for some people. Package it with screw terminals for the LEDconnector and the plugs like https://www.amazon.com/ALITOVE-Female-Connector-WS2812B-SK6812-RGBW/dp/B071H5XCN5 could provide a much less finicky, solder free (for most) product that can be installed near the head of the strips with just a USB cable running to the wall could be a hit.

I could be wrong.

Good luck! I'm happy to talk through anything you like...

On Tue, Apr 16, 2024 at 3:42 AM ale1800 @.***> wrote:

Sorry, when you say "If you build some", do you mean the 44 pin breakout board or my board with the S3?

Regarding the input, a DC5521 would be absolutely useful, but I think that if someone need a board with that input, should go with the Quinled boards. They are made for that. I think mine would be more expensive and "without reviews" compared to the others.

I checked the WCH board and are quite interesting! My only concern is about if these IC would be reliable as the STUSB4500?

I really appreciate your time to provide valuable suggestions!

— Reply to this email directly, view it on GitHub https://github.com/ale1800/USB-C-PD-Led-Controller/issues/1#issuecomment-2058557688, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACCSD33HBC7TXPSMO3Y4ZLDY5TQAXAVCNFSM6AAAAABGGPDF3GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANJYGU2TONRYHA . You are receiving this because you were mentioned.Message ID: @.***>

[ale1800]

I wasn't aware those board were from WCH. Good to know! Based on your experience, is the esp32 s3 native usb reliable? Because, like for the S2, I found a lot of people complaining about it. Last year I tried two ESP32 S2 mini dev board with the USB-C and I've never been able to program them. I also read that all the esp-web-tool do not work very well with the native usb. I always chose the WROOM-32E because of this and software compaitiblity in general

[robertlipe]

My experience on MacOS is mostly positive. The two asterisks that I know of are that the max bitrate for a successful firmware update is lower and that when the chip resets, that controller resets. That does make it a nuisance when developing. This means your GDB connection and your serial console connection will each break when you do a reset from a firmware update. For example, my firmware build and update script ends like this:

~/.platformio/penv/bin/pio run --target upload -e $E

while : do (stty 115200; cat -u ) < $PLATFORMIO_UPLOAD_PORT || exit 1 done

Because $PLATFORMIO_UPLOAD_PORT (for example /dev/cu.usbserial1101 if that's the physical port I'm using) will disappear briefly when the controller resets, the terminal session or pio device monitor or gdb connection or whatever elese might be using that port will all get a SIGHUP and close, I have the loop below that just waits for the port to reappear and then shovels bytes to the screen so I can see the serial console. I can't find one right now on this system (an indication that I don't use GDB a lot these days) but if I'm using GDB, I end up scripting a 'reboot' command that does a an upload and then re-runs the file .pio/build/mesmerizer/firmware.elf (to get the new symbol table) and target remote $PLATFORMIO_UPLOAD_PORT to recreate the connection to the device.

If I'm using the "real" serial port, these hoops are usually not needed. I can just leave the 'platformio device monitor' or "cat -u" running and it'll survive a firmware upload. I just have scripts that tend to paper over these for me.

As a counterexample, on MacOS, the UART ports "work" with the native driver, but they work badly. An upload will start and fail in the middle at any bit rate. You have to install a driver from a chinese site, override security settings (what could go wrong?), and then remember to use /dev/wch.usbserialBIGNUMBER (the new driver) instead of /dev/cu.SOMETHINGELSE (the one from the native driver) each time for reliable data transfer.

So, you're right to call it out. Neither approach is awesome. USB provides a way to do awesome, high speed connections, but these guys still insist on thinking it's 1969 and treat everything like a teletype. (USB serial, if I remember my days writing USB stacks correctly, use the interrupt pipe for transfer, which limits effective speed to 63 bytes per frame (?) which is why they're all USB 1.1 speed devices. If they're put them on the bulk pipe where God herself meant them to be, they could write up to 4K (?) bytes per frame and be real 'high' speed device like it's at least 2000 instead of

1998. (USB 1.1 didn't actually live very long in isolation.) But nooooo, everything has to be a stinking serial port.

To play double devil's advocate, a device could be like the Adafruit products (I own an S3 Matrix which uses S3 and doesn't use UART - Adafruit does this on many products) You can run a tiny bootloader on the device which makes it look like a tiny little disk drive. Copy a uf2 ( https://github.com/microsoft/uf2) file to it and the device resets and poof, it's running new firmware. If the ESP chips implemented USB2 or USB3 speeds (sigh) it would actually be a high speed connection. But copying a file is clearly a better experience than writing and running a dedicated uploader talking to a tty in 2024, right? Well, usually.

At least twice, MacOS has screwed this up. Here, I offer https://github.com/adafruit/circuitpython/issues/8449. (The report wasn't actually about the MatrixS3; I crashed it and we quickly learned it was the same problem affecting multiple devices.) It turns out that Finder (the file browser, of all things) implements its own version of DOSFS and at least twice in recent OS release history, they've screwed up FAT16 (FAT12? I'd have to look it up) badly enough that our tiny little embedded devices are broken, but even the smallest thumb drive that you'd dare to plug in works because it's a FAT32 filesystem.

I'll disclaim that I've not used the S2. I've always had the impression it was basically their testing ground for Xtensa LX7 before they made the dual-core version in S3 to give their compiler and debugger team a head start, but I don't really know how much of that was Cadence vs. Espressif. I think that, by volume, Espressif is the largest user of Xtampsa and the most open-source friendly, and thus the one most vested in making a sane GCC/GDB/Clang/LLDB release.

The C3, S2, and S3 were pretty clearly aboard the same launch trajectory. They all have a similar USB host-mode controller and the same internal serial/JTAG USB "device". IIRC, the C3's is missing something in this space that's sort of important. (I had some of the first ones they shipped and there's a note in the box that says "oh, THIS doesn't work. It's an errata. Sorry".) It's clearly a mistake that they corrected on the S2 and S3. Maybe later revs of all these parts have gotten this closer to right and maybe the later parts (hey, just this week, they finally announced a dual-core RISC-V part) that all have this same USB controller have gotten better. Maybe. Maybe they're just annoyingly different.

So, the grass on the other side of the fence is always brown, it's just a different color of brown. I think I've made a case for and against every combination of ports and protocols and provided a compelling argument that embedded development is just a terrible way to spend your life and you should have some self-respect and learn pool or gambling on on ponies or something else to pass your time instead of screwing around with melting metal onto tiny little rectangles and training electrons to run down specific paths in them. :-)

Seriously, I'm happy to tell you anything I've learned about these parts.

On Tue, Apr 16, 2024 at 8:43 AM ale1800 @.***> wrote:

I wasn't aware those board were from WCH. Good to know! Based on your experience, is the esp32 s3 native usb reliable? Because, like for the S2, I found a lot of people complaining about it. Last year I tried two ESP32 S2 mini dev board with the USB-C and I've never been able to program them. I also read that all the esp-web-tool do not work very well with the native usb. I always chose the WROOM-32E because of this and software compaitiblity in general

— Reply to this email directly, view it on GitHub https://github.com/ale1800/USB-C-PD-Led-Controller/issues/1#issuecomment-2059128894, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACCSD35S2AE4PEJLDCMNQI3Y5UTI3AVCNFSM6AAAAABGGPDF3GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANJZGEZDQOBZGQ . You are receiving this because you were mentioned.Message ID: @.***>

[ale1800]

So it seems that the native USB needs a bit more attention compared to the "external" one. I will think about that and give it a try. Thanks for your really detailed explanation! I can confirm that the S3 module's price is the same as Wroom-32E + cp2102n + transistors. Swapping them seems worthy saving a lot of space.

[robertlipe]

Fair. It's slightly more fiddly for developers attaching debuggers and such.

Users that will probably only ever OTA won't care. They'll never see any of that.

You can lay empty pads and just float on a uart or have the house populate a. Board or two for development. We did that kind of thing a lot at my former hardware company.

Sounds like you're on the way. Always feel free to buzz me if you want to chat.

[ale1800]

Hi robert! Can I ask you the reason why with 24V I would not need the power injection? I always have 5V at the input of the strip

[robertlipe]

I think I can answer that either "always" or "never", depending on your goals for the USB-C power source.

If you're going for laptop-class PD sources, you may very well have 24V available to you just by asking for it. (A lot of them top out at 20V...)

If you're going for leftover phone chargers, you will probably never have 24V available, so you'll probably want to provide options to attach an external 12 or 24VDC feed for the strips.

As you've probably learned by now, USB-C power sources generally offer a menu of power options to the host (e.g. "I can give you 5V@xA, 9V@yA, 15V@zA, or 20V@aA") and the PD negotiates which one gets delivered. 12V is optional. 20V is common. It's kind of unfortunate that the two that are most useful in strip lighting, 12V and 24V, are somewhat rare.

You can either get those voltages by tapping an external power source, somewhat taking the punchline from using USB-C PD, or by using a boost converter and stepping up 9V (or whatever) to whichever ou need, but knowing that strips can be hungry for wattage, you may need some heavier demands on the charger than a typical crappy $5 phone charger will get - not to mention extra circuitry that's going to generate a bunch of HV switching noise that'll you'll need to filter and design away.

Do I get double credit for arguing four ways? :-)

• You'll always need it for phone chargers.
• You'll never need it, just require "appropriate" power (and prepare to die in the market because nobody ever states it.)
• You may need it, just rely on luck of the draw for 12V.
• You can design around it and master your own destiny and make your high power at an appropriate voltage.

P.S. tagging 'robert' got someone that wasn't me. I think you missed a tab completion.

[robertlipe]

Here's a representative USB-C supply that I'd imagine is the sweet spot of price/availability. The 65W GaN chargers are dirt cheap and awesome for even a Macbook. This one gets 65W in a variety of ways, with max voltage at 20V@3.25A.

Modern WS2812B's are about .3W per LED. "Better" grade strips are 60LEDs/m. (gotta run. You can math it from here...)

[ale1800]

Oh ok, Now I got it. Yes I could some jumper to select the output voltage from the buck converter. It's just 2 or 3 more resistors. Does KnightDriver have some mqtt support to use with Home Assistant or other platforms?

[robertlipe]

Yep, I'd agree that once you've accepted that what you've asked for from the PD and what you want out of the PD aren't necessarily the same, it's probably not terribly difficult to "fix" it if you have a buck populated anyway. Just spare a GPIO for an LED (or something...) for "USB source is too wimpy" to cut down on nastygrams from that inevitable person that plugs in a QuickCharge device ("That's like PD, right?") and is then shocked that it only gives 9V @ 1.5A (wimpy even for a phone, but laughable when the best WS2812's are about 45W/M at full tilt.

Anyway, sounds like you now "get" the problem, so I'm happy you'll be able to solve it.

NightdriverLED doesn't really have any MQTT facilities. It can receive or transmit the pixel array from/to a Real Computer that's doing more animation than we can handle on-board. We have a web JSON API https://github.com/PlummersSoftwareLLC/NightDriverStrip/blob/main/REST_API.md that's mostly for our own on-board web UI.

I haven't really thought much about adding MQTT to it. It's available in the SDK we use https://docs.espressif.com/projects/esp-idf/en/stable/esp32/api-reference/protocols/mqtt.html thought there might be some preference for a bloated Arduino layer atop of it to take even more memory (that we don't particularly have on the base ESP32s...) We (at least I) just don't hear a lot about the HA crowd in this project. I don't think I've seen patches that were turned down, but I also haven't see anyone else even ask. Maybe they're all happily on WLED. {shrug}

I've given some thought to a more featureful fork that would REQUIRE PSRAM, but usually that urge passes quickly.

[ale1800]

Ok, thanks. Good to know👍

[ale1800]

Hi @robertlipe! Where can I PM you? Could you give me your email address?

Thanks!

[robertlipe]

Done.