LED Panel Project – PWM Control Test 1
Over the past couple of weeks, I’ve been writing about my LED light project. This article is no different. There’s functionally two aspects of this project that I’m working on simultaneously. One is designing an actual LED Light panel, we the controller for one at least ,and the other is more investigative work on various control mechanisms and the required level of precision and accuracy for control.
The intent of this experiment is to begin to look at the accuracy of PWM control over LEDs, especially as they approach very low duty cycles.
Controller and Software
These tests are being done using an Arduino Uno v3 to generate the PWM signal and a fairly beefy N-channel MOSFET transistor to switch a test light panel.
Software is custom written Arduino code that access the PWM registers directly and exerts control over both the PWM clock and the operating range of the PWM system.
PWM on the Arduino, the frequency and the available range are interdependent. That is, it’s not always possible to choose a PWM frequency precisely and retain precise control over the range and precision. I’m still in the process of writing a more in-depth post on PWM configuration and limitations on the Arduino.
Broadly, the test code, maps the 10-bit (0–1023) ADC input from my control potentiometer, to a range of 0 to 10; with 0 being off and 10 being fully on. The intermediate 9 steps 1–9, then correspond to power of 2 divisors for the PWM max value of 1000. This yields a range of 0 to –9EV in approximately full stop increments.
For example, if the control knob corresponds to interval 7 (–3 Ev from full power), the value specified for the PWM compare register (OCR1A) is 125. Which corresponds to a duty cycle of 12.5%.
Test Setup
The test LED panel is an approximately 4×6 inch panel built from commodity self-adhesive LED strip lights — the kind that are about $1/foot from Amazon. With each strip being 8 mm wide, the panel consists of 12 6-inch long strips. These specific strips are rated to produce 82 lumens per foot. With a total of 6 feet of strips on the panel, the overall output of the panel is approximately 492 lumens.
The brightness of the panel was measured with an X-Rite i1 Display Pro (sometimes known as an i1 Display 3) and the spotread
tool which is part of the Argyll CMS suite. The specific command used was spotread -v -a ~/test1.log
to measure ambient light levels and log the results to a file.
Five samples were taken and averaged at each power setting.
The colorimeter was placed an arbitrary 6 inches from the test light panel to minimize the size of the test setup and to insure that it was close enough to make measurements at the –8 and –9 Ev levels.
The entire test setup was then covered with a standard corrugated cardboard box to minimized external light contamination.
Data
EV | Measured (lux) | Computed curve (lux) | Error from ideal (lux) | Error from ideal (%) |
---|---|---|---|---|
0 | 5588.5890154 | |||
1 | 2787.1677928 | 2794.295 | 7.127 | 0.255% |
2 | 1389.0822026 | 1397.147 | 8.065 | 0.577% |
3 | 694.4962282 | 698.574 | 4.077 | 0.584% |
4 | 344.7141498 | 349.287 | 4.573 | 1.309% |
5 | 172.6770506 | 174.643 | 1.966 | 1.126% |
6 | 83.7093576 | 87.322 | 3.612 | 4.137% |
7 | 39.1745548 | 43.661 | 4.486 | 10.275% |
8 | 16.9035222 | 21.830 | 4.927 | 22.569% |
9 | 5.872084 | 10.915 | 5.043 | 46.203% |
Discussion
The test setup appears to preform sufficiently well that I expect to continue to use it for future tests. As such, I anticipate the numbers produced by any future test should be directly comparable to the numbers in this test.
The deviation from the expected value is almost certainly a product of the both the limited bit depth (1001 instead of 1024 values, or 9.96-bits not a full 10), and the use of integer arithmetic which truncates fractions.
For example, the ideal value for OCR1A for the –9 Ev setting would be 1.953, and 2 would likely be the best “rounded” alternative. However, integer math truncates instead of rounds and results in the value of 1 being used, which will undercut the power by 46%.
This error just underscores the interdependency of the bit-depth and internal generation of the PWM clock.
Honestly, I also just plain forgot to even consider or factor the math in when I was writing the code. And I would point out, that while I should have been well aware of the fact that I was introducing an inaccuracy into the system by trying to map 10-stops of control into less than 10-bits of range, I simply neglected to consider it while attempting to get a specific frequency.
That’s about all I have for this test. While I didn’t generate great data about the precision all the way over the range I’m working on, I did isolate an issue I hadn’t anticipated — though I should have — so I can improve the test and try again. I would also point out, that while this was directed at PWM, the issue of mathematical rounding, accuracy, dynamic range, and bit depth still apply for alternative mechanisms to control the LEDs (such as using a DAC or PWM to generate a reference voltage).