One pixel offset

[MattDahEpic]

Hello!

I've just assembled a transit tracker and have a question about the offset of the letters on the screen. It seems like display wraps and is offset one pixel to the right, in the example image below it seems like the rightmost edge of the "n" in "min" has wrapped around onto the left just before the 1 of "1 Line".

It also appears directional, when flipping the device over it takes the leftmost column of the 1 Line 1 and puts them to the right of the time.

[tjhorner]

That's very strange, definitely not supposed to happen. Where did you buy the displays? I'm thinking it might either be faulty or use a different communication protocol.

I would be interested to see what happens if you swap the displays.

[tjhorner]

ESPHome Builder should be fine.

Can you send a photo of the back of one of the displays? Make sure there is good lighting and it's high-res, I want to check for differences on the PCB vs the Waveshare displays.

And just to confirm, did you try these specific combinations?

# 1.
clock_phase: true

# 2.
shift_driver: FM6124

# 3.
clock_phase: true
shift_driver: FM6124

# 4. (Even though it *should* be false by default, just in case)
clock_phase: false

Another thing I would like to try is using the external HUB75 component from before ESPHome had one built-in. Change the ref you're using for the package to this commit: d74e1eb7805e82db030aa3a50b096ec6b4948ee0.

If we aren't able to get it working using the display options then there might be some hacky way to offset the pixel mapping in the firmware so we can manually shift it back.

(Or if you're fed up with all the troubleshooting you could return the AliExpress displays and buy the Waveshare ones on Amazon, I wouldn't blame you 😛)

[MattDahEpic]

Here's a picture of the back of one of the panels. Apologies as my phone camera sucks but I tried to get all the writing on the chips at least mostly readable. I'm happy to get closer pictures of specific areas or transcribe screen printing if needed.

I've tried all 4 of those combinations. Options 1 and 4 had no change while options 2 and 3 just showed that "HUB75: flip_buffer() called but DMA not initialized" error in the logs

The external hub75 component with no additional changes did not work.

Thank you very much for your continued assistance!

[tjhorner]

When switching to FM6124, do you see "Failed to initialize DMA engine" or "Shift driver initialization failed" in the logs? They will be pretty early during initialization so you might need to see them via USB.

The photo's good enough that I can see the driver chips are marked SM16238S. I wasn't able to find any detailed datasheet, but based on the pin diagram it looks like a clone of an FM6124-compatible chip. No obvious differences from what I can tell.

One last thing I would like to try is a simple "hello world" example without all the additional components from the base firmware, just to rule those out as causing the issue. (I don't expect they are, but you never know...)

Try this:

esphome:
  name: transit-tracker-test

esp32:
  variant: esp32s3
  flash_size: 8MB
  framework:
    type: esp-idf

logger:
  level: DEBUG

display:
  - platform: hub75
    id: matrix
    board: adafruit-matrix-portal-s3
    double_buffer: true
    update_interval: 32ms
    panel_width: 64
    panel_height: 32
    layout_cols: 2
    g1_pin: 40
    b1_pin: 41
    g2_pin: 37
    b2_pin: 39
    e_pin: 21
    brightness: 255
    pages:
      - id: test_page
        lambda: |-
          it.print(0, 0, id(pixolletta), "Hello, world!");

font:
  - file: "https://github.com/EastsideUrbanism/transit-tracker/raw/refs/heads/main/firmware/fonts/Pixolletta8px.ttf"
    id: pixolletta
    size: 10
    glyphs:
      - abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789.,:;!?()"'-+/*=%@#[]{}<>|&^~
      - ÄËÏÖÜÉÈÔäëïöüéèôŊŋÁÊÎÛÝáêîûýĜĝÀÌÒàìòÑñÍÓÚíóúÇçĆČĐŠŽćčđšžÙùÕõŞŁŇŘşłňřÅåØøĀĒĪŌŪāēīōūÂâĞğıĎĚŤŮďěťůÆæIJijŒœÐðŸÿßŐŰőűÞþÃãĂĔĬŎŬăĕĭŏŭĨŨĩũĄĘŃŚŻąęńśżĖėĢĶĻŅģķļņĮŲįųŔŹŕźĊĠċġħŜŝŢţŦŧŴŵŶŷĹĽĺľİ
      - " "

And, just to be thorough, maybe try with some permutations of these options:

clock_speed: 10MHZ  # <— we haven't tried clock speed yet
latch_blanking: 4
brightness: 128

I briefly looked into how it might be possible to implement a global offset for display rendering so that we can shift all the pixels back by one column, and while possible, it seems non-trivial. It might be best implemented as an external component which wraps an existing display, intercepts the draw calls to it, and re-issues them with the offsets applied.

I ordered two of the displays from the AliExpress listing you linked earlier so I can do some additional research on what makes these different, because now I'm really intrigued as to what could be going wrong. It would be good to document and account for the quirks of these various display vendors.

[MattDahEpic]

Installing the Hello world program resulted in the same issue but adding just the clock_speed seems to work! Maybe these screens are just put together worse than the Waveshare ones and can't handle the full 20MHZ speed. For completeness I also checked the 16MHZ option and it works too, so somewhere in those last 4MHZ it starts failing.

display:
  - platform: hub75
    id: !extend matrix
    clock_speed: 16MHZ

Thank you so much for your assistance on this! I wouldn't have known where to start.

[tjhorner]

Oh that's great to hear! Happy to help.