Close

part 4: logo, brightness control, Giger board.

A project log for Megapixy: a 13" Retina-class screen on a boom arm.

Google's $1300 Chromebook Pixel has an awesome screen. i only want the screen.

tshen2tshen2 04/11/2015 at 04:021 Comment

let's detour into visual design - did you notice this on the previous update?

it's the Megapixy logo!

i like Megapixy, and i like making logos. go figure.

in the infinite possibility space of logo (and not-logo) design, some reason must be provided for why anything looks like anything. the Megapixy logo exists because:

  1. Megapixy uses the embedded Displayport video interface.
  2. Megapixy has the same 3:2 aspect ratio as the Chromebook Pixel.

with regards to 1, there's a little homage to the Displayport logo:

as for 2, the Megapixy logo also has a 3:2 ratio.

now back to engineering :D


hybrid PWM/PFM brightness control

brightness control should be easy, right? nope.

there's an ATtiny microcontroller on the 'comma' board which reads the brightness dial. the microcontroller creates a PWM signal which gates the backlight driver. it looks like this:

[block diagram of Megapixy brightness control (first try).]

some simple measures were taken to reduce electronic noise:

and then, an interesting bug. when the screen was on, i could hear a tiny whining sound!

and to explain that, i'll have to talk about PWM.

[cartoon of pulse-width modulation (PWM)]

pulse-width modulation (PWM) means controlling something with a series of on/off pulses. the perceived 'on-ness' (e.g. backlight brightness) is based on the fraction of time when the device is 'on'. this fraction is called the duty cycle. the on/off pattern repeats with a fixed frequency.

the backlight driver's on/off pulses were a PWM running at 500Hz. i was powering the Megapixy with a cheap 5V power supply, which was now having to supply more & less power on a 500Hz cycle. this caused my power supply to buzz audibly at 500Hz - the so-called 'coil noise'. how could i fix this?

i could make the sound inaudible by increasing the PWM frequency from 500Hz (repeating every 2ms) to 20kHz (repeating every 0.05ms).

inaudible to humans, anyway. some dogs might notice.

the problem is, the higher your PWM frequency, the shorter your 'on' pulses:

during each 'on' pulse, the backlight driver has to turn on and pump up the backlight voltage. this process takes about 0.01ms. if the backlight driver doesn't have enough time to turn on, it shuts down completely until the circuit is reset. with a 20kHz PWM, this places a 20% minimum duty cycle on my backlight brightness control.

why is this a problem? because people like their screens to be really dim at night!

a 20% to 100% brightness adjustment isn't good enough. so what can i do?

there's this other thing called pulse-frequency modulation (PFM):

[cartoon of pulse-frequency modulation (PFM)]

in PFM, the duration of each 'on' pulse is always the same. to reduce the duty cycle, you can increase the time between 'on' pulses. at very low duty cycles, you will have large gaps between each 'on' pulse, which means a lower (and perhaps audible) frequency.

but PFM is still worthwhile because you can reach a lower duty cycle (brightness) without shortening the 'on' pulse. this gives the backlight enough time to turn on, even at very low brightness settings.

neither PWM or PFM does exactly what i want, but can i combine them to solve my problem?

the power supply might make sounds in the lowest brightness settings, but at least i would have lower brightness settings.

[partitioning of brightness control into smoothly-transitioned PWM & PFM.]

getting a smooth transition requires a teeny bit of math.

[featuring a random notebook from a random hotel.]

the net result is a brightness dial which adjusts from 100% (silent) to 2% (almost silent).

[cartoon of hybrid PWM/PFM brightness control.]

that's enough about brightness control!


i'm still not satisfied

with the Megapixy. why? let me count the ways.

  1. the 'comma' board looks stupid and wastes space. it's a sure sign that i haven't constrained it enough.
  2. the Displayport cable sticks out at a stupid angle, like an awkward elbow. it should attach neatly, next to the screw mount.
  3. the chassis is stupid. the wood warps when wet, the design wastes material, and the bezel bends under my fingers when i hold it.
  4. the LCD panel is mounted unevenly, causing backlight bleed.

let's address 1. why does the 'comma' board waste space?

to fix 2, i want to reposition the Displayport video connector, so i definitely have to move the LCD cable connector. i might as well move it closer to the controls, to reduce board size.

how can i make the cable reach its connector's new position? i can bend it. duh.

i can also move the tallest components out from under the screen. it saves a precious millimeter.

this was around the time that H.R. Giger died, which made me sad. being in a Giger-ish state of mind, i ended up making a PCB which looks.. strangely organic.

i call it the Giger board.

[schematic of Giger board.]

[layout of Giger board.]

[Giger board, front.]

[Giger board, back.]

[assembled Giger board in chassis (TBA).]

[LCD cable, bent to reach new connector position.]

[backlight capacitor & inductor, no longer under the screen. the on/off switch cover has a living hinge.]

the result is a smaller, denser, more beautiful board which scratches my artistic itch.

but there's still two problems to solve!

and that's what we'll talk about next time.

next update: fancy chassis design, lasers, lasers, lasers.



Tshen2 2014

Discussions

esot.eric wrote 04/12/2015 at 07:19 point

Good solution, but (shameless plug) you heed HFM :)

Rather, I dig your explanation, here, about PWM and PFM...

High(est) Frequency Modulation, as I call it, was something I intended to use for variable-power on solenoids (which make a *lot* of noise with low-freq PWM, especially when mounted on a huge resonating box). It was found useful (but not unique) for many other things, and later discovered, maybe, to be PFM. But your explanation suggests otherwise.

HFM is only a handful of instructions, but basically does what you're doing with one bit of code. It also has the added benefit of arbitrary-resolution... e.g. you want 30% duty-cycle, it goes on for one-cycle and off for two... you've got 2/7ths duty-cycle, it goes on for one cycle, then off for three, then on for one, then off for two...

(If you're curious there's an explanation burried in here: https://code.google.com/p/avr-lvds-lcd/source/browse/_commonCode_localized/hfModulation/1.00/hfModulation.h )

Anyways, shameless plug. Sorry! Mainly I'm just intrigued because it seems you may've shown me a use for HFM that might not be accomplishable with PWM or PFM. Thanks :)

(Sorry for the brain-dump... Actually, in your case, with "warm-up time", it may not be as good a fit as your method, since, e.g. the 2/7ths case you'd have 2 separate brief pulses which might result in less brightness... a single double-width pulse would allow it to be on longer after warm-up, still not 2/7ths brightness, exactly, but probably closer).

That screen-res is INSANE. I can definitely see why you've put so much effort into this... I did similar just to bump up from 1024x768 to 1440x1050.

  Are you sure? yes | no