Waveshare 1.5in OLED SSD1351 intermittent issues

[cobraPA]

Firstly thanks for taking the time to file an issue. Chances are, you are not the first (and wont be the last) to have this problem: By creating a public issue, others can browse and solve their issues - possibly in a self-service style - just by reading the discourse on your ticket, so try and be clear in the describing the problem you have.

Secondly, github issues are not just for raising problems - if you have a question, a documentation fix, or suggested improvement, please get in touch.

Lastly, there are a number of related LUMA projects - please check to make sure to create the issue in the right GitHub repository.

The module I have been trying out is a Waveshare 1.5in OLED 128x128 unit. Available from USA Amazon here: https://www.amazon.com/gp/product/B07D9NVJPZ/ref=oh_aui_search_detailpage?ie=UTF8&psc=1 Also, Waveshare documents are available from: Wiki : www.waveshare.com/wiki/1.5inch_RGB_OLED_Module

Type of Raspberry Pi

Not all Pi's are equal at the hardware level - what works on one, might not work on the next. This library has been tested on every variant except the RPi3.

Currently testing on Pi 3B+

Linux Kernel version

Paste in the output from running uname -a at the command line on your Pi.

uname -a Linux raspberrypi 4.14.52-v7+ #1123 SMP Wed Jun 27 17:35:49 BST 2018 armv7l GNU/Linux

Expected behaviour

Add a few concise notes about what you are expecting to happen. Even better, if you paste in a code sample that demonstrates what you want to achieve.

I've been trying out the SSD1351 luma.oled driver in some python code for testing, but seeing intermittent results. I believe I've worked through all the wiring and setup issues, and the module is sometimes working properly. But then other times it will not display anything, or the display will display junk.

I have some local code that works at times, then does nothing sometimes, so I went back to the demos. For example, the invaders.py seems to work perfectly at times, filling the display and animating properly. But other times it is half size, corrupted, or black display with nothing.

I am running it with: python invaders.py -d ssd1351 -i spi --height 128 output: Version: luma.oled 2.4.1 (luma.core 1.7.2) Display: ssd1351 Interface: spi Dimensions: 128 x 128

My module is wired as 4-wire SPI.

Actual behaviour

Now add some details about what actually happened - if there is an unexpected crash, paste in the traceback info.

I also tried the Waveshare demo code linked in their documentation above. I thought maybe the display or wiring was bad, even though it sometimes works correctly. But when using the Waveshare demo, called main.py in their sample download, the display always seems to work.

This makes me think the luma.oled ssd1351 driver has an initialization problem. I have not reviewed both sets of code to determine differences, but wanted to post some details in case others struggle with this display as I have been.

[cobraPA]

Pictures of module:

[rm-hull]

Away on vacation at the moment, but I'll investigate further next week when I'm back

[rm-hull]

I would say though, try reducing the SPI speed to see if you get more stable results

[cobraPA]

I halved the default speed (8MHz) and tried something slower, like 5MHz. It didn't seem to make a difference when the behavior was bad. I will do some more testing when I get a chance. I am suspicious there may be a power issue also. But when I wrote this report, the demo code from waveshare was 100% in multiple tries, and the luma demo's were not.

[cobraPA]

I've tested this display with luma some more and I believe my issues where either power or the module connector issues. Using shorter USB cables and making sure the supplied connector for the waveshare board is fully seated has made display reliable again. I'm going to close this issue.

[Querela]

Hello, I'm currently using the same OLED display. The luma.oled code did not work for me but everything worked fine with the waveshare initialization. I looked a little bit into the source and found that waveshare did send some additional initialization bytes. Since it was not fully documented, I'm not sure what all of those mean. Additionally they defined some constants but did not use them but wrote the numbers directly ... :(

The Waveshares demo code is here: https://www.waveshare.com/wiki/1.5inch_RGB_OLED_Module
It is the SSD1351 display.

waveshare:

# spi config?
SPI = spidev.SpiDev(0, 0)
SPI.max_speed_hz = 9000000  # luma.oled would fail here with its assert
SPI.mode = 0b00

# initialization
def Device_Init():
    OLED_CS(0)
    OLED_RST(0)
    Delay(500)  # half a second?
    OLED_RST(1)
    Delay(500)

    Write_Command(SSD1351_CMD_COMMANDLOCK)
    Write_Data(0x12)
    Write_Command(SSD1351_CMD_COMMANDLOCK)
    Write_Data(0xB1)

    # >>> from here compareable to luma.oled ?
    Write_Command(SSD1351_CMD_DISPLAYOFF)
    # SSD1351_CMD_DISPLAYALLOFF
    Write_Command(0xa4) # Normal Display mode (-> SSD1351_CMD_NORMALDISPLAY ?)

    # SSD1351_CMD_SETCOLUMN
    Write_Command(0x15) # set column address
    Write_Data(0x00)    # column address start 00
    Write_Data(0x7f)    # column address end 95
    # SSD1351_CMD_SETROW
    Write_Command(0x75) # set row address
    Write_Data(0x00)    # row address start 00
    Write_Data(0x7f)    # row address end 63

    # SSD1351_CMD_CLOCKDIV
    Write_Command(0xB3)
    Write_Data(0xF1)

    # SSD1351_CMD_MUXRATIO
    Write_Command(0xCA)
    Write_Data(0x7F)

    # SSD1351_CMD_SETREMAP
    Write_Command(0xa0) # set re-map & data format
    Write_Data(0x74)    # Horizontal address increment

    # SSD1351_CMD_STARTLINE
    Write_Command(0xa1) # set display start line
    Write_Data(0x00)    # start 00 line

    # SSD1351_CMD_DISPLAYOFFSET
    Write_Command(0xa2) # set display offset
    Write_Data(0x00)

    # SSD1351_CMD_FUNCTIONSELECT
    Write_Command(0xAB)
    # ?
    Write_Command(0x01)

    # SSD1351_CMD_SETVSL
    Write_Command(0xB4)
    Write_Data(0xA0)
    Write_Data(0xB5)
    Write_Data(0x55)

    # SSD1351_CMD_CONTRASTABC
    Write_Command(0xC1)
    Write_Data(0xC8)
    Write_Data(0x80)
    Write_Data(0xC0)

    # SSD1351_CMD_CONTRASTMASTER
    Write_Command(0xC7)
    Write_Data(0x0F)

    # SSD1351_CMD_PRECHARGE
    Write_Command(0xB1)
    Write_Data(0x32)

    # SSD1351_CMD_DISPLAYENHANCE
    Write_Command(0xB2)
    Write_Data(0xA4)
    Write_Data(0x00)
    Write_Data(0x00)

    # SSD1351_CMD_PRECHARGELEVEL
    Write_Command(0xBB)
    Write_Data(0x17)

    # SSD1351_CMD_PRECHARGE2
    Write_Command(0xB6)
    Write_Data(0x01)

    # SSD1351_CMD_VCOMH
    Write_Command(0xBE)
    Write_Data(0x05)

    # SSD1351_CMD_NORMALDISPLAY
    Write_Command(0xA6)

    Clear_Screen()
    # SSD1351_CMD_DISPLAYON
    Write_Command(0xAF)

luma.oled:

    def _init_sequence(self):
        self.command(
            0xAE,        # Display off
            0xA0, 0x72,  # Seg remap
            0xA1, 0x00,  # Set Display start line
            0xA2, 0x00,  # Set display offset
            0xA4,        # Normal display
            0xA8, 0x3F,  # Set multiplex
            0xAD, 0x8E,  # Master configure
            0xB0, 0x0B,  # Power save mode
            0xB1, 0x74,  # Phase12 period
            0xB3, 0xD0,  # Clock divider
            0x8A, 0x80,  # Set precharge speed A
            0x8B, 0x80,  # Set precharge speed B
            0x8C, 0x80,  # Set precharge speed C
            0xBB, 0x3E,  # Set pre-charge voltage
            0xBE, 0x3E,  # Set voltage
            0x87, 0x0F)  # Master current control

There is either another firmware on the chip or something else ... Not really sure.

I would like to use luma.oled but my display isn't even reacting ...