Page 1 of 1

Soliciting Encoder Design Ideas

PostPosted: Sun Sep 16, 2018 4:44 pm
by jkinkennon
I'm working on another encoder that will again be open source hardware and software though this time I may actively pursue selling a few assembled versions. I do sell encoders from time to time but haven't pushed this as so far they have not been readily configurable without specialized software.

So this will be a full-featured pie-in-the-sky version that should still be a bargain either assembled or as a kit. The details are at

I'd like ideas about ribbon vs flex cable for matrix keyboards, any features that seem important, whatever comes to mind. Right now I'm leaning towards the Molex 6-pin connectors you can see on my web site along with screw terminals for the odd outputs for relays, LEDs, lamps and stuff that is never the same from one console to the next. I've used 20-pin IDC (ribbon cable) housings for matrix keyboards.

So far I haven't settled on any display device other than the conventional LCDs but I am open to suggestions.

Re: Soliciting Encoder Design Ideas

PostPosted: Sun Sep 16, 2018 6:47 pm
by murph
As a slight aside, a basic board with single kbd contacts that accomodates Fatar key-beds with attack. Make the code have a simple one line change that changes its ID. in HW, all done in Teensy 3.2. code.


The change ID bit makes life easy...... (Gt, Sw, Ch etc...)

Re: Soliciting Encoder Design Ideas

PostPosted: Mon Sep 17, 2018 1:39 pm
by jkinkennon
MIDI Boutique does such a nice board for Fatar keyboards that it would be like reinventing the wheel. When I needed a quick solution for adding Pianoteq to a console I used the which was great.

If someone wants to do the programming I could modify my Teensy 3.6 encoder to connect to a Fatar keyboard. I had intended to do a more capable Teensy encoder but ran into constraints. The PIC32MZ2048EFH has 6 fully buffered SPI channels that can run in 32-bit mode and buffer 128 bits (2 keyboards) per channel. The chip on the Teensy 3.6 has one fully buffered SPI channel with an additional 2 channels which are not buffered and not readily supported by the Teensyduino libraries.

I wonder how many PIC32MZ projects use the vast majority of the 144 pins on the largest of the PIC devices. I can run the entire project on a development system that makes 100 pins available except for implementing the 22x16 matrix that will be required (4-11x6 or 4-8x8). That won't happen until I have my own PCB in hand.

My goal is a $100 encoder for those willing to build their own. That will be a challenge with all the connectors adding to the cost.

Re: Soliciting Encoder Design Ideas

PostPosted: Sat Oct 26, 2019 5:36 pm
by jkinkennon
One year ago I posted my ambitious plans for a new encoder. I also acquired a kitten, now a cat who just walked across my computer's power switch and destroyed a half page draft of this post.

I am pleased that I've accomplished much of what I set out to do. Five prototype PCBs for the main encoder board arrived from Hong Kong and two are built and working great using the MCU modules from Micro Elektronica. I had a smaller trial board completely assembled by the same firm and am confident that they can handle the 144-pin MCU (pic32mz2048efh144) and do a second encoder version which will add four matrix ports and an ethernet connection -- that's nearly complete but will require a lot of extra data for the Hong Kong firm to do all the pick and place operations required.

The first version looks like this:


A second version will replace the piggyback MCU board including four matrix ports and ethernet connectivity for RTP-MIDI. Looking down the items from the first post I will be going to a mostly SMT circuit board with just the connectors being through hole devices. Features will include:

6 SPI ports for 12 channels of 64 inputs AND outputs each. 768 In / 768 Out
4 matrix manuals either 11x6 or 8x8
256 stops (Allen), 128 stops for conventional stops without drivers
4 serial ports for serial enabled LCD displays
8 analog inputs
8 open collector outputs for power relays, lamps, and similar
8 GPIO lines for use with status LEDS or as needed
4 outputs for an Allen capture supply
1 USB-UART console port will be removed to accommodate the ethernet MagJack
-- future console configuration will be over ethernet
I2C ports were omitted from both versions due to speed and reliability constraints
-- a new SPI-based IO board is a drop in replacement for the previous I2C board

So all in all version 1 looks solid and version 2 doesn't present major new challenges. The first version one board is slated for a huge 4-manual Allen with something like 157 drawknobs and couplers. When the second version is ready in a few months I'll post info on how to make one of your own. I should be clear that most connected devices, stops, pistons, and manuals go through external input boards. A DIY solution also looks to be extremely affordable for those who don't count the hours of labor involved.

Meanwhile I'm excited about the great new Teensy 4.0. Right now a lot of essential libraries are being written, but in the near future it will be another fantastic way to build a DIY system. Thanks to Robin at for those wonderful Teensy boards!

Re: Soliciting Encoder Design Ideas

PostPosted: Sun Oct 27, 2019 4:44 am
by csw900
Hi jkinkennon

A very interesting project - especially as I used to design and program specialised hardware myself before I retired. Its nice to see that after a year it is nearly complete.

However, you have said that your hardware encodes and decodes, but have not actually said what it is to be used for and why the same job could not be done by one of the recent stand alone and very versatile ready built and cheap microcomputer boards.

You have hinted that it is to do with encoding organ stops - the only "difficult" task that an organ has.

You have mentioned Allen, about the only organ maker who does not reveal how their organ's sound is produced.

Please give us a bit more detail.


Re: Soliciting Encoder Design Ideas

PostPosted: Sun Oct 27, 2019 2:33 pm
by jkinkennon
Sometimes I make assumptions about my audience. Clearly this is a MIDI encoder. The mention of 'decoder' is due to the fact that most MIDI decoders I am aware of are a separate device for handling stops or LCDs and not a part of the main encoder.

This new encoder is intended to handle all or most of the MIDI traffic between a VPO console and a computer running Hauptwerk. The communication channel is USB-MIDI both for the speed vs.5-pin MIDI and to eliminate the need of a MIDI port on an audio interface. The USB-MIDI interface is class-compliant so that it can connect to a PC or Mac without a custom driver. It just plugs in and works.

My intention in doing projects like this is to share an open source, open hardware solution that may interest those who want complete control of their encoder/decoder electronics and want to convert a console to be a VTO at a very low cost. At 71 years old I no longer have the energy or patience to do the kind of support that would be required should I sell boards. I do rework a console on occasion, usually one or two a year so I have a small hobby that barely breaks even. I also have the joy of knowing that a number of churches worship with a better organ than they could otherwise afford. Meanwhile I exercise the brain cells and keep somewhat active.

My mention of Allen has to do with having been able to reuse the Allen stops with their attached drivers and with the combination power supply in an efficient and cost saving manner. That, I think, has been a unique capability.

I do love the affordable Teensy boards as mentioned previously. I've built a small pipe organ combination system and have converted a couple of consoles using the Teensy 3.6 along with a board built primarily to put some of the Teensy ports on connectors.

Besides a number of encoder possibilities I also share input and output boards at OSH Park. These can be ordered from them or the design info can be downloaded if one wanted to order a larger quantity overseas. I have intended to keep everything as through hole designs so that the DIY people could order a board and parts. That's become all but impossible these days so now the new boards tend to be surface mount only except for the connectors. I keep them 'through hole' both for simplicity and to avoid extra costs where not every connector is needed. It seems that SMT IC's are cheaper than connectors.

Re: Soliciting Encoder Design Ideas

PostPosted: Sun Oct 27, 2019 4:35 pm
by engrssc
Lots of good ideas regarding making PCB's and using SMT IC's, etc:


Re: Soliciting Encoder Design Ideas

PostPosted: Sun Oct 27, 2019 6:00 pm
by jkinkennon
Ed, that video is very much the same method I use for building prototypes. I have a great little reflow oven and can get quality results for most boards. I didn't notice whether the gentleman was using lead-free solder but for myself I gave up the lead based solder ages ago. Lead-free does make rework MUCH harder.

Lately I'm learning that Hong Kong assembly prices are as good as the PCB fab prices. That's a godsend for me as the 144-pin chip is way too fine a pitch for all but the most skilled techs. I think it will be exciting to see a price on a fully manufactured board. A little fine-pitch level shifter I had assembled came back just perfect at about $1 each for 25. $2 each including DHL shipping which got me the boards in less than a week. I'm guessing that the encoder will come in under $50 each -- more or less depending on connectors.

I use Eagle for the PCB design. I've heard that kCad (sp?) is good on Linux. The only hassle with the assembly portion is that the firm doing the work needs the precise placement and rotation of every part in a spreadsheet that references their own stock numbers. That's a tedious bit of work but not as tedious as placing the components yourself under a magnifying glass.

Re: Soliciting Encoder Design Ideas

PostPosted: Tue Oct 29, 2019 5:07 am
by csw900
Hi jkinkennon

Thanks for the extra, very useful, information.

Looking at the PCB assembly video I certainly will not be self-assembling any PCB's using SM components.

I have had a look at your website and found what looks like this project - looked at the matrix schematic to get an idea of what was going on. I also looked at your software and with relief found it was written in c. A language I am very familiar with.

As you probably know I have produced a software organ, eplayOrgan, which currently needs a touch screen to input stops while playing. This works well, but it would be nice to be able to recommend a hardware method of inputting stops as an alternative. Your boards potentially look to be able to do this. eplayOrgan can currently accept stops only by sending it Allen's Universal NRPN's which require sending the stops on the same channels as the manuals. The idea behind this is that the stops can be permanently labelled and also be applicable to multiple different organs without ANY configuration by the user. As this is different from what HW needs I am wondering whether your board/s and software would be able to cope.

As this is a bit off topic for this forum it might be best if you respond with an email. (see 'About' on my website for my address).


Re: Soliciting Encoder Design Ideas

PostPosted: Tue Oct 29, 2019 5:36 am
by engrssc
Your discussion is prompting some interesting thoughts, thanks, 8)