Turn Coordinator and Much More
- James Wiebe
- 2 days ago
- 3 min read
Radiant Tech Note – November 25, 2025 When a “Drifting” Inclinometer Wasn’t the Problem
Editor’s Note
At Radiant Instruments, we’re using AI as a genuine engineering partner to speed product development. The story below is a good example.
James Wiebe drives the concepts, experiments, and decisions. An AI assistant helps track subtle interactions in a 4,500-line embedded program, suggests hypotheses, and occasionally guesses wrong. James challenges it, corrects it, and together they converge quickly on robust solutions. This is human experience and AI pattern-recognition working together, not replacing one another.
The Symptom: A “Drifting” Digital Ball
Today in the Radiant lab, we were adding an adjustable backlight feature to one of our products. That sounds simple, but it had unexpected downstream effects on the internal sensors.
Our electronic inclinometer (“the ball”) started behaving strangely:
After power-up, the ball would sometimes sit a little left or right of center.
Performing a CAL on a leveled jig would recenter it… until the next power cycle.
At mid-brightness, things got much worse: the ball would jump several positions to one side and then snap back.
We needed to know whether this was a sensor problem, a math problem, or something else entirely.
So we instrumented the firmware to display the raw tilt delta in a debug window:
dtilt = CurrentTilt – ZeroCalBall
Then we put an oscilloscope on the 3.3 V rail that powers the microcontroller and sensor.
The Smoking Gun: Power Rail Abuse
At half-brightness, the scope told the story:
The 3.3 V rail showed approximately 250 mV of droop, in perfect lockstep with the LCD backlight PWM signal.
In hindsight, the accelerometer and ADC weren’t “wrong” at all.They were accurately reporting a supply line that was being yanked around by the backlight.
In other words: the inclinometer wasn’t drifting — the power rail was.
The Fix: Move the Noise, Not the Math
The LCD module in this product has two separate supply pins:
Logic VCC – 3.3 V for the digital interface
LED VDD – the supply for the backlight LEDs
Originally, both were fed from the same 3.3 V regulator, so every LED current pulse showed up as a load step on the analog rail.
The fix was wonderfully simple and cost nothing in hardware:
We moved LED VDD off the 3.3 V regulator and
Re-routed LED VDD to the Li-Ion battery rail instead.
Because the backlight is driven from a current regulator, it doesn’t care whether it’s fed from 3.3 V or the raw battery pack, as long as the voltage is within spec. Now the LED current pulses are sourced from the battery, instead of beating up the delicate 3.3 V analog domain.
Once the rail was clean, we also removed a no-longer-needed “VCC compensation” block in code that had been trying to correct for earlier supply variations. That code was based on sampling VCC/2 once at startup, and it was quietly introducing tiny random biases across power cycles. With a stable rail, it was better to remove it.
The Result
After these changes:
DIM and mid-brightness no longer disturb the inclinometer.
The debug tilt value is rock-steady (±1 count) on a leveled jig.
Repeated power cycles now all return to the same numeric center instead of picking a new “home” each time.
And as a nice side effect, code size shrank slightly with the removal of the compensation logic.
The inclinometer “drift” we saw originally was not a bad sensor, not bad math, but simply an overworked 3.3 V regulator being asked to drive both precision analog circuitry and a PWM-chopped LED load.
Technical Takeaway
Before you blame your sensors or algorithms, put a scope on your power rails.
Sometimes the “drift” is just your LEDs yelling on the wrong power net.