problems with SSD1306 displays

[John E. Finster]

Hi, I came across some problems with my SSD1306 displays:

 

1. Using big fonts in conjunction with the txt56 syntax doesn´t work completely yet. I wasn´t able to test this thoroughly until now, sorry, otherwise I would have reported this earlier.

When I initialize my box (with mackie emulation) the tracks host message is fine like this:

 

 

But when the text on the second line changes the first character still gets cut off:

 

 

It seems, that the first character on the second line gets shifted 8px above. This is the case for every first character on a track.

 

 

 

2. Another (bigger) problem I came across is that there are a lot of artifacts occuring on all the displays which data lines are not connected to the core, but to a DOUT module (so, lcd 9 and above). This can be seen here:

 

 

What is seen here are the 12. and 13. display. The artifacts always occur on the display before (like in the picture) and the characters on the "original" screen sometimes disappear. This can also be seen in the picture.

This is not static, but changes every time a button event is sent. I am relatively sure, this isn´t a wiring problem, since I thoroughly checked all connections with a circuit analyzer. No shorts, no broken connections, nothing....

 

If someone has an idea, what I could have done wrong, please tell me.

 

Thanks

 

my regards

Edited July 17, 2013 by John E. Finster

[John E. Finster]

Hi, I did some experiments and I found a workaround for the 2. problem, the artifacts. Since they always appeared on the display before the one with the original content, I rearranged the pins and left out every second pin on the dout module, so SR1: dataline 9 - 11 - 13 - 15 and so on... That seems to work, I didn´t notice any artifacts yet. I still have disappearing characters (or parts of them) on the screens, but if I use the meta event "UpdateLCD", most of them can be reinstated.

 

my regards

[TK.]

The first problem could be related to the display width/height configuration.

Which lcd_width/height values did you configure in the MIOS32 bootloader?

 

Best Regards, Thorsten.

[John E. Finster]

Hi TK, thanks for replying.

 

Here is the configuration from the bootloader

 

 

[248333.620]   set lcd_type <value>:    sets LCD type ID (current: 0x85 - GLCD_SSD1306_ROTATED)

[248333.621]   set lcd_num_x <value>:   sets number of LCD devices (X direction, current: 32)

[248333.621]   set lcd_num_y <value>:   sets number of LCD devices (Y direction, current: 1)

[248333.622]   set lcd_width <value>:   sets width of a single LCD (current: 128)

[248333.622]   set lcd_height <value>:  sets height of a single LCD (current: 64)

 

I tried other host available to me right now to exclude that this error could be caused by Reaper´s MCU Plugin itself, but this error occurs with others too.

 

my regards

[TK.]

Hm, strange... would probably need some debugging at my side, but this can take some time.

 

On the other hand: as a workaround you could try to define two SysEx commands: one for the upper, another one for the lower line.

 

Which EVENT definition are you currently using?

 

Best Regards, Thorsten.

[John E. Finster]

Here is how the host message is displayed atm:
 

# Print mackie control host message
EVENT_RECEIVER id= 4 type=SysEx stream="0xf0 0x00 0x00 0x66 ^dev 0x12 ^cursor ^txt56" lcd_pos=2:1:3 range=map1 label="&d"

# Map mackie control host message
MAP1  2 3 4 5 6 7 8 \
12 13 14 15 16 17 18 \
22 23 24 25 26 27 28 \
32 33 34 35 36 37 38\
42 43 44 45 46 47 48\
52 53 54 55 56 57 58\
62 63 64 65 66 67 68\
72 73 74 75 76 77 78

while 'label="&d" refers to a modified font with 12x16px. But the error also occurs with the default big midibox font.

I thought about the alternative to split the host message into two (or more ) sysex commands, this would have been my prefered option actually :happy: , but I couldn´t figure out, how to do so. I studied the available sysex syntaxes in the manual, but this option never revealed itself to me.

How can this be done?

my regards

Edited July 23, 2013 by John E. Finster

[TK.]

Still looks correct, still would need some testing at my side (which I can't do this week...)

 

 

 

I thought about the alternative to split the host message into two (or more ) sysex commands, this would have been my prefered option actually  :happy: , but I couldn´t figure out, how to do so. I studied the available sysex syntaxes in the manual, but this option never revealed itself to me.

How can this be done?

 

Well, do you rely on the mackie protocol, or are you able to send your own (customized) SysEx strings in the DAW?

 

Best Regards, Thorsten.

[John E. Finster]

In fact I do rely on the mackie protocoll, my whole midibox design is orientated that way.

 

I want to use the mackie protocoll from klinke, a guy over at the Reaper community. He modified the native protocoll (from Reaper) in a way, that turned the MCU into the most sophisticated control surface I´ve ever seen. That´s where I´m heading with my box...

 

my regards

[John E. Finster]

Hi,

 

I´d just like to give a little update on my display situation.

 

1. I filled all my 18 displays up with info now. Since I skipped over every second shift register on the DOUT module, there are no artifacts any more, but when I start up my box there are a lot of pixel information missing on the screen (like in the second display in the third image above). I have to execute the UpdateLcd meta event several times to restore all the pixels. This also happens when Information on the screens is changing and mostly the displays connected to the DOUT module are affected (so, #9 and above).

For the missing pixels at startup I tried to use a *.ngr script as a workaround, but I got an error message in Mios Studio saying that this meta event (UpdateLcd) was not valid.

 

Imo, this problem might be connected to the MB_NG firmware. When I upload the bootloader there seems to be nothing wrong with the all the displays. When I type "store" into the terminal the LCD info (e.g. LCD #22.1 and so on..) is printed on all screens with no problems. Just a guess though....

 

1. Another big problem came up. After a while (sometimes after 5 min, sometimes after 2 hours) all the displays suddenly go dark and slowly fade in again. All the info on the screens is still there, but kinda messed up (gibberish characters, shifted positions). The faders, encoders and buttons seem to work as usual. A new startup seems to fix this.

I have no idea what could cause this.

 

my regards

[Duggle]

 

1. Another big problem came up. After a while (sometimes after 5 min, sometimes after 2 hours) all the displays suddenly go dark and slowly fade in again. All the info on the screens is still there, but kinda messed up (gibberish characters, shifted positions). The faders, encoders and buttons seem to work as usual. A new startup seems to fix this.

I have no idea what could cause this.

 

You'd need to eliminate the possibility of a glitch on the power supply lines.

I'm thinking it's something that is common to all the displays.

What sort of power supply? Is it a linear regulator (getting hot and tripping, perchance?)

Does it happen when all displays are running, but then not when most of them are disconnected? 

If you have the luxury of a digital CRO, set it up to trigger on the falling edge of the positive rail to capture what is happening.

[John E. Finster]

Hi,

 

I´m using a switchable psu, regulated I think. AC to DC Adaptor. I set it to 14V, 2,3A output and it´s getting warm, but not hot. I need a little more voltage to drive my penny&giles faders.

I´ve never paid any attention to any currency fluctuations, because I always thought that the 7805 on the LP17 Core would level all incoming currency to 5V anyway (if the fluctuations stay above 5V, of course).

 

 the luxury of a digital CRO

 

No, unfortunately not, maybe I could borrow one. How would I have to set it up? I´ve never used one before.

 

 

Does it happen when all displays are running

 

So far, yes. When I was building my box, I did a lot of checks along the way, and I never had this problem. It has become an issue after I finished my box (the worst possible moment  :rolleyes: ).

 

This error became quite an adventure over the last days. The day after I posted my last post here, I used my box almost the whole night without any problems. Yesterday then I had two dropouts like that...

The first time, the displays #9 and above suddenly became darker and began to flicker every time I pressed a button.

The second time an hour later, I just looked up for a second, when I looked back at the displays, they all were mirrored from left to right. I gave up drugs almost a decade ago, but for a moment I thought I´m having flashbacks... :hyper: .

 

If you have more infos to share on this, I´m gratefull for any kind of input.

 

 

I also wanted to give another update on the cut off characters in the Mackie Control message. This might be a minor discovery, but maybe it can be usefull:

 

I tested my box again with Ableton Live and I noticed that this issue is only limited to the first track, not to all 8 tracks like when I use Reaper. After a hint klinke from the Reaper community gave me, I monitored the sysex output of Ableton´s and Reaper´s mackie implementation and this is what I got:

 

 

Ableton Live:

 

0004D555   1  --     F0  Buffer:    64 Bytes   System Exclusive 

SYSX: F0 00 00 66 14 12 38 20 32 38 52 20 20 20 20 20 36 52

SYSX: 20 20 20 20 20 35 52 20 20 20 20 20 32 52 20 20 20 20

SYSX: 20 34 4C 20 20 20 20 20 37 4C 20 20 20 20 20 43 20 20

SYSX: 20 20 20 31 39 52 20 20 20 F7

 

Reaper:

 

SYSX: F0 00 00 66 14 12 38 20 20 2D 33 2E 30 20 F7

00095BB6   1  --     F0  Buffer:    15 Bytes   System Exclusive 

SYSX: F0 00 00 66 14 12 38 20 20 2D 32 2E 34 20 F7

000961F3   1  --     F0  Buffer:    15 Bytes   System Exclusive 

SYSX: F0 00 00 66 14 12 38 20 20 2D 32 2E 37 20 F7

000962AB   1  --     F0  Buffer:    15 Bytes   System Exclusive 

SYSX: F0 00 00 66 14 12 38 20 20 2D 33 2E 33 20 F7

00096943   1  --     F0  Buffer:    15 Bytes   System Exclusive 

 

This shows the change of the second message line of track 1. I understand now, that byte 7 (38 in these cases) define the offset for the lcd message. Here it seems that Ableton always updates the whole line if the messeage on the second line is changing (byte 7 "38" never changes when I text changes on another track), while Reaper only changes the message of the track that is modified.

 

So, I think that the issue at hand might be related to the 8th byte of a sysex message for the mcu, since it is always the first character on the second line (Ableton: only 1.track; Reaper tracks 1-8) that reacts this way.

Again, this may be a minor discovery, so it´s just a mere guess from my side. This whole sysex thing also is very new to me.

 

 

And just a small update on the missing pixels on my displays:

 

I got the UpdateLcd event to work inside a NGR script, so currently I´m working on a script that can update the lcds a couple of times when particular midi events are sent to or received from Reaper.

What I don´t understand yet, is why the motors of my fader always react on a meta event. I have to figure out a way to exclude them, when I want to perform an lcd update.

 

 

Ok, that´s it for today....Sorry for blowing this whole thing up like this. I realise, there might be bigger things to adress, so.....

 

Many thanks for reading and chipping in.... :flowers: .

 

My regards

Edited August 6, 2013 by John E. Finster

[Duggle]

Does the 7805 run hot? (nearly too hot to keep your finger pressed to it?)

Just to confirm: If you disconnect half of the displays, then you don't see this problem?

[John E. Finster]

Yes, the 7805 runs pretty hot, around 60°-80° C. But according to the datasheet, this temperature is well within the acceptable range.

 

 

 If you disconnect half of the displays, then you don't see this problem?

 

I think so. When I was assembling my box, I first had 2 displays connected, then 8, then 14 and finally 18, before I closed my box. I did a lot of experiments along the way in every stage except in the last. There I connected the last 4 displays, did some test and closed the box. I didn´t encounter any problems like that to that point, except for the other issues I mentioned above (txt56 error, artifacts and missing pixels). 

 

But as I think of it now, I did power the core only via usb to that point and had the MF modules powered by a seperate psu (a laboratory psu), because I wanted to try different voltages for the fader without effecting the core module. I connected the core to a psu power when I put everything together into the case. After that the displays sometimes become unstable.

[Duggle]

Yes, the 7805 runs pretty hot, around 60°-80° C. But according to the datasheet, this temperature is well within the acceptable range.

I would put a heatsink on the 7805 so that it never goes above 40degC. These devices have a thermal shutdown feature which is what I suspect is happening to you.

BTW, I'm not receiving email notifications from active threads. Is it just happening to me?

[John E. Finster]

Ok, I will try to put a heatsink on it and observe if that fixes the problem. I didn´t think, a 7805 would be so sensitive regarding the heat.

Thanks for the advice.

 

I'm not receiving email notifications from active threads.

 

Me neither. I suspected some kind of error with my email provider, but since others seem to be affected too,....

 

my regards

[Duggle]

Ok, I will try to put a heatsink on it and observe if that fixes the problem. I didn´t think, a 7805 would be so sensitive regarding the heat.

Thanks for the advice.

The devices feature thermal shutdown.

[John E. Finster]

Hi,

 

I´d like to give another update on my situation.

 

1. I installed a heatsink onto the 7805 and this seems to fix the problem with the displays going crazy, I didn´t have a dropout since then.

Thanks again, Duggle, for the tip!

 

2. I was also able to fix the problem with the cut off characters when using the mcu host message and the ^txt56 command.

 

Instead of using the ^cursor command I defined a seperate RECEIVER event for every occuring cursor position inside the sysex stream from the mackie protocol. For Reaper there are 16 ( 2 for every track -> 1. and 2. line ) and for Ableton there are 2 ( 1. and 2. line ). Every receiver became it´s own lcd position.

 

3. I´m still working on the problem with missing pixels/characters.

 

For the startup of my box I set up an *.NGR script, that first locks the faders, then performs 5 lcd updates and then unlocks the faders again.

That works on a startup.

 

I tried using a script with lcd update commands for other functions that require screen changes, but unfortunately the fadermotors seems to react on a meta event and "twitch" whenever a meta event is executed. This can cause small, but sometimes very annoying parameter jumps.

This approach doesn´t seem to work as a permanent workaround for the situation.

 

 

That would be it for now. I will report back if anything new comes up.

 

 

my regards