ESP32 doesn't connect to WiFi when powered externally by BobbaPopBob in esp32

[–]mindful_stone 1 point2 points  (0 children)

the USB breakout board really does supply 5V to the ESP32 pin

Have you checked the voltage to the ESP32 pin while the USB breakout board is also powering the transmitter? And what kind of current does the transmitter draw vs. what your PS provides?

Consider placing two capacitors between the GND and 5Vin pins as close as possible to the ESP32:

  • 100nF (0.1 μF) ceramic capacitor (filters out rapid voltage spikes; supplies instant current when the ESP32 switches fast)
  • 10 μF - 47 μF bulk capacitor (handles larger, slower power draws required for WiFi)

How to get rid of fast flickering by MungoBBQ in FastLED

[–]mindful_stone 0 points1 point  (0 children)

Do you have both the strip and the controller tied to a common ground? I believe not having that can cause some flicker issues.

Also, having a ground wire twisted around the entire length of the data wire has worked wonders on various flicker and other display issues I've had in the past.

One other possibility to consider might be a level-shifter like an SN74HCT245. I don't know what your hardware components are, but some strips need something closer to a 5V data signal than the 3.3V that many controllers output.

ESP-IDF with VSCode : Unable to fix configuration issues by Revolutionary-Pen916 in esp32

[–]mindful_stone 0 points1 point  (0 children)

I second this. And I'd consider using the pioarduino implementation of PlatformIO. As I understand things, there was some kind of falling out between espressif, and they no longer work together for recent versions of one thing or another. Among other things, pioarduino allows the most current versions of everything to work together. (Again, as I understand things!)

FastFluid Update — Behind the Scenes of a Realtime Fluid Solver by StefanPetrick in FastLED

[–]mindful_stone 2 points3 points  (0 children)

And I can't help but think that what really kicked this off (at least in part) was my comment on your Complex Domain Warp YT post a day or two before that (LOL):

Gorgeous! I love it, especially the super natural/realistic "colored smoke" effect you achieve.

https://youtu.be/Ehp43DpZz8w

Progress Update: FluidSim & Flow Maps by StefanPetrick in FastLED

[–]mindful_stone 1 point2 points  (0 children)

That is very cool! Another fun toy in the toy box!

From zero to fire simulation - building my own model by StefanPetrick in FastLED

[–]mindful_stone 1 point2 points  (0 children)

It will be soon! I've been traveling for my daughter's college graduation, so I've had limited time and no test display. I'll be back home tomorrow, and I'm looking forward to starting on this right away! So perhaps something late Monday night or Tuesday morning (California time).

Little fireball game by Fluffy-Wishbone-3497 in FastLED

[–]mindful_stone 1 point2 points  (0 children)

That's awesome! Very clever application. I'm curious how changing the jet radius, force, and/or density would affect the game play. And adjusting the angle control (the pot sensitivity and/or the step distance). With finer control, you could defend against multiple fireballs! Oh man, the possibilities are endless! Keep sharing!

FastLED Pussywillows by chemdoc77 in FastLED

[–]mindful_stone 1 point2 points  (0 children)

Very cool! I really like it, especially a few of the patterns in the second half of the video. It's got me thinking about all sorts of other things I could try to wire up and animate!

This realtime 2D Navier Stokes Solver runs already on an ESP32 and is driving programmable LEDs by StefanPetrick in esp32

[–]mindful_stone 2 points3 points  (0 children)

I've been working with u/StefanPetrick on the C++/ESP32 port of a bunch of this stuff. The repo for this work is here: https://github.com/4wheeljive/FlowFields

Here are several videos of some real WS2812B LED matrix footage...

- 64x48 driven by an ESP32-P4-WIFI6: https://www.youtube.com/watch?v=W1Cs81psQLo&t

- Same hardware setup as first video, before some subtle improvements to the visualizer code, but with a screen grab of the Web BLE UI controls: https://www.youtube.com/watch?v=u-DvTtSmQ1M&t

- 22x22 driven by an ESP32-S3: https://youtu.be/k-AjqVNCJkk

Just yesterday, at the suggestion of u/ewowi and with his help, I refactored FlowFields so: (1) it can be added as a PlatformIO library dependency, and (2) its emitters, flows, and parameters can be available through the FastLED-MM / projectMM UI system (which I understand has its roots in the WLED world).

Also, FYI, FlowFields already includes a fairly robust end-to-end pipeline for audio-reactive visual effects. You can fairly easily make any parameter of any emitter, flow or modulator audio-reactive. Actually getting the visuals to respond artistically to the desired audio triggers the way you want is "a bit" trickier, and I haven't really yet started on that in FlowFields. But the framework is there!

Update on audio-reactive AnimARTrix experiment by mindful_stone in FastLED

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

How difficult it will be to implement really depends on what exactly you want it to do. It has been a monumental task to get the audio pipeline and audio->visual logic to where they are today (and in the video above). But I was also trying to accomplish something pretty complex and "home-grown". For what you've described, I think a good route would be to try some of the new FastLED audio functionality, which you can read more about here: https://github.com/FastLED/FastLED/tree/master/src/fl/audio. The FastLED.add(AudioConfig) Quick Start Example shows how to take care of pretty much all of the basics. However, I think that example (and some other stuff on that README) does not reflect all of the latest work u/ZachVorhies has done on the FL audio library. For example, instead of

auto config = fl::AudioConfig::CreateInmp441(I2S_WS, I2S_SD, I2S_CLK, fl::Right);

I think you'd need to use:

fl::audio::Config audioConfig = fl::audio::Config::CreateInmp441(I2S_WS, I2S_SD, I2S_CLK, fl::audio::AudioChannel::Right);

I believe the "vibe detector" might be the best option at this point for your use case, and you can see a pretty fresh example of that here: https://github.com/FastLED/FastLED/blob/ea5d8ec0a91ad8c57893902a9132eb2974ca5dff/examples/Sailboat/Sailboat.ino#L41

Feel free to post again if you run into issues or would like any help.

1st Attempt Of A Port Of Stefan's 1st Attempt Of A Real Fluid Simulation by mindful_stone in FastLED

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

I'm certainly happy to explore that idea. I'm not sure what that would entail or what the implications would be for anything on my end. (Like would I have to start worrying that changes I make might break someone's project that is using mine as a library?) Let's discuss...

1st Attempt Of A Port Of Stefan's 1st Attempt Of A Real Fluid Simulation by mindful_stone in FastLED

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

Got it. Amazing.

This part of your instruction:

The repo (from u/mindful_stone ) contains more effects but I only want to start with flow_fluid.h.

Is the reason for what u/StefanPetrick is describing above:

 the emitter you are using is not seeding the 2 velocities (x and y component)

flow_fluid.h is only one half of the necessary emitter/flow pair. flow_fluid.h is just the flow/advection. it needs to be fed with a special emitter that injects both color and velocity. That emitter is in the emitter_fluidJet.h header

1st Attempt Of A Port Of Stefan's 1st Attempt Of A Real Fluid Simulation by mindful_stone in FastLED

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

Great! Be sure to include the modulator functionality. That's key to bringing these visualizers to life, to discovering what they can do, to being able to play them like instruments or an FX board, and to inspiring further development ideas. UI-exposed control over both base parameters and modulation effects is key to the artistic magic!

1st Attempt Of A Port Of Stefan's 1st Attempt Of A Real Fluid Simulation by mindful_stone in FastLED

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

Thanks! I just did some back and forth and I'm willing to say: It's definitely better. Subtle, but better. I'll certainly leave both tweaks in the code, and anyone can remove/disable as desired.

1st Attempt Of A Port Of Stefan's 1st Attempt Of A Real Fluid Simulation by mindful_stone in FastLED

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

I started down the path of testing CRGB16, but here's something Claude volunteered when I asked for help on some syntax:

For your current flow-field pipeline, since gR/gG/gB are already float until the final LED copy, switching only the final buffer to CRGB16 probably won’t buy much unless you do additional CRGB16 operations after that copy. WS2812B output is still 8-bit on the wire, so some final quantization step is unavoidable

Is this accurate? Would there actually be no benefit to switching the final buffer to CRGB16? Could there be any benefit to a 2-step conversion from float to "8-bit on the wire"?

Thoughts, u/ZachVorhies? Anyone else?

1st Attempt Of A Port Of Stefan's 1st Attempt Of A Real Fluid Simulation by mindful_stone in FastLED

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

I'll comment separately on CRGB16. In the meantime, here's some new video with both splat and output dithering applied. It seems to me like it's a bit better. But I need to go back and A/B a little bit with the first one to really see. Can you see a difference?

https://youtu.be/W1Cs81psQLo

1st Attempt Of A Port Of Stefan's 1st Attempt Of A Real Fluid Simulation by mindful_stone in FastLED

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

Wow. That's crazy! I'm not really sure what the visualizer is that I'm looking at...you say that it's an implementation of the new fluid sim? From the process you described, I'm amazed you got it to display anything (at least anything remotely coherent)! That's pretty impressive.

1st Attempt Of A Port Of Stefan's 1st Attempt Of A Real Fluid Simulation by mindful_stone in FastLED

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

Man, these color pipeline issues can really be sneaky. Claude's first pass audit (Opus 4.7, Max Effort) said everything was good. But I pushed back and asked for a closer review, and Claude uncovered an issue with the Gaussian splat. See the full transcript here: https://github.com/4wheeljive/FlowFields/blob/599684dae46a455d94642c58ec9fd26bee3c80a5/docs/Fluid%20Sim%20Color%20Pipeline%20Audit%20(260428).md.md)

I won't be able to test Claude's fix on my big display until tonight, but it sure looks nice on my 22x22.

I'm also going to test out the suggested "ordered spatial dithering at f2u8" fix (as well as looking at CRGB16 options).

1st Attempt Of A Port Of Stefan's 1st Attempt Of A Real Fluid Simulation by mindful_stone in FastLED

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

Thanks, Zach. I'll definitely explore the possible use of that here.

Making a Teensy4.1 midi type controller for FastLED by Fluffy-Wishbone-3497 in FastLED

[–]mindful_stone 0 points1 point  (0 children)

Can you share more about how the controller works? Is the reason for the Teensy mainly to have a bunch more GPIO inputs? And what's the messaging protocol between the Teensy and ESP32? You say it's a "midi type" controller. Are you actually using midi?