mattytrentini/led_strip

Control a LED strip using an ESP8266, PWM, an N-Channel MOSFET, a rotary encoder and some Micropython

led_strip's Issues

No silk screen annotations on connectors

In the Rev A version of the shield PCB, there is no silk screen annotations on the connectors. This means that prior knowledge of the board is required for knowing how to connect the LED strips, and could very easily result in the strips being wired backwards (unlikely to be damaging for the strips, but could lead to some confusion).

This should be rectified for Rev B of the PCB.

led_strip_breadboard.fzz: Unable to find part

Upon opening the led_strip_breadboard.fzz Fritzing file, an error pops up stating, "Unable to find the following part: 'Camdenboss_CTB0158-2_5_08mm_pitch_90deg_terminals' at '/home/USER/Documents/fritzing-VERSION/fritzing-parts/core/Camdenboss_CTB0158-2_5_08mm_pitch_90deg_terminals.fzp' ". Error seen on Fritzing 0.9.3b.

Pull-downs on FET driver lines required

Currently the LEDs are briefly on when the board is powered up before they turn off - see #18. Pull-down resistors need to be added to the LED_DRIVE_x nets in order to aid in resolving this issue.

Fade should look better for lower brightness settings

Notice that the fade looks great when the brightness is near max. Notice too that there's barely any fade when the brightness reduces to below about half.

It's because the number of fade steps is simply however many values are between the brightness level (of a range from 0-1020) and 0. The pause between each step change is constant (1ms by default) so the fade is longer for brighter values.

Should divide the desired duration by the number of steps. Maybe have some corner cases when brightness is low (ie at 1 or 2).

Only listen to rotary encoder when LED strip is on

Currently the value of the encoder is recorded even when the LED strip is off.

This means that the LED strip can be turned off and the brightness changed before turning it on again. That's unexpected behaviour! Should ignore the encoder while the strip is off.

Debounce resistors too high

The debounce resistors have too high a resistance (27k), which means that they cannot successfully overcome the pull-up resistors inside the ESP (10k). For example: Pressing the rotary encoder button results in a voltage of 2.5V, which does not trigger the button press interrupt.

Debouncing needs to be handled

I tend to prefer hardware solutions (10nF cap across switch?). But could be done in software too.

Note that debouncing isn't really a problem when the brightness is high - the fade duration means that the debounce has stabilised by the time the fade is complete.

So, to test, reduce the brightness to the lowest setting and press the switch repeatedly. It's pretty easy to reproduce a repeat event (it will fade off then on - or vice versa - for one button click).

main.py: LED strip driving functions should be brought out into own class

Currently the LED strip driving calls are all nestled within the main.py file. It would be good to extract these calls / functions, neaten them up, and place them in a class so that multiple LED strips can be driven at once. Fading and debouncing logic will have to be re-designed to a non-blocking implementation.

Fades should be able to be interrupted

The fade routine should be able to be interrupted. Specifically, if the strip is off and the switch is pushed a fade-in should begin...if the switch is pushed again before the fade is complete then the fade-in should be stopped and a fade-out should begin until the strip is off.

No LEDs on board

In the Rev A shield PCB, there are no LEDs built into the Design. This means testing functionality is harder than would be ideal.

Preferred setup would be to have an LED to show power on the 12V and 3V3 rails, as well as an LED across each of the LED strip terminals to show when they're powered. This should be implemented for Rev B of the PCB.

Add PIR to the system

A Passive InfraRed sensor could be used to detect when someone is nearby and turn on the LED strip automatically. Just need to hook this in to the broken-out GPIO and monitor it for changes.

Need better control over LED strips on startup

Currently when the button is pressed the LED's come on temporarily at full brightness then back to completely off.

When the rotary encoder is pressed it allows the LED's to be lit but starts them at 0 brightness. Once the encoder is turned it enforces a minimum brightness.

What should happen is that when the application starts the LED's should - perhaps - turn on and off quickly but with a very dim brightness. Then, if the rotary encoder is pressed, the LED's should be lit to the minimum brightness.

Fade needs to be smoother

There are obvious steps in changing the brightness when fading, it should be smoother. If we put a simple fade routine in a (non-async) loop:

from machine import Pin, PWM
from time import sleep_ms

led=PWM(Pin(22))
for i in range(1024):
	led.duty(i)
	sleep_ms(5)

It's very smooth.

A few issues to consider:

• Need to time how long the async sleep was actually asleep for
  • Just because we request x ms doesn't mean we will exactly get it.
  • Initial measurements look like it's typically a few ms later (ie async.sleep_ms gives a minimum sleep time)
  • Adjust the brightness step by the actual time since the last step
• Use a rate of change to adjust brightness
  • Something like 0-100% brightness in 1.5 sec
• May be best to change brightness to a percentage
• Brightness appear to be non-linear
  • Fade routine can work with a linear percentage but we can introduce a function to return a non-linear percentage
• The last step may need some care
  • For example if we get very close to the goal brightness on the second-last step we may sleep for too long
• Need to time what the minimum sleep time of async.sleep_ms is
  • Initial measurements look like it can go down to 5ms though the documentation suggests 10's of ms is more realistic
  • Even a 20ms sleep should be able to look smooth? Need to test...
• Remember that print statements can affect the timing dramatically!
  • Maybe put them in another async loop that's serviced infrequently