Much has changed in UPSide over the last week. Ground has been broken on the software; one key piece of the control daemon, the policy state machine, now exists.
The design of UPSide is coming together very nicely. We don’t have a full parts list yet, but we do have a functional diagram of the high-power subsystem most of which can be expanded into a schematic in a pretty straightforward way.
If you want to see what we have, clone the repo, cd to design-docs, make transactions.html, and view that in a browser. Note that the bus message inventory is out of date; don’t pay a lot of attention to it, one of the design premises has changed but I haven’t had time to rewrite that section yet.
We’ve got Eric Baskin, a very experienced power and signals EE, to do the high-power electronics. We’ve got me to do software and systems integration. We’ve got a lot of smart kibitzers to critique and improve the system design, spotting problems the two Eric’s might have missed. It’s all going well and smoothly – except in one key area.
UPSide needs a battery technologist – somebody who really understands all the tradeoffs among battery chemistries, how to spec battery types for different applications, and especially the ins and outs of battery management systems.
Eric Baskin and I are presently a bit out of our depth in this. Given time we could educate ourselves up to the required level, but the fact that that portion of the design is lagging the rest tells me that we ought to recruit somebody who already knows the territory.
Any takers? No money in it, but you get to maybe disrupt the whole UPS market and and certainly work with a bunch of interesting people.
My wing chun sifu played a classic martial-arts-master trick on me tonight.
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:
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 external-interface specs (some details may change).
I’m expecting both my prototype copy of the forebrain Unix SBC (an Olimex LIME2) and the interface contract for the high-power subsystem to land on my desk tomorrow.
Interest in this project continues to be huge. Another company wants in as of this morning. The volume of feature requests is high enough that I’m buckling under the editing load.
The rest of this post is instructions to potential contributors about how to get on board.
1, Get an ID on GitLab. Tell me what it is so I can add you to the project group.
2. If you have a feature request, please Don’t post it on this blog. Add it to the “General feature request thread” on the tracker.
3. Read the wiki. Read the tracker issues. I try to keep both pruned so the volume is not overwhelming. Read the Rejected Ideas page on the wiki, too.
4. Read the design documents in the project wiki. The important one is the transaction design; the I2C message inventory will change, but the basic state diagram probably won’t.
5. Participate in the design discussion. This takes place in tracker threads.
6. When we’re ready to breadboard a prototype, throw some parts money in the tip jar we don’t have yet. If you must contribute before then the PayPal blogbutton works fine.
7. Prototype builds will probably go down at PA Makerspace in Phoenixville, PA. If you are within driving distance and a competent electrics tech, consider joining us for a build.
8. Once we have a full design with a PC board and enclosure: if you have a shop facilities for it, try to replicate the build. We’ll know we have the build recipe debugged when other people can do it.
9. If your favorite hardware feature request doesn’t appear in the version 1 prototype, relax, We may think it’s a good idea but be holding off till v2 out of a desire to keep v1 simple and launch fast.
10. If your favorite software feature request doesn’t appear in the version 1 prototype, pitch in and make it happen. A Unix SBC is not a difficult programming environment – the OS on this one is a Debian port.
After step 10 and a couple of design iterations the future becomes less clear. maybe try to get it into volume manufacturing through a partnership with an established vendor.
Inertia is a powerful force. The computing world retains a lot of practices that are odd little dysfunctional relics of past stages of its technology. The one I’m here to talk about today looks like this:
Mar 6 15:11:07 snark postfix/qmgr: 0422513A6C53: removed
That’s a log message hot’n’fresh from my /var/log/mail.log file. It’s entirely typical of traditional log formats on Unix systems, and these things offend the bejeezus out of me every time I see them. Now let me show you how this would look in a sane universe:
Andrew Klavan has a thoughtful essay out called A Nation of Iagos. In it, he comments on William Shakespeare’s depiction of Jews in a way I think is generally insightful, but includes what I think is one serious mistake about the scene from The Merchant of Venice in which the (black) Prince of Morocco woos Portia.
He chooses poorly, fails her father’s test, and as he leaves Portia mutters “May all of his complexion choose me so.”, which Klavan reads as a racist dismissal. I winced.
I tried to leave a comment on the essay only to find when clicking “Post” that it required a login on the accurséd Facebook, with which I will have no truck.
Here it is:
There’s a lot of buzz about Iain Banks’s Culture universe lately, what with Elon Musk naming his drone ships in Banksian style and a TV series in the works.
I enjoyed the Culture books too, but they were a guilty pleasure for me because in a fundamental way they are bad SF.
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 my face hurt.
* A high-level system design (about which more below) that promises to be extremely capable, scalable, flexible, and debuggable.
* A really sharp dev group. Half a dozen experts have shown up to help spec this thing. critique te design docs, and explain EE things to ignorant me.
* Industry participation! We have a friendly observer who’s the lead software architect for one of the major UPS vendors.
* A makerspace near me where the owner recruited himself onto the project and is looking forward to donating bench time and skilled hands to the hardware build.
All this helpfulness almost – but not quite – fills in my deficits as a designer/implementer. I don’t really know from hardware design, so I’m attacking the problem with the modularity and information-hiding principles I know from software.
Here is how the design looks:
An I2C bus that ties together a “forebrain” which is a Unix SBC, almost certainly at this point an Olimrx LIME2, with a “midbrain” that is an Arduino-class microcontroller.
The midbrain is mechanism – a simple state machine whose job is to control the high-power subsystem (inverters, battery, AC input and output). Policy decisions and stuff like battery state modeling will live in the forebrain. It will also run the USB and Ethernet interfaces, and host the development environment for the firmware
The forebrain will talk to a 20×4 LCD panel over I2C, and various other controls like alarm mute and self-test buttons via GPIO pins.
I’ve actually written the spec for the I2C bus messages already. And here’s your cute hack for the day…
I realized early on that one of the first things I needed to do was draw a state/action diagram for the system so I could pin down its behavior in response to any given transition in its environment (mains power up, mains power down, battery dwell limit approaching, those sorts of things). So I reached for one of my favorite tools, a graph-drawing DSL called dot.
Only when I write the first version of the graph, I found the dot markup cluttered and repetitive. So I wrote a couple of cpp macros named “state” and “action” that expand to dot markup, and expressed the graph as a sequence of macro calls.
Then I blinked, looked again, and realized…hey, I could compile these calls to C source code for a state machine! And now it is done – I can already generate the tricky part of the application logic for the midbrain directly from the state/action diagram. (The action functions are stubs but the control flow is all there.)
(If the fact that I just solved a design problem by writing a DSL to generate code in another DSL and provably correct equivalent C application logic seems weird to you, you must be be new here. This is how I think all the time. It is obedience to the Unix wisdom: never hand-hack code you can generate from a higher-level description.)
This, however, does not solve the entire firmware problem by any means. The midbrain’s going to need system logic to do things like receive and send I2C messages, poll A2D converters from sensors watching the mains and battery voltage, and so forth.
Accordingly, we need a firmware developer. I’ll learn how to do this if nobody steps up (which is why I said “wants” in the post title) but the whole process will doubtless go faster and more smoothly if we have someone with experience. So:
WANTED: One firmware hacker. Must be familiar with AVR-class microcontrollers and the Linux toolchains for them. Experience with I2C and low-level programming of USB endpoints would be a plus. Perks of the job include getting one of the first UPSides made, your name in lights, and working with a dev crew that is impressive even by my elevated standards.
EDIT: Well, that didn’t take long. A&D regular Jay Maynard has signed on.