Help with display and RasPi not "working"

Yes, I know I had a lot of fun getting the software installed/working.

It is now, but there is another problem.

The display is getting corrupted with messages when I send it messages.

I can’t show you a GOOD display picture as it gets corrupted too quickly for my webcam to take a picture in time.

Here are two which show what is happening.

The second one is better, but you can see how the time is corrupted.

I am suspicious - but not certain - it is the I2C bus and interference from the big ribbon cable which is used to connect the RasPi and the display.

WHY THE RIBBON CABLE!!?? I hear you ask.

Well, it is still kind of in prototype mode, and it also negates the need to solder wires.
There are going to be a heap of buttons on it in the future too.

Thoughts on if it could be needing pull up resistors on the I2C bus?
I think they would be 4k7, but am not 100% sure.

And they would go to the 3.3v rail. NOT the 5v.

Hi Andrew :slight_smile:

Hmm, doesn’t look like anything is corrupted to me - those are all nice clear digits. I suspect this is an issue with the draw order on the LCD.

I’m guessing you’ve got the clock setup to scroll across the screen left to right? I suspect what’s happening is you’re telling the LCD to draw a character, but you’re not telling it to get rid of it. Computers are very dumb, and they’ll do exactly what you tell them but no more!

I bet if you add a space character " " at the end of your clock/time string to wipe out whatever is in the last cell it’ll fix your issue.

Ollie :slight_smile:

I say corrupted and that is a bad use of the word, but I am at a loss how to better describe it.

The clock is only supposed to be shown at a static place on the display.
(Basically a wrist watch)

The time/date update in place every second.

Just that now and then the positioning information is corrupted and it is put at/on the wrong place on the display.

I am only thinking it is the I2C bus as that is the only thing connecting the two together.

I have had similar problems with an Arduino project years ago and I had to add pull up resistors on its I1C bus to fix the problem.

Though that wasn’t regarding a display. But still…

Any other messages to be displayed would be sent as needed.
All messages are send with an x/y position on the screen where they are to be up.

IF the message going down the I2C bus is corrupted (to give it a word) the address and sometimes character would be different.

I’ve seen strange characters appear on the display now and then as well.
So it kind of backs up that theory.

But I am still only guessing.

Can you share your code?

Preferably strip it right back to the basics for displaying info on your LCD and see if the problem persists. I’m still banking on this being an alogrithm/logic issue rather than a wiring/interference issue. It looks like a pretty short cable, and soldered connections look satisfactory at first glance.

Um, yeah, but it isn’t “code” as such. I am using Node-Red to do it, so it is not quite that easy.

Basically these are the messages sent:
This is sent daily.


As is this:


And this is sent every second:


That is sent to a python script which is this:

#  Imports
##  This must be the first line.

from __future__ import print_function
import sys
import os
import time
import paho.mqtt.client as mqtt
import qwiic_serlcd

def on_connect(client, userdata, flags, rc):
    print("Connected:", rc)
    client.subscribe("alarm_clock/#", 0)

def on_subscribe(client, userdata, mid, granted_qos):
    print ('Subscribed:', userdata, mid, granted_qos)
    print ('We are here, waiting for commands...')

def on_message(client, userdata, msg):
    global abort
    if msg.payload.decode("utf-8") == 'Heartbeat':
        client.publish("alarm_clock/response", "Script is alive")

    if (msg.topic == "alarm_clock/ctl"):
        if msg.payload.decode("utf-8") == 'Stop':
            print ("Script terminates..")
            client.publish("alarm_clock/response", "Script is stopping")
            abort = True
##  Now put other commands here.
        if (msg.payload.decode("utf-8") == 'CLS'):
            myLCD.clearScreen() # clear the screen - this moves the cursor to the home position as well
        ###  Also need contrasts adjustments in here.
        #  work needed on backlight stuff.  Not touched for now
        x = msg.payload.decode("utf-8")
        y = x.split(":")
        if (y[0] == 'BKL-ADJ'):
            print ("=============")
            print (y[1])
            colours = "("+y[1]
            colours = y[1].split(",")
            print (colours)
            print ("R ",colours[0])
            print ("G ",colours[1])
            print ("B ",colours[2])

        if (msg.payload.decode("utf-8") == 'BKL-ON'):
            print("Backlight On")
        if (msg.payload.decode("utf-8") == 'BKL-OFF'):
            print("Backlight Off")
        #  done
        if (msg.payload.decode("UTF-8") == 'BLK-OFF'):
            print("Blink Off")
        if (msg.payload.decode("UTF-8") == 'BLK-ON'):
            print("Blink On")
        #  done
        if (msg.payload.decode("UTF-8") == 'C-ON'):
            print("Cursor On")
        if (msg.payload.decode("UTF-8") == 'C-OFF'):
            print("Cursor Off")
        if (msg.payload.decode("UTF-8") == 'D-OFF'):
            print("Display Off")
        if (msg.payload.decode("UTF-8") == 'D-ON'):
            print("Display On")

#  Text part
    if (msg.topic == "alarm_clock/text"):
        txt = msg.payload.decode("utf-8")
        print ("=============")
        print (txt)
            text = txt.split("@")
            print ("Text to display is ",text[1])
            print ("Raw co-ordinates are ",text[0])
            print ("=============")
            cord = text[1].split(",")
            print ("X ",cord[0])
            print ("Y ",cord[1])
            x = int(cord[0])
            y = int(cord[1])

# inits
myLCD = qwiic_serlcd.QwiicSerlcd()
mqtt_broker = ""
mqtt_port = 1883
abort = False
client = mqtt.Mosquitto()
client.on_connect = on_connect
client.on_message = on_message
client.on_subscribe = on_subscribe
resp = client.connect(mqtt_broker, mqtt_port, 60)

while abort == False:

del client
print ('Script has terminated')

and it should all work.

SHOULD being the operative word.

Did I miss anything you need?

Oh, and this is a good screen picture of what it should look like - all things being good.

With the time being updated every second.

1 Like

Why are you using a try except - if you get an error and it runs the except code it won’t set an X,Y location and will just write to the screen wherever it was up to last - and then write over the top at a later time and date.

Do you always print it to the same location - if so, why not hardcode the XY coordinates locally?

What happens if your time command arrives while the screen is still updating - will it lose some of the command? Is the LCD library blocking or non-blocking code? (see: What is non-blocking or asynchronous I/O in Node.js? - Stack Overflow )

TBH, I didn’t write that code.

But that may be what is the problem.


Because as you saw I am sending three messages to the screen - now.

There will be more when alarms are on/active/set/what ever and other things happening which I haven’t yet done.

This is just above the base line to get things working.

I am now not sure if I should ask the person who wrote the code for help or what…

That stuff is way beyond me at this stage. I was stuck and the person wrote the basic idea for me and I accept that it isn’t/wasn’t exactly explained at first asking.

This is code modified from something else I think and the LCD stuff got put on to it.

But what you have said would go a long way to explain what is going on.

Greatly appreciated.

So, now the dumb question: would you mind helping me get my head around this?
the other person is half way around the world and the timezone thing makes for difficult interactions.

(The display is now quite populated with incorrect stuff. I’d take a picture but I don’t think it would really achieve much)

How could I make the except part just drop the message?

That way if I see it skipping seconds now and then I would know that is the cause!
(Actually I could just make it change the text to a message and see how often that comes up …)


1 Like


I did that (changed the code) and got an indication that is the problem.

Ok. Now I need to go and study what is going on with that part of the code.

But as a quick and easy way out:

How could I just exit and do nothing if that condition is true?
So: rather than print something, it just … exits… ?

1 Like

Um, looking at what you said…

I kind of get it, but kind of don’t.

Here’s why:

Node-Red is sending the messages to the python script.
It is then talking to the LCD.

If Node-Red is sync/async isn’t a problem.

It is more if the code I have and/or the LCD can handle the messages coming in on top of each other.

Is that right?


Ought to do it I think? That way if you get an incomplete string for some reason it just won’t try to write it, and the next time a fully formed string comes in (or at least one that can be split at the @ symbol) it will write the string to the display.

So worst case it’ll just miss a few seconds - though if you’re trying to make a clock, it may be better to run a timer locally and just sync it every few minutes rather than sending a time string every second. Depends what your end goal is really - I presume displaying the time is just a first step towards something else.

One way or another, there is an error occurring in this code:

            text = txt.split("@")
            print ("Text to display is ",text[1])
            print ("Raw co-ordinates are ",text[0])
            print ("=============")
            cord = text[1].split(",")
            print ("X ",cord[0])
            print ("Y ",cord[1])
            x = int(cord[0])
            y = int(cord[1])

Whether it’s a malformed string being sent by NodeRed, or an incomplete string being received/read by your python script is yet to be determined - it’ll take some more testing and debugging to figure out exactly what’s going on.

1 Like

Thanks. The PASS bit threw me.

I put a print("We have a problem") - which is only for the sake of having a line.
It isn’t sent to the LCD.

But I’ll change it to pass now.

That may be all I really need.

It isn’t crucial that every message gets through - at this stage.

Though I know that is going to come back and bite me soon.
Maybe I should put code in there (where the pass is going) and send back a message saying something like: “Message not received” and that way the other part will know and either resend it or what ever…

But that has gone a long way to fixing the problem it would seem…

Spoke too soon.

Though not conclusive: I just got a little mui (micro) character after the seconds on the display.

Further investigations to happen.

1 Like

Now that’s interesting! That’s more like data corruption - but it’s almost certainly not an issue with the display or the wiring, it’s an issue with the data being sent to the display.

Yeah, but Mr Murphy may have his hand in things.

I think a longer time frame needs to be used to see if this continues to happen or it was just … something that happened.

Although that is true to need follow up, if it isn’t a real thing… how much effort needs to be put into fixing it?

(Sort of rhetorical)

But I’ll hook it up to a supply and let it run for a few hours and see what happens.


Ok, getting the mui characters after the time.

Now to work out how to find out when they happen.

Very infrequently.

Could be because I have been doing other things on the RasPi ITMT too.


Hi Andrew,

Very strange… Apparently the UTF-8 for mu is 0xCE 0xBC so looking for numbers or data you’re sending that is similar to that could be something to try, not sure why the end of your time string would trigger problems like that though…

No mu in your serial log?


1 Like

Where would I see the serial log?

Apologies, I skimmed over the code and read this as a debug statement rather than assembling a string, If you’ve got any way to output your string in a console that’d be my next bet, to see if the mu is somehow in the code, or is just an artifact on the display

1 Like

Yeah, no problems.

I am thinking of doing that, but don’t have the python skill set to write to a file.

(Or open one for that matter)

I am trying to work out how to simulate sending that kind of code to the display to see what it does.

Just to get a base line if that is what is happening.

Though - of course - having a log of what is being sent to the display would be just so much better.

1 Like

Forgive me for asking, but that code you said… 0xBC or 0xCE… When I look up the ASCII table for mui it is 0xE6.

No problem.

I’m guessing you got that code from the table for this display?

If it isn’t too much to ask: do you have a link for it?

That way I can send it all kinds of codes and see what happens and not be confused if what I see isn’t matching the ASCII table I used just now.

1 Like

Update to things:

Changing the python code has reduced the frequency the weird thing happen.

But it hasn’t stopped it.

I have written code to capture both messages (the one sent to the script and the one sent back from the script) and that isn’t being invoked as much as I would like.

But these extraneous letters are still happening.


They seem kind of consistent in where they are and what they are.

Usually I am getting the divide by symbol (the old school one) and the mui symbol after they time.

I dug up my digital camera and am taking piccies.
When I get a few I will post them here for outside checking.