Are frequent speed changes a good idea?

Issues
1

Hello - I recently tried an experiment that didn’t work well and wanted to ask if the group would expect effects to continue rendering smoothly while receiving requests to change speed via the JSON API? The hardware I’m using is an Adafruit Sparkle Motion with an ESP32. I’ve built a 3D printed warp core (Warp Core v2 by CrazyJ - Thingiverse) which has about ~140 or so LEDs split into 9 segments running the Chase effect. I’d like to vary the speed of the effect based on the power being reported by an exercise bike via BLE. Since I’m not a C++ dev I’m not confident about spinning up a bluetooth client in a usermod so I’ve created a proof of concept where a Raspberry Pi receives the bike data and sends a JSON message to WLED with updated “sx” values for each segment about every 2 seconds. Unfortunately, sometimes the LEDs jerk around noticably after speed changes. I’m thinking there could be two possible causes:

  1. Maybe the REST API overhead is too much for this to be a good idea.
  2. The Chase effect, if I’m reading the code correctly, doesn’t step sequentially through the LEDs but rather grabs the current millis from strip.now() to essentially figure out where in the strip it should be based on the time and speed. Perhaps by varying the speed mid-cycle I’m causing the effect to take a step backwards or skip forwards.

So I thought I’d take a quick “sanity check” break to see if you guys think this idea is even going to be workable or if hitting up the REST API that frequently is too much. If you think the Chase algorithm is problem here, I’ll try to write my own that steps sequentially and maybe stores SEGENV.speed in .aux0 at the beginning of each cycle and only picks up speed changes at the end of the cycle.

2
  1. yup! hitting WLED hard with web requests is a bad idea.

BLE, bad idea as well.

What’s easy to implement is a usermod that will read voltage and update (custom?) effect with the voltage level. See battery usermod for sample code.

3

Well, that’s a bummer, but thanks for the feedback. Guess I’ll need to roll my own firmware. If I’m very lucky, maybe the chase effect in the Adafruit CircuitPython LED animation library will be good enough.

4

You are welcome to make improvements others may benefit too.

5

On second thought, I think your suggestion might solve the problem for me and I should try it before going the full custom route. So, I take it the idea is for an external component (in my case, another ESP32 reading the BLE data) setting a voltage level on a pin, then using a usermod to do an analogRead on that pin and set the segment speeds?

If I couple that with a variant on the Chase effect that is certain to step progressively forward one step at a time (so there’s no opportunity to skip forward or take a step back during a speed change) that might do it. Or I could have the usermod update the new speed on aux0 and have the effect only pick up speed changes when reaching the end of a segment.