A program can vary the command to a UV lamp without telling you how much ultraviolet energy reaches a surface. If you are evaluating an early device concept that involves UV, decide which claim each experiment supports. Otherwise a control demonstration quietly turns into a performance promise that nothing has tested.
On our bench we ran a UV LED array module from a Raspberry Pi Pico on a Graft carrier board, programmed in BIPES blocks that generate MicroPython. It belongs to the same family of output experiments as driving a fan or a small motor: a switching stage, an external supply and a timed PWM sequence. The project idea behind it was a disinfection gadget. Nothing in this test measures that application, and this note is about keeping the two apart.
Trace the electrical command
The setup has a controller, a switching module, the UV array, a battery and a converter module that supplies the load. The load's power path is separate from the controller: the GPIO pin is a control connection, not the power source for the array. That is the first thing to confirm in any driven-load prototype, before looking at the software.
The program configures GPIO6 for 1 kHz PWM and steps the command from 0 to 36000 in increments of 3000, one step per second. At each step it prints a "current PWM output" label and the value. At the end it prints "turn off UV array". Those console lines report software commands. They are not readings of current, voltage or light.
Two details of the generated code are worth noticing if you reproduce it. It creates a new PWM object on every pass through the loop rather than once before it. And it first tries a duty() call, falling back to duty_u16() when that fails. On the duty_u16 scale, where 65535 is fully on, 36000 is about 55% high time.
That 55% is an electrical duty cycle. It is not 55% of a measured optical dose, and it does not establish that useful output rises linearly with the command. LED output, driver behavior and temperature all sit between the number and the light. We made no wavelength measurement, no irradiance map, no exposure-geometry record and no treatment result.
Keep the physical demonstration in its proper role
A visible glow on the bench tells you, at most, that the driver is switching. Visible brightness in a photograph or to the eye cannot measure ultraviolet output.
Likewise, a "turn off" message in the terminal does not independently verify that the output is electrically inactive. In our program the off step reconfigures GPIO6 as a plain output and drives it low. Whether low actually means off depends on the switching module's circuit, not on a universal assumption that high means on.
A cleaner off sequence would be explicit: command zero duty, release the PWM where appropriate, and set the inactive GPIO state that the actual driver requires. Then confirm it at the load with a meter, and check what the output does during reset and power-up, before the firmware has configured the pin. We have not tested that revision on this hardware.
Match each test to its claim
There are three separate things a UV prototype might need to establish, and each needs different evidence:
- Electrical control. The firmware can switch and dim the load, the supply holds up, and the off state is the real off state. A meter or scope on the load circuit answers this. Our bench run covers the first part of it.
- Optical output. What wavelength is emitted, and how much UV reaches the target surface at the intended distance and angle. This needs an appropriate UV meter or spectrometer and a fixed geometry.
- Application effect. Whether that exposure does what the product claims. This is a separate validation question that needs the right expertise and test methods, not an electronics bench.
If you only want to learn PWM control of a light source, an ordinary visible LED gives directly visible feedback without implying any UV application. If the product genuinely needs ultraviolet output, then optical performance, containment of the light, and interlocks that stop exposure when a cover is opened become design requirements in their own right, with their own measurements. A dimming ramp on the bench answers none of them.
Write the intended claim down first, in plain words. It decides which of the three tests you need before anyone talks about the product doing what its name suggests.