Modular OpenDeck v3

[wayland]

Hi!

I've been editing OpenDeck in EESchema, and have run across references to the "Igor" library, but I don't appear to actually have this library. Is there any chance either:

• Information could be included/given on where to get it?
• It could be included in the OpenDeck repo somehow?

Thanks!

[paradajz]

Which schematic? I assume v3?

[wayland]

Yes. I found out that by finding a component that was already using the igor library and copy-pasting it into the sheet, I could get the igor library components to work. Thanks for responding though!

In case you're interested, I'm working on a way of making the OpenDeck hardware more modular. I should be done with the schematic in a month or so, and I'll ask for your opinion at that point :) .

[wayland]

Update: The finalising of the schematic for the modular version progressed much more quickly than I had anticipated. So I'm done, at least with the first round. I'm keen to have your input if you're willing to give it; I'll probably start designing the PCB a week from today, and, while I'm happy to have your input at any point, if you happen to have time to have a look before then, that'd be great! It's currently located in my fork of the OpenDeck repo, but I'm happy to merge (or not, as you prefer) when I've got something usable.

The writeup (with links to the schematics) can be found at https://github.com/wayland/OpenDeck/tree/master/bin/sch/ModularDeck

Points to note are:

• I recommend that you start looking at the schematic of the Base Board and the Classic Breakout Board so you can see where I suggest we draw the line between the main board and the breakout boards.
• The goal is to be able to chain together multiple breakout boards to get more inputs/outputs without too much effort
• I don't intend to ever design a PCB for the classic, but I wanted to do that schematic so you'd see where I'm going
• The Standard Breakout Board is much like the Classic, but it allows for chaining better; it has less capability itself, but chains better than the Classic
• The 3x3 Breakout Board is much more directed at the kind of application I have in mind: a control surface made of a bunch of 2x2 and 3x3 keypads representing different areas of the stage
• Conceptually, I can see room for more kinds of breakout boards (an obvious one being the "4x4 Breakout board", which does 4 keypads with up to 16 keys each)
• Just a warning that I'm not a professional electronics designer; I recognise that the layout of mine doesn't seem quite as aesthetic as yours. On that note, if I've done anything particularly dumb in my circuit schematic, I'm happy to hear about it

The things I'm keenest to have your feedback on are:

• Does the daisy chaining of the LEDs and buttons look like it will work? Will that work if we just configure it into the existing OpenDeck, or would it require some extra coding?
• Should I (or we, whichever you prefer) be doing something different in chaining the analog inputs? The way I've done it maxes out at 4 MUXes (64 inputs), the same as OpenDeck v3. Other options I've thought of:
  • Should I add a 74HC4067 to the baseboard, and then use each channel of that to drive a different board? This would require 12 more pins on the header, which is why it's not my preferred option
  • Should I grab the last channel of each board, and route it out as a daisy chain? That'd mean that each board would only support 15 channels (though we could add another header to get that last channel out of the last board in the chain)
• Are you aware of anything that will make this not work?
• Are you aware of any limits to how many of these breakout boards we can stack, other than the 4 MUX limit mentioned before

Thanks very much for your time in reading this message!

[paradajz]

This looks like some serious work, so I have to applaud your efforts here. I'm also glad that my project fulfills your needs enough to base your work on it.

The goal is to be able to chain together multiple breakout boards to get more inputs/outputs without too much effort

Are you planning on selling the modified modular version or is this purely for your needs? Just curious, project is permissively licenced so you can do whatever you want.

The Standard Breakout Board is much like the Classic, but it allows for chaining better; it has less capability itself, but chains better than the Classic

I really like your method of daisy chaining the common mux pins, quite clever. I actually needed to do similar thing on a past project, but your method is a lot better than what I did.

the 74HCT125 is replaced with a TXB0104PW (so that we can daisy-chain out the LEDs

Clever.

The 3x3 Breakout Board is much more directed at the kind of application I have in mind: a control surface made of a bunch of 2x2 and 3x3 keypads representing different areas of the stage

On that schematic I've noticed two KP6 headers. Mistake or? Either way, why 7 headers instead of 8? Not sure I understand what's going on on that schematic to be honest, even after reading your writeup on the fork (very good job on that, by the way).

Does the daisy chaining of the LEDs and buttons look like it will work?

I haven't looked in great detail, but from what I see I haven't noticed anything obviously wrong, so for now I'd say yes.

Will that work if we just configure it into the existing OpenDeck, or would it require some extra coding?

Heh, depends on how you imagine this to work. Currently, OpenDeck doesn't have run-time concept of dynamically detecting more I/O as that is fixed in the configuration (YAML) file, or even the concept of changing the amount of I/O with Web UI. So at least for now you'd need dedicated configuration file (in other words, firmware) for each daisy-chain combination. Having the firmware automatically detect more boards / I/O would require both more pins on MCU just for detection and also some custom logic in the firmware which I'm very much against, since the entire idea of OpenDeck is to be a generic firmware without custom addons. I guess few more entires could be added in the YAML file with which you could define expected I/O "growth" or something like that, and then enable more boards via Web UI. Still, I imagine it would be a lot of work to implement something like that. To be completely honest, I would need to be incentivized somehow to implement that kind of functionality. It is very much possible, though.

Should I (or we, whichever you prefer) be doing something different in chaining the analog inputs? The way I've done it maxes out at 4 MUXes (64 inputs), the same as OpenDeck v3.

Your current method looks fine to me as it requires no changes whatsoever to the current firmware.

Should I add a 74HC4067 to the baseboard, and then use each channel of that to drive a different board? This would require 12 more pins on the header, which is why it's not my preferred option

That kind of setup isn't currently supported in the firmware.

Are you aware of anything that will make this not work?

As I said, not at the moment.

Are you aware of any limits to how many of these breakout boards we can stack, other than the 4 MUX limit mentioned before

In theory, there is no limit. The only limit is how much latency you're willing to tolerate, especially for analog inputs.

[wayland]

First, thanks for your very prompt reply! Much appreciated. Thanks for the compliments :) . As someone who's not trained in electronics, I'm pleased to know I've done something right :) .

Selling: I'm not planning on selling it, but I might send it to some circuit-boards-on-demand place (Olimex used to do that, and may still do).

MUXs:

• Regarding you having had to do something similar to the chaining, maybe then the ModularDeck concept would be useful to you in future projects
• Regarding the Analog MUXs, since I only need maybe 1-4 for what I'm looking at doing, I'll leave it as it is (and if we want more someday, we can make a ModularDeck V2 with a different pinout)

Keypad confusion:

• Yes, that was supposed to be KP7.
• In theory I could've squeezed in 11 keypads, but chose to go with 7 keypads and 16 unassociated buttons.
• I've drawn a (logical) diagram of what I'm planning with the buttons ( https://github.com/wayland/OpenDeck/blob/master/bin/sch/ModularDeck/3x3BreakoutBoard/v1.0.0/LogicalButtons.svg ) . Logically they're an 8x8 grid, and I'm planning that each keypad will have a breakout header, but that the individual buttons will be on a breakout header like the one you used (except the buttons and LED headers will be hopefully close to each other). Probably I should've chosen different colours, but I think you'll still be able to see what I'm aiming at. If I've failed to clear up the confusion, let me know and I'll have another go.

Modularity:

• Regarding not detecting IO, I could tell that there wasn't likely to be any, and that adding detection would be non-trivial and annoying. If it were easy, early computers would've been better at it :p
• Yes, I think the least bad option would be defining modules in the YAML, and then using the Web UI to set up the modules, and am glad to hear it's possible; would you be likely to accept pull requests for this?

Latency: Good point, and thanks. I think my application has a relatively high tolerance of latency, since it's more for switching lights/cameras between speakers, and doesn't have to eg. align with music or the like.

Thanks again for your useful and informative response, and hopefully this clears up some of the points.

[paradajz]

Selling: I'm not planning on selling it, but I might send it to some circuit-boards-on-demand place (Olimex used to do that, and may still do).

I've had good results with JLCPCB, and that's also where OpenDeck v3 boards have been assembled. Just FYI.

• Regarding you having had to do something similar to the chaining, maybe then the ModularDeck concept would be useful to you in future projects

For that particular project I've actually thrown modularity out of the window and did everything on a single, large PCB, but it might come in handy for something else.

• I've drawn a (logical) diagram of what I'm planning with the buttons ( https://github.com/wayland/OpenDeck/blob/master/bin/sch/ModularDeck/3x3BreakoutBoard/v1.0.0/LogicalButtons.svg ) . Logically they're an 8x8 grid, and I'm planning that each keypad will have a breakout header, but that the individual buttons will be on a breakout header like the one you used (except the buttons and LED headers will be hopefully close to each other). Probably I should've chosen different colours, but I think you'll still be able to see what I'm aiming at. If I've failed to clear up the confusion, let me know and I'll have another go.

Ah, now I understand. Thanks for the diagram.

• Yes, I think the least bad option would be defining modules in the YAML, and then using the Web UI to set up the modules, and am glad to hear it's possible; would you be likely to accept pull requests for this?

Of course. You would need to get really familiar with the codebase, though, since something like that would require you to deal with the code-gen scripts, database layout and SysEx layout as well. Also stuff in the board/IO layer.