More questions on the 20 x 4 RGB display

The display:

SKU: LCD-14074

Trying to get things working better, I was wondering:
I am using the I2C bus to talk to it and I am getting weird characters which some people say could be hardware timing problems.

But the display also has a “comm port” input too.

So I guess I could try sending the display the messages that way rather than via the I2C bus.

I have read that it is default 9600 baud.

But I am having no luck getting the RasPi GPIO comm port working.
I know they (the comm pins) are pins 8 and 10.

But that is where I am stuck.

Could someone help me with this - please?

Ok, update:
I believe I have it working.

Now I am wanting help on where I can get the commands I can use with the serial port.
All I can find is how to use it with QWIIRC (or what ever it is called) language.

I’m too stupid to know if those command would work if sent in/on/with the comms port.


Hey Andrew,

Just to confirm, this was the display you’re referring to?

There’s a brilliant video by Electronoobs explaining the basics of Serial communication protocols and conveniently, this SerLCD can actually use any one of the three.

The main takeaway that we’re concerned with is that I2C and SPI are synchronized protocols, meaning that there’s a line used as a clock that is shared between the two so you don’t need to worry most of the time what the bit-rate is.

9600 baud is the typical bit rate for UART which stands for Universal Asynchronous Reciever-Transmitter which as can be guessed, is asynchronous, meaning that both the transmitter and reciever have their own separate clocks which must both be close enough to precise so that you don’t get misreads.

QWIIC is Sparkfun’s version of the 4-pin JST-SH (Japan’s Solderless Terminal, SH provides the size and keying) connection, it’ll look similar to this:


Usually, this is used for I2C, so you’ve got shared power and ground, then a shared clock and data line. You can basically ignore this if you’re not using I2C

When you’re connected to pins 8 and 10 I suspect you’re using UART at a 9600 baud rate and hooked up to these pins. Can you send us through a photo of how you’ve got it rigged up, post the code you’re using some ``` above and below it so it looks like this:

# This is example Python
print("Hello World!")


Personally, if you’re getting started with it I’d suggest following the examples where you use I2C with t
the Raspberry Pi in order to communicate with the board. Sparkfun has all their drivers/libraries available on their Repos as well as clear instructions and demo code for how to get it running using I2C:

If you’re set on using UART Serial you may be able to read through the demo code provided for the Arduino boards and then determine which libraries as well as how to compile and run them on your Pi to communicate with this board appropriately, although I2C will almost certainly be much easier to use:

All the best with the project!


Thanks Bryce.

But going on what this thread says…

There MAY be hardware timing problems with the RasPi and the I2C bus with this particular display.

So to prove it (one way or another) I am wanting to use the serial port and see if the problem happens.

Until then the display … works but it isn’t exactly usable with the rogue characters on it.


Hi Andrew,

That thread STRANGE POWER UP CHARACTERS ON SERLCD 20X4 doesn’t seem to refer to a Raspberry Pi or to I2C and is rather a discussion about missing a capacitor to smooth out the power supply to the LCD which is causing noice on the data lines on what I assume is being used for UART.

Was there another thread that you’ve been looking at and accidentally linked this one?

Also, is there any way that you can send through some photos or even a video (easiest way to post it is to generally upload it unlisted to YouTube and share the link here) of how you’ve got it set up and what kind of rogue characters you’re getting?

Depending on the types of rogue characters showing up it may give us some insight as to what is going on by seeing whether their ASCII (or another protocol that is being used) values are similar in binary and this is being caused by noise, or whether it’s a timing issue and bits are being missed/shifted from where they should be.

This video is more just general interest and demonstrates why data being sent via serial communication protocols can be unstable, although if you’re looking to learn more about the topic I’d highly recommend both this and Ben’s channel in general, he gets into some pretty impressive in-depth projects:


Sorry… Wrong link.

It doesn’t help with over 400 tabs open.

Anyway I am trying to now write the clock code to use the serial port - and what a big can of worms that is - and I will test it using that to see if the problem is resolved or not.

I can only try. :wink:

Sorry for the wrong link.


Yes, from what you’ve described it sounds like a desynchronized clock so bits are being misinterpreted when received via UART serial, I’d be surprised if this still occurs while using a synchronized protocol such as I2C or SPI which have that shared clock line I mentioned earlier.

Noise often plays a factor too if the errors you’re getting are inconsistent, so if you’ve got any nearby wiring running near your RxTx I’d suggest moving the wiring around a little to ensure that no currents are getting induced in them (for example if the wiring is coiled up and you’ve got a nearby 230VAC power supply it’s fairly easy to corrupt TTL)


Yeah. The wiring can’t really get much simpler.

There are 4 (well, now 5) wires going from the RasPi to the display.
The 5’th is for testing/trying the comm port.

Status quo I am using the I2C bus and I’m getting weird things on the display.
Semi predictable but … :wink:

So I was pointed to that link… Be it true or otherwise.

I am wanting to try with the comm port and see what happens.

The wire length is… 20cm… the length of the jumper leads I recently bought from you.

I am having a lot of fun (not!) getting the RasPi GPIO serial port working (now done) and writing code to send stuff via the serial port.

Basically just hacking a copy of the working I2C code, just replacing the I2C_library stuff with commport stuff.

But the control characters for the display are tripping me just now.

Sorry Bryce… I have to try things to make sure I’m not flogging a dead horse - if you get what I mean.

And as I want the display to be CLEAN… I can’t have these rogue things popping up on it.

Although the I2C has a shared clock, if the timing on it is off… what happens?
(Semi rhetorical.)
As I said, I was asking on other forums, and that was offered as a possible cause.

1 Like

Good/interesting news.

Last night I got the Python3 script working to talk to the display.

It has been running all night. No weird characters on the screen.

So, it kind of re-enforces the theory that it was bad timing (or something) on the I2C bus.