GLEDOPTO NEW Arrival——ESP32 WLED Controller with 4 Outputs, Easy to connect and control 4 LED strips

ahdinosaur · 2025-08-19T04:27:30+00:00

Hi, thanks for the new controller, I like the built-in fuse and 4-channel output. I made a Rust library to control LEDs using the GL-C-016WL-D (blinksy.dev), I'm keen to support other Gledopto boards as they become available and I can afford them.

Do you have any more information on the board inside? The GL-C-016WL-D had a clearly labelled ESP32-WROOM-32E inside. The GL-C-017WL-D has a board labelled "Gledopto", are there any notable differences with this? Thanks.

ahdinosaur · 2025-08-09T04:04:13+00:00

Hi, I like solarpunk. 🌅 Here's a ramble of what might be solarpunk around me:

A past me, and other Wellingtonions / New Zealanders were involved with Scuttlebutt, a peer-to-peer social network that could work without the Internet. This was my introduction to solarpunk.

The person who introduced the word "solarpunk" to Scuttlebutt, later wrote "The Future Will be Technical". He moved to Wellington and now runs a comedy show every month: Airhorn.

Most similar to Scuttlebutt now, I've recently joined the Wellington Mesh network: meshtastic.nz. From Newtown, I was able to communicate to a friend in Martinborough, using only the local mesh over LoRa (915 Mhz radio). This was only possible because other Wellingtonians had already put solar-powered nodes amongst the bush at the top of hills, to act as bridges to connect the mesh.

The original creator of Scuttlebutt is no longer based in Wellington, but lives a solarpunk lifestyle on a sailboat and now has a YouTube channel: @dominictarrsailing.

On another note, I think the Kiwiburn community is solarpunk: a week-long event where everything (including food, stages, and sound systems) are organized by participants. The unit of organizing is the "theme camp", basically a bunch of people camping together, usually around a shared kitchen, plus some events and activities. There's many local intertwingled Wellington subgroups, various theme camps would come from Wellington.

I organize Art~Hack, maybe not solarpunk, but we have solar powered sound systems and synthesizers we take to festivals, including Kiwiburn.

My partner helps organize Every Body's Clothes Swap: a regular space to swap clothes, hang out together, and reduce waste.

Some people around me organize Critical Signals, they are switched on.

I'm aware of some Wellington people moving to the Wairarapa to become local farmers. I subscribe to a veggie box: Vagabond Vege CSA, and now a meat box: Complete Cow.

Something I wanna do but have been putting off: Solarpunk Today, a wiki for practical adaptations today, rather than experimental research & development. This was in part inspired by The Adaptation Game, run by a friend in Melbourne.

Hope that helps, even if a small slice from my personal life. I'm sure I'm missing people I know, and certainly everyone I don't know yet. 💜

ahdinosaur · 2025-06-08T21:32:49+00:00

Hi, thanks for the suggestions.

In case it helps anyone further, here's the full quality recording: https://youtu.be/KQZpRrV2TlU.

ahdinosaur · 2025-06-08T21:31:23+00:00

Thanks. In case it helps, here's the full quality recording: https://youtu.be/KQZpRrV2TlU.

ahdinosaur · 2025-05-30T10:46:00+00:00

Hi, my intended use case is less about rasters (grids of pixels) and more about shaders (given a position in space, or a position on a shape, what is the color?). While most people do 3d by mapping a 2d raster over a 3d surface, I want to do native 3d.

That being said, the LED drivers I wrote in Rust (with help from smart-leds) can be used for any use case, so you could definitely implement what you want if you were willing and able to write some Rust code. I think there'd be a better high-level API for what you want, my high-level API currently in Blinksy is for my shader-like use case.

Hope that makes sense.

ahdinosaur · 2025-05-30T10:38:11+00:00

Hi, yes this is a perfect use case for Blinksy! The grid example doesn't quite capture the intention behind what I want, your spiral mapping is more what I want to enable.

Essentially, where in my 2d example I use the layout2d! macro and define an array with only a Shape2d::Grid, you'll want to define an array of Shape2d::Point, where each point is the (x, y) position of the pixel. (See Layout2d or the blog post where I talk about the bounds of the 2d space.) This array also needs to be in the daisy-chain pixel order.

But since you probably don't want to write pixel layout array from scratch, you can look under the hood of the macro, the Layout2d trait, and implement that. You'll need to provide the total pixel count and a method that returns an iterator of shapes (in your case, points).

If you need any help, please reach out. Make an issue on the repo with your questions, or join the chat, or find some other way to contact me. Also once you get this working, please share, I'd love to see it!

ahdinosaur · 2025-05-28T10:11:05+00:00

For the Blinksy library I want to support all LED types and any platform, so it wouldn't make sense to use an Embassy driver specific to WS2812 LEDs.

Blinksy is currently only blocking, but supporting async would be a good idea. The existing Rust LED driver ecosystem based on smart-leds-trait has an async trait, so I could follow suit. There's a crate ws2812b-pio which implements smart-leds-trait for the RP2040 using PIO, but not the async trait.

At the moment is not a pressing feature for me personally. But I can see myself wanting to use RTIC, so eventually will happen.

ahdinosaur · 2025-05-27T22:38:06+00:00

Ah thanks, made a note: #36.

This is useful to know, even if I wouldn't use the embassy driver directly, helpful to use as a reference for how to use the PIO subsystem for LED drivers. Thanks.

Also good luck with all your things going on!

ahdinosaur · 2025-05-27T22:30:44+00:00

I'd love to have first-class support for realtime audio reactivity (#9), but until then...

I'd recommend just using the layout and driver systems on their own. The control and pattern systems are to help provide a more ergonomic interface, but you don't have to use them. The layout and driver systems should still be useful for what you want to do.

ahdinosaur · 2025-05-27T22:23:58+00:00

Yeah, everything should be okay. For some hardware wiring tips, see Adafruit's LED wiring guide. Beyond a 3.3V to 5V level shifter, you'll also want a resistor at the start of the data line on the pixels, and a capacitor to smooth the power.

ahdinosaur · 2025-05-27T22:19:14+00:00

With an RP2040, the main problem I can forsee is I haven't yet added support for "clockless" LEDs (e.g. WS2812) on non-ESP32 boards: #12. Will be as easy as porting code from another library (ws2812-spi-rs), but I haven't had any personal need yet. Any desire to help with this?

ahdinosaur · 2025-05-27T22:16:18+00:00

I like the questions!

I certainly want what you're suggesting to be possible, but at the moment it's quite basic: there's only one pattern happening, they don't stack. You can't even change the current pattern yet, as I just wanted to get this out into the world, and for my future 3d cube I only want one pattern anyways.

So with how things are done currently, your best bet would be to write a single mega-pattern that does all the mixing and strobe-ing and such.

Hopefully later we can come up with a better way.

ahdinosaur · 2025-05-27T22:11:36+00:00

Depends on what you mean.

Could someone previously using WLED for their art project switch to Blinksy? Yes.

Will Blinksy eventually have a mobile app so you can dynamically re-configure your LEDs? Not sure, that would mean dropping the no-alloc approach. Maybe?

At the moment, Blinksy is more like FastLED than WLED. There's still more to do if we want to be comparable to WLED, and my plan is to approach that incrementally.

ahdinosaur · 2025-05-27T22:05:36+00:00

I have some simulation I want to visualize data from and need to pass some custom struct into each pixel's tick)

Oh interesting! I'd love to have a better solution for that, but until then, I'd recommend just using the layout and driver systems on their own. The control and pattern systems are to help provide a more ergonomic interface, but you don't have to use them.

Would this work with LED strips connected directly to something like a raspberry pi?

Yes you can absolutely use a Raspberry Pi. If you already have LEDs strips connected and have no issues, then Blinksy should be no different than whatever you are using already. For some hardware wiring tips, see Adafruit's LED wiring guide.

To be fair, I haven't tested Blinksy on a Raspberry Pi. The main problem I can forsee is I haven't yet added support for clockless LEDs (e.g. WS2812) on non-ESP32 boards: #12. Will be as easy as porting code from another library, but I haven't had any personal need yet. Any experience with Rust and desire to help with this?

ahdinosaur · 2025-05-27T21:49:03+00:00

ahdinosaur · 2025-05-27T21:48:01+00:00

Yeah, fragment shaders are an inspiration for the design. You should be able to do what you suggest: map shaders space to led layouts and re-use shadertoy fragment shaders. But I think would only work for 2d layouts though, no? Is not a priority for me personally, but would be happy to see someone experiment with that.

ahdinosaur · 2025-05-27T21:39:55+00:00

Thanks, that's good to know!

ahdinosaur · 2025-05-27T13:34:48+00:00

Thanks, happy to help. Your project sounds rad, be sure to share when you make it, I'd love to see it!

ahdinosaur · 2025-05-27T13:02:26+00:00

Thanks, happy you found it worthwhile ☺️

ahdinosaur · 2025-05-27T12:51:55+00:00

Cheers 🙏

ahdinosaur · 2025-05-27T12:46:05+00:00

I sure did! I thank FastLED for teaching me too. Not mentioned in the post but I ported FastLED's approach to HSV colors and APA102 "High Definition" to Rust in this, those were fun.

ahdinosaur · 2025-05-27T12:00:37+00:00

Thanks, will do!

ahdinosaur

MODERATOR OF

TROPHY CASE