what is a kegerator? a kegerator is the combination, typically home-made, of a barrel of beer and a refrigerator modified with beer-dispensing equipment.

what is a kegbot? that's the kegbot to you, since right now only one exists! the kegbot is a kegerator that has been equipped with special tracking hardware and software; it runs linux. by limiting and tracking access to the product, you can find out how much people drink, how much is left in the keg, and other fun stuff.

for a better idea, please see the features list. please also see the Kegbot Wiki, for some more information. (there is some overlap and disorganization at the moment, i know, sorry..)

NOTE: so long as the emphasis is on coding the kegbot itself, expect this site to be somewhat out of date and incomplete. when the next keg is installed (any day now), the focus will shift back to here.

some dated photos.. (more new ones soon, promise..)

the kegbot has been getting more attention than usual lately. please make your way to the Kegbot FAQ if you happen to be lost!

kegbot and i (and a bunch of others, in fact) are headed down to defcon 13 in las vegas today. we're setting up a kegbot at the fromtheshadows.tv party. it ought to be spiffy.

in related news, some fancy kegbot PCBs arrived thursday and are help making this weekend's marathon trip possible. trip report to follow!

i left town for a few weeks, and i came back to find kegbot.org offline. oops! a billing screwup (my fault) with my hosting provider. now fixed!

also, the kegbot wiki has moved, for now at this location. (i switched from tikiwiki to mediawiki)

just created the kegbot-dev mailing list for general talk about how to build sucha tracking device. sign up if you are interested, should be pretty low key.

also, eric surprised me to tell me that 10 new flow meters arrived in LA today. it is time to get those kits together!

so, you got yourself a coinco magpro mag50b bill acceptor on ebay, you read the coinco datasheet, and you STILL don't know which pin is which? fool!

i had the same problem. not familiar with the magpro's sparsely populated headers, i mailed coinco. david n. promptly wrote back (thanks david!) and cleared it all up. here's a pictoral look:



this view is looking at the headers with the controller box facing up (ie, label to sky). david's descriptions, left to right:

1. 110 VAC High Level Pulse Interface
   • Credit (-), This is the DC voltage ground reference for the credit pulse.
   • Credit (+), This line should be tied to +5 volts DC through a 10K pull-up resistor.
   • 110VAC Neutral, This is the neutral side of power supplied to the bill acceptor.
   • Neutral Inhibit, If the neutral side of 110VAC is supplied, bill acceptance is disabled.
   • Hot Enable, The hot side of 110VAC must be supplied to this pin to enable bill acceptance.
   • 110VAC Hot, The hot side of power is supplied to the bill acceptor at this pin.
2. MDB (Multi-Drop Buss) Interface
   • Master Receive, The vending machine controller bd. receives serial communication on this pin.
   • 34VDC return, This is the MDB power ground reference pin, 0VDC.
   • 34VDC Power, This is the power supplied to the bill acceptor.
   • Master Transmit, The vendor controller sends serial commands to the acceptor on this pin.
   • Communication Return, This is the ground reference for the transmit & receive lines, 0 VDC.

so, if you want to get up and running, grab a power cord, hack off the end, and attach two female spade connectors to the lines. connect one end to AC neutral, and one end to both ac hot and ac hot enable. you're now ready to accept money! (i tried to earn some cash by offering "demos" to my friends -- "see what happens with a $20!")

this may also provide some insight into the mysterious MDB protocol. basically it is 3 pins of Rx/Tx/GND. remember, it's almost like 9600 baud rs232 but (a) it appears to be TTL level, and (b) there are 9 data bits (they call them "8 data bits and 1 mode bit" -- ahh, nice try..)

a few people have asked me some questions either regarding the kegbot or building a kegerator in general. to take care of the common questions, i've started two FAQs that i'll add to as new questions come in:

- kegerator FAQ
- kegbot FAQ

suggestions welcome!

this weekend, we finished keg #3. interestingly, the kegbot was the most accuracte yet in determining the remaining amount of beer. with the keg empty, it believes there are 35 ounces (or 2.1%) left in the keg.

i've no idea how much foam/unreachable beer there could be in the keg, but this is very good news. very little beer from this keg was lost during hookup, and no drinks were not counted.

here is the keg #3 status page.

(to give you an idea of how far the accuracy had come, keg #2 was thought to be 11% full when empty, and keg #1, with lots of flow problems, 67%.)

i've just gotten some free time, and i updated the kegbot a bit. the kegbot.org site is now hosted at a real hosting company, which should make it snappier. i also twiddled with the stats a bit, and now all drinkers are shown with some interesting stats.

(surprisingly, i've only had just over 15000 calories in ~1000 ounces of beer to date. that's like a few meals, but not terrible... right?)

about a week ago, i let google start crawling the kegbot pages, and (perhaps not coincidentally) a couple people have e-mailed me asking for more details about building a kegbot. this is really cool!

so, the latest status is, i'm putting together a better (and cheaper) parts list, and i'll be ordering larger quanitites of all the important parts from a distributor, probably digi-key.

the PCB for the kegbot is pretty simple; the hard part is just getting the non-standard parts properly defined in my cad program, so that the autorouting and component placement turns out alright.

while the board is being fabbed, i'll be waiting for delivery of a handful of flowmeters. i have no problems with the current one, so we'll just use that. since finding the right flowmeter is such a pain, this part isn't likely to change. maybe i'll be able to get dan to hunt down the plastic connectors we use and order another batch.

so there you have it, the 5-week plan for kegbot domination!

here are some more pictures:

• a beerkey connected to the kegbot.
• a pour in progress as seen on the kegbot-lcd. (don't get alarmed - i had more than two ounces!)
• what you get after you are done with your pour
• the kegbot menu, again on the status lcd. this is navigated with a keypad. currently it doesn't do much, but it will soon be used for setting up guest beer keys

i just realized that there is no link to the 'live stats' page for the kegbot on this, the project page.. well, here it is: live stats (kegbot.org)

in other news, i've just started a new job, so getting the PCB spec'd might take a little longer. on the plus side, time away from the kegbot might give me a chance to better update this page (like, with some recent pictures!). more soon..

the kegbot meets slot machines. now, whenever your pour hits a certain marker (say, 12 ounces - the size of the standard beer can), a loud, honarable sound is played through some connected speakers. kinda like hitting the jackpot -- this sound announces "someone is using the kegbot, and he just poured himself a full beer. OHHH YEAAH"

currently, the first few seconds of "yello - oh yeah" are played (aka, duffman's theme)

i took a week-long vacation, and in that time without me looking after it, the kegbot had no problems. i think the hardware and software reliability is now at a very nice place.

because installing them will require a new controller board to be soldered up, the ftdi chips are not yet being used.

next big features/changes to add:

• add the drink cost breakdown to the drinker login page. (price recording for drinks has always worked, but now it is time to display the awful truth to the drinkers).
• connect the dollar-bill acceptor. it works, but i need to whip up a small pulse counting circuit in order to interface it to the computer. also, some hardware (like wood or plastic) is needed, because currently there is no good way to attach the acceptor to the fridge.
• build the kegbot facade. this will take someone with basic artistic skills. the goal is to mask the fridge look and make the kegbot look more appealing outside. (this should also hide the compressor at the back, and incorporate the controller hardware and bill-acceptor.)

the ftdi chips should arrive tomorrow! and with that, i will greatly simplify the power requirements of the kegbot controller.

presently, we require ~110VAC for the freezer, 12VDC for the solenoid valve, and 5VDC for the microcontroller and relay valves. (technically, +/- 16VDC are on a few lines courtesy of the MAX232, but that isn't really a PSU requirement now is it..)

with the magic of USB, however, we're guaranteed 500mA of 5.0VDC bus power! so, configuring the ftdi to power the pic, we no longer need a 5VDC wall wart. (the DK relay draws only 40mA; i'll have to account for all the other components, but we're still probably well under 500mA)

now, we still needed 12VDC, which is a pain.. but i just remembered that the solenoid valve is also available in a 120VAC configuration. this will require changing the relay that switches teh valve, but other than that, that eliminates the need for a 12V rail in the controller!

after all this consolidation, we will be left with the following ports:
  - USB plug
  - 120VAC in (power cord)
  - 120VAC out (fridge switched)
  - 120VAC out (solenoid switched)

cool!! and to think i was looking at bolting a 5v/12v DC PSU to the fridge.. it would have worked but.. ugly!

oh, forgot to mention this new feature from last night..

the host-side alarms are now in place! here, my cellphone has been paged because regularly temperature recordings seem to have stopped.

the neat thing is that this alarm system can run on any machine -- not just the kegbot host machine. so, i can run an instance of the alarm daemon (actually, its just a one-shot program that runs via a cronjob) on any machine that can connect to the kegbot.

my cellphone is loud and (sadly) nearly always near me, so it makes an ideal alarm. the 'paging' uses sprint's e-mail gateway that converts a message into some bastardized sprint-style text message.

although it has come a long way, the microcontroller for the kegbot has needed some changes, both in the hardware and the software.

software changes
i'm now testing a newer method of communication with the mc. the new state machine is much simpler and much easier to understand.

all commands the host can send to the MC consist of a single one-byte command word. examples include OPENVALVE, GETSTATUS, etc. the host now replies to all commands with a single unform "status packet", which contains around 7 bytes of status: state of the relays, current flow ticks, and so on. this will soon contain the temperature information, which is presently handled by the secondary quozl pic.

the other major change is that the MC now "pushes" flow ticks to the host. this means that the internal flow counter only accumulates between status packet sends, which the host requests every second or so. when a status packet is sent, the MC clears the internal counter. this eliminates all the kludgey "greater-than-8-bit" arithmetic i was doing inside the PIC, since the counter should only rarely exceed 8 bits in length..

(of course, this also means we now rely on the host to reliably receive and accumulate these counts, but that should be a fair assumption...)

hardware changes
the edgeport usb drivers -- and actually, the usb serial generic driver -- in the linux 2.4 and 2.6 kernels cause numerous panics and OOPS's these days. this is extremely odd, since my edgeport/4 has worked great until 2.4.22+... greg KH (usb kernel master) was kind enough to take my bug report, but i just havent had time to thoroughly examine these panics. but they do occur, typically on close() calls.

this, and the fact that a usb-serial converter is another piece of hardware have led me to move (albeit slowly) to a USB-only MC interface. i've ordered some evaluation units of the ftdi ft232bm usb UART chip. the chip looks very nice, requires only a few external components (xtal, a few resistors), and is relatively inexpensive (~$5 in one-off quantities). considering that a max232 costs around $3, i think i can justify this somewhat premium pre-made solution. (evaluation boards with a USB connector, xtal, and the other misc hardware cost $25.)

this means that the dependency on serial ports in the kegbot will be reduced by 1, leaving the 1-wire and LCD display on rs-232. (and it is surely conceivable that one could use USB versions of either -- they do exist).

whew! well, sloppy typing aside, that's whats new. in summary: better controller means no more freezes!

two new things to report today.

first, i went to halted and picked up a small 120vac to 12v and 5v DC power supply. the kegbot needs 5v for the controller board, 12v for the flow valve, and 120vac for the fridge... i'm trying to consolidate the variety of ad-hoc wall transformers used now to one supply.

also, the kegbot froze today. actually, it was the software that froze up, but somewhat amusingly, the beer in the fridge soon did the same. time to finally enable those watchdogs!

now that school is out, and after several months of major revisions in between exams, i'm happy to say that the first 'real' keg will be online this saturday!!

those of you that may have had the opporunity to drink from 'ketbot v1' last winter will see a vastly improved beer-pouring machine! all the features we wanted are there, and all the shitty hardware that was stopping us has been replaced.

the only thing untested is the foam situation. but i can't see how it would be any worse than the last keg, and even that was pretty drinkable.

more soon!

today, i was finally able to test the freezer temperature control on its own. i'd known since i replaced the relay and the temperature sensor that it would work, but never tested the whole thing together.

below, you will see two graphs. the first is temperature observed from about the middle (in space) of the freezer, and the second is the activity of the freezer's compressor.

in this test, the maximum high temperature was set to 6.2°C and the maximum low temperature was set to 4.0°C. when the fridge temperature reaches the high temp, you can see the compressor is activated, until the low temp is reached.




another interesting result of this test is that we can see the duty cycle of the fridge looks to be no more than 15% active. (data i'm seeing in the logs is around 5 minutes on, 40 minutes off, so even 15% is a bit conservative.) interestingly, bumping the low temperature up 0.4°C increased the duty cycle to nearly 50%! obviously, the less active, the better.

this data was taken on a warm (80°F) afternoon in LA, so as the ambient temperature gets lower (at night and in the winter) this should be a bit more efficient.

one of the interesting tangents in the kegerator project has long been in payment methods: can we interface the kegerator with a credit card processor, a bill acceptor, or a coin slot?

the usefulness of at least the second two would be awesome; people could purchase beer a la carte, or fill up their kegerator accounts with money for future beer (or past debt!) now, granted, we aren't exactly running a bar here -- getting paid for every drop certainly isn't the goal -- but it would be really cool to have that sort of hardware available.

taking a renwed interest in this topic, i have done a lot of reading. the first stop is Bill Acceptor 101, where a very well written history and description of bill acceptors (from their names to their recognition methods) is laid out.

i've sort of been stuck looking at coinco bill machines, first because they seem to be very popular on ebay, and second, because their company website has a nice concise section of documentation.

so, i bought a bill validator. the coinco magpro. the problem is, this system uses a proprietary bus, called "Multi Drop Bus", or MDB for short. unfortunately, they ("NAMA") desire $40 to read a PDF of this spec. the bus itself is basically a master-slave setup, with 9600 baud serial communition (8N11).

i've managed to find a copy of their 1994 version of that spec, and while it is not the latest and greatest, i expect to be able to write a sufficient MDB-to-Linux interpreter for my MagPro.

next in this series: MDB explored.. stay tuned..