Display corruption?

All things relating to OLED Screen(s)
G8SEZ
Posts: 52
Joined: Fri Apr 13, 2018 8:26 pm

Display corruption?

Post by G8SEZ » Fri Jul 20, 2018 12:04 pm

I have several Pi-Star devices running on RPi Zero Ws with an MMDVM_HS HAT board, the OLED displays are standard 128x64.

What I notice is that the larger text, scrolling "MMDVM" and static "DMR", often have various small corruptions with pixels either off when they should be on or with odd little lines of a few lit pixels extending vertically from the 'correct' lettering. This is OK after a reboot but gradually corrupts as the uptime increases.

Any idea if this is a hardware issue or is it subtle memory corruption within the MMDVMhost software?

Anyone else see this?
--

Brian G8SEZ

KC6N
Posts: 20
Joined: Mon May 07, 2018 5:07 am

Re: Display corruption?

Post by KC6N » Sat Oct 27, 2018 2:01 pm

I see various types of "corruption" with the 0.96 display (the one from HRO) but it seems to clear up after a while. I see DMR show up in mid screen with info above, below and in the middle of it. Do I have a setting wrong somewhere?

User avatar
VK7HSE
Posts: 172
Joined: Sun Apr 15, 2018 6:35 pm
Contact:

Re: Display corruption?

Post by VK7HSE » Tue Oct 30, 2018 11:17 am

Ensure that you have the display logging set to zero (0) as that's what is the cause for the visual corruption

This is in the expert panel under mmdvmhost Image

Sent from my Pixel 2 XL using Tapatalk


W3WDC
Posts: 7
Joined: Tue Feb 12, 2019 11:54 pm

Re: Display corruption?

Post by W3WDC » Sat Feb 16, 2019 2:25 am

I'm running V4.0.0-RC3 on a MMDVM v1.2 Duplex board on Pi 2B and am also seeing the OLED display corruption. Also saw it on V3.4.17 before I upgraded.

It's fine when no status words in the larger font are displayed: CW TX, Idle, Stopped, -CLOSE- When displayed those status are either pixilated or split in half. It's almost like the font is wrong or the wrong scale. When screen goes standby MMDVM logo goes to top and is displayed normal. When TG status display returns the DMR logo is displayed in the middle of the screen (should be top) with the TG status pushed to top and bottom. Occurs with scroll or no scroll.

Seems to work best with CW ID = 0 , which eliminates the need for CW TX and Idle to be displayed. The only time it goes corrupt is when -CLOSE- or Stopped is displayed. Otherwise "perfect" except I'm not sending a CW ID.

Changing Log | DisplayLevel (and FileLevel) to 0 doesn't change the behavior I'm seeing.

Running V4.0.0-RC3 on a Pi Zero W with MMDVM Simplex with OLED and no corruption there. Perfect displays with or without scroll.

G0OFY
Posts: 6
Joined: Wed Apr 11, 2018 10:20 pm
Location: Crossens, Southport.

Re: Display corruption?

Post by G0OFY » Tue Jun 18, 2019 12:59 pm

Same problem on rpi2 B v1.1with a .96 screen. At switch on MMDVM shows at top of screen and at tx, info displays correctly. If cwtx is on that scrolls from left to right. When idle shows it starts to scroll right to left and the screen pixilates at random and scrolls. On the next tx DMR is showing plus the slot and tg info but it positioned anywhere on the screen.

K9EQ
Posts: 20
Joined: Wed Jan 09, 2019 4:07 am

Re: Display corruption? [solved]

Post by K9EQ » Mon Sep 09, 2019 3:49 pm

This has been bugging me. The 1.3 screen works fine, the 0.96 does not. Here's what's going on.

The 1.3" screen uses the SSD1306 controller. Adafruit uses this controller on all their OLED screens. The (cheap) Chineese OLED screens use an older SSD1106 controller.

Raspberry Pi uses the Adafruit OLED driver software, so Pi-star does also. Naturally Adafruit has no desire to support the SSD1106 as they don't sell anything that uses it. In other words, the standard Pi-star distibution OLED driver doesn't work with the SSD1106 .96" displays.

What's different? The SSD1106 has a slightly smaller refresh RAM array than the SSD1306. That causes each line of pixels to be off by 2 hence small valid text ends up looking like garbage. The graphics still look okay.

The solution is to replace the Adafruit driver with a modified version that supports the SSD1106. The driver is located at /usr/local/lib/ArduiPi_OLED.so.1. I have built a replacement driver with the SSD1106 support.
1. SSH into your Pi-Star (can be done from the Expert screen).
2. Make the disk RW with the command "rpi-rw"
3. Copy the replacement driver to your Raspberry Pi. (I.e., use Filezilla from your Windows PC) And do #3 right after #2 otherwise the disk will revert back to RO.
4. From the SSH console switch to root with "sudo su".
5. Copy the driver file from where you placed it into the above mentioned directory overwriting the existing file.
6. Change the permissions on the driver with the command "chmod 777 /usr/local/lib/ArduiPi_OLED.so.1". (I don't know why '777' '755' should work but the original was '777'.
7. Reboot

Now it might seem like I left out a few steps like where to get the replacement driver. Later today (Monday, 9 Sept 2019) I will post the driver to HamOperator.com. Look under Fusion->Hotspots or use the search function. I'll place more complete instructions there.

Nice, now my 0.96 OLED is working on *all* my hotspots.

73,
Chris, K9EQ

User avatar
KE0FHS
Posts: 1067
Joined: Wed Apr 11, 2018 8:40 pm
Location: Colorado, USA
Contact:

Re: Display corruption?

Post by KE0FHS » Mon Sep 09, 2019 4:52 pm

Just double checking one fundamental thing: have you tried changing the OLED Type setting in the Expert Editor on the MMDVMHost page in the OLED section?
For 0.96", set OLED Type = 3
For 1.3", set OLED Type = 6
Apply changes, and then reboot Pi-Star.
73, Toshen, KE0FHS
Playing with Pi-Star (unofficial notes about setting up and using Pi-Star):
https://amateurradionotes.com/pi-star.htm

K9EQ
Posts: 20
Joined: Wed Jan 09, 2019 4:07 am

Re: Display corruption?

Post by K9EQ » Mon Sep 09, 2019 9:51 pm

You need to set OLED type to 3 for the 0.96" and 6 for the 1.3". You won't see the driver problem if you have a 0.96" display with the SSD1306 controller.

Believe me, I played around with ALL the settings a lot before I downloaded the tools to build the library from source code!

BTW, the driver information is now posted: https://wp.hamoperator.com/?p=1121

73,
Chris, K9EQ

KE7FNS
Posts: 416
Joined: Wed Apr 17, 2019 11:11 pm

Re: Display corruption?

Post by KE7FNS » Tue Sep 10, 2019 6:05 am

K9EQ wrote:
Mon Sep 09, 2019 9:51 pm
Believe me, I played around with ALL the settings a lot before I downloaded the tools to build the library from source code!
Well, normally in the linux community you provide the instructions so someone can do exactly the same as you and build it on their own, and not just a link to download a library.
All views, comments, posts and opinions shared are entirely my own.

K9EQ
Posts: 20
Joined: Wed Jan 09, 2019 4:07 am

Re: Display corruption?

Post by K9EQ » Thu Sep 12, 2019 7:44 pm

The download was provided as a community service so that people would NOT have to:
1. Install the software to build C and C++ programs.
2. Install the necessary libraries.
3. Obtain the source code off of Github
4. Build the code.
5. Test it. (I actually test things I do.)

The point is *ALL* the information is there. I didn't do anything more than document it and post the compiled results. Unlike the Linux community I actually documented what I did for others to benefit from.

I suspect you didn't visit my website where I ACTUALLY POST AND GIVE CREDIT TO the person that did the work on the library. You can follow HIS links to HIS Github repository.

Keep in mind that many people using Hotspots don't care about the "Linux community". They just want their hotspot to work. They don't care about Linux and would prefer not to know anything about the command line. THAT'S WHY I POSTED THE BINARY ALONG WITH SIMPLE INSTRUCTIONS FOR ITS USE!

On a more personal note, I don't think it's a good idea to complain about people trying to do things to make things better. Even if they don't do it the way you would have done it. So I really don't think you have anything to complain about. There's plenty of work that needs to be done, perhaps you should consider undertaking a project or two.

73,
Chris, K9EQ

Post Reply