The UPSide state diagram

I think this diagram is now stable enough to put on the record. Both this diagram and the Go code for the policy logic are generated from this pseudocode: render.state(“DaemonUp”, “Daemon running”) render.action(“DaemonUp”, “ChargeWait”, CHARGING) render.state(“ChargeWait”, “Charge wait”) render.action(“ChargeWait”, “MainsUp”, CHARGED) render.action(“ChargeWait”, “OnBattery”, MAINSDROP) render.state(“MainsUp”, “On mains power”) render.action(“DaemonUp”, “OnBattery”, MAINSOFF) render.state(“OnBattery”, “On battery power”)… Continue reading The UPSide state diagram

UPSide progress report

The build-a-better-UPS project is progressing nicely. About a week ago we had first hardware lightup; I successfully threw messages over an I2C bus to the 20×4 LCD we plan to use as a status display. Hey, it’s not the power plane (yet) but it’s something.

UPSes compared to guard dogs

Somebody using the handle JeffyPoooh (yes, ‘ooo’) left a comment on The Register that is an only slightly exaggerated summary of the reasons for UPSide:

How to get started on the UPSide project

The current state of play is: We have a high-level system design and a map of the behavior states. We have a capacity target (300W for 15 mins) and a peak-continuous-load spec (400W) We know we’re going to build a double-conversion design and we’re considering a couple of alternative topologies. We pretty much know the… Continue reading How to get started on the UPSide project

upside wants a firmware dev

The UPSide project, announced here two weeks ago, has come together with amazing speed. We now have: * A hardware lead – A&D regular Eric Baskin – with thirty years of experience as a power and signals engineer. He is so superbly qualified for this gig that my grin when I think about it makes… Continue reading upside wants a firmware dev