Yet another Arduino Based Brewing controller

Australia & New Zealand Homebrewing Forum

Help Support Australia & New Zealand Homebrewing Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.
TheWiggman said:
A few queries -
  • There are 3 sensors pictured in the original drawing but only two used, what's the go?
  • Why is there a resistor across one sensor's +ve and 'data' leg?
  • How do all two/three sensors work if they're read off a single terminal?
  • There are additional PCBs below the TFT, are there basically terminal boards to make screwing things easier?
The three sensors are: HLT, Mash and internal panel temperature. The software produces an on-screen alarm if the panel temperature > 50C. I've read that SSRs can produce a bit of heat if they're working hard, that said, I've never seen them get anything but warm. So far, (on ~25C days) the panel gets to about 35C. That said, they are screwed to quite a heavy metal (aluminum?) base plate.

The DS18B20 digital temperature sensors need this resistor for good readings. They suffer a bit from line noise, and this resistor helps. The capacitor there is also supposed to help with this, but it's probably a bit big. But it was the first one I grabbed, and it did seem help with failed re-reads.

The DS18B20 sensors use the "OneWire" protocol. Each sensor has a 5(6?) byte address - a bit like a MAC address of an ethernet card. When you request something from a sensor using the API, typically you include the sensor address in the call, so the sub-system knows which sensor to use.

The two extra PCBs in the photo are:
- Just a bunch of common (+) (-) screw points where power is delivered to stuff, and earths grounded.
- An attachment point for the DS18B20 sensor power lines, and the OneWire bus line. It also holds the 4.7k resistor and a hastily-added capacitor.
So yeah, you're basically correct, they just made wiring it up easier.
 
TheWiggman said:
Tops thanks.
Any reason I couldn't get a Uno R3 instead of the nano so there's more memory available? I like the idea of being able to expand in the future. Id imagine there are a few references in the coding to change.
I'm prepared to be corrected, because I'm not going to go check - but the Nano has exactly the same specs as the Uno (apart from the obvious physical size differences)
Definitely at least as far as memory is concerned (~30k after the boot-loader).

But if you want to use an Uno, it should be 100% ok.
 
sp0rk said:
I think it's OK, as long as there's a "SW" pin on the board, or search for "Rotary Encoder with button/switch".

I found rotary encoders a bit of a PITA to solder into a board, so I started buying them pre-mounted.
I have a few of these: https://www.aliexpress.com/store/product/Rotary-Encoder-Module-24-steps/1950989_32678025587.html
The RobtoDyn stuff seems to have a good build quality. You can probably save 10 cents ordering direct too ;) http://robotdyn.com/
But I just used a generic one in my project, because it was on hand at the time.

(BTW: if you want to buy from an Australian retailer, Core Electronics is outstanding - http://core-electronics.com.au/ )
You'll (possibly) pay more, but of course you get a warranty, and faster delivery.
 
sp0rk said:
Using a slightly bigger screen with an sd card slot but the same resolution shouldn't be a problem as long as I'm only wiring the required pins, right?
Once the programme is loaded, there is only about 300 *bytes* of storage memory left, so using that SD card would probably be out of the question, since you couldn't even include the API for it.

But the short answer is: If it's connected by SPI and supported by the PDQ_GFX library, then yes. (So: ILI9340, ILI9341, ST7735, ST7781).

The LCD pins do seem to get moved about and renamed a bit. So it might be necessary to re-work out which pin goes where.
It will be pretty close to the existing naming, but I did have to spend some time experimenting to work mine out.
There was documentation, but it differed from reality. I'm no expect whatsoever, and I worked it out, so I doubt it'll be a problem.
The LCD I used does not even have a ChipSelect (CS)pin (AFAICT) - so you can only use one LCD board at a time. (i bought the chepest because I'd not used one before)

A bigger LCD might be easier to read though.
 
Brilliant!
My main thing was I'd already built a controller box with an STC1000 for my HLT and a pump, but the smaller screen wasn't wide enough to go in the hole that the STC currently fills (i'll be ditching the STC)
Might give a bigger screen a go and just see how it works
 
Nice work! :icon_cheers:

If you're not phased by a bit of fiddly soldering work I'd recommend looking at replacing the Nano with an ESP8266 12F in the future, skip over this if you're familiar with it but I like that it:

- can be programmed from the same Arduino program and likely the same Arduino '.ino' file you are using with just a few small tweaks. It can also be loaded with firmware for other programming languages if you like, most are 'interpreting' languages like Lua, JavaScript and Python - they take up more space but you can program live while the device is running rather than re-compiling every time you want to test an idea.

- is about the size of a postage stamp - plenty of left over real estate in your project box.

- has 4M of flash memory - which can help with adding extra peripherals / displays / sensors etc.

- can act as a WiFi server or WiFi client - so you can either push your data to a server like www.thingspeak.com to monitor your brew remotely, or it can act as a server and show the data in a webpage which you can monitor and control from the internet browser on your phone / computer etc. rather than relying on fixed displays

- crunches numbers at up to 160Mhz, 10x the Nano - not going to make any difference for this application but gives you scope to grow your ideas.

- is about $2 here - you could afford to have a whole bunch of 'things' all over your brewhouse / house all speaking to eachother, monitoring and doing . . . . . . beer stuff.

Anyway, food for thought and good luck with the project
 
littlejohn said:
Nice work! :icon_cheers:

If you're not phased by a bit of fiddly soldering work I'd recommend looking at replacing the Nano with an ESP8266 12F in the future, skip over this if you're familiar with it but I like that it:
[...]
- is about $2 here - you could afford to have a whole bunch of 'things' all over your brewhouse / house all speaking to eachother, monitoring and doing . . . . . . beer stuff.
I'm not really interested in fiddly soldering ;)
So I ordered one of these: https://www.aliexpress.com/item/V3-Wireless-module-NodeMcu-4M-bytes-Lua-WIFI-Internet-of-Things-development-board-based-ESP8266-esp/32647542733.html

I also have an arduino mega in the post.
I like the Arduinos because I only get small snatches of time to work on stuff. Generally if there's any sort of problem, a bazillion people have already had it too, and solved it.
That makes it really quick to get your ideas turned into an actual machine.
 
Mr Wibble said:
I'm not really interested in fiddly soldering ;)
So I ordered one of these: https://www.aliexpress.com/item/V3-Wireless-module-NodeMcu-4M-bytes-Lua-WIFI-Internet-of-Things-development-board-based-ESP8266-esp/32647542733.html

I also have an arduino mega in the post.
I like the Arduinos because I only get small snatches of time to work on stuff. Generally if there's any sort of problem, a bazillion people have already had it too, and solved it.
That makes it really quick to get your ideas turned into an actual machine.
I know what I'll be buying once I've used/killed all my arduinos!
 
littlejohn said:
I'd recommend looking at replacing the Nano with an ESP8266 12F in the future, skip over this if you're familiar with it but I like that it:

- can be programmed from the same Arduino program and likely the same Arduino '.ino' file you are using with just a few small tweaks. It can also be loaded with firmware for other programming languages if you like, most are 'interpreting' languages like Lua, JavaScript and Python - they take up more space but you can program live while the device is running rather than re-compiling every time you want to test an idea.
If you have enough space left over after writing your C/C++ or Arduino code, the ESP8266 is capable of doing OTA updates -- handy when you need to tweak your sketch but physical access to the device is a bit tricky.
 
After some thinking I think I'll just buy the bits and essentially replicate what Mr Wibble has put together. That'll get me brewing while I learn how Arduino coding works (I did C in one computing class in year 9, things have come a long way since the mid '90s and my memory ain't one of them). I only want to make a few changes, mainly being -
  • Add a button/switch to the front so I can turn the pump on manually. 2 ideas are -
    Button+ SSD relay. -ve: Extra bits, no power when unit is offline. +ve: will look neat, requires no feedback, can program to shut off pump, SSD will allow any size pump or device
  • Double pole switch with feedback

[*]Change the code so the HEx won't run if the pump is off (that's trapped me a few times)
[*]Move the 3rd sensor to the HEx liquid temp, to show temp and prevent boiling in case flow is lost
[*]Add an additional 'sparge mode', which is in effect starting the pump and setting the HEx outlet temp to 80°C after I rearrange hoses
If my wife asks what the bits are for it's because I'll tell her I'm building an automated sprinkler system.
 
Yeah, in the next version I'd like to add pump controls.

The boil-alarm sensor is a good idea. I also considered putting in some s.steel float switches in the various tanks to fail-safe the heating elements. I bought a couple, but I never got around to using them. They did seem a bit "lightweight".

I received my arduino mega yesterday, but maybe I'll wait until the ESP8266 arrives and see how much porting of libraries is necessary for it to work.
I guess the mega should be mostly just a simple re-compile.

It would not take much code to read a digital input from your switch to know if it's on/off.
 
I've downloaded the Arduino software and had a look through Mr Wibble's code and boy oh boy, there is a hell of a lot of work there. Staggering amount. I thought I might have a chance at changing a few things if I wanted but I've found myself reading through the "how to turn on an LED" level guides to understand what the hell is going on. I'm fairly competent in VBA and was in Fortran but this is an entirely different kettle of fish. Full credit to you for sharing this code, clearly many hours of work here and much appreciated.

I was going to PM but figured this might be a broader issue. I've tried to compile the code and had a big issue with libraries (bear in mind this is my first experience with Arduino). I read the readme and uploaded the Adafruit and PDQ libraries for the graphics. However, it's stalling on the drawing of the pots with teh following error message:

'class PDQ_ILI9341' has no member named 'drawEllipse'

Any ideas?

I took the plunge and bought a lot of components, first of which is the Uno (sitting in front of me). After some faffing about with drivers I realised why these things are so cheap... because they're counterfeit. Should have known at the price!
 
You blokes who know about electronics etc are good value to others ( me) who have absolutely no idea of what your on about. But we are very happy to bung it in our rigs and say... look what I've got.
Brew **** rocks !
 
TheWiggman said:
I was going to PM but figured this might be a broader issue. I've tried to compile the code and had a big issue with libraries (bear in mind this is my first experience with Arduino). I read the readme and uploaded the Adafruit and PDQ libraries for the graphics. However, it's stalling on the drawing of the pots with teh following error message:

'class PDQ_ILI9341' has no member named 'drawEllipse'
Sorry for the late reply, I have subscribed to this thread, but have not received a notification as yet.

You need the PDQ_GFX Libraries, these are based on the Adafruit ones, but optimised.
They can be found here: https://hackaday.io/project/6038-pdqgfx-optimzed-avr-lcd-graphics
(Note: it does say this in the README.md :D )

I have added a couple of functions to the libraries, one of which is drawEllipse(), these additions can be found in the code under extra_graphics.h
However to save confusion, I have pulled a copy of the library into the project with these changes already made.
EDIT: if you add this library, you need to restart the Arduino editor (or at least you have had to in the past).

I hope this solves your problem.

-kt

PS> Post any changes you want to do and we'll nut them out here (or PM, whatever).
 
TheWiggman said:
I'm hearing you there spog.

As a side note for one of the temp sensors I've gone for a board mounted sensor like so: http://www.ebay.com.au/itm/172405211767?_trksid=p2057872.m2749.l2649&ssPageName=STRK%3AMEBIDX%3AIT
This has the pull up resistor and diode already mounted. No long leads or anything to coil up and can screw down easily to monitor the control box temp. Winner.
I use the long-lead waterproof ones so I can shove it down inside one of those temperature probe housings you mount in the side of the pot.
I guess it doesn't need to be waterproof, since the stainless housing takes care of all that.
 
Not sure if you're commenting on the fact I read the readme or not Mr Wibble, but I did follow the instructions in the readme and I still got the error. I'll check your comments about the extra code tonight (hopefully), otherwise it'll be after Christmas.
I've got 2 waterproof sensors on their way for my thermowells, the board mounted sensor is going in the control box.
 
Tried again, exactly the same error. I did the following in this order -
  1. Loaded updated project from Github
  2. Deleted old PDQ_ILI9341 from library, uploaded the one you indluded in your package
I'll play around after a short holiday. Merry Christmas.
 
TheWiggman said:
Tried again, exactly the same error. I did the following in this order -
  1. Loaded updated project from Github
  2. Deleted old PDQ_ILI9341 from library, uploaded the one you indluded in your package
I'll play around after a short holiday. Merry Christmas.
You need at least the PDQ_GFX/ directory copied in there too, since this is where the header definition is.
The drawEllipse() is defined only in this super class, since it does not implement anything hardware-specific.

It's OK to copy in all the PDQ_* directories, and this is probably the best way forward.

In my extra libraries directory, I have:

DallasTemperature
Encoder
OneWire
PDQ_GFX
PDQ_ILI9340
PDQ_ILI9341
PDQ_ST7735
PDQ_ST7781
PID_v1


Just to streamline this, I've pulled all these libraries into the git project (now) under Libraries/
https://github.com/kt--/ArduinoMashController

So if you copy in everything from here, restart the IDE, it should build without issue.

If it doesn't:
- check you really restarted the IDE (no stray window left open or suchlike).
- check the library directory is being included in the compile
- It should be under [File]->[Preferences] then whatever is set for "Shetchbook location" /libraries

cheers,
-kt
 
Back
Top