Add support for (non linear?) current limited LEDs in auto brightness limiter
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 45/100
- Tipo di issue
- Funzionalità
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Tranquilla
- Ambito
- embedded-iot
Direzione di ricerca
Start by reviewing the linked predict.py model and the proof-of-concept commit, then trace how WLED currently estimates LED current and limits brightness. Compare the model's predictions with the attached measurements and consider how its parameters could support other LED types. Done means WLED can account for shared, nonlinear channel current limits accurately without breaking existing LED types.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Is your feature request related to a problem? Please describe.
I have ordered some 12V WS281x compatible LEDs from AliExpress (this), built a simple controller for them (2 channels with 600 LEDs). I realized that I had miscalculated the total current, so I had to current limit it in software. However, it kept tripping the psu's short circuit protection. After testing again with my lab bench psu, I figured out that WLED's current measurement was way off. The limit was set to 8 amps total (this is the rated current of my power supply), but the actual current draw was 10+ amps without getting brightness limited.
After some measuring around, I figured out that these LEDs were a little weird: The current is linear initially, but then it gets clamped at ~10 mA per led, regardless of the color after that point. I did a test again, but now actually recorded the data (I attached the file). It seems like these LEDs have a shared current limit across the colors channels. The limit is only applied when multiple channels are lit simultaneously within the PWM cycle. I could prove this by looking at the current draw with an oscilloscope, and seeing 1 to 3 distinct spikes.
Describe the solution you'd like
I would appreciate if more accurate current calculation for non linear current-limited LEDs got implemented. Ideally, this could be a new LED type, or maybe a toggle for current LED types (eg. WS281x, maybe a second custom type for WS281x). Different LED ICs probably have different thresholds, so the implementation should ideally be generic and parameterizable
Describe alternatives you've considered
My temporary solution was to greatly limit brightness
Additional context
I then wrote a test that goes through some colors and logs the LED current. Based on these measurements, I created a current profile model that matches the measured current with less than 1% prediction error. I used Claude to help prototype the algorithm in Python and produce a C implementation. I also made a proof of concept fork implementing this current model. I have been running it 24/7 on my own LED installation for ~2 months without having any issues, although it has only ever been tested on my exact hardware.
Current profile of one led (this is what I gave to Claude): 1led.txt
I uploaded all of the code I or Claude wrote to this repository
Current prediction code by Claude: predict.py
Proof-of-concept implementation is in this commit.
Thank you for your ideas for making WLED better!
- Lingua principale
- C++
- Stelle
- 18.8k
- Fork
- 4.4k
- Merge medio
- 4g 6h
- PR unite (30g)
- 12
Preparare l'ambiente
Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.
- Nessun Dockerfile né file Docker Compose
- Nessun modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di wled/WLED
-
Gravimeter: bars turn black at full volume (uint8_t(segmentSampleAvg*8) overflows)Forse già presa @DedeHai l’ha presa 1 giorno fa. Apertabug confirmed
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
I maintainer di solito rispondono entro 1 giorno
-
bug cannot reproduce
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
wled/WLED#5840 · 12 commenti ·
I maintainer di solito rispondono entro 1 giorno
-
enhancement
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 88/100
I maintainer di solito rispondono entro 1 giorno
-
backburner enhancement
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
wled/WLED#4132 · 5 commenti · 2 reazioni ·
I maintainer di solito rispondono entro 1 giorno
-
discussion enhancement
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
wled/WLED#3478 · 13 commenti ·
I maintainer di solito rispondono entro 1 giorno
Issue simili
-
Status: Awaiting triage
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
espressif/arduino-esp32#12984 ·
I maintainer di solito rispondono entro 1 giorno
-
torch_ops/logprob.cu does not compile with the serving container's nvcc (13.3.73); check_torch_ops.py cannot run as shippedForse già presa Una pull request collegata a questa issue è aperta o già unita. Aperta
Difficoltà 2/5 Meno di un'ora Idoneità per principianti 72/100
ashhart/TensorFold#535 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 66/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
I maintainer di solito rispondono entro 1 giorno
-
agent:Windows bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 62/100
I maintainer di solito rispondono entro 1 giorno