I know it’s been a bit since I’ve done an update but I wanted to put it out there – the first public revision of the CREMA firmware!! It’s being released under the Creative Commons Attribution-ShareAlike License so as to provide a significant amount of freedom with respect to what people can do with it.
You can get it here: https://github.com/josh-blake/CREMA
Presently, the CREMA firmware provides you with:
- Custom brew Presets and the ability to modify: temperature, duration, and pump duty.
- Real time clock with alarm and auto-on / off.
- Steam temperature control with auto-refill (marching ants).
There is a LOT more that I need to do with the CREMA firmware including:
- Storage / Retrieval of settings from Flash Memory
- Modifying PID settings (they’re currently hard-coded)
- Finishing off the rest of the menu elements
A note about compiling this firmware: you WILL need to enable SPRINTF functions with FLOAT capabilities as I’ve previously outlined (http://josh.to/crema/rebuilding-the-arduino-ide-to-support-sprintf-with-floats/). Everything else should work as is.
I’ll post the hardware next!
So I’ve soldered up the first CREMA Revision A board and spliced it into Silvia’s internals. It works exceedingly well except for a few minor hiccoughs that I tracked down and worked out. To start, the CREMA board was spontaneously aborting during brew cycles, and it took the better part of 24 hours to hypothesize, test, and revise. It turns out it was caused by two problems: one was hardware related (in Silvia’s native wiring), and the other was software (duhhhhhhhh ….).
As it stands, Silvia is wired to power the solenoid valve when the brew switch is thrown – both line and neutral wires are switched. The only place to splice in the brew switch line voltage is at the point where the solenoid LINE voltage (orange wire if you’ve cracked your Silvia open) meets the switch. Unfortunately these solenoid valves act like MASSIVE inductors so every time the brew switch was thrown and then powered off, a residual current would discharge through the line voltage sensor – in short it didn’t turn off promptly. However I fixed this by bypassing the switch and tying the neutral lines directly together (keeping the LINE voltage switched) to allow for a more favourable current discharge path. Hardware issue resolved.
The software issue was a silly one – I forgot that I had included some ‘press ok to go to next step’ sort of steps in the code for testing purposes. The display keypad kept jiggling with the vibrations from the pump and tripping the OK state >_<. Sigh. Commenting out the offensive lines of code resolved the issue. I need to finish writing the code now for the alarm and RTC although that's trivial. I also need to tune the PID parameters to get it to stabilize (rather than over or undershooting the target). The menu system and navigation is also fairly well complete. I'm pretty content with how I've coded the menu. To store a multidimensional menu system (that is, one with sub menus and sub menus etc.) with an excess of 80 menu elements (each with screen contents and associated button functions) in SRAM is not possible when you have a total of 2500 bytes available. So everything got pushed into program memory instead. Effectively the number of elements in the menu has no footprint in SRAM - ^_^. On how it tastes ... I've pulled a few shots using the CREMA board, and so far, I've noticed two things: the flavours are far more robust than I would have ever imagined, and the temperature is far more consistent than I would have ever imagined. It's amazing the difference a PID makes. Right now I'm drinking Femenino Columbia Cosurca, a single origin from Dark City Coffee here in Toronto – and while it was super tasty before, it’s beyond this world now.
More to come as I work out the software!!
The prototype boards arrived today from OSH Park! Can’t wait to get started soldering one of these puppies up!
This is just a quick demo video of how the pump pressure is controlled using PWM to control the pump flow rate (and therefore pressure at the grouphead).
So I’ve finished the board for CREMA Revision A – Prototype 1. It’s a beaut!
I’ll have it printed and wire it up. I can’t wait.
Unfortunately due to size constraints, all components are surface mount (to the exclusion of the Molex headers etc.) Fair warning: unless you have a reflow oven, soldering this board will not be for the faint of heart. There are no components smaller than a 0603 resistor so if you’re good with that, then this will be a breeze!
The prototype has the following functions / features:
- Dual P.I.D. Boiler Control (PWM based)
- Dual PT100 RTD Temperature Sensors with 24-bit resolution providing 0.05°C temperature accuracy
- Single Pump Control (PWM based: allows for pressure profiling)
- 16×2 Display Module
- Onboard real-time clock with two alarms
- Bluetooth or WiFi (using Electric Imp) connectivity for remote control
Some of the design details include:
- Onboard 5V 2,000mA power supply with resettable fuse and ESD protection
- Faston Quick Connect tabs to be compatible with internal wiring of many espresso machines
- Power indicator LEDs for Boiler A, Boiler B, and Pump solid state relays
- Zero-crossing solid state relay to allow precise control of vibratory pumps
- Line-voltage sensors to determine switch states without requiring any special wiring
- Molex connectors with gold-plated pins to minimize connection problems
Once I work out any underlying bugs, I’ll firm-up the firmware and make a public release of the board.
Some of you have asked for the library that I’ve made up for the CrystalFontz displays – so here it is!
The library, in its current state, is the bare minimum necessary to operate the display. I WILL be elaborating on it, and changing it around significantly in the final firmware revision.
You are free to use the library as you want, however I would appreciate an acknowledgement and a heads up on what you might be using the library for (to see what kind of cool stuff people are doing!).
Just the wiring topology that I’m using with the ADS1247. Many of you have asked so here it is!
Pins 20, 19, 18, and 16 are wired as appropriate directly to the Arduino. C1 should be at least 10uF but no greater than 47uF.
Pardon the delay! The past three months have been hectic with school and work. I’m finally taking some time over the holidays to get this project wrapped up.
I’m leaning towards implementing an Arduino Leonardo in place of a Pro Mini for two main reasons. The first is that the Leonardo has built-in USB support which frees up the UART for use with a Bluetooth module. The second major advantage is that the Leonardo actually has two 16-bit timers. While at first this may seem trivial, it in effect allows me precise control over the vibratory pump as well as boiler. Because the Crydom relay used to control both pump and boiler is a ‘zero-crossing’ relay, the relay can be toggled at 60Hz without the vibratory pump ‘stuttering’ – a full sinusoidal wave-form is allowed to pass through the relay before it latches on or off.
I can effectively control the pressure at the brew head by controlling the flow rate of water through the pump. Any standard duty cycle will work here (number of 60Hz cycles on to the number of 60Hz cycles off) allowing for precise control of pump activity. While the prescaler doesn’t allow for coincident timing at exactly 60Hz, the frequency discrepancy is so low (0.0961538 Hz) that a switching error (ie the Arduino pin would toggle at the zero crossing point, missing the step) almost never occurs in practice.
Timer (PWM) based control of the pump (Timer3), boiler (Timer1), and pin-change interrupts for the Brew (Pin 10 / PCINT6), Hot Water (Pin 11 / PCINT7) and Steam (Pin 8 / PCINT4) switches means that basic control over Silvia can be driven by interrupts instead of actively polling in the main loop. Additionally, the RTC interrupt pin on the DS3231 can drive Pin 7 / INT.6 allowing for a real-time clock based alarm / wakeup.
In short, the main body of code then will simply be to passively update the PID and Display module.
One of the biggest limitations within the Arduino IDE is the inability to render float types using
sprintf() or some other
print() family function. For the sake of sketch size, these functions were largely stripped down of their ability to handle float types in favour of a float-to-string conversion function for those who needed it. Anyone who does use
sprintf() with a float type will be met with a
'?' in place of their float. However this is not to say that the Arduino IDE cannot generate sketches capable of handling floats! In fact, the AVR compiler that the Arduino IDE uses supports floats in sprintf() – just not by default. So we need to instruct it to do so.
I’ve written up some (pretty simple) instructions that you can follow to prepare your own Arduino IDE that will support float types with sprintf():
- Navigate to: http://code.google.com/p/arduino/wiki/BuildingArduino and prepare your build environment so that you’ll be able to compile everything okay. Proceed with the build instructions up until Step 3.
- Navigate to the following file and open it using your favourite text editor (you might have a slightly different file structure depending on your operating system):
- Search for the following line of code:
- Replace that line of code with:
- Save the file and continue with the rest of the build process.
If all goes well, you should now have a fresh Arduino IDE built from the latest source code that supports floats in sprintf(). No more nasty ‘?’ :). You’ll notice however that even basic sketches are rather large in size (~10kb). However this is a tradeoff that you must be willing to make if you want sprintf() with float support.
I hope this helps everyone – I know I certainly appreciate having float support.