My home has mostly been converted to LED lightbulbs. With a variety of needs of brightness and socket bases, we have a variety of bulbs on switched dimmers, with a variety of turn-on behaviours. Some start from zero and ramp up. Some start from the minimum turn-on level of the bulb. Some seemingly start randomly then approach the expected output level. This has got me thinking about the topic of filter-initialization.

AC Dimmer Introduction

Wall power here is 120-Volt, AC/sine, 60Hz. Typical home dimmer systems operate by chopping the sine-wave at a specified phase(point in time relative to the cycle). This leads to a rather jumpy voltage delivery to light bulbs. In the incandescent past, the thermal mass of bulb filaments was enough to filter out the voltage spikes from the dimmer. With the advent of LED bulbs, "dimmable" bulbs usually include a decoder or filter of sorts to handle this.

Alpha-Filter Introduction

An alpha filter, or exponential moving average filter, is one of the simplest low-pass IIR filters. Generally, the filter is represented by two values. The first value is a state-variable that is updated each time we process a new sample. The first value is a constant, named alpha, that relates to how much smoothing occurs. For each sample the math is simply:

state = sample * alpha + prevState * (1 - alpha)

When alpha=1.0, the filter simply passes input to output, and can be considered to have unlimited bandwidth. When alpha=0.0, the filter blocks any changes as has zero bandwidth. Everything in-between provides a trade-off between responsiveness and smoothness. Typically, alpha is an application-specific constant.

I have no idea if light-bulbs use alpha-filters, but we'll use them as a way to discuss a more general problem.

Initialization

What should we use for prevState for the first sample? In some applications turn-on transients may not matter too much, but here are a few approaches:

Option1: zero

prevState = 0

Starting at zero means the filter is going to under-estimate the target value for a while, but in the case of a light-bulb this can give a slow but not unpleasant ramp-up, especially while carrying a newborn infant around the house wondering about how my lightbulbs handle filter initialization. One downside is that there is a noticeable delay getting a useful level of light output.

Option2: minimum bulb output

prevState = minOutput

Similar to starting at zero, starting from the minimum bulb steady-state output also gives us a small amount of light immediately, then ramp-up to the target. One odd thing about this when the dimmer is set to the minimum level when switched on, the bulb turns on immediately but then doesn't ramp up at all since it's already reached its target output. It feels inconsistent and find myself sometimes expecting it to brighten further.

Option3: first sample

prevState = anyPossibleInputValue

Some of my lightbulbs strike on to a seemingly random value, then ramp up or down as needed to the target dimming. Due to the chopped AC waveform, this is almost certainly the wrong choice for a light bulb, but may not be a bad choice for other applications.

But this approach has one advantage - on average, it'll at least start somewhere in the expected range.

This is equivalent to overriding alpha=1.0, just for the first sample.

Proposal: variable filter bandwidth initialization

What if we ramped alpha from 1.0 toward during the first few samples? It turns out we can get both quick initialization and a variety of filter responses from this. One possibility - substitute alpha for 1/N (where N is the sample-number, starting with 1):

state = sample * 1/N + prevState * (1 - 1/N)

This happens to generate a sliding-window filter. After 1/N decreases below some minimum-alpha, we can transition to traditional alpha-filter behaviour, like so:

tmpAlpha = MAX(alpha, 1/N)
state = sample * tmpAlpha + prevState * (1 - tmpAlpha)

The end result of this is that we take the first sample as truth, then several subsequent samples are averaged together with decreasing filter bandwidth for each, before reaching our final minimum bandwidth steady-state alpha. Early during startup this can lead to very noisy samples, so we might want to clip tmpAlpha, like so:

tmpAlpha = CLAMP(alpha, 1/N, 10 * alpha)
state = sample * tmpAlpha + prevState * (1 - tmpAlpha)

Here's what that looks like. 1500 random samples, alpha=0.002 for the fixed-bandwidth filters, but ranges 0.002 to 0.02 for the variable filter:

The variable-bandwidth filter approaches the target value quickly, perhaps a little too quickly and overshoots slightly, then smoothly approaches much quicker than constant alpha filters.

One of the upsides to older car ownership is that over time, more internal information tends to leak out from manufacturers.

Every vehicle has a relationship between pedal input and throttle. With older vehicles, there was a lever, linkages, or cables between the pedal and engine. Some amount of nonlinearity can be chosen by adjusting the linkages or the throttle pulley. With electronic systems, we can replace that relationship with software, and switch it at runtime.

Toyota's implementation is known as Electronic Throttle Control System- intelligence(or ECTS-i), and I recently found a "How it works" PDF. Largely the 2000s can be divided into three periods for each Toyota model: before ETCS-i(mechanical throttle cable and pulley), ETCS-i with mechanical fallback, all-electric ETCS-i.

At time of writing, I still own a 2002 Toyota Highlander. There's a throttle cable between the pedal and throttle, so I knew it wasn't not fully electric. This car features a Snow-Mode button that tends to reduce take-off burnouts, but I have always wondered exactly how it works. This PDF confirms that snow mode does nothing at all to the throttle - Highlanders up to 2003 are mechanical cable only, and 2004 and beyond are ETCS-i. This largely confirms that snow-mode on these earlier 1st gen cars is implemented by adjusting the transmission shift points.

Later on in the document, there's an interesting description of the details of the newer implementations. To start, the pedal is a 5v sensor, and outputs a linearized DC voltage(presumably with the standard headroom & footroom that allows the ECU to detect a broken or shorted signal wire). Once the ECU reads the input from the pedal, it can remap the pedal to throttle relationship programmatically, like so:

Anyone who has tuned RC vehicles may recognize these curves as...mostly just expo!

I need to build a packet-dropper for work. I bought a sack of ethernet couplers, but they were surprisingly heavy. Molded into the case is "RJ45 Coupler" and "Cat 15A16A", neither of which are particularly descriptive.

Ages ago, they used to be lightweight beige plastic with stamped metal pins connecting from one side to the other.

So, I opened one of the new ones to find they use a tiny 2-layer circuit board now, and standard through-hole connectors. The traces aren't length-matched, but that probably mostly matters within each pair of signals. My handiwork has indeed damaged a few of the traces.

The circuit board isn't long enough to solder to the shield, so the shields are floating bits of metal, and this acts as a break in STP. Since the shields aren't soldered, they're usually held by the plastic molding. A few times I've run into really interesting uses of conductive rubber and plastics, but no, the meter says 20+ mega ohms.

But why?

I ran into a strange situation at work where I needed to be able to drop packets on demand. I was pushing a button on a device under test, and found I could rub my wedding ring on the RJ45 coupler pins more reliably than stretching across the desk to fiddle with the ethernet cable and trying to jam it back in. Eventually this resulted in this fix to the ESP-IDF