The new official deployment of SlatePermutate is now live on slatepermutate.org! Course data is available for the following institutions, with more to come soon:

• Calvin College
• Cedarville University
• Community College of Baltimore County
• Hope College
• Michigan State University
• University of Maryland
• University of Michigan

Want your school supported by SlatePermutate? Let us know!

Protofusion is a group of college students who develop open-source hardware and software. Check out updates from our various projects below, or check out our projects page.

I recently purchased a used Gaggia Classic machine on Amazon. After realizing that it was not as “lightly used” as the seller denoted, I took apart the entire machine to clean it up. I’ve written this guide as a teardown guide, but feel free to read it from bottom-up to get a clear understanding of how to assemble this machine. Feel free to drop a comment if you have any questions or information to add.

Tools

Before you start out, I would recommend purchasing a few tools (most available at your local hardware store):

• Brass brush
• Metric allen wrench set
• Citric acid or espresso machine cleaner
• Phillips screwdrivers
• Pliers or a crescent wrench

Note: You can buy citric acid at many bulk food stores for a reasonable price

Remove the Boiler

Begin by removing the two attachment screws on the top of the machine by the water spout. The top plastic water spout / sheet metal assembly should pull off towards the back of the machine.

Next, pull the steam wand knob off (it might take a bit of effort). Note that the valve in the photo above is a bit offset, this is due to my machine being damaged. Yours should (hopefully) be centered in the hole. You’ll also want to pull the push-on connectors off of the power connector on the rear of the machine, and pull all the cables off of the front switch. I recommend numbering each of these connectors before pulling them off so you can easily reconnect them.

Flip the machine over and use allen wrenches to remove the four bolts attaching the group to the chassis.

After removing these screws, your boiler should be free. Remove the boiler from the chassis and place it in a clean work area. Note that things might get messy and/or moist very soon.

Using a standard or crescent wrench, remove the chromed steam wand from the copper steam pipe. This will allow you to set the group down on a flat surface without damaging the copper pipe.

Next, detach the electronics and pump from the machine. You will need to detach the pump hose from the OPV and unplug all push-on connectors. If you leave your wire assembly as-is after you unplug all connectors (don’t bend or crush the wires!) you should be able to easily see where all of the wires connected to for reassembly.

To make life easier, remove all hoses from the machine. You should only need to remove the 3-way solenoid hose and the OPV hose at this point.

Now flip the boiler on its side. You’ll see a phillips screw head in the middle of the shower screen.

Remove the phillips screw from the shower screen, and then pull off the shower screen itself. If it is stuck due to calcification or coagulated coffee compounds, use a small flathead screwdriver to pry it off.

Now grab an allen wrench and take off the metal block that resides under the shower head. You should now be able to see the top of the group.

Using a plastic spudge, flathead screwdriver, or even your fingernails, carefully pry up the rubber gasket from inside the group.

Now flip your boiler assembly back up on end.

Using a wrench, remove the steel nut from the top of the solenoid valve. The black solenoid coil should slide off freely. Next, unscrew both of the thermal switches from the top and the side of the boiler. The high temperature switch goes on top, and the low temperature (brew) thermal switch goes on the right side of the boiler.

Now remove the solenoid valve assembly from the boiler using an allen wrench. You might want to take out the rubber o-rings for cleaning if they are badly calcified.

At this point you can unscrew the hose fitting on the top of the OPV. This is most easily done when the assembly is still attached to the boiler.

Now unscrew the entire OPV assembly from the boiler. Once again, you might want to remove the rubber o-rings for cleaning if they are looking shabby.

Now is the time to remove the steam valve. This step can be a bit tricky, especially if your machine is older. I recommend removing the two bolts and twisting the valve back and forth. After some twisting, use a flathead screwdriver to carefully pry each side of the valve until it comes free. Don’t be too aggressive, as brass is a soft metal. You’ll probably want to remove the rubber gasket as well, mine was very calcified.

Next, remove the four bolts attaching your boiler to your group, and your machine should be fully disassembled! You’ll want to remove the rubber gasket from its slot in the group, if you have an older machine this gasket and its slot will definitely need some cleaning.

Cleaning

Your boiler probably looks something like the photo above and/or it might look white with calcification. Pretty nasty. If you have a lot of white calcification, a brass brush (available at most hardware stores) will take care of it. If you have a lot of oxidation and black residue like I had, a dremel tool with a stainless steel brush attachment will get the job done.

Above is my boiler after significant dremeling and brass-brushing. It’s not great, but it’s good enough for me. Although the aluminum around the seal is very pitted, I haven’t experienced any leaks whatsoever.

To clean the rest of your components, I recommend soaking them in a solution of citric acid or special-purpose espresso machine cleaning solution (available at many online retailers). This will remove significant amounts of calcification.

If your machine is as old as mine, you might need to do some more intensive cleaning. Try using a brass brush with your citric acid or espresso machine cleaner solution. Use the brush to clean off brass fittings (especially the steam valve fitting), the group, and any other metal components. This should take off any lingering calcification or other gunk.

Now that you’ve cleaned everything up, it’s time to put things back together! If you need additional help, just read this guide backwards to get a good idea of how to re-assemble machine.

Has this guide helped you out? Spare a few pennies and feed a poor college student!

Background

If you have a working BOPM installation, you are trying to prevent abuses of your IRC network effected through anonymity services such as proxies. BOPM has built-in support for scanning for open proxies. It also has support for looking up clients in DNSBLs, which are used to publish lists of misbehaving or malign hosts. One such DNSBL, called TorDNSEL, provides a way to check users connecting through the Tor anonymity service.

As discussed at TorDNSEL’s information page, the purpose of this service is to provide finely-grained information about whether a client’s connection could be through a Tor exit node. Tor exit nodes can be configured with advanced exit policies which specify the sorts of direct outbound connections a Tor exit node is willing to make on behalf of its anonymous client. For example, a Tor exit node administrator could disallow his node to make connections to government sites and disable outgoing connections on common IRC ports. If a Tor exit node is run by an administrator who is interested in also connecting to an IRC network, that administrator would disallow outgoing IRC connections. Thus, any IRC connection made (on a common IRC port) through that node would be a legitimate connection made by a user on that host and not a connection from an anonymous client. The TorDNSEL DNSBL lets—and requires—networks which use it to take this into account.

Prerequisites

This short guide assumes that you have successfully configured BOPM to connect to your IRCd, parse oper notices informing it of client connections, and issue a G/Z:line or SHUN for some other event which identifies a client as using a particular anonymity service.

Configuring BOPM

As TorDNSEL’s information page documents, performing a TorDNSEL lookup requires the IRC client’s IP A.B.C.D, the port of the service being accessed P, and the public IP of the IRCd E.F.G.H. With these parameters, a query would be an A record lookup of the domain name D.C.B.A.P.H.G.F.E.ip-port.exitlist.torproject.org. If the response was NXDOMAIN, then either there is no Tor exit node at A.B.C.D or, if that IP identifies an exit node, that node is unwilling to connect to E.F.G.H on port P because its exit policy forbids such a connection. If the response is 127.0.0.2, then there is a Tor exit node at A.B.C.D which would willying connect to E.F.G.H on port P. From this information, we can produce a BOPM blacklist block:

OPM { … blacklist { name = "P.H.G.F.E.ip-port.exitlist.torproject.org"; type = "A record reply"; reply { 2 = "Tor exit server"; }; ban_unknown = yes; # GZLINE issuing a 7-day network-wide zline with UnrealIRCd-compatible syntax kline = "GZLINE *@%i 7d :You are connecting from a Tor exit node willing to connect to E.F.G.H:P"; }; … }; 

The above blacklist should be copy-pastable into your bopm.conf‘s OPM section. But, remember to replace E, F, G, and H with the respective components of your IRCd’s IP address. In the name line, it is intended that the components of the IP are in reverse order. This is because the right end of a domain is more general and the left end is more specific whereas in the first component of an IP address is most general and the rightmost component is more specific.

Also, note that you shouldn’t copy the … into your bopm.conf; each of these is just a placeholder indicating that you probably already have other blacklist blocks which should be preserved defined inside the OPM block.

One last note about this blacklist entry. If your IRC network, like many networks, allows connections to multiple ports, you must specify a blacklist entry for each port. For example, 6667 is the port an IRC client will try, by default, to use when connecting to an IRCd. But if a client wants to use SSL (without STARTTLS), you might have instructed your IRCd to listen for SSL connections on port 6697. A side effect of TorDNSEL’s specific entries is that a tor exit node may be instructed to deny outbound connections on port 6667 yet allow them on 6697. Since BOPM cannot (AFAIK) be configured to automatically choose a value for P, you must create a blacklist block for each IRCd public IP and port combination.

Breakdown

OPM { … blacklist { name = "P.H.G.F.E.ip-port.exitlist.torproject.org";

Here you specify your server’s public IP, E.F.G.H, in reverse as H.G.F.E as well as the port your IRCd is listening on, P. BOPM will prepend the IP of the IRC client which connects, A.B.C.D, in reverse order as D.C.B.A when it checks if the client is in this TorDNSEL.

 type = "A record reply";

This specifies that BOMP should take the IP address the DNSBL returns and interpret that as a response. DNSBLs generally use IPs in the reserved localhost range, 127.0.0.0/8, to avoid pointing to IPs owned by third parties.

 reply { 2 = "Tor exit server"; };

This is the list of potential DNSBL responses which you anticipate from TorDNSEL. If the DNSBL returns NXDOMAIN (which means, “I don’t know about this doain”), BOPM will ignore the answer and assume the client is not in the DNSBL. However, if the server responds with an IP such as 127.0.0.2, BOPM will subtract 127.0.0.0 from the IP and then look for the result 2 in this reply list. If it finds an entry, it performs the action in kline discussed below.

TorDNSEL currently only defines two possible responses. NXDOMAIN indicates that the node would not connect to E.F.G.H:P on behalf of a Tor client. 127.0.0.2 or, as BOPM interprets it, 2 indicates that there is a Tor exit node at A.B.C.D which is willing to connect to your IRCd.

 ban_unknown = yes;

This line states that, if the DNSBL responds with an IP other than those handled in the reply block, it should assume that the client still should be banned. The TorDNSEL guide states Other A records inside net 127/8, except 127.0.0.1, are reserved for future use and should be interpreted by clients as indicating an exit node. This means that the TorDNSEL project reserves the right to add a new response, such as 127.0.0.3, which would indicate a subtly different sort of tor exit node. Until this new response is defined, all we know is that the IRC client probably should be banned by BOPM.

 # GZLINE issuing a 7-day network-wide zline with UnrealIRCd-compatible syntax kline = "GZLINE *@%i 7d :You are connecting from a Tor exit node willing to connect to E.F.G.H:P";

This is the IRC command which BOPM will issue when a client is listed in TorDNSEL. The above command will set a network-wide ban on the user’s IP which will last for 7 days using UnrealIRCd‘s syntax. A Global Z:Line is an efficient ban as the client’s connection can be closed by the IRCd before the IRCd looks up the client’s hostname. The reason listed with the GZ:Line is formulated so that the IRC user will understand exactly why he was banned.

 }; … }; 

Be careful when editing your bopm.conf. Don’t forget any semicolons; even the ones after closing curly braces (}) are ncessary. If you’re reading this guide, you hopefully don’t need this advice .

Testing

Once you have added the necessary configuration directives to your bopm.conf, you should test and check that BOPM catches the Tor exit nodes which are willing to connect to your IRCd. If BOPM was already running, do not forget to rehash it (BOPM’s readme suggests that /KILL BOPM (rehashing) is a convenient way to force BOPM to reread its configuration and reconnect). The following uses BOPM’s in-channel command interface to ask BOPM to scan an IP and check if it would be banned if a client connected from that IP. This requires that you have properly configured BOPM to join a channel with an IRC::channel block. An alternative test would be to just connect to your network through Tor, but that is probably more involved.

To check if your BOPM would detect a Tor IP, first find a Tor exit node (if using list list, ensure to choose an IP for which the “Exit Node?” column has “YES”). Then join the channel where BOPM is and issue the command BOPM check IP, where you replace BOPM with the nickname your BOPM bot is using and replace IP with the Tor exit node IP you looked up. A successful detection will look something like the following:

-!- BOPM2 [~bopm@Clk-NNNNNNNN] has joined #opers
<&binki> BOPM2 check A.B.C.D
< BOPM2> CHECK -> Checking 'A.B.C.D' for open proxies on all scanners
< BOPM2> CHECK -> DNSBL -> A.B.C.D appears in BL zone 6667.H.G.F.E.ip-port.exitlist.torproject.org (Tor exit server)
< BOPM2> CHECK -> DNSBL -> A.B.C.D appears in BL zone 6697.H.G.F.E.ip-port.exitlist.torproject.org (Tor exit server)
< BOPM2> CHECK -> DNSBL -> A.B.C.D does not appear in BL zone 6900.H.G.F.E.ip-port.exitlist.torproject.org
< BOPM2> CHECK -> DNSBL -> A.B.C.D appears in BL zone 7000.H.G.F.E.ip-port.exitlist.torproject.org (Tor exit server)
< BOPM2> CHECK -> All tests on A.B.C.D completed.

In this scenario, the port 6900 was inside of a reject range policy on the Tor exit node I selected. For some odd reason, it seems that this port is part of a range which is commonly disabled in Tor exit nodes. Yet, the Tor exit node I chose admits that it is willing to connect to my IRCd still and will be banned because of one of the other OPM::blacklist blocks I have defined, such as the one for port 6667.

In your own tests, you might encounter Tor exit nodes which BOPM does not flag as needing to be banned. There are multiple reasons for this. First of all, you may have selected a Tor exit node with policies which disallow Tor clients to access IRC through it. Thus, you must try with multiple exit nodes randomly selected from some listing of Tor exit nodes before despairing. If you have checked multiple hosts and your BOPM refuses to recognize them, you may have misconfigured your BOPM’s blacklist entry. Double-check that you have put your correct server’s public IP in reverse order properly along with the correct port in the blacklist::name entry. Test that BOPM’s DNS is working by looking up D.C.B.A.P.H.G.F.E.ip-port.exitlist.torproject.org, perhaps using the getent hosts or dig tools. Remember to rehash BOPM (by /killing it with your /oper powers perhaps) after editing bopm.conf.

As of Arduino 1.0, interrupts are not supported on the Arduino Leonardo. I’m working on a project using the atmega32u4 with the Arduino IDE which needs interrupt support for both software serial and frequency counting, so I investigated ways to add interrupt support for this device. I began by checking out the Leonardo pins definition file to see what was missing for interrupt support. Long story short, I ended up copying the macros for interrupt bitmasks/registers from the Teensyduino project, which has a mega32u4 target board. In addition to modifying the pin definition header file, I also needed to modify WInterrupts.c—swapping out the default AttachInterrupt() and DetachInterrupt() funcitons with those from the Teensyduino project.

I have included links below to the pin definition header file and interrupt functions in my project repository. Place these files in the hardware/arduino/core and hardware/arduino/variants/leonardo folders. Note that my current revision of these files only support the m32u4, interrupt support for other devices is broken. You can throw some #ifdefs in there and include the existing code to support devices other than the m32u4, I will hopefully get around to adding this in the coming weeks.

I also want to get SoftwareSerial up and running on the m32u4; I’ll be looking into the Teensyduino variant of NewSoftSerial this week, check back for more updates in the coming days.

Downloads

• WInterrupts.c
• pins_arduino.h

The first prototype ZonCoffee v3 boards have arrived and are nearly up and running. I’m currently porting the code over to Arduino 1.0, as this board uses the Arduino Leonardo bootloader. Read on past the break for more info on the new board.

v3 Features:

• 6-Pin AUX port allows use of parallel LCD or custom expansion
• Supports SparkFun serial LCD
• USB port emulates virtual serial port for logging and loading new firmware
• All ports broken out to screw terminals
• Power via USB or external independent power source
• MAX6675-compatible footprint (also supports Maxim-IC’s newer chips)
• 6-Pin ICSP header for flashing custom bootloaders
• Main power and USB power LED indicators

This PCB includes connectors for external power, a SparkFun serial LCD, a pusbutton encoder, a thermocouple probe, a solid-state relay, and an auxiliary port. The auxiliary port pins are all connected to the ADC, allowing additional analog or digital IO for expansion. Note that the logo is silkscreened backwards, which is the only (thankfully superficial!) problem I have encountered with my board so far.

The PCB is populated with an ATMEGA32u4, an 8-bit Automotive-grade microcontroller from Atmel that features a USB interface as well as USART and SPI. This board takes advantage of USART for the SparkFun serial LCD, SPI for interfacing with the MAX6675 thermocouple interface chip, and USB for logging and updating firmware with a computer.  All parts on the PCB aside from headers are surface-mount, allowing a very compact design. For permanent installation, screw terminals can be depopulated and wires soldered directly to the board (except for the thermocouple leads, which cannot be soldered).

I have fully populated and tested two of these PCBs so far, and everything is completely functional. There are still a few software quirks from porting my original code to Arduino 1.0, but the boards themselves are fully functional. After a bit of tweaking with the encoder library and creating a drop-in library for attaching a HD44780 LCD to the auxiliary port, this design should be completely usable. I have one board up and running on my espresso machine for both use and development, and I also have a board attached to my roaster (modified Poppery I) that I will be using to experiment with ramping the setpoint for temperature-controlled coffee roasting.

Want to get one?

I’m planning on making a small beta run of boards in the coming months. Drop me an email or a comment below if you’re interested. I haven’t priced the beta boards out yet, but they will be available at a reduced price as long as you’re willing to provide a bit of feedback on the system.

Update (2/9/12)

Development on ZonCoffee has been a bit slow lately, as I’ve been working on a more time-critical project. Coincidentally, the project I’ve been working on also uses the ATMega32u4 on a much larger scale, so I can backport some fixes to the Arduino Leonardo specification to this project. I should be able to resume work on this project in the next couple of weeks.

Update (2/25/12)

I just wrapped up getting the parallel LCD code up and running, users can now switch between a parallel LCD on the auxiliary port to using a 1-wire serial LCD by changing a single define in the code. The last issue I have to deal with is my rotary encoder handling. I should be ready to do a run of the boards once I get some new encoders in to test with.

I acquired a free Sigma 24-70 f/2.8 lens that had a few issues–namely, autofocus was broken and the zoom was incredibly hard to turn. After using the lens in full manual for a while, I determined that I would attempt to repair it.

I first did a quick disassembly of the mount, exposing the autofocus motor and the top of the lens components. It was clear that the metal bracket on the AF/MF switch was broken, one of the metal arms that push down the gear was dangling from the bracket. I removed the bracket and mixed up some J-B weld to glue the pieces back together.

After some googling, I determined that the lens must have already been disassembled for repair (made apparent by scuff marks on screws) as the spring that engages AF was on the wrong side of the gear. This resulted in the bracket pushing down on the gear rather than pulling it up against the spring’s force, causing the bracket to break.

After gluing up the bracket, I continued disassembly to see if I could do anything about the sticky zoom. Taking the remainder of the lens apart was tough, as Sigma lenses have soldered-on ribbon cables instead of nice detachable ribbon cables like all Canon lenses have. In addition, you must remove a single setscrew to take off the zoom ring which is hidden under the zoom ring’s rubber grip.

When removing the bottom of the lens, I pulled a bit too hard and ripped the aperture drive motor ribbon cable–I didn’t even notice I had broken it until I looked inside the disassembled lens body. Be incredibly careful when pulling apart separate pieces–these ribbon cables are very fragile! I left the aperture cable broken for the time being, as it will take a fairly long amount of time to solder back up. Note: be very careful when removing focus/zoom rings from your lens, zoom/focus encoder brushes are also very fragile.

When I reached the zoom portion, I found several small plastic bushings which were apparently crushed. The previous owner of the lens must have dropped it, crushing the bushings and skewing the alignment of the zoom. Several screws for these bushings were loose, and tightening them did make the zoom a bit easier to use. However, I could not do any more to fix the stuck zoom issue.

I also noticed that the encoder brushes for the focus assembly were bent and broken. I attempted to bend these brushes back in, but I was largely unsuccessful. I couldn’t find any replacement brushes online that matched the brushes in this lens, so I left them as-is. Interestingly enough, AF worked fine without the encoder brushes.

After waiting for the J-B weld to cure, I reassembled the lens with the spring in the right location and tested it out. AF worked properly, and the zoom was a bit easier to use. Other than the aperture being stuck at F/2.8, this was a very usable lens.

I have since repaired the broken aperture cable, and I’ll throw together a post on that procedure in the near future.

When you’re trying to grow a bunch of plants in a field where a water source is lacking, things can be a bit tough. Hauling water on-site is a very arduous process, even with a tractor/trailer full of buckets. After hauling 5-gallon buckets to water blueberry bushes for months, we began to work on a better reservoir irrigation system that was cheap and easy to automate with expandable capacity.

To store water, we decided to use a 55-gallon drum. The drum provides enough water for just over a week of watering every other day. We plan on adding another barrel with a siphon hose connecting it to the main barrel for additional capacity.

After deciding that a gravity-fed system would be inadequate, we purchased a very inexpensive 1250 GPH bilge pump. As cheap as it is, this pump provides enough pressure to water an entire row of blueberry bushes. If you are planning on a more extensive system, you likely need a more powerful pump (more about this later).

We added garden-hose threaded adapters to both the hose of our bilge pump and the intake of our watering line. Having a garden hose adapter for the bilge pump line allows us to use garden hose and sprayer nozzles to water other plants, if needed. Note that an in-line anti-siphon valve is necessary to prevent water from constantly flowing out–we eventually added one after these photos were taken.

We used standard black irrigation tubing and spray nozzles for our watering lines. This hose is incredibly cheap and the spray nozzles are about $.50 apiece. These nozzles are adjustable, allowing them to work with the very low water pressure that the bilge pump provides. Our watering hoses are laid on the ground, however lines can be suspended over plants on stakes if necessary (this help keeps dirt and other particles out of the nozzles).

We terminated the end of our watering line with a garden hose connector as well, mating nicely with the connector on the bilge pump hose.

We laid our tubing along the ground without stakes initially, however we ended up staking down the hose between every nozzle to keep it from moving around.

The setup itself is not incredibly unsightly and does a great job of watering plants in locations that don’t have a source of water close by. If the barrel is topped up every so often, watering is quick and easy.

Future Plans

In the near future (likely next season), I plan on adding automation to the system with a relay, microcontroller, and RTC chip. I am developing this system while at school for my small-scale indoor automated watering solution (documentation to come soon).

In addition, we have purchased an RV pressure-regulated water pump with much greater capacity, allowing us to water more plants and some of our fruit trees next season. If you need greater capacity for your watering system, you can buy one of these pumps for about $50 on eBay. If you need greater water capacity, you can add additional 55-gallon barrels with siphon hoses between them. This is an easy way to increase capacity without making any changes to your existing system.

MNL is a multi-node high-power RGB lighting system. It consists of a controller (PC or embedded system) and multiple light nodes networked with RS485. The first prototype nodes are up and running, and we will be developing the second revision of prototypes in the coming months. Read on past the break for more information.

Node Hardware

The node board is a small PCB with two RJ-45 ports and a power terminal strip, along with an ICSP header for flashing firmware. The nodes are designed for daisy-chaining both data and power.

Current features:

• RS485 communication
• Supports LEDs of up to 1.2A per channel
• Upgradeable firmware for additional features
• TBD: Firmware updates over RS485
• Multiple fade types, dwell modes, etc.
• Hardware-agnostic network supports different types of nodes (e.g., strobe, motor driver, etc)

LED Circuit

The LED used for prototyping is a 10W RGB LED from DealExtreme, which provides a generous amount of light with low cost per lumen. Although the heatsink is a bit small, forced-air cooling keeps things at a reasonable temperature.  The PCB includes a fan output which is PWMed according to the average instantaneous luminosity of the node. Forced-air cooling could be helpful for installation in compromising environments, such as can lighting fixtures.

The current design incorporates 3 current-limiting resistors for each channel of the LED. Although this is less efficient than current-regulated supplies, it allows flexibility in LED choice without requiring extensive PCB modifications.

Prototype Software

I developed a quick Processing sketch for testing purposes. It creates a FFT of the stereo mix and uses the lowest three bins to determine R/G/B brightness. If the largest of the three values is over the threshold specified by the slider, then an update command is sent to the node. The processing sketch also has an Open Sound Control (OSC) interface, allowing easy control from the TouchOSC app for iPhone or Android over WIFI as well as any software package that supports OSC.

This project is still under heavy development, and is still in the prototype phase. We are adding additional features to the software and hardware, so expect significant updates in the coming months.

Want a nice hearty printed circuit board desktop background? Well, here you go (right-click, save as). The PCB is an older Arduino NG board placed on top of one of our 10W MNLC lighting nodes (still under development, more information to come).