OLED display driver/carrier boards/SCS

[latigid on]

I'm working a bit with @Hawkeye and @jojjelito on their awesome MB-Programma project, only we'll try to use my illuminated encoders in place of the sadly obsolete LRE boards.

The Programma makes good use of displays mounted at 45 degrees to label each encoder. But to do this it requires quite a mishmash of wiring. I propose a new PCB set to make things easier, not just for Programma but a range of NG builds. I'm still working on the 45 degree board, but I have a fair idea of the others should work.

Here's how 4 OLEDDs look. This 7-pin type is very common and quite cheap. Spacing is at 30mm on a 120mm PCB.

 

I thought it would be interesting to combine a sort of SCS, a bit different in layout to @ilmenator's. 10mm switch footprints will also be added.

 

You could split the SCS over two PCBs (using a single ribbon with two connectors on it) or a single PCB if you liked.

 

Once you go over 8 OLEDs, you need to start using DOUTs to generate the #CS (chip select/slave select) lines. It was mentioned that the Programma had a few issues with signal integrity, so I thought it might be an idea to combine a line driver with a shift register chain, and also an optional power regulator circuit. Adding to this, the new F4 Core J10B doesn't use 1:1 pinning with J1 on a DOUT board, so would need a special cable. I found some discussion that a similar circuit using 541 drivers and 1k output resistors could happily drive an array of displays spaced 10 metres in each direction. The resistor also acts as "termination" which attenuates reflections in the data lines. I will also add RC termination on the carrier boards. I didn't buffer the 595 outputs as they have reasonable source current already and #CS is less critical for timing. Apparently the displays run at 22mA each, so a linear Vreg should be okay to drive 32. Standard ribbon wire can take 500mA per per strand, again we should be okay, but I'll put an alternative power option on the carrier board.

Two driver boards could be chained for a possible 64 OLEDs (!). If possible I will try to connect the remaining #CS lines so one could drive 8 additional displays, though I think 64 is the limit. @Hawkeye suggests that it's better to use #CS from one source only to avoid problems i.e. directly from J15A or DOUTs.

 

 

Any questions or comments, please share!

 

 

[Phatline]

each display show labeling and values for 2 encoders (one row above, one below)?

[latigid on]

You mean for the Programma? That's better explained in their thread but for my variation it's something like this:

 

Potential layout of 8*8 grid with extra displays, top is for displaying 1 or more custom envelope curves, bottom has an "SCS" built with 4*OLED and, 6 buttons, 1 encoder:

[ilmenator]

Good to see this happen!

I think it would be great to have the encoders much closer to the displays - in my opinion this is crucial for ease of handling and for keeping the overview in live situations.

Which would obviously require a different kind of modularity: e.g. modules/boards that hold all the functionality required for 1 or 2 displays with associated encoders. That way, there would be true scalabilty in the system.

[latigid on]

Just to clarify; do you think the three rectangular boards (4*OLED; 2*OLED, 1 enc; 6*buttons 2*OLED) are too far away from the encoders? I have the 4*4 illuminated encoder boards already, but my idea was to create another PCB which holds 4*OLEDs mounted at 45 degrees as per the Programma design, which is stacked over the encoder board. So I think that's what you suggest: displays mounted as close as possible to encoders? Sorry if that's confusing, the rectangular boards are useful for different kinds of NG builds or as the menu interface for Programma.

I completely agree about the modularity though. You should be able to start with as many (up to 4) or few encoder boards and displays as you need and scale from there. If the arrangement doesn't suit you could also add distance between them or lay them out e.g in a straight line.

[Hawkeye]

Great work!
Having these boards available would really encourage people to bring their MIDIbox NGs (Programma is only a name for a given defined hardware subset) to a new level of functionality and bling :-).

Andys approach already is very modular. A set of boards that were proposed above for use in a NG/Programma context might look like:

[TOP]
[E][E]
[E][E]
[L][R]

Where [TOP] is one or two of Andys first listed boards with four displays. These are optional in the Programma context and would only display additional (but not vital) status information, e.g. a graphical representation of envelopes, LFOs, OSC mixer settings...

[E] is one of the awesome new 4x4 encoder + 4 OLED boards. Each OLED is mounted in a 45° degree angle to allow maximum packing density. The OLEDs are really close to the encoders, partly overlapping with the encoder base (but mounted above the encoder base). The setup with 4x4x4 boards would be equivalent of the first version Programma prototype lingering around here, with 64 encoders and 16 encoder displays. It is a nice size also to control complex synths. More encoders would be possible, but it gets really confusing already to find the correct parameter with 64 encoders, even if labels are there. It is just a lot of knobs and I would personally prefer banking after having 64 encoders available for use.

[L] and [R] is the bottom menu and bank selector section. The six pushbuttons are equivalent to a SCS, the encoder is the bank selector, or when in menu mode, the menu item switcher (like MIDIbox NG right now). The two displays each left and right are intended to be used for
a) Menu display and encoder-current/original value display (two displays used)
b) Keyboard layout of the six (circular) keys. These can be remapped to different functions when in different modes and labelled accordingly. E.g. a different 6-key layout in normal use mode and in menu mode.
c) Current bank info. Big synths require multiple banks. E.g. you could have a bank for the oscillators, a bank for the filtering action, a bank for fx, ... (each bank is a set of 64 encoders). This would display a graphical label of the bank, the encoders are currently in. Turn the main encoder to quickly switch banks.

Of course, these boards can also be used for other/different projects, and is not necessarily only for the NG (with Programma code extensions). It would be nice to have a quad-OLED module available in many projects, for example for MBCV....

Many greets,
Peter
 

[Phatline]

good idea... if someone make a pcb and or OLED-Bulk i am in

to "verwurst"-code...i would use some modules in first case for aout-Filterbank-version.... and many other cases

[ilmenator]

On 20.4.2016 at 11:38 AM, latigid on said:

I have the 4*4 illuminated encoder boards already, but my idea was to create another PCB which holds 4*OLEDs mounted at 45 degrees as per the Programma design, which is stacked over the encoder board. So I think that's what you suggest: displays mounted as close as possible to encoders?

Yes exactly, I didn't see any such display board, hence my suggestion.

[mongrol]

Would these be usable with the Minicore or perhaps a Duino/Teensy board? I get dismayed everytime someone mentions "core". It's just so bloody big. In this case it'll be as big as a 4x4 pcb,

[latigid on]

Just the buttons and encoders? Sure thing. But the illuminated encoders and displays need the big brother. I know there's Arduino code for WS2812s, it just depends on what you want to do with it. Who knows, maybe there'll be a new F7 Core design that could be made much smaller.

[tago]

@latigid on

My question has not directly to do with your board.

Will the SCS work with only a single 128x64 OLED? Would you use an original or emulated SCS in this case?

[latigid on]

Here's an updated picture:

 

 

You can see 7 pin SIL rows for the displays and the six switches/encoder (two positions possible). Encoders with built-in switches are supported but you have to wire your own pins.

Possible configs are:

1. OLED OLED OLED OLED
2. OLED [6 buttons] OLED
3. OLED OLED encoder
4. OLED [6 buttons] encoder
5. only switches
6. only encoder
7. combo of switches + encoder
8. fewer OLEDs

Pinning for the OLEDs is based off J15A from the Core32F4, same for the display driver.
Pinning for the SCS is the standard J10(A). 

 

It would be possible to split the SCS functions across two boards, e.g. with OLED [buttons] OLED on one and OLED OLED encoder on the other.

Edited July 25, 2016 by latigid on

[tago]

17 minutes ago, latigid on said:

4. OLED [6 buttons] encoder

Do you have a photo showing how the SCS menu will look in that configuration (single OLED)? I've only seen LCD SCS.

Edited July 25, 2016 by tago

[latigid on]

Not yet.

[tago]

Just now, latigid on said:

Not yet.

I hope i'm not too obtrusive. The photo could be one of a breadboard/flying setup, i only want to see how the 128x64 displays the menu text. Thank you :)

[latigid on]

No worries, PCBs should be here today if DHL get their act together. I have white 0.96" OLEDs on the way, could possibly try with a yellow-blue I have left.

The thing is, you don't have an ordinary button layout, so maybe traditional SCS LCD functions don't make sense anyway. But as far as the display goes, a 2*20 CLCD is 100 pixels across with a gap of ~1 pixel in between characters. So the horizontal resolution is comparable.

I chose the 6 button "hex" layout just to try something different. My thought was that there's enough space to provide two menu rows of 3 items each. Have to see though, my guess is @Hawkeye will do most of the hard work with the Programma builds ;-).

This gives an idea of how the text fits, approximately 20 characters:

[tago]

30 minutes ago, latigid on said:

The thing is, you don't have an ordinary button layout, so maybe traditional SCS LCD functions don't make sense anyway.

You mean your circle 6 button layout? What's the thinking behind that arrangement?

 

30 minutes ago, latigid on said:

But as far as the display goes, a 2*20 CLCD is 100 pixels across with a gap of ~1 pixel in between characters. So the horizontal resolution is comparable.

Looking at the photo it seems like you can compare the lower lines, they have the same character count (20). Around 3-4 times smaller then LCD character height. But the OLED has more vertical pixels. Maybe a condensed font is the solution to fill the whole display? Or simulate a 4x10 LCD? What looks the SCS on a 2x40 LCD, is there lots of blank space?

I want the SCS mostly for patch selection purposes in an universal synth controller. It would make sense to have a larger font on OLEDs, at least for patches names.

 

 

Edited July 25, 2016 by tago

[latigid on]

 

3 minutes ago, tago said:

You mean your circle 6 button layout? What's the thinking behind that arrangement?

31 minutes ago, latigid on said:

I chose the 6 button "hex" layout just to try something different. My thought was that there's enough space to provide two menu rows of 3 items each. Have to see though, my guess is @Hawkeye will do most of the hard work with the Programma builds ;-).

 

 

3 minutes ago, tago said:

Looking at the photo it seems like you can compare the lower lines, they have the same character count (20). Around 3-4 times smaller then LCD character height. But the OLED has more vertical pixels. Maybe a condensed font is the solution to fill the whole display? Or simulate a 4x10 LCD? What looks the SCS on a 2x40 LCD, is there lots of blank space?

I think it would be possible to do a 4*20 display on a single OLED. Understand that the traditional SCS layout (visible in the MB CV control surface above) typically puts 4 buttons below the LCD to select menu items.

 

3 minutes ago, tago said:

I want the SCS mostly for patch selection purposes in a universal synth controller. It would make sense to have a larger font on OLEDs, at least for patches names.

You're describing the Programma. 1-4 ELO boards with sets of 16 illuminated encoders and 4 "labelling" OLEDs, auxiliary SCS-OLED boards for patch name, envelope shapes, SCS button labelling etc. 

[tago]

7 minutes ago, latigid on said:

You're describing the Programma. 1-4 ELO boards with sets of 16 illuminated encoders and 4 "labelling" OLEDs, auxiliary SCS-OLED boards for patch name, envelope shapes, SCS button labelling etc. 

Only partly. My idea is to have a more traditional/analog section with pots and sliders and additionally a universal Encoder/OLED section (e. g. 4x (or 8x) Encoder/OLEDs combinations) plus a SCS for patch selection/system stuff. The analog section would occupy the most space on the frontpanel.

So i've three main sections

1. Lots of analog inputs (pots/sliders) with an edit button for each synth section e. g. LFO, OSC.. - maybe with additional OLEDs for each section to show waveforms and other paramters

2. Encoder/OLED combinations (with banking) that show corresponding (sub) parameters of the selected synth section via the edit buttons

3. SCS/System menu, mostly displaying the current patch name, patch selection, patch saving..

I hope it's getting not too offtopic.

[latigid on]

Fair enough. Out of interest, how many pots are you looking to implement? 

[tago]

Around 40, max. 50

Do you think my idea is idiotic? I mean not building a Programma.

 

Edited July 25, 2016 by tago

[latigid on]

Only you can decide that. 

My perspective on pots is that they make less sense on architectures with presets, like a universal controller. Of course you have relative/snap/absolute handling modes, but they don't beat the simplicity of an incremental encoder. Pots (also encoders) are subject to wear and dust and are inherently more difficult to scan. This difficulty increases with the number of inputs (slower scan rate etc.), although I'm sure TK. has routines for minimising jitter errors.

If you're sending CC data rather than NRPN (well first we have to look at the effective resolution of the ADC), it's all quantised anyway. Pots also make little sense with lower resolution parameters. A prime example is the Rhodes Chroma ENABLER. Almost $4000 to have one built (a lot of wiring and parts) and some parameters have as few as 4 values. But it demonstrates that it can be done with pots if you choose.

 

 

Finally the likelihood of a project being completed is inversely proportional to its size and complexity. Pimping the ELO (Programma) boards, this breaks the task down into smaller chunks.

[tago]

1 hour ago, latigid on said:

A prime example is the Rhodes Chroma ENABLER.

Is the Enabler based on Midibox?

 

1 hour ago, latigid on said:

My perspective on pots is that they make less sense on architectures with presets, like a universal controller.

Yeah, that's the downside. IMO ok if you don't mind old analog synths. They often have not even presets. But i can imagine a second synth controller wholly based on encoders.

Do you see jitter problems with around 50 pots? The AINSER board is ready for 64 inputs, so i assume it should work. I know that multiplexers will not make things easier concernig jitter. Therefor i asked before if i shoud go the AINSER8 route to get better wiring. But it seems you can't have lots of AINSER8 modules.

Do you know someone who built a similar midibox, who could be asked about upcoming issues?

Edited July 26, 2016 by tago

[latigid on]

3 minutes ago, tago said:

Is the Enabler based on Midibox?

I don't think so, but from memory it uses a PIC.

3 minutes ago, tago said:

Yeah, that's the downside. IMO ok if you don't mind old analog synths. They often have not even presets. But i can imagine a second synth controller wholly based on encoders.

Do you see jitter problems with around 50 pots? The AINSER board is ready for 64 inputs, so i assume it should work. I know that multiplexers will not make things easier concernig jitter. Therefor i asked if i shoud go the AINSER8 route to get better wiring. But it seems you can't have lots of AINSER8 modules.

Do you know someone who built a similar midibox, who could be asked about upcoming issues?

I don't have personal experience with scanning pots into MIOS, apart from the BLM 16*16+X. AINSER(X) is the external ADC solution to expand the AIN capabilities but I don't know about the performance (try searching the forum). PICs in general have better handling of analogue inputs; this is why they are used as part of the MF_NG module. Then again, Mutable Instruments uses a single ADC pin and four multiplexer chips to scan 28 pots in Elements. I know from using the module that some parameters are definitely lower resolution, e.g. the tuning controls are quantised. 

[tago]

2 minutes ago, latigid on said:

PICs in general have better handling of analogue inputs; this is why they are used as part of the MF_NG module.

Is there an alternative PIC based AIN board?

I fear we're getting too offtopic.