BrewPi: Scrambled Screens?

Homebrew Talk - Beer, Wine, Mead, & Cider Brewing Discussion Forum

Help Support Homebrew Talk - Beer, Wine, Mead, & Cider Brewing Discussion Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.

How long on average before your screen scrambles?

  • One Hour

    Votes: 0 0.0%
  • One Day

    Votes: 0 0.0%
  • One Week

    Votes: 0 0.0%
  • One Month

    Votes: 0 0.0%

  • Total voters
    3

LBussy

A Cunning Linguist
HBT Supporter
Joined
Jan 19, 2013
Messages
4,271
Reaction score
1,874
Location
Doo-Dah
Since I'm going to be releasing a new version of the firmware here imminently, I wanted to poll everyone on how often they seem to be getting the screen scrambles. Our own resident EE @day_trippr seems to have ruled out pretty much everything but shag carpeting and sunspots. It's apparently something we have to live with.

The way I understand it, it's not horrible but gets worse over time so I've put in a screen reset on a timer that should clear it out. I've never (knock on wood) had the issue myself, so I wanted to get an idea how often it happened to everyone else.

Please choose the answer that best describes the average frequency at which your screen is noticed to scramble. If you want to add notes, well, pretty sure you know how to do that. :)
 
In version 0.2.11 the screen resets every 15 minutes right now. I think that's way too frequent.

I have a setup next to me on my desk and I notice it flashing on and off. The backlight turns on briefly when it resets as well. My (perhaps flawed) thinking is that there's a finite life on that part and I want to reduce how many times I cycle it. Even if it does not have a finite life, it bothers me when it flashes because I think the controller reset and I have to look and see if it crashed. :)
 
fwiw...I have four BrewPi Bluetooth minions sporting 20x4 4-bit parallel screens, and rarely get a scramble (but I've seen it ;)).

I've always suspected putting the power supply for the Arduino on the same cable that supplies the AC power to the relays (and thus to a compressor) leaves it vulnerable to the inductive thump starting said compressor propagating through the supply. There are lots of ways to screw up logic and a good one is to throw a voltage spike at VDD.

On my minions I used the heaviest AC power cables I could find for the input side and avoid extension cords for the fridges on the switched side...

Cheers!
 
fwiw...I have four BrewPi Bluetooth minions sporting 20x4 4-bit parallel screens, and rarely get a scramble (but I've seen it ;)).

I've always suspected putting the power supply for the Arduino on the same cable that supplies the AC power to the relays (and thus to a compressor) leaves it vulnerable to the inductive thump starting said compressor propagating through the supply. There are lots of ways to screw up logic and a good one is to throw a voltage spike at VDD.

On my minions I used the heaviest AC power cables I could find for the input side and avoid extension cords for the fridges on the switched side...

Cheers!
Actually my setup has the power supply for the controller and ESP running off the same AC that supplies the relays. I have not noticed issues yet but I have not actually had it running under a test batch. (Planning soon).
Maybe I should switch to a dedicated AC line for my PSU.

I also wonder if the scramble has to do with the LCD quality during the manufacturing process or the version of firmware on the LCD microcontroller? Is there multiple versions of this LCD? Better versions?



-M
 
I doubt it’s the LCD. That’s just a garbage in, garbage never goes away thing. If it were the LCD it would be reproducible by folks without load and I’m not sure that’s ever happened.
 
Not sure I follow that logic as the LCD typically sources all power and gnds from the Uno.

It comes down to which element is most susceptible, and because it's no small task to write characters to the LCD via the shift register it's pretty unlikely the root fault is external to the LCD. And whenever I've noticed a scrambled screen on one of my three chambers the minion is still holding temperature and in communication with the web host.

So I believe it's the LCD that gets its brains internally scrambled while the Uno cruises along blissfully unaware that anything happened.

fwiw, the test minion on my desktop has no loads to switch and it never scrambles when relays switch...

Cheers!
 
Not sure I follow that logic as the LCD typically sources all power and gnds from the Uno.
Well, the pics I've seen have been random "stuff" but vaguely "character-based" as in it looked like components of letters or symbols. Therefore my assumption was an erroneous signal that was received and rendered. Hopefully that makes sense. Might be that what I saw was not common too.
 
I doubt it’s the LCD. That’s just a garbage in, garbage never goes away thing. If it were the LCD it would be reproducible by folks without load and I’m not sure that’s ever happened.
I guess what I'm saying is the quality of the components of the screen can't handle this kind of circuit? Like maybe their is something happening in the controller or the relay switching that a well made or a diffren LCD architecture would not be affected by... maybe these cheaper ones can't filter it or buffer it out..
Also is has anyone hooked a scope up to the input side of the LCD and watched for changes in behavior when the scramble shows up (prob someone has)?
Also, I'm wondering if there are grounding loops going on? Not that I know lots about Ground loops, but I do remember back in the day I had this HDD player in my car (OMNIFI) and if the player did not have it's own ground wire. It would garble and scramble. The owners manual specified to use a dedicated ground to avoid poor ground and possible ground loops, and damage would occur to LCD..
Just a few ideas.
 
I know one person here had the ability to diagnose it. I believe the issue is that he was unable to reproduce it in the manner that affects the afflicted.
 
I apologize if this has been answered elsewhere, but is the LCD reset timing a configurable option? After getting my system assembled, it seems like I'm getting frequent strange characters that must be related to load switching because it ran fine without loads connected. Reading through some posts it appeared to be set by config.h, but is this already compiled into the .hex file? (Sorry for a naive question -- I'm using this project to learn about the Pi and microcontrollers). Have there been other solutions to the strange characters implemented? Thanks for your help!
 
The LCD reset timer is hard-coded to 3600 seconds (one hour) in line 109 of config.h:

https://github.com/brewpi-remix/bre...305b1c4a198c7a092b/include/Config.h#L104-L112If you are getting scrambling that makes that not frequent enough, I'm wondering about your setup. Is it possible you have wires wrapped around each other in your project box?

Yes, that can be changed and recompiled, but I think that's going to be hiding another issue.
 
Dear Lee,

Thank you for your reply. I totally agree that there was a more fundamental problem to tackle. I have a lot of space in the enclosure to reroute lines, but I was worried that it still might not work so I thought I'd enquire. After your note I reroute the power lines and buried them below the relay board and away from the back of the display board. Seems to be working much better now! Thanks for all your help and efforts on this project -- it's been fun for me to put together a 3-unit system and dig into the electronics a bit. Cheers!

Jim
 
Glad it's working better for you. Yes, those wires lying next to each other are evil ... it's very easy to generate spikes in the next.
 

Latest posts

Back
Top