How To: BrewPi LCD Add-On

[wmubronco]

Regarding this;

if( (ticks.millis() - lastLcdUpdate) >= 120000) { //reset lcd every 120 seconds
lastLcdUpdate = ticks.millis();

display.init();
display.printStationaryText();
display.printState();


Do I need to recompile everything, or can I just nano edit and it should be in place? I have intermittent scrambling issues, thinking its caused from when the freezer compressor kicks on.

 

[day_trippr]

If that code is part of the AVR firmware, it has to be compiled into a loadable hex file so it can be uploaded to the Uno...

Cheers!

 

[wmubronco]

That's what I figured. I am running legacy, so not sure if I want to even mess around.

Got a new wifi dongle and that took care of my wireless issue with not having to unplug/plug back in the uno all the time to get wireless back.

 

[Asmodeus]

The snippet of code should be inserted into brewpi.cpp and the main loop that run the avr (line 100 of the legacy branch). For that you need atmel studio 6.2 setup (and turn on line numbering somewhere as thats not on by default)

Do note that the attached hex file link is for a modded arduino uno setup using an LCD with a I2C backpack with adress 0x27 and a rotary encoder. I think that was a more tidy solution and I had the parts already when I set out to do the brewP. I think I will test out emcos update of the legacy branch next week as I anyway will dig into the code in order to try make a software shutoff for the lcd.

Regards /A

 

[sctcts]

So after reading through this whole thread I'm still a little unclear on which transistor to use for the backlight dimmer circuit. I've come across references to the following transistors:

BSS84 - I don't want to deal with trying to solder this tiny thing
2N2906 - these seem to be uncommon? Digikey and my local electronics shops don't stock them
2N2907 - very similar to the 2N2906? they share a spec sheet but some values are different and I'm not familiar enough with this stuff to know whether the differing values matter.
2N3906 - again, similar to the 2N2906?
BC557 - any reason to use this over the others?

I can easily get the 2N2907, 2N3906, or BC557, so which would be the best to use out of those three?

Also, does the resistor that's paired with this transistor change depending which one is used? I'm referring to the 200ohm resistor connected to the base of the 2N2906 in day_trippr's latest schematic.

I'm probably overthinking this but I want to make sure I get all the right components the first time.

 

[ame]

Based on a very quick glance, any of the 2N2907, 2N3906, or BC557 will work. It's a generic PNP transistor and it's only being used as a simple switch. Whatever you can get easily should work, although I am surprised that the 2N2906 is hard to find.

The base resistor (200 ohm) is also not critical. Anything close to that value that you have in your junk box parts bin will be fine.

 

[wbarber69]

If you buy a bag of pnp transistors from rs they'll all look the same but have different labelings they will all work

 

[Brewski_59]

I used 2n2907 because we have them in the shop. They work just fine.

 

[HairyJamie]

Hi, I have a working setup with an I2C backpack to a 20x4 LCD with a rotary encoder and automatic reset every 2 minutes (and Bluetooth, thanks day_trippr!). Link for download : http://s000.tinyupload.com/index.php?file_id=15700787823698715094 , it is for an Arduino UNO, I2C backpack with adress 0x27, rotary encoder.

-While that is fine, there is room for improvement and I think that it would be possible to have software switch off the backlight (or the whole LCD)? It is certainly under software control using a I2C backpack, though dimming does not work (without more hardware like a LDR or PWM) , its either full on or off AFAIK.

The reset of the LCD is done through the little snippet in Brewpi.cpp at line 100:

if( (ticks.millis() - lastLcdUpdate) >= 120000) { //reset lcd every 120 seconds
lastLcdUpdate = ticks.millis();

display.init();
display.printStationaryText();
display.printState();

That takes care of scrambling issues, but its not ideal. It would be far better to do that after pushing the rotary encoder and the main loop could switch off the backlight or the whole LCD after a set period of time. One could even use another sensor as input to switch it on again (like a proximity sensor or whatever).

The I2C (software)implementation is herrfrosts on github that maintain the pin configuration of the RevC board it can be found here: https://github.com/herrfrost/firmware, I just downloaded that, installed Atmega studio and compiled the hex after adding the above code.


The advantages of using a I2C backpack is that everything on the AVR is modular, there is no need of a proto board and very little soldering (I just made a connection block for GND and 5V). - I made my "minions" connected to a multi chamber set up this way, and they are rock solid (but LCD where sometimes scrambled, likely from using sainsmart relays in combination with 230V mains).

- Anyone have an idea on how to implement a method for SW on/off backlight (or LCD)? I have yet to prod into how the code for the project is set-up, I just included the reset hack. After a SW backlight off/on is implemented this solution is ideal in my opinion. Possibly one could use a ESP8266 instead of an Arduino UNO, but that is another project altogether.

Regards and cheers! /A

Wow great work!

Any idea if this would work for an Arduino Nano?

Also - for i2C connectivity I understand that you need to use pins A4 and A5, but isn't A4 used for the onewire input?

Apologies for the basic questions, I'm waiting on my i2C LCD and Nano being shipped and want to get the design work done.

Any chance of a picture of your setup?

Thanks again.

 

[wbarber69]

Yes a nano is just a small uno. And you are looking at the wrong implementation for I2c. The newer one on GitHub uses pins 10 11

 

[HairyJamie]

Excellent - thanks for the quick response wbarber69, appreciate it.

 

[HairyJamie]

Hi,

I'm still not getting this - I have my Arduino Nano wired up to the i2c LCD, pins 10 and 11. The Hex file uploaded succesfully, and the web interface recognises the script running but I still have nothing on the lcd display?

I've tried swapping the two data lines in case I have the pin assignments wrong but still nothing.

Is there anything else I need to do?

Thanks all

EDIT: I obviously have the ground and 5v lines going to the LCD and the backlight comes on, I have tested the LCD with an example sketch and it works

 

[Asmodeus]

Hi,

I'm still not getting this - I have my Arduino Nano wired up to the i2c LCD, pins 10 and 11. The Hex file uploaded succesfully, and the web interface recognises the script running but I still have nothing on the lcd display?

I've tried swapping the two data lines in case I have the pin assignments wrong but still nothing.

Is there anything else I need to do?

Thanks all

EDIT: I obviously have the ground and 5v lines going to the LCD and the backlight comes on, I have tested the LCD with an example sketch and it works

I struggled a while as well and did the ame thing: swapped the data lines etc. But if you tested with an example sketch and it displays readable text on the LCD that should not be it, one possible thing could be the adress of the I2C module, the adress of that should be 0x27 I believe, and some other modules are 0x20, but again, the example scetch would verify that. I also had a hard time before I realised that the contrast was turned down way low and nothing would be displayed as a result.
Try with the sketch I linked to a while back, I know for a fact that works and check the github link (with right branch selected) for the wiring, from memory I think data lines are 10 and 11, but if the example sketch works and the brewPi one does not, adressing and wiring can be the only culprits.

Regards and good luck! /A

 

[HairyJamie]

I struggled a while as well and did the ame thing: swapped the data lines etc. But if you tested with an example sketch and it displays readable text on the LCD that should not be it, one possible thing could be the adress of the I2C module, the adress of that should be 0x27 I believe, and some other modules are 0x20, but again, the example scetch would verify that. I also had a hard time before I realised that the contrast was turned down way low and nothing would be displayed as a result.
Try with the sketch I linked to a while back, I know for a fact that works and check the github link (with right branch selected) for the wiring, from memory I think data lines are 10 and 11, but if the example sketch works and the brewPi one does not, adressing and wiring can be the only culprits.

Regards and good luck! /A

Thanks Asmodeus,

I'm starting to get annoyed!

The LCD is addressed at 0x27 - I've tested it and it works.
I'm using your linked sketch and I have the pins correct as per the github instructions.
Contrast has been checked and rechecked!
I've also tried both 2.2k and 4.7k pullup resistors on the data pins.

On every occasion the Pi sees the Nano and reports fine on the software LCD screen but nothing on the physical one.

I may try another Nano ...

Still no joy

 

[1Tuff4by]

Probably a stupid thought on my part, but bad the same trouble with one out of 3 of the brewpi setups i built. Checked wiring both on the shield board and what was connected, changed trimpot, tested the lcd and had no luck. Ended up being 3 solder joints needed a bit more "'meat" upon closer inspection and then everything worked fine.

 

[HairyJamie]

Probably a stupid thought on my part, but bad the same trouble with one out of 3 of the brewpi setups i built. Checked wiring both on the shield board and what was connected, changed trimpot, tested the lcd and had no luck. Ended up being 3 solder joints needed a bit more "'meat" upon closer inspection and then everything worked fine.

Thanks but no solder joints yet - this is just on a breadboard to prototype it so far.

Still scratching my head with this one - the LCD works fine on pins 4 and 5 with a test sketch but nothing on pins 10 and 11 with the i2c BrewPi sketch.

 

[HairyJamie]

Thanks but no solder joints yet - this is just on a breadboard to prototype it so far.

Still scratching my head with this one - the LCD works fine on pins 4 and 5 with a test sketch but nothing on pins 10 and 11 with the i2c BrewPi sketch.

Success!

Actually it was the soldering - but on the headers I'd soldered onto the board itself, I had a dodgy connection on D10!

Thanks for everyone's help

 

[day_trippr]

Cadibrewer sent me one of his v1.1 shield PCBs and this evening I finally got around to building it and firing it up on my bench-test setup.

Assembly went swiftly with no wires to solder! I stuffed everything but the headers and just went nuts with the iron.



Leads clipped, headers soldered in, and the whole thing washed down with flux remover.




Note that all of the inline headers are stake pins instead of sockets.
I greatly prefer this for the lower profile and higher contact reliability.


Looks sweet! Ready to roll!



Et voila! Up and running via Bluetooth (with a couple of esp sniffers attached).



I was able to hammer on the relays by toggling their polarity in the Device configuration panel and not a hiccup from the LCD.
Good start!

I'll let this run for awhile then swap the shield into one of my minions and let it do some real work.

I have to say it was a pleasure building this and getting it running in a little over an hour, compared to pretty much an entire Saturday for the wired shield.

Nice job, cadibrewer!

Cheers!

 

[Bigdaddyale]

I was going to go with SSR but if you guys aren't having any issues with the LCD maybe I'll use the relays called out in the original build.

 

[Bigdaddyale]

I just noticed on my red shield from DirtyPCB the LCD pins are labeled wrong with #1 on the left next to C1 and #16 on the right.

 

[Bigdaddyale]

 

[CadiBrewer]

I just noticed on my red shield from DirtyPCB the LCD pins are labeled wrong with #1 on the left next to C1 and #16 on the right.

Nope. I had the silkscreen labeled incorrectly on the version I sent day_trippr. I fixed it in the file before I put it on the website. You should be good to go.

It took me an hour to figure out my mistake when I built my first one. The screen actually lights up but has some funky things going on when it is wired backwards. That's an hour I'll never get back. Chalk it up to too much homebrew on the night I was adding in the silkscreen to the board file.

 

[wbarber69]

I was going to go with SSR but if you guys aren't having any issues with the LCD maybe I'll use the relays called out in the original build.

Day_tripper wired his up and has not *yet* had any issues with the relay not powered up to a motor. other than that there has been no indication that lcd problems have vanished with the inclusion of this particular pcb.

 

[day_trippr]

^true^ on all counts.

That said, all of my BrewPi systems use the same SainSmart dual relay module, yet none of my four LCD-equipped minions - including my desktop test system - have ever exhibited the LCD scrambling problem.

And I didn't expect that to change after swapping my hand-wired shield for cadibrewer's pcb...

Cheers!

 

[ame]

The LCD corruption is no mystery. It's caused by electrical noise affecting the LCD data lines.

The most likely culprit is the relay coil producing a spike on the power supply lines or inducing noise somewhere else in the circuit, but it could easily be any other noisy electrical device, such as the fridge compressor or something unrelated but nearby.

The solution is to have plenty of filtering in the circuit, i.e. decoupling capacitors all over the place, or anticipate the problem in software and refresh the display completely and more often.

 

[day_trippr]

The LCD corruption is no mystery. It's caused by electrical noise affecting the LCD data lines.

If only it was that easy: the exact same syndrome has been observed using I2C LCDs.

The most likely culprit is the relay coil producing a spike on the power supply lines or inducing noise somewhere else in the circuit, but it could easily be any other noisy electrical device, such as the fridge compressor or something unrelated but nearby.

That's two different root causes right there - one presumes locally generated noise, the other noise on the AC mains that somehow makes it all the way to the LCD.

One of those is fairly likely, the other not so much.

The solution is to have plenty of filtering in the circuit, i.e. decoupling capacitors all over the place, or anticipate the problem in software and refresh the display completely and more often.

Again, this presumes a root cause that I do not believe has been established, never mind confirmed.

There's no doubt most if not all of the scrambles are associated with relay-induced noise.
If that's the case - and the exact same syndrome can be seen whether 4-bit parallel or I2C LCDs are used - the shield becomes less likely to be a contributor, and I think you have to look at the voltage (and ground) rails hitting the actual LCD.

And Elco's original shield design put a big honking electrolytic cap right on the LCD power/gnd pins.

Now, as the LCD scramble has zero effect on the AVR, the whole thing is clearly a nuisance issue to those so afflicted.
And that's where the hacked hex file with the 60-second LCD reset cycle becomes a viable "solution"...

Cheers!

 

[obsi]

Just to add to the scramble mystery, I was experiencing them with my initial build which had the SainSmart 2 channel relay and a shift register based LCD. I have just updated the box to use two SSRs instead of the relay, and I am still getting scrambles after the relays switch.

 

[ame]

Just to add to the scramble mystery, I was experiencing them with my initial build which had the SainSmart 2 channel relay and a shift register based LCD. I have just updated the box to use two SSRs instead of the relay, and I am still getting scrambles after the relays switch.

What if you unplug the load from the SSR-controlled outlets? Do you still get scrambling when you toggle the SSRs?

 

[day_trippr]

So it turns out that red soldermask is more photogenic than purple...




Thanks to @Bigdaddyale for the pcb from his batch of boards.
Populated the board, plugged it in, tweaked the pot and it's up and running.
Easy peasy...

Cheers!

 

[Bigdaddyale]

So it turns out that red soldermask is more photogenic than purple...

View attachment 355505
View attachment 355506

Thanks to @Bigdaddyale for the pcb from his batch of boards.
Populated the board, plugged it in, tweaked the pot and it's up and running.
Easy peasy...

Cheers!

If anybody is interested in getting a board send me a PM. I have a few extras available.

 

[obsi]

Hi Bigdaddyale. Just tried to PM you and got the message "Bigdaddyale has chosen not to receive private messages or may not be allowed to receive private messages. Therefore you may not send your message to him/her."

 

[Ben58]

If anybody is interested in getting a board send me a PM. I have a few extras available.

I'd be in for one.

 

[obsi]

What if you unplug the load from the SSR-controlled outlets? Do you still get scrambling when you toggle the SSRs?

I'll have to do some experiments to determine the answer to this.

 

[Asmodeus]

I'll have to do some experiments to determine the answer to this.

I ran my setup (i2c, rotary encoder, sainsmart relays, 230v, lrd dimmer) for at least two weeks without fridge or heater connected and there was no scrambling. When I plugged in the fridge and the heater, scramling occured, and I have seen the scrambling kick in when cooling was activated firsthand. I remedied that (kinda) by a reset of the display every second minute (new code to the arduino).

Regards /A

 

[Arminius757]

Anyway we could get a full recap posted somewhere with all the design changes and tweeks? I saw this project and I am very interested, been through about a dozen pages and I am getting a little lost as to what is going on in terms of changes being made. Also, those prebuilt boards look great! Would simplify this all down quite some for someone like me who is only a novice when it comes to playing with electronics.

 

[day_trippr]

Now that the @cadibrewer layout has been fairly well vetted (I have two instances running myself) I recommend anyone contemplating this to hook up with someone who has extra pc boards available. There are currently at least two folks here (cue @bigdaddyale) that should have extras and I'm sure they'd be happy to part with them for an agreeable figure.

Anyway, this is the latest schematic


And if one followed my protoshield build, here's the connectivity to/from the shield to everything else.


Top-side component placement


Headers and components installed


First set of wires added


Second set of wires added


Third set of wires attached


Last set of wires attached


Adding the BSS84 P-FET
Remove connection:


Install BSS84 to back of board


Cheers!

 

[Bigdaddyale]

Let me know if you're interested- I have 7 boards available.

 

[Mikmonken]

Any of you guys with the spare boards based in the UK by any chance?

 

[colenz]

I'm interested in a CadiBrewer Board. I'm in New Zealand. Are there any bugs in the design? Anyone getting any scrambling issues at all under any condition? and Is it both stable for the standard relay board and the SSR relays?

 

[SvErD]

Let me know if you're interested- I have 7 boards available.

I'm intrested in one or two boards if you ship international.