Matthew Kocsis' Lab Notebook

Week 01

January 10, 2006 (1 hour):
This was the first day of class. I can't wait to be a chronic digijock!

January 12, 2006 (1 hour):
I met with the team and discussed ideas for our project. We decided that the kegerator project would be pretty neat. We brainstormed features and wrote up the prelim proposal plan. Features include: Temperature control, access control, user control, pour statictics, LCD interfacing, Network programming. Our official project name is the Digital Real-time Intelligent Networked Kegerator. Should be pretty cool, I'm getting pumped.

Documentation on similar projects:
Link 1
Link 2

Accomplishments: Met with team, decided on the Kegerator project.
Weekly Work Total: 2 hours
Project Work Total: 2 hours

Week 02

January 16, 2006 (4 hours):
Today I started doing more research on flow control and valves. A friend recommended that we use a solenoid flow valve for ease of use (current closes it, lack of current opens it, or something very similar). So far I have only found a few Industry versions which are much larger and more robust than we need. I also found a reference page for different typed of flow control units here: Ian has already referenced the kegbot’s recommendation, so I plan to cross reference that and possibly use their recommendations.

Further investigation showed that most flow valves and flow meters are designed for extreme volume and pressure. To avoid line turbulence, it is recommended to keep all line diameters constant (or very similar) and to avoid opening and closing the line often without actually dispensing any liquid.

January 17, 2006 (3 hous):
Research today focused on small volume valves and flow meters. The VISION series flow meter was of particular interest (referenced by the previous keg project). The vision, produced by Remag AG, comes in two models, the 1000 and the 2000 ( The fitting is also 1/4", which is very close to the 3/16" line setup that we are using. I contacted their sales department, and I got a response from Sonja Rothenbühler. She said that with a little more information, they can direct us to one of the two products and send us a free sample. I returned the nevessary information and explained that we would need 3 for our prototype (2 plus one spare) and asked about minimum orders. I also found low pressure solenoid valves from a company in India. The G 1/180 1/4"x1/4" design seems to do what we need, especially because of the small (1/4") size of pipe diameter. I have no received a reply email to them. The current design of solenoid valves might hinder the flow of carbonated liquid too much for use, but testing will have to prove this. I still have not received any information from the kegbot team as to which part they used for their solenoid valve.

I also started to work on the team website using one of my previous templates.

January 18, 2006 (2 hours):
I threw together some preliminary information on the data structures needed for users and kegs. I'm starting to work on software information flow ideas also.

I learned that a friend (ChemE) knows much about fluid dynamics, so I will be contacting him about solenoid valves. Giplindia has not returned my inquiries.

January 19, 2006 (6 hours):
Sonja from Remag AG returned my email this morning. She recommended the 4F23 model of the VISION 2000 flow meter (data sheet here). There are two options for electrical hookup and threading. After some research (and going to Lowe's to have them tell me that they had no idea what I was talking about) I found out what the two hookups were for, one Tapered (NPT) and one straight (G, NPS, BSPP). The following website has information on the two thread types: There are also two wiring options (as seen on the above data sheet). I picked the angled mounting tabs because they get the wiring going at an angle back up the line (which would reduce the width of the entire unit) as opposed to the flat connectors.

Sonja gave me the option of a free sample and then a regular price on the two extra meters (52 CHF). She also gave me the option just to order all three at a promotional rate of 25 CHF (19.56 USD) a piece. I decided to go with the three at once. I will wait for her response about shipping so I can give her credit card information.

I also worked with Dustin on some SC wiring schematics for the compressor part of the freezer. It appears like the power into the unit is modular (has nice connectors) and the power interrupt for the existing temperature controller is also modular. That leaves to possibility for just disconnecting the current controller and adding the actuator circuit at that point.

I also thought about the idea of mounting the controller and LCD on the top of the draught tower. We could possibly even fir the solenoid and flow meters inside the tower thus protecting them and keeping the cutoff as close to the actual tap as possible.

I finished the webpage design and uploaded it to the server. The notebook pages are also up for each user. I sent everyone detailed instructions how to update them.

Accomplishments: This week we ironed out the specific features and ways to implement them. We also researched specific components and alternatives. I have made prograss on obtaining flow sensors and thinking through data structures and software management.
Weekly Work Total: 15 hours
Project Work Total: 17 hours

Week 03

January 22, 2006 (4 hours):
We met in EE today to work on the project proposal. I found a website from the National Highway Traffic Safety Administration outlining how to calculate a theoretical BAC score. NHTSA BAC Calculation Website.

After more research into solenoid valves (the gipl company hasn't yet gotten back to me) I found another company for food related valves: I send the company an email asking for more information tonight

January 23, 2006 (1 hour):
I completed a rough flow chart for software control today, including access, what to do whe pours start, checks, and such. I'm still looking for a suitable solenoid valve

January 24, 2006 (2 hours):
I got an email from Remag AG this morning and our three flow sensors have shipped via airmail. They want me to send a check for 100CHF or wire the money. We'll see how sketchy it appears to wire money to a swiss bank account.

I also started thinking about data management for the date structures we have. Since we will have a large amount of flash that can be written to a reasonable amount of times (~10,000), we can store much of the reasonably static data on it. The more dynamic parts can be stored on SRAM. I propose that we use an id system to refrence back and forth. The variables below are all in FLASH unless notes.

Data Structures

User Information (Hybrid)
access level
max BAL
max ABV
credit reset
credit reset time
max pour
credits (SRAM)
total pour volume (SRAM)
monthly pour volume (SRAM)
weekly pour volume (SRAM)
nightly pour volume (SRAM)
average pour volume (SRAM)
last pour (SRAM)

Keg Information (FLASH)
access level
credits per oz

Pours (FLASH)
pour volume

Each of the available keg hookups will have an variable to declare which keg (by kegid) is connected, or if no keg is connected. The system will have to keep a reasonably accurate clock so it will know the time of day and how to correctly calculate a user's BAL.

January 25, 2006 (4 hours):
We met in class today and decided to meet in MSEE189 at 6:30 on thursday. The team went to the lab today and worked with Chuck Barnett to get a dev board and a computer account. We checked out a Rabbit 3300 board and talked with Nick about design considerations for choosing a controller. We chose on the Rabbit 3315 because of its expanded flash memory (4M). This is because we will be doing a large amount of embedded web design and need room for all the database entries. We ordered the controller in lab.

Ian found a good rotary switch online today so I purchased it through Newark InOne. I also checked some resources and found some documentation on a good solenoid valve. It is made by McMaster-Carr, part number 7876k25 (24v 3/8" normally closed value with quick connects). We need to debate whether to use a normally closed or normally open valve on our project. Two considerations drive that choice: Do we want security or functionality if the system has problems or is off; What is the power consumption, ie: if we are goign to leave it open most of the time, who waste power to run the solenoid if we could just have it open by default. I am leaning for normally open because there are only a few cases where we will have to shut off the valve. Since we want to avoid opening and closing the valves without pouring, we have to change the design a bit. On a single keg unit, when a person logs on, the valve could be opened given that the user will be pouring from that tap. On ours however, if we leave them closed and then open them when a user logs on, one of the two lines will not be poured. My idea is to leave them all open by default and then only close them when we have to, leave them closed until a valid use logs on, a specific time expires, or the unit is put into a standby mode of sorts.

I also found a post from the previous kegbot team that has tricks of how to connect the tubing for the solenoid and flow valves (link). I think I will use this advice and play with the tubing once I get the parts in.

On other notes, our presentation today was pretty sweet, so I'm pretty sure our success criteria are a go. I want to have all of the needed parts ordered by friday so we can start putting things together.

I filled in a few more missing pages on our website this evening. There is an overview on the main page, I got the the "About Us" page ready, and I updated our PSSC section in the Project proposal on our site.

January 26, 2006 (3 hours):
In a group meeting tonight we went over the remaining parts, made a spec sheet for power supply characteristics and needs, and compared the last few part decisions. I ordered the normally open solenoid valves tonight, and the parts from Newark shipped. We should be ordering the contactor, temperature sensors, and the RFID reader tomorrow. Our hope is to have all the parts in hand next week so we can start a real PCB design.

Accomplishments: We finialized all the parts and placed orders for everything (except PS). We have a dev board ready for when the controller comes in. We also started on the next round of documentation. Next week is for testing all of the parts and starting software development.
Weekly Work Total: 14 hours
Project Work Total: 31 hours

Week 04

January 29, 2006 (2 hours):
Today we had a group meeting. We are looking for current devices that exist in the real world that do a similar function. There is a pub in Europe that has a similar product installed at every table. The place is called The Pub. On the site there are pictures that show the device un use.

The device at a table.

The front, and someone pouring

Each table has a single unit

Everybody Pouring

January 30, 2006 (2 hours):
The flow meters showed up today. USPS doesn't even try to deliver things anymore, so Ian and I will be picking up them at the Post Office tomorrow morning. We will be ordering the temperature sensors when we know more imformation on LCD or RFID units. Apparently TI couldn't cut us a good deal on the RFID kit we wanted.

Ian and I spoke to Nancy Clement today about entering the I2P competition, but we learned that only EPICS teams were allowed to enter because of grant stipulations. I really think we had a good shot at the $15,000. We still still be looking for patent information as the project moves along.

I also updated a few more things on the website. We now have pages in all nav locations, and we are mirroring all spec sheets of ordered products under Documentation - Spec Sheets.

Ian found this LCD today, but the controller doesn't seem to be nice and advanced like the one we were trying to get. I am searching for a different graphic LCD with a built in controller. No more suprises.

January 31, 2006 (2 hours):
I picked up the flow meters today. They happen to be clear, so we will be able to figure out if they are generating any foam. The tube size change could be bad because of the 2 fold increase (3/8" to 3/16"). I also discussed the data structure idea a little more with ian and a friend. I think we are going to implement individual 'enable' values to chose whether or not to enforce certain limits. TI wouldn't give us a doscount on the RFID kid we need, so i should be ordering it tonight along with the temperature probes when Ian gets back from EPICS work. I am still waiting on McMaster-Carr to ship the solenoids... they claimed the shipping time was 2 weeks. Those should attach right to the flow meters so we only have to change the tube diameter once. Once the RFID/Thermometers/Solenoids come in, we should have all of the components. The next step is hooking them up and starting to play with basic software interfaces to each device. At the same time we will be developing the PCB and layout. I hope to be at this point early/mid next week.

February 1, 2006 (0.5 hours):
I ordered the temperature controllers (4) and the RFID system from digikey today. Ian also found a new LCD, so I reviewed the specs with him and started discussing/brainstorming techniques for bitmap menu navigation.

February 2, 2006 (4 hours):
We met as a team at my apartment today to look at the freezer, look into menu design, and create a more detailed block diagram with power and some discrete components included. We decided on a menu format similar to the table below

Information specific to what menu level we are at
Menu 1
Selected 2
Menu 3
Menu 4

Ian made a rough sketch of the contents of the menus and where they lead. I think that should be in his notebook under today. I worked on data structs for users and kegs again. We are goign to use bool values to check if certain users or kegs are inforcing rules, credits, etc. I am currently booting up the dynamic C program, and I'm going to see what I can do. I might go to the lab tomorrow and hook up the dev board and see if I can get something to happen.

Ian and I went into lab and hooked up the dev board. The good news: the board works. The bad news: it has no idea what the 3315 is. we got a few programs to work on the 3300, however we are goign to have to find an update for the dynamic C software sometime very soon.

I started reading the dynamic C documentation tonight, and overall it seems remotely straightforward. It gets complicated when it attempts to simulate multitasking and memory management. Right now I am looking to find a way to access some I/O pins and write a few structures and functions. Actually getting the embedded webserver to work will be a whole different story. I started reading the intro to networks part of the documentation, so hopefully there will be some good example modules.

Accomplishments: This week we ordered the last of our main components and started working with the Rabbit software. I read up on dynamic C and started to develop ideas around their "Multithreading" techniques. I also continued work on the packaging constraint homework. As a team we focused on managing all of the peripherals and tieing them together.
Weekly Work Total: 10.5 hours
Project Work Total: 41.5 hours

Week 05

February 4, 2006 (2 hours):
Today we met in lab and reviewed Rabbit module information and interfacing. We realized that SCI interfacing will require an external RS232 chip so we are adding that to the overall block diagram. I also determined exactly what version of the software we need (Dynamic C v. 9.25). I also read up on web documentation, read through chip libraries, and looked at sample programs. I think the Rabbit only has 2 external interrupt lines so we might have to tie all the inputs together with an OR gate and then rely in the ISR to scan the inputs and determine which one caused an interrupt. We also discussed solenoid valve theory and methodology for closing/resetting the system.

February 5, 2006 (1 hour):
I worked on rabbit code today looking over sample programs and searching for open source examples online. I found one page with some good examples. I hope to use some of that information for developing the web module. Right now I have no experience with writing my own TCP/IP stack and interactive webserver (makign it display is one thing, but entering data on forms and then changing system variables is another).

February 7, 2006 (8 hours):
Today's task was to complete the Project Packaging Specification homework. I first begun by reviewing our three major alternative products:
Auper Harpagon
After completing all of my research, I generated a list of all the components that need to fit in the control module. They are:
-Bill Accepter
-Rabbit Module
-RFID Module
-LCD Controller

Because of the size of the Bill Accepter, I started with that, and with the help of Miriam Simon, we built the major components in, built extra room for the boards and controllers, and then built a housing. The images are found on our Multimedia Page. I am now finishing the analysis of why we have certain packaging constraints. I will need to make my slide for tomorrow after this.

February 9, 2006 (5 hours):
I completed the Packaging Constraints homework tonight and worked with Dustin on the initial PCB layout. Learning the PCB software took the longest, and I think we will have to make quite a few custom packages for our miniboards.

February 11, 2006 (4 hours):
I went into lab today to start getting things to work on the Rabbit 3300 (we are still waiting on a responce from Rabbit about the new software). The Bill accepter arrived and after looking at it and taking it apart, I think we're not going to be able to take off the bill stacker like we previously planned. That will greatly influence the overall package design, but I will know more later.

The first goal of mine for the Rabbit was to get the flowmeters hooked up and determine a way to interrupt the system. Sine the Rabbit only has 2 interrupts, I had to develop a way to assess which meter interrupted the system. Justin joined me and we tested the flowmeters by blowing through them. We decided that we would have each flowmeter hooked up to an input on the Rabbit, and then all the lines coming together to somehow trigger the interrupt. Checking the flowmeters, they don't simply pulse, they can just form an edge and then go high to low, etc. That means two things: a simple AND gate won't work; and we might actually be able to be twice as percise. We hooked the 3 inputs up to a quad dual-input XOR gate (i have the part number written down in lab) by stacking two XORs together. We coded software and it correctly counted the edges from any single flowmeter. We could not however read the ports that the meters were hooked up to individually. We changed from D to A (parallel bus) and we still couldn't get them to read (even after setting the ports to input). There might be an initialization routine, so we will be looking that up before next time.

Accomplishments: This week I finished the Packaging homework, we started on an initial PCB layout, and finished power analysis. I also started coding the rabbit and I got interrupts to work with the flow meters. SCI interrupts/messages and reading port pins is next. We need every external device hooked up and working by the end of next week so we can make the PCB correctly.
Weekly Work Total: 20 hours
Project Work Total: 61.5 hours

Week 06

February 12, 2006 (2.5 hours):
I went back in lab today and messed around with more code to try to get the input pins on the rabbit to work. After looking up every library I could find, I finally just used BitReadI() instead of BitReadE. Apparently for some reason the I for internal works and the E for external doesn't. I have no idea why this is the case, but using the new code, all of the flow meters work (at the same time) and the system correctly handles them. Under the very very improbabble case that two inputs change in the same 1/44,000,000 sec and the XOR gate does not blip, I think we can legitimately ignore the 0.5 mL of liquid dispensed.

I also started to work with the serial interface. Dynamic C's costate commands are still a little strange, but I think i have some basic I/O commands down. I played with a test program that connects two of the rabbit's serial interfaces to each other and send stuff back and forth. The next step is to hook the three wires up to a real device (such as the LCD) and try sending commands.

February 15, 2006 (3 hours):
The solenoid valves arrived today and I brought them into lab to test out. The first problem I encountered was that there was an extra attachment on the top of the valve which was not shown in any pictures. The second problem was that there was only a small amount of flow from the IN opening to the top opening, none straight through the valve. Upon further inspection and searching, I found their website and the specific valve model online (McMaster-Carr did not have this information). The manufacturer is Evolutionary Concepts Inc, and the product spec sheet is online here . This spec sheet continued to baffle us because the picture was still different, until I found This page. Apparently the normally open valves have a completely different design.

I went to Home Depot and Lowe's and picked up the hardware required to connect the flowmeter/valve unit to tubing. Neither store sold female quick disconnects, so the current plan is to use a female-female brass connector to join the flowmeter to the tube. The other major annoyance with the changed solenoid design is that the flowmeter now has to be inline before the solenoid because the solenoid's outtake line is 1/4" not 3/8". This new configuration has a 90 degree bend in it, so we might have some foam troubles. It also is very difficult to blow through the flowmeter/valve unit so I am becoming skeptical about the beverage actually making it through the unit. I plan to buy a keg tomorrow, hook it up, and pray.

February 17, 2006 (2.5 hours):
I finished the solenoid/flowmeter attachment today so I purchased new washers for the taps and I bought a keg of Miller Lite. I stopped by lab and worked with Dustin and Ian a bit with some RFID parts. Ian and I finally got the correct software installed on the lab computer and got the RFID module working correctly with TI's software. Ian then was able to run the software via terminal (without software) so we now have a stand alone RFID solution (still with dev board). I got an RMA number from Digikey, so we will be searching for which antenna to purchase and which RFID chips to use when we purchase the individual module early next week. We might try to make our own antenna (there is TI documentation on it) but we want to test it with the deb board before sendint it back. The plan for the next few days is to get serial working in the rabbit and to test the RFID module separately from its dev board.

February 18, 2006 (1 hour):
The initial solenoid/flowmeter test was a complete failure, the quick disconnects didn't seal at all. I decided to shift technique and test out barb adapters. I went to Home Depot and picked up 1/4" inner diameter hose barb connectors in both 3/8" and 1/4" male NPT threads (A-193 and A-192) unfortunately the only female 3/8" barb connector had a 1/2" barb size, so I will still have to use the 3/8" to 3/8" female-female converter on the intake side. I also picked up adjustable ring clamps to tighten over the barbs to secure the hose..

After more thought and considering the new bill validator size, I'm goign to pursue changing the complete package design. The new design will include the draft tower in the entire package. It will resemble a large T, with two taps on each side. In the middle will be the bill validator, the LCD, the RFID antenna and the fingerprint scanner. I can order the special draft parts from We will need 4 shanks, 2 more faucets, 4 more Beverage Tubes, and some various extra air tubing to expand the CO2 lines to 4 possible taps. I will work with Miriam on some CAD renders soon.

Accomplishments: This week we got more of the individual peripherals working including the RFID, the flowmeters, and the solenoids. I tested out a few different configurations for attaching the solenoid/flowmeter unit up to the beverage line.
Weekly Work Total: 9 hours
Project Work Total: 70.5 hours

Week 07

February 19, 2006 (1 hour):
I hooked up the new solenoid valve today and it completely messed up the beer flow. The liquid was clear entering the flowmeter, clear going through the flowmeter, and then completely white (foamy) exiting the flowmeter. I poured an entire 32 oz of foam, and only about 4 oz was clear liquid. After 15 minutes it ended up being around 12 oz of liquid (it was probably also flat). I talked to a few friends (ChemE, EE) about other possible valves. One option is hooking a ball valve up to a motor of some sort and trying to turn it open or closed. That technique will be more complicated and I am still looking for other alternatives. I might just try the normally closed version of the valves I have now (other people said that they have worked in the past.

February 20, 2006 (4 hours):
Today I worked with Ian on the schematic design dealing with my specific parts. I then begun working on serial interfaces (cabling and protocals). I disassembled a DB9 cable and checked checked all of the wires and mapped them to pins. I then referenced the pinouts of standard RS232 DB9 cables and noted them. I was not able to boot the rabbit because Ian was on our lab computer. I also contacted McMaster Carr and ordered the new normally open solenoid valves. They also told me that returns on our previous order were fine and that they will refund us fully. The new parts should be in tomorrow or Wednesday.

February 21, 2006 (9 hours):
The first study today was the RFID antenna. After reading all ofthe documentation, I hunted down enameled wire to attempt to make a wire antenna similar to the specs TI gave us. It was hard to find something good to wind it around, so i made 2 contraptions, one out of a styrofoam cup and one our of surface mount chip cases (the long plastic holders). I wrapped 15 wraps of wire and then secured the wraps. I still needed to somehow determine the L value for the antennas, so I set them aside to ask Barrett later.

The next mission of the day was to start coding and using serial on the rabbit. I researched the bill accepter's protocal (8 bits, even parity, all signals are 1 byte) and started coding the rabbit for communication. For the first hour the rabbit would not send or recieve any data, so finally I guessed that maybe the DB9 pins were reversed. After switching them, it started functioning. Apparently the reference I was using (the male side) was not the one referenced (usually the female side of the DB9 cable is at the local end, the other is at the peripheral). After some trial and error, I sucessfully developed code to control the bill accepter, distingish bills, and accept or reject them.

The final stage of work tonight was getting the RFID reader to work over serial. Because it doesn't use single bytes, I had to set up strings and multiple sucessive reads. After some coding and trial/error, I was able to sucessfully instruct the RFID module to sharge the antenna for a read. The responces I got back were not what I expected, but then I realized that I was using a R/W RFID tag. When I switched to a read only tag it correctly read the 8 byte ID. Occasionally I am getting different status values (0x07 instead of the typical 0x0C (Read tag) or 0x0D (R/W tag)). I will have to read more documentation on what the specific status bits mean, and build more error checking into the software.

During the entire evening I also worked with Ian and Dustin on minor schematic and layout problems/questions. I also called Rabbit today and they refused to offer us anything better than 15% off of all software products. I will be contacting prof. Meyer about possibly getting the course to pick it up.

February 22, 2006 (0.5 hours):
We got the new normally closed solenoids today. We didn't have all of the hardware to connect tubing on both sides of it, but we were able to put beer through it and the beer came out clear after a second or so. I will go get the correct hardware tomorrow and if they work, I will send back the normally open ones and purchase two more Normally closed models.

I took a few pictures of the rabbit serial setup I have just for reference. I also documented the antenna design with pictures.

February 23, 2006 (3 hours):
I got the fittings today and the solenoids work well. The flow is a little light, so i will play around with the CO2 pressure to see if that makes a difference.

I started a new main function that is slowly going to bring all of the individual programs i've written together. Unfortunately the dev board only has 2 RS232 ports, so I will need to hook up an esternal level converter so i can use the LCD, RFID, and the Bill Validator at the same time. I want to start prototyping the hooked up components soon using as little of the dev board as possible.

Accomplishments: This week we got the solenoid/flow meter setup to work correctly installed, and I got serial communications to work on the rabbit. I am now able to control the RFID and the Bill Validator with the 3300 alone.
Weekly Work Total: 17.5 hours
Project Work Total: 88 hours

Week 08

February 27, 2006 (3 hours):
Tonight we met to put together a preliminary presentation for our design review this week. After that, I met with miriam and sketched the new CAD which can be found on our multimedia page. We will put all of the components together in the final presentation tomorrow.

February 28, 2006 (2 hours):
Today I continued work on my design presentation. I am working on the Packaging, Component Selection, Software Theory/Status, and Timeline.

March 2, 2006 (1 hour):
Today Ian Justin and I met in lab to work on the temperature probes. We found that it will probably be easier to use 2 pins on the rabbit, one input and one tristate output. This would prevent us from having to change the port pin during operation. We also discovered that the temperature probe requires very short and specific timing intervals. Since the rabbit does not do well with small precise times we came up with an alternative soltuion. Every 2 minutes we will check to see if a user is currently logged in pouring a beverage. If there is somebody logged in, we will wait. If nobody is logged in, we will disable interupts and drop into assembly where we will have a specific amunt of NOP insturctions. We will then insert C commands periodically to load and store line values. This hopefully will let us do reasonably precise timing without problems. We should have enough leway for some inprecision in the micro. If this does not work, we will try a different unit and adjust the PCB before next Friday. The total time for a temperature read will be under 10ms, so web responces and RFID polling can wait.

March 6, 2006 (9 hours):
Today Ian and I continued to test individual components. Our first goal was to get RS232 devices to work with our external chips. Ian soldered one of the chips onto a DIP package and we started testing it. After soldering we had to clean the chip up so that pins were not bridged.

We hooked up the circuit with all 0.1uF ceramic capacitors, and the system did not work. We hooked it up to an oscilliscope and monitored the inputs and output of the 232 chip. Since we needed a minimum of +/- 5V swing on the output level, we changed to electrolitic capacitors (same value) but the output still did not work even though it was right around 10Vptp. We then changed the chip over to 5V supply instead of 3.3V supply and changed the capacitors to c1: 0.1uF, c2-c4 0.33uF and the bypass to 0.1uF. This now sent the correct output, but the system did not work. I hooked the validator up to the onboard serial port E which again didn't work. I reversed the pins on the validator side and got it to work with the dev board. The ground pin was connected to pin 5, the Rabbit's RX was connected to pin 2, and the Rabbit's TX was connected to pin 3.

A wire got stuck in the DB9 connector on the validator's cable, so I took it apart and found that the RS232 chip from the validator is actually on the end of the cable. That means that it might be possible to take advantage of the 5V signal coming out of the validator without having to use serial.

With our new pinout knowledge, we hooked up the C serial port (TX:PC2, RX:PC3) to the RS232 chip and then hooked the chip up to the validator. When we turned power on, the validator initialized and the code ran just as if we were using the dev board's E port. It ran at 9600 baud with even parity.

Since the RS232 chip had 2 pairs of translators, we wired up the back of the LCD up to the chip and then hooked up serial port D (TX:PC0 RX:PC1). We were then able to sent it single byte commands such as place bitmap (already stored in flash) and clear screen. It ran at 115200 baud with no parity. I combined the code for the validator and the LCD together and they did not work. After working backwards for a while, we reconnected some loose pins and got them to both work. When the $10 bill is entered, it is rejected and the LCD displays a stop sign. This shows that we can successfully run 2 serial channels with external level trancievers with different properties. We filmed a short video of this operation.

Ian and I connected the optioisolators we found in lab according to the available schematic and found that they do not work. Once power is supplied to the input side, the output stays active unless it is interrupted. We believe that since the device is built out of a traic, it needs switching AC power in order to reset the output side. We will continue to look for more devices.

Another device we tested was the autio transducer. We ran it at 3.3V with a square wave. It worked audibly from 10Hz to 18kHz. We will test this on the rabbit using a PWM next week.

We still need to test the solenoid inrush current, but I will require a very small resistor. Brian recommends a length of nichrome wire that I can caucluate resistance due to length. I will be asking team 5 how they did their calculations so that we can make sure the PCB traces are sized correctly.

Accomplishments: This week we worked on our design review presentation, and I tested individual components. We have all major components working on the rabbit with developed code. THe RS232 tranciever chips work well, and we found that we will need to order new opto-isolators and 3.3-5V level translators.
Weekly Work Total: 15 hours
Project Work Total: 103 hours

Week 09

March 6, 2006 (1 hour):
Dustin and I worked on testing transistors today. We did not get any to work with the solenoids, so we will be getting a '362' version.

March 7, 2006 (4 hours):
Today I focused on getting a temperature measurement device to work. I was worried about the complexity of the digital thermometer, so I started researching alternatives. I found a LM35 analog temperature probe, and I was easially able to hook it up and get it to work. I then found out that the Rabbit does not have any A/D ports, so the alternatives included an external A/D chip or the digital thermometer. I searched quickly for an A/D chip in the building, but the only one I could find was a 24bit high precision version. After talking to Dustin, We decided that it wouldn't be worth the trouble to add a new component and route it.

I studied the entire datasheet for the DS18S20 digital thermometer. I also checked into some rabbit features (timer channels) but i found that the timers are used to control serial baud rates, so at the moment my plan is to use code segments for rough timing. My only other worry is the speed at which i can change a port from an input to an output. This could possibly be avoided by using 2 pins, but the output would need to be set as an input as soon as possible so it won't tie the bus high or low.

March 8, 2006 (8 hours):
To test the theory for the 1-wire thermometer, I needed to create reasonably accurate timing delays. My initial thought for this was to create a function that would set a line high, delay by some means, and then set the line low and return, where the function would then immediately be called again. Doing this I would be able to hook up an oscilliscope and it would hopefully pick up a periodic signal.

My first attempt was to create the initialization sequence. I created a function inittemp() that would handle this. I chose to by default set the port as an input so it would remain high-Z. in the function inittemp, I set the port as output, set it to 0, then ran a for loop to waste time. After the loop ended, i toggled the input to 1 and ran another loop. I hooked this up to the oscilliscope, and I got a very nice signal. With some guess and check, I was able to adjust the for loop timing so that I got acceptable delays.

With delays created, I set up a series of writes and reads from the bus that fall within spec for the probe. I pull the line low for 490us, I then release it for 66us, I check the value on the bus, then I wait for 436us. If my read returns a 0, then a probe is responding. If it remains high, then there is no operational sensor attached. below is an example of the code i used for this:

BitWrPortI(PDDDR, &PDDDRShadow, 1, 2); //set port D2 to output
BitWrPortI(PDDR, &PDDRShadow, 0, 2); //write a 0 to the output port
for (i = 0; i < 150; i++) //wait for ~490us
BitWrPortI(PDDDR, &PDDDRShadow, 0, 2); //set port D2 to input
for (i = 0; i < 20; i++) //wait ~66us
result = BitRdPortI(PDDR, 2); //check to see if something has pulled it low
for (i = 0; i < 130; i++) //wait ~436us
return result;

I hooked up a probe on the bus (pulled up by a 4.7k resistor) and ran the init routine. The sensor pulled the bus low. Victory (part 1).

I used the same technique to then build both bit read and bit write functions for the bus. If i'm writing, I pull the bus low for 3.6us and then either leave it loe for 50us, or I let it go high for 50us. If i'm reading, I pull it low for 3.6us, wait for 10us, and then read the value on the line. After writing these, I wrote byte functions that shifted and masked bytes of data and called my initial bit functions. I tested these, and after fixing some code, I successfully interfaced with a sensor and pulled its ROM address down. I did this to another probe, hooked up both of them, and was easially able to address individual probes. I built a looping function that asked for temperature conversion, waited for conversion to complete, and then queried each probe. I was able to quickly and visibly see change by simply putting my finger on a probe. I will still need to adjust the code for negative temperatures.

At this point, Ian joined me and we hooked up the contactor. I added additional code to turn on the contactor if the temperature got above a level (we chose 23C). Ian blew up an isolator, but after fixing the circuit, the code ran on the rabbit and correctly closed and opened the contactor when the temperature on probe 1 went above or below 23C.

At this point, we have run EVERY external interface device on the rabbit with our own code.

March 9, 2006 (14 hours):
This morning I printed out scale copies of the top and bottom PCB and spent a few hours checking traces for right angles and thickness. I then spent some time with Dustin and learned how crappy the layout program really is.

Tonight we checked the entire schematic and re-worked a few PCB areas to make sure it was correct. The RS232 ports were a bit messed up, so the RFID and Bill Validator need to be swapped on the schematic (we didn't want to mess up the PCB... It still works, they are just reversed). We had to move the Biometric serial connections to different ports, and we need to put the XOR chip upside down. When Ian rotated it, it inverted all pins. The pins are in the correct places, just named wrong. We submitted the Gerber test a few times, and at 7:30 submitted the final correct PBC. Dustin also made some impovements on the power supply by placing parts closer following a set guidline in the datasheet.

I'm glad this part is over, and I'm pretty confident it will correct - at most a few small errors.

Accomplishments: We have all peripherals working in hardware (individually) and we finished the final layout.
Weekly Work Total: 27 hours
Project Work Total: 130 hours

Week 10

March 22, 2006 (1 hour):
I checked the PCB today for any design problems. I assisted Ian and Dustin in testing the traces for continuity and current rating. We were able to hook up all 3 solenoids in lab and there was no issue.

Accomplishments: Recieved the PCB, no major accomplishments
Weekly Work Total: 1 hour
Project Work Total: 131 hours

Week 11

March 28, 2006 (2 hours):
I did some preliminary research on Patent and Liability analysis. I found a few very similar patents, but many are very specific and obviously do not perform the same function as our design.

March 29, 2006 (7 hours):
Ian and I continued work on the PCB. We got the Rabbit hooked up and working on the PCB and I was able to program it. We then hooked up the buzzer and that also worked correctly. We moved onto the solenoid, and found out that the 4N33 was hooked up wrong. Pin 3 was connected to ground instead of pin 2. After a bit of confusion about the transistor, we realized that it needed to be loaded to output correctly. The solenoid seems to work because the PS overloads when the solenoid kicks off. We tried to find a larger current PS but were unsuccessful.

I completed much of homework 9 tonight. I'm using two patents and one commercial product for comparison. I'm having a bit of trouble meeting the length requirement.

March 30, 2006 (1 hour):
I finished the patent homework this morning and turned it in. I had to submit early because this morning I leave for San Jose for an EPICS presentation and I will not return until Monday early morning.

Accomplishments: Modified software to test new PCB components, completed homework 9
Weekly Work Total: 10 hours
Project Work Total: 141 hours

Week 12

April 4, 2006 (4 hours):
I worked in the lab on the PCB to try to get some simple software components working with the hardware components. The flowmeters are not working so far, it seems like the input isn't making it to the pins. Also, PB0 is a little strange, it doesn't seen to want to function at all. I think it might have some special alternative function that I will need to explicitely disable. We're using that for the "keg attached" function. I will be able to test more software as Ian and Dustin populate more of the board.

April 5, 2006 (1 hour):
I begin a detailed design of how the packaging structure will be folded and assembled. It seems that we will have to fold it out of sheet metal and that we will need several pieces. While in Denver last weekend, I saw a draft tower that utilized a diagional hinge that provided access to the entire back side of the faucets. I am encorporating this into our design. I will be talking to Miriam Simon soon about techniques and practices.

April 6, 2006 (3 hours):
I met with Miriam and designed the complete construction plan for the enclosure. We will have 3 major components and one smaller removable one. The front will be one unit, the top of the "T" (where the faucets connect) will be another piece, and then the hinged back piece will be the last major component. The top front where the LCD/Biometrics/RPG are mounted will be removable so we can get access to the wiring and circuitry behind them without taking apart the entire unit. We will probably be using Aluminum sheet metal to prevent rusting.

April 8, 2006 (1 hour):
I adjusted some software today to test new hardware components that have recently been added. The Temperature code is not working entirely, but I am able to togle port pins correctly. There is a much different characteristic with the falling edge of the signal once a port pin becomes an input, so I will probably need to go back and re-calibrate all of my functions and re-test the entire routine on the PCB.

April 9, 2006 (4 hours):
I purchased poster board and cut out a mockup of the enclosure using exact size pieces. I made a few adjustments with angles, but overall the design was sound. I attached the mounts and the faucets and found that there should be enough space to mount the flowmeters and solenoids inside the top section. I also need to look again for plastic fittings because I would like to avoid using brass.


The front of the mockup.

Closeup of 2 of the faucets

Back of the unit

Inside view, after back cover is opened

Accomplishments: Continued to adjust software for PCB components. Finalized design of enclosure and created a mock-up.
Weekly Work Total: 13 hours
Project Work Total: 154 hours

Week 13

April 10, 2006 (1 hour):
I worked on some RS232 software today, however we are still having trouble recieving data from the bill validator. I'm also not sure if the controller is sending bytes at the right time. I think I am going to load up the dev board and test how it functions there.

Miriam and I went to the central machine shop, but they ended up being closed. Their hours are 10:30-4:00. We need a 6'x3' piece of Aluminum. We're not yet sure about the thickness, but we think it will be between 1/16" and 1/32". We need to balance between strangth and ability to bend, so I will be picking the thinnest piece that still is reasonably stiff. I will go tomorrow and try to pick up a piece. I hope to have much of the enclosure cut and bent by the end of the week.

April 11, 2006 (1 hour):
I checked out alunimum sheet metal today and decided that 032 was much too thin. I chose 050 (T4 alloy) so it would be strong but bendable. I placed an order for 3' x 6'.

April 12, 2006 (1 hour):
I picked up the sheet metal today and found that they charged me a little extra and gave me the scraps. I have still not been able to contact Chuck Harrington, so worst case we can use the ME machine shop. I also worked with Miriam to make sure the updated CAD drawings for the components were correct. I don't think that the computers in the lab have AutoCad, so we might have to try to print a scaled picture.

April 13, 2006 (5.5 hours):
I brought the metal in lab and found out there is actually AutoCad on the lab computers. Miriam and Brian helped print out the CAD files (for some reason, 1:1 does not do anythign meaningful, so we had to print and check and adjust the ratio). Miriam and I traced out all of the components. I also stopped by the EE machine shop. Chuck is out of town, however one of the managers said that we could come down tomorrow from 9:30-11. I hope to do the major cutting in the EE shop, and then possibly use the ME shop if needed to finish the pieces.

April 14, 2006 (2 hours):
This morning Miriam and I went to the EE machine shop and help them cut out our metal pieces. The band saw was a little shaky, so we will have a few edges that will need some work because they are exposed to the user. We also folded the paper cutouts and noted which parts needed to be folded first. The folding machine in the EE shop is much larger than the one in the ME shop, so we will be using it for most of the folds. We will need to go to the ME shop to use hand Brakes and the rivet gun however. Unfortunately, Chuck gave me a green sheet, so I will need to get a signature for some sort of billing.

April 15, 2006 (4 hours):
Today we drilled holes in the metal where there will be three folds coming together at a point. To do this we had to fix the drill press in the design lab. We also picked up rivets, the hinge, and bolts to attach the lcd section, the back, and the hinge to the main piece. Ian also commented that we should look into adding a window to the PCB side of the enclosure. We will look into this, but time constraints might not allow it this time.

April 16, 2006 (4 hours):
I came in to troubleshoot the temperature probe and while tracing the circuit I realized that the 4.7k resistor was placed in the wrong location. The resistor needs to pull the temp bus high, not pull the +5 line high. We will need to short the 4.7k resistor and add one from +5 to the TEMP_BUS and I believe operation will return to expected. All of the problems we were having can be explained: the long decay slope is because the bus isn't being pulled any direction, and the reason the probe isn't doing a temperature convert is because it doesn't have enough power. Ian and I will fix this and re-test it tomorrow.

I also searched McMaster-Carr for plastic fittings for the solenoid/flowmeter units. I found the male pipe-nipple units, but female ones are very rare (needed for the flow meter side). I found a female piece in brass which is an improvement over our current setup, however i still have hope that there is a plastic version that we can use. People have commented that brass can change the taste of the beverages.

Later in the evening, Miriam and I came in and traced the locations that we needed to mill the metal. We added places for the LCD, RPG, Biometrics, and the bill validator. We also designed a piece so that we can mount the PCB on the side of the bill validator.

Accomplishments: Started enclosure construction, worked on overall software design
Weekly Work Total: 18.5 hours
Project Work Total: 172.5 hours

Week 14

April 17, 2006 (4 hours):
Today I continued work on software and I cut the extra pieces that we designed yesterday. Ian and I fixed the temperature probes, so the compressor/ tempterature unit works correctly. I had trouble getting the RPG code to work however. When i read the count register, it apparently does not read or print correctly. I'm not sure what happens - i'd assume that even if it wasnt' set properly it would still print whatever the bits were set to. I'm looking into more control bits, and there is a possibility that changing the timer A10 channel might effect it.

April 18, 2006 (13 hours):
5 hours - metal work We started the main construction of the metal today. Miriam and I went to the ME machine shop to try to mill out the holes for the front panel. After remembering how to use a mill machine, we had problems with the metal staying clamped in, so a few of the cuts had small problems. We then found out that the LCD screen hole was a bit bigger than we measured. We also tried several folding techniques and in the process destroyed the piece we made earlier. We did find a good process to fold over edges however (involving several iterations of using the bender).

After construction, I continued work on the main code structure and flow. The majority of it is still a polling loop. We have three loops; one around 10ms to check RPG entries, one around 500ms to check serial devices, and one at one minute to update calculations and check temperature. Each polling loop will check values and if an event happens call an external function. I also coded the pouring system. When a flowmeter detects a pulse and the interrupt handler figures out with meter it was, the system counts the pulse and checks if there is a valid user and if the user has the correct permissions. There is another part of the polling loop that then checks the amount of pulses, and compares that amount to the amount 30 seconds ago. If there is a pour occuring and there have been no pulses for 1 second (this might change later) the system counts it as a pour and saves the data entries.

Dustin re-wired the RPG and the code I wrote yesterday works correctly. We also worked a bit with freezer wiring now that we have the unit in lab. I met with Justin and we discussed the layout of the web page, and he sid he would take care of coding it. We still need to get that working on the 3315, so I told him to move to that module.

This is the way we are setting permissions. There are a few user levels: Admin, VIP, User, Guest, Anonymous. Each permission entry is one byte.

--Insert table here--

April 19, 2006 (10 hours):
I finished construction of the enclosure today. Eric helped us mill out the holes, we bent the metal in the EE shop and the ID shop, and then we constructed the enclosure with rivets in lab. Bending small pieces of metal by hand is very difficult. The completed unit has a few cosmetic issues, but we have plans to use trim and extra metal to cover/fill them.

April 20, 2006 (10 hours):
I connected two solenoid/flowmeter units today. I decided to use the all plastic fittings, so they are a little bigger than before. To twist them correctly, I had to remove the spades from the flowmeters. Unfortunately, they were on so tight that halfd of the wires came undone. Dustin will have to re-attach these now that I have connected the units. The one flowmeter unit that I was using for testing back at my apartment seemed a little dirty, so i attempted to clean it with water. The blades were locked up, but I was able to break them free with a zip tie end. We will probably want a calibration tool for each tap in case the flow meters are not consistent.

I also attempted to fit two of the units inside the enclosure. They are very tight, so I will have to take care to position them. I might have to put one or two down under near the bill validator if all four won't fit at the top. Since we can't find the 4th flowmeter (lost in lab somewhere) I was thinking that we might want to have one tap that is not monitored and controlled by the system. As much as this "defeats" the purpose, the point would be so if needed a keg could just be used with the system. Typically we'd never plug a keg into this faucet, but if needed one could be attached if there was a software, hardware, or solenoid failure. I will need to speak to the rest of the team about this. The neat way to do this would have been to only use a flowmeter and not a solenoid (so it records, but can't control) however since we lack the flowmeter we might not be able to do that.

I read through the biometric module and there is a lot of functionality that we will not have time to use. Right now we need to focus on getting communication to work, developing a technique to enroll users, and then a method to identiy users. Ian wants to add functionality to return the scanned print and display it on the LCD, but we need to get the basics covered first. I also wrote more code for the main function and simplified the flowmeter interrupt code. The new technique will be to assess access rights when the user logs on, and then only check the BAL calculations every few clicks (ie 10, 20, maybe something else). This will lower the time spent in the interupts, which is important. Justin and I are about to combine the web code into the main code and with any luck, we might be able to test a "pour" tonight.

We successfully made a pour tonight, the system reads flowmeter 0 correctly and judges a pour after a specific time of no flow occurs

April 21, 2006 (3 hours):
Tonight I studied the extended paperwork on the biometric reader. We will be using it to "Enroll" Fingerprints and then "Identify" them. This is contrary to the validate method where a userid needs to be provided ahead of time. There are a large number of functions, however it only seems like we'll need a dozen or so to set it up and use it.

April 22, 2006 (8 hours):
We picked up the rootbeer keg today. It turns out that it takes a 2-prond adapter, so after taking it apart I went to Home Depot and picked up a few fittings to hook it up to our current system. I don't have the correct gasket, so I'm a bit worried rootbeer is going back up the air hose. When we are done with this keg I will take everything apart and make sure it's clean. The fittings also are not perfect (it has a wierd thread) so there is a slight leak. We need to hook it up when in use, and make sure to unhook it up when not in use.

We worked on the login software a bit and have the system to a point where an RFID tag is read and solenoid 1 opens. After a pour is finished (based on the previously mentioned timeout scheme) it closes the solenoid. We hooked this up to the keg and it works well with the rootbeer.

April 23, 2006 (4 hours):
Justin and Ian and I worked more on the software and integrated the LCD code a bit into the main code. We adapted all the code to work from the global variables presented. We made quite a few adjustments on the webserver code and the main flow code. Because of odd behavior we think we're going to give up the costate concept and run through one main execution loop running subfunctions on certain intervals.

Accomplishments: Combined Software, got pours to work
Weekly Work Total: 52 hours
Project Work Total: 224.5 hours

Week 15

April 24, 2006 (15 hours):
Ian and I went to the powdercoating place this afternoon and chose a black finish for the enclosure. We previously agreed on $75 with a turnaround by Thursday.

After returning I changed the entire code structure to the single main loop and I integrated new LCD code from Ian. Justin and I built in user management and statistics running durring pours. We have having serious issues with code and variable space, so i'm sure there is some trick that will let us use more than the 64k that appears to be available.

After an 8AM night, we have a finished PSSC video that shows all of our criteria met. We are still having a few issues. First, the system occasionally locks up. We believe this is in some loop because interrupts still work correctly. Second, After a user logs out, the next login seems to go back to the main screen and not the user screen. This will have to wait till tomorrow to be solved.

April 26, 2006 (10 hours):
I re-wrote the entire main loop today so that each subfunction had its own systemcount setting so that we can independently change the frequency of the events. I also used tabs to distinguish loops correctly so that debugging would be easier.

I first solved the login bug. Apparently Ian's LCD code was logging in and then immediately logging out because the button press was still an event (ie it just changed) and the previous user was last on "Logout". I changed the code so that if a user was just logging in it would bypass that conditional. After that, multiple logins are functioning.

I spent a lot of time getting timing and RFID to work, and during this i discovered that the RFID code I designed had wait loops waiting for serial data. These present a problem because if somehow the system enters one of those loops and there is no more incoming data, it is stuck because we can't request any data while in the loop. To work around this, I made state variables for the RFID read. If data is not available, the code moves on and when it returns to the RFID code it goes back to where it was and tries again. This works well.

After getting a working reliable system, I attempted to run the system in flash. I immediately got a variable space memory error, so I tried a fix that I read about in the Rabbit memory management documentation. The system can separete Instruction and Data space, which somehow by flipping bits (handwaiving in my opinion) creates 52k of "extra" memory. This technique worked, and I was able to flash the board and run it without a program cable. I'm leaving it overnight (well, over-morning) and I will check to see if there were any problems when I come back in after class.

April 27, 2006 (5 hours):
The system still works correctly after leaving it overnight. My fixes seem to fix the lockup problem we were having earlier.

I cut the metal and mounted the PCB on the side of the bill validator today. I used some plastic inbetween the aluminum to make sure that no flywires had a chance of shorting against the metal. Poe helped me bring in the sheet of MSB I had in my apartment, so I had Chuck Harrington help me cut out the correct size for the top of the freezer. Miriam and I drilled and cut the wood to line up with the enclosure and then re-drilled and re-cut the freezer top for the new piping. We mounted the board on top of the freezer and I went to purchase extra lag bolts for attaching the enclosure and paint. I found some black latex spray paint and I painted the entire top section. It dried very well and is relatively water resistent.

April 28, 2006 (5 hours):
Today we finished up all of the material for the EE270 bonus presentation. I created an intro video for the project, however we apparently ran out of space on shay as I was uploading it (and it didn't error out) so it was completely cut off. We got ice cream, cups, and spoons and served everyone rootbeer floats to demo the project. People were interested and we showed many of the ones who stayed behind how the system worked

April 29, 2006 (4 hours):
This morning I reworked my two homework papers to be more concise so that they could be added to the final report. I went in to lab and also changed the code to allow the system to run more than one keg. I ended up using for loops instead of my previous plan (which had them simply unrolled) in order to save instruction space. I have the software currently set to use separete Instruction and Sata space, but it still complains when I try to compile to RAM (I have to compile to flash, run in RAM).

April 30, 2006 (10 hours):
I added code for permissions and BAC tosay, however modifications to the webserver code needed to be done so I hadto wait for Justin to come in to test them. While he was fixing his code, I wrote up the Senior Design eval paper and created parts of the user manual. I'm still having a slight issue with permissions, so i'm just going to create an array of permission variables rather than messing with bit shifting (which doesn't appear to be working). I started the poster tonight, but due to the requirements I'm having a tough time being creative. I'll keep working on it tomrorow.

Accomplishments: Fixed all software, Finished installing all hardware, we have a complete working system.
Weekly Work Total: 49 hours
Project Work Total: 273.5 hours

Week 16

May 1, 2006 (3 hours):
I checked the documentation thos morning for errors. There is no way I'm going to be able to check the whole thing, but I'm reviewing new parts. I also worked on the poster design.