Problems with OLEDs over time

[FantomXR]

Hey people,

I have some problems with my OLEDs. Technical background: The OLEDs are mounted on a PCB and powered through a stable 5V power supply (they can be powered with 3.3V or 5V). Each OLED has a 1k resistor between RST and VDD and a 10uF cap between RST and VSS.

The OLEDs are triggered by NG. In NG I've added several receivers and senders, which translate sysex-streams into labels. That works very well... but!

I uploaded a picture where you can see the problem. Sometimes after using the MIDIbox for a while I get those errors. I'm really not sure what the problem is. I need to powercycle the midibox, to "reset" the displays. As you can see the whole label gets moved down and it will NOT reset by sending new sysex-events. 

So, do you have an idea? Is it something in the firmware or is it hardware?

Maybe also @TK. can help ;-)

Thanks!!

Best,
Chris

Edited December 2, 2017 by FantomXR

[latigid on]

Hi Chris,

The power-on reset circuit will only do that: hold the display in reset until the power stabilises. What you have looks like a frame shift error. My guess is that the clock signal isn't clean, and that after time data is shifted into the wrong "timespace" of the display. What is the wiring like between the Core and your displays?

Also, please upload your images here or on the wiki so future travellers may see the issues you describe.

Best,
Andy

[FantomXR]

Dear Andy,

thanks for the reply! I uploaded the pictures into the gallery! 

I designed my own core which has only the connectors on board, that I need. The core is connected through a 10cm ribbon cable to the OLEDs-PCB (there are 9 OLEDs on this PCB). The shift register, which is normally on the core PCB I've added to the OLED-PCB so I can save space on the core. The pinout of the connector you can see on the pictures:

OLED-PCB schematic:

 

OLED-PCB layout:

 

Core-layout:

 

Thank you for your help!

[latigid on]

The 595 only provides CS signals (relatively slow) so it's probably not that. Are all displays on the same PCB or is it split across multiple ones? The ribbon cable length seems reasonable. The Core PCB layout could be improved, but I understand the choices given the placement of J30.

Something else I remember is that the Futuresonus Parva had trouble with OLEDs. I think the issue had something to do with loose component tolerances, meaning the displays went out of sync with each other at some point.

You might try adding a manual reset switch. You can test this by briefly connecting the reset pin to ground. Perhaps it could be periodically called from a spare Core pin (would have to code it yourself) or using a timer/oneshot.

[FantomXR]

Dear andy

thanks for the suggestions. 

To answer your questions: on this pcb there are 9 displays and another 6pin-connector on the very right or the pcb. A 10th display is connected through six 0.25 single wires to this 6pin connector pcb. Those have a length of about 35-40cm. 

In the boot loader the number of displays is x=10, y=1 

I need to mention that this effect occurred on the first display as well as on the 10th. All other displays were still running fine. 

[latigid on]

As the "J15" port only supplies 8 CS signals, the others must come from elsewhere. Is there a discrepancy somewhere in the wiring/connectors?

[FantomXR]

Dear Andy,

This should be correct. 8 CS signals come from the 595. The other two come from PC13 and PC14 of the core.

Edited December 2, 2017 by FantomXR

[FantomXR]

Also another strange thing:
Yesterday I had the machine running for about 7h and it occurred at the end... today it happened already a few times.... strange...

[FantomXR]

Meanwhile I think it maybe related to the power supply.... look at this...

The LEDs are powered from a separate power supply. So the OLEDs and LEDs do not share the same....

The powersupply contains of a 19V laptop-supply which than goes into LM2956-module to break it down to 5V. 

[FantomXR]

I pulled the LEDs from the power and now it worked till now. Now the 10th display is "shifted"....

I think I need to test your suggestion regarding connect RST to GND...

Edited December 2, 2017 by FantomXR

[latigid on]

You mention two different power rails, but is the 0V (ground) common to both or do you have separate PCBs? If the LEDs are controlled by the Core, then you might have weird current return paths as the 0V is shared there. Perhaps try to join the 0V rails of the PSUs together, or try using only one PSU.

[Hawkeye]

Hi Chris,

had the same problem with the Programma (24 OLEDs of the same type).
I had the impression, that the length of the signal lines (especially clock) is a problem, installing a small ceramic capacitor (22pf or such) between clock and ground at the OLED at the end of the chain solved a few problems, as well as adding good power supply (3.3v linear vreg), but in the end, buffering might be necessary.

The problem is, that the OLEDs themselves might "talkback" into the data lines and especially the clock line, and the more you have, the worse the signal gets.

TK. recommended buffering to me, when i talked to him about it, and i think he is right (as usual :-)), the problem should go away, if there are only very few OLEDs or you are using very short data wires, or are using termination (like described). Andy also came up with a nice "inline termination" and buffering idea a while back, this will be worth a try and you need not modify anything on the display boards.

An explanation: the long data lines act as kind of "antennas", this also explains why the problem is there on one day, and you have no issues at the other day. Without termination, then part of the signal at the end of the line is bounced back into the line, further degrading the clock signal.

Many greetings,
Peter

[FantomXR]

Hey guys,

thank you so much for your help.

@Andy: You are right: They both share the same GND. This has something to do with the LEDs. Those are WS2812B and they absolutely freak out if they have not the same GND as the core. This is why it's shared.

@Peter: Yes, I'll overwork my powersupply with super-stable-low-ripple-3.3V / 5V (doesn't matter on those OLEDs... they are brighter with 5V though). So, if buffering is the solution, how would the schematic look like? Could you give an advice how such a buffer works? Is there a documentation that I can adapt to my needs?

Thanks!!

Best,
Chris

[Hawkeye]

Hi Chris:

I'd recommend to try out the clock line termination first, with "only" 10 displays it may already solve your problems for good. And you only need a single small cap and can solder that directly to the OLED between CLK and GND.
If you google for "clock line termination" and "ac termination", it is a common problem and addressed by many papers.

Regarding buffering and inline-termination, Andy is the person to ask, he made a circuit for the programma, but we have not tried it out yet.
Many greets,
Peter

[FantomXR]

So to clear it up: You suggest adding a small ceramic cap between CLK and GND and see if the problem is gone? You are right... if that solves the problem, it's the easiest way....

I'll try and report back!
Thanks!!

//edit: I found that note:
https://www.diodes.com/assets/App-Note-Files/AB023.pdf

They suggest values between 50pF and 120pF if I understand it correctly:
AC termination is recommended most for clock applications. An example of AC termination is when a 75? impedance is coupled with a 100pF capacitor. To allow for leakage in input impedance of the receiver, the resistor is selected to be larger than the trace impedance. To allow for rapid transition of the clock edge, the capacitor value is selected at 120pF. A higher capacitor value allows for heavier current levels to pass. However, higher capacitive values increases power dissipation. Capacitor values less than 50pF diminish the effectiveness of termination.

Edited December 2, 2017 by FantomXR

[Hawkeye]

No problem, and yes only a single cap! It nearly solved all of my problems on the V1 programma and that has some very long lines to the displays. I've therefore not spent any more time on the issue, but an additional software solution might be to reinitialize the OLEDs while MBNG is running, e.g. when a bank-change occurs. That way, a garbled screen could be cleaned up again only using software. But it was not necessary, yet.

I've experimented for a day or so to find good end-of-line termination, including resistor, excluding resistor and in the end, the resistor made no difference in my usecase and i ended up with a single 22pF ceramic cap on the last OLED between CLK and GND, it is so flat, you can solder it on top of the OLED. Before doing that, i stabilized the voltage supply to the displays (3V3 linear vreg), which was necessary, as i had been using only the tiny 3V0 onboard regulator of the disco board, which was overloaded after 12 displays or so, but if you are using 5V, probably it is no problem.

Regarding the terminiation capacitor: you might need to experiment with the value there, as it depends on your setup and the "line length". If the cap has a too high capacitance, it will draw too much current and will "kill" the clock signal (I'd say no damage can occur, when experimenting with the value, you just won't get any output), if the capacitance is too low, no termination effect will occur, but i'd guess if you try out a handful of different values around 22pf, you will get a huge improvement.

Edit after your edit (hehe): yes, by all means try higher capacitance values as well (or even try with an additional resistor as often recommended)! I might also not have found the best possible solution, but it was good enough for me.

Many greets and have a nice weekend!
Peter

[FantomXR]

Hi Peter,

sounds great! I'll try!
The only problem I have is, that this problem occurs random. It runs smooth for a while (like yesterday over 6h) or it can happen immediately (like today). Do you see a way to "force" this error? How did you check if the cap has the right value? Maybe I will add this cap not only to the last OLED but also to the 9th and see if that helps. Will do on tuesday hopefully.

I don't use the onboard-regulators of the disco at all. 

BTW: If you say "it was good enough for me" and "it solved nearly all my problems"... what are the problems you still have to deal with? 

Thanks again! You saved me weekend ;-)

Best,
Chris

[Hawkeye]

Hi Chris,

well, the "antenna" effect of the wiring is why it happens at random, any kind of rf signal could be picked up, e.g. if you have a 433mhz garage door opener, try to hold that close to your OLEDs while operating it, and I'd be quite sure, you can trigger the effect instantly, if segments of your wires are about 20-30cm long :). Or (and that is mean), a switching psu that is nearby can cause it, they quite often emit RF, that will be picked up by those lines. It needs not even power the MIDIbox, but can power a different synth/unit. I once had a very noisy 5V switcher, that completely killed nearby GPS reception (other usecase, no MIDIbox).

Regarding that my problems were only almost solved: yes, it still happens to me (the exact same display shifting effect you are also experiencing), but only once per evening session or so, earlier on, it happened after 5 minutes, but i am sure, that is because i put 24 displays on the same clock line (unbuffered) and the wiring is very long (i'd guess at least 1.2 meters!).

Just try it out, if it does not work, only a few cents for the caps are gone and then you can investigate the "proper" buffering solution. Andy did quite some research there and has built an experimental buffer board already, that you could try out.

Many greets,
Peter

[FantomXR]

Just now, Hawkeye said:

Andy did quite some research there and has built an experimental buffer board already, that you could try out.

Oh yes... I'd be really interested in this... I'm really looking for a professional / proper solution that works at anytime....

The 5V that powers the core is indeed a switching PSU running a LM2596. But I need to add an LC filter to reduce output ripple. I'll try that and the pF-cap on the clock-pin and see if it improves it...

BTW: I worked with those OLEDs the whole last week without any problems! Than I moved with it to another place, and it went crazy. 

[Hawkeye]

Very cool then, please keep us posted on your findings. Probably using a 50R resistor and 100pF or so would be a good try, in addition to my 22pf solution, as many people recommend it :)

Quote

BTW: I worked with those OLEDs the whole last week without any problems! Than I moved with it to another place, and it went crazy. 

That almost certainly sounds like a RF-induced problem. Long time back in the last millenium, we had some strange network problems in a then coax-wired 10mbit environment. A local network guru came by and asked us: have you put the Arnold on? Well, we did not know what he meant. Only a few minutes later he said, still grinning: Arnold=Terminator!!! :-) Yes, ok, it was a reaaaaly bad joke, but he was right, we forgot one of those tiny screw-on coax terminators, that should basically do the exact same thing as our OLED clock termination... and our network problem was solved :).

Have a good evening!
Peter

 

[latigid on]

The display driver (~10cm square) is as shown:

J15 connection top left (unfortunately I made a mistake and mirrored it...). To the right is a connection to the Core to generate a DOUT-like chain. The SPI data, clock and D/C signals run through 541 buffers and join with CS signals from 595 shift registers on the middle connectors. These have the pinout matching a (correctly oriented) J15 comprising only 4 CS lines. Works fine, as long as you remember to mirror J15! Let me know if you want a board.

The board above has buffers plus damping resistors for all of the data lines. This means the Core MCU doesn't have to drive a long signal, which is better for performance. The RC termination as suggested by Peter can help. The capacitor effectively forms a lowpass filter that smooths out the spikes. It's not a question of drawing more current with a larger value, but lowering the corner frequency. At some point the clock transitions are too round to be detected and everything grinds to a halt.

 

 

Edited December 2, 2017 by latigid on

[FantomXR]

Hey,

thanks for sharing!
In my design I don't have space for such a board and it would be overkill because I do not drive so many OLEDs. 

Anyway: I'll try Peters way first and report back!

Thanks so much for your help!

[Antichambre]

Hello, I have a look on your PCB, the cap for decoupling is after the power supply of your 595. A decoupling cap must be between supply and IC supply pin or it can have no effect. More than that it's always better to put one for each component which must be supplied.
Put a a bigger one also (1~10uF) close to the board supply connector too. For that I use tantalum instead of electrolytic, there are more expensive but smaller and better for digital domain and high frequencies. Don't use it for audio or analog purpose!
Best
Bruno

Edited December 3, 2017 by Antichambre
Don't use it for audio or analog purpose!

[FantomXR]

Hey people,

@Antichambre: I can't follow you regarding the decoupling cap. It should be in the right place....adding the cap to the supply-connector seems useful! Will do!

I can't do too many changes at the moment to the electronic. But to try it out I killed the external power supply and power the core now via USB. As you can see I have the same problems (see pic). 

I hope I can do those changes we discussed here on tuesday...

 

Edited December 3, 2017 by FantomXR

[FantomXR]

It goes crazy!