1.3" OLED

[andrewerrington]

I decided I'd like a slightly bigger display.

I purchased this:
https://m.aliexpress.com/item/4001205659261.html

It is a 1.3" OLED display with SSD1306 driver (same as the original 0.96" display), I2C interface, and 3.3V power supply.

It appears at address 0x3C, so far, so good, but only the top line of the display works, and it's slightly offset. The rest of the screen is just noise.

I'm happy to do some work on this, but if anyone has any obvious suggestions to start with I'd love to hear them.

[sethvoltz]

Hmm, my first guess was that the dimensions pixel dimensions were different as, the way I understand it, the graphics lib just spits out a long sequence of bytes that auto-wrap to create the image. However, the listing claims the same dimensions as expected.

That said, even the first line isn't working there and the text that is working is way off.

[kgutwin]

I'm wondering whether or not you can get it to work with some of the other examples out there?

I found this page which walks you through running some examples from the Adafruit library. Could you test one of these to see if they work?

https://www.raspberrypi-spy.co.uk/2018/04/i2c-oled-display-module-with-raspberry-pi/

[andrewerrington]

Yup. I'm happy to try the OLED test code. Naturally, being lazy, I was hoping for a drop-in replacement. It seems that some of the other 1.3" displays use a different driver chip. It's also possible that the vendor's description was, shall we say, inaccurate.

[sethvoltz]

It's happened before. I would also double check all your wiring. We've seen issues where poorly crimped wired can cause issues with these displays. For my final setup, I ended up crimping all my own ends and soldering a custom socket for the Pi side.

[andrewerrington]

It's not the wiring. I have a 0.96" module which I swapped in and it works (of course).

I've tried a few debugging things, but I think the problem is in the Adafruit driver. I also think the module might have an SH1106 driver, despite the vendor's claim.

I'll try some tests with another SSD1306 driver (not Adafruit) and an SH1106 driver too.

[andrewerrington]

Ok. A little progress, based on random Googling.

In the Adafruit driver there is a class _SSD1306, which has a parameter page_addressing. I forced this to True, because reasons, and I have an interim result.

You can see four pixels of noise in the centre of the display, which is dead memory. The SH1106 chip supports up to 132 pixels wide, but the display itself is 128 pixels. The SSD1306 chip only supports 128 pixels. The generated image is 128 pixels wide, so the last four pixels are never written. Obviously the display should be shifted so that the dead pixels are not visible.

Word on the street is that the SH1106 based displays which have 128 pixels are offset to the "centre". i.e. there is a strip of two pixels to the left and right which we don't see. Other drivers deal with this, but the Adafruit one might not.

[sethvoltz]

I've been considering a switch to a different driver for a number of reasons, but I never went back.

Now that the code has been refactored with the virtual and physical displays being separate, maybe now is the time.

[andrewerrington]

Don't get too excited. It's a cheap hack of which I am not proud, but it shows that the hardware can be made to work:

I don't have any buttons yet, but the OLED display changes mode when I click on the buttons on the web version of the display.

I've posted on the Adafruit webpage for the driver asking about some hints. Hopefully I can make it work in an elegant way.

If you wanted to investigate new drivers I'm not sure what to recommend. I think u8g2 might be a good candidate, but I'm not sure it has been ported to Python.

While you are thinking of that you might consider deprecating RPi.GPIO and moving to gpiozero. I think that is the current best-supported GPIO library.

[andrewerrington]

Also, the show() method should be removed, otherwise screen blanking doesn't work.

def show(self): """Show the currently set image on the screen. """ pass

It's a bit tightly integrated in other code, which I didn't want to mess with.

And GitHub messes up the formatting again.

[slipslyman]

@andrewerrington thanks for the ping on my previous post, hoping you might be able to help here.

i2c detect -y 1 returns an address, either a 3C or 3D, wiring as per Step 3 and the comments section respectively of this https://www.instructables.com/OLED-Tutorial-Convert-SPI-to-I2C/

My particular sh1106 driver oled display is the 6 pin one below so I've done a bit of troubleshooting to check I've not got a simple wiring issue.

I've installed luma.oled as per these instructions, https://luma-oled.readthedocs.io/en/latest/software.html. I can get myself a lovely "hello world" displayed following the example a bit further on in that link.

Thought I was on the home straight at this point, I've modified the micro_panel.py to replace the adafruit library with the luma.oled and removed the show() method as you've outlined above, but now I only get a blank screen. Not even the joy of the garbled static anymore.

I've diff'd your micro_panel.py and the original. The only sections I can see changed to accommodate luma are:

from luma.core.interface.serial import i2c
from luma.core.render import canvas
from luma.oled.device import ssd1306, sh1106
import RPi.GPIO as GPIO
import time

and

    # set up display
    self.serial = i2c(port=1, address=self.i2c_address)
    self.disp = sh1106(self.serial)
    #self.disp = ssd1306(self.serial)

Additionally I've looked through the init.py to see if I missed some other change referencing luma there but no dice.

Admittedly I'm super green to all of this, so for full transparency of where I might be arsing it up, I'm using nano to edit the micro_panel.py hoping that's the correct way. My last suspicion is I haven't installed luma.oled correctly in the oprint environment

[andrewerrington]

Hi there!

The only thing that comes to mind is did you install Luma onto the Pi in the OS, or onto the Pi into Octoprint's environment? Octoprint maintains its own drivers and files independently of the OS-installed ones.

The instructions here tell you how to use pip to install into Octoprint's environment are here:
https://community.octoprint.org/t/octopi-how-to-use-pip-through-ssh/24111

Otherwise, sorry. I suppose one day it might all get packaged up nicely for easy installation.

[slipslyman]

I did end up trying to make sure I had Luma installed in the correct environment.

No success unfortunately. I suspect this is the likely reason though.

Tested my skills and paitence a bit too much and opted for a 3.5" tft display which I miraculously got to work.

Thanks though, definitely pushed me to learn a bit more so still came away with something.

[andrewerrington]

Ok. Cool. If you don't mind, could you start a new discussion with some key points about how you did it (or put them here) so the next person has a head start? No worries if you choose not to (especially as you might be expected to support it) but useful if you do.

[andrewerrington]

I thought I had written a conclusion here, but it does not seem to be present.

I built a four-button board the same size as the ones I have ordered. Everything works as expected.

There are occasional glitches when updating the display, but that could be because the core code is written to use the Adafruit library which may deal with screen updates in a different way.

Going forward I'm not sure what the best approach is. I think the luma.oled library is more versatile than the Adafruit library. Upgrading from one to the other might be tricky though, so maybe a new project could be started, with pretty much the same code, but installs the new library.

Anyway, I'm going to build an enclosure for my screen and buttons and install one each on my two printers. Great project!

[andrewerrington]

And for my own memory I'm planning to use Cat5 Ethernet cable to connect the display board with the Pi. Two reasons for this. Firstly because I don't know where I'm going to put the display and the Pi. And secondly, I couldn't help but notice there are 8 connections.

1 Button 1
2 Button 2
3 +3.3V
4 SCL
5 GND
6 SDA
7 Button 3
8 Button 4

On the display side GND will connect to the OLED display and the common pin for the buttons. As you can see, SCL and GND are on a pair together, and SDA and power are on another pair together, although for the short distances I am planning (about 0.5m) it's probably not an issue.

[kgutwin]

Some quick recommendations from my experience - despite having the panel and Pi close together (about 6 inches) I had a lot of frustrating interference issues, with display glitches and phantom button presses. It seemed particularly tied to certain stepper motors for me (Ender 3). What I did to solve it:

• Split the display and button grounds into two separate wires going to two different GND pins on the Pi.
• Added outboard pull-up resistors on the button lines, as close as possible to the Pi, to make up for the relatively weak internal pull-ups on the Pi’s GPIOs.

I was really worried I was going to need to add shielding or go to more drastic measures to cut down on EMI from the printer, but those two steps seemed to solve it for me. I didn’t try them separately so I can’t say if one was more impactful than the other, unfortunately…

[andrewerrington]

Thanks for that. Things are a little worse with 0.5m Cat5, but it still works. I could try a decoupling capacitor on the display too.

The problem is that I have two different printers, which means two different mounting solutions for the Pi itself and the display. Ideally I'd like the display to be in (or part of) the Pi case, but I haven't looked to see if a single design would work for both printers. Currently both Pis are on the desk tucked away behind the printers.

I've found some mounting designs on Thingiverse but I need to evaluate them. One printer is an Ender 3 V2, the other is a Monoprice Mini.

Sigh. First-world problems.

[sethvoltz]

I was worried about these things as well but I have about a meter of Cat5E and rarely, if ever, see glitching on the display. I2C is a pretty resilient wire protocol. The buttons have had issues, though. Never with false presses but instead not registering clicks. I have to hold them a tick longer than we normally would for a guaranteed hit.

The things I did do were solder all the connections for a rock solid interface and also crimp the Pi ends into a custom connector. I don't have my notes handy but if you'd like more info I can dig it out.

Things I could do to improve this would be decoupling caps and some external pull-ups on the buttons.

[andrewerrington]

I see there is one other person looking for this. What is the best way to proceed?