GPS PCB design update

It may seem that there is not so much progress lately, but I’ve been working on GPS, EFIS, MCP and COM/NAV panel PCB designs in parallel and working on ‘volume’ production of all the dual rotary encoder parts.

During testing of the GPS PCB I thought to have found a problem in the COM and VLOC volume rotary encoder connections when the GPS PCB is connected via 40 pin cable directly to an OpenCockpits Master Card: rotary encoders must be connected to two consecutive inputs. I thought that I had taken this into account while designing the PCB, but I had missed the fact that only for the even pin numbers of the 40 pin connector two consecutive pins also have consecutive input numbers. For the odd pin numbers this is not the case.
The dual encoder connections all are OK, but the wrong COM and VLOC single encoder connections can be patched by swapping the encoder ‘up’ and transfer switch connections. With these two patches I was able to test the single encoders.

In fact this is not really a problem because X-Plane does not have an interface for the COM and VLOC volume functions, but I found this when temporarily using these encoders for the COM coarse and fine frequency dialing instead.


I’m still looking for a reliable interface with the X-Plane 11 GNS530 via the OpenCockpits hardware: initially I used the keyboard mapping but this didn’t work very reliable.

Because a lot of keys are already mapped to different functions of the simulator I used CTRL and ALT combinations for the GPS functions that don’t have a key mapping by default.
These key combinations are defined in the sioc.ini file. Via some OpenCockpit manuals (I found that one of them has incorrect information on the numbers to be used for SHIFT and CTRL) and examples I learned that SHIFT, CTRL and ALT keys are defined by \1 (SHIFT down), \2 (SHIFT up), \3 (CTRL down), \4 (CTRL up), \5 (ALT down) and \6 (ALT up). Both down and up must be specified in a key sequence.
Normal keys are uppercase by default, a lower case character needs an additional <

Example: in my SIOC script I programmed the GPS Menu push button to generate a key value of 106, in X-Plane I defined CTRL+SHIFT+m for the GPS Menu button and in the sioc.ini script I added a line
which means that key value 106 must generate a CTRL down, SHIFT down, lowercase m, SHIFT up, CTRL up key sequence.
This worked, but for some reason appeared to be not very reliable in X-Plane: it seems as if occasionally some of the SHIFT, CTRL and ALT up or down actions are missed causing very weird behavior because for Windows or X-Plane it then seems as if the SHIFT, CTRL or ALT key is still being pressed.
I learned that this could be ‘reset’ by pressing the SHIFT, CTRL and/or ALT keys on the keyboard, but this is undesirable.

I also learned that the cheap Chinese EC11 rotary encoders don’t work very well with OpenCockpits: the COM encoder that I temporarily programmed for coarse frequency dialing decremented the frequency no matter if turning the encoder knob up or down. Also clicks were missed when turning fast.
The fine frequency dialing by the VLOC encoder only kept toggling between one position up and down when turning the knob in either direction.

I’m not sure yet where the actual problem is, but decided to also test the GPS PCB with an Arduino Mega and the ArdSimX software and with this the encoders work fine.
Initially I also noticed occasional jumps when the encoders were rotated fast with this setup, but I found that this was ‘intended behavior’: there’s an acceleration feature for encoders in ArdSimX that can be used for faster incrementing and decrementing when rotating the encoders faster.
This can be switched off by a manual setting in the setup.cfg of ArdSimX and with that change the encoders work reliable.

Dual encoders on pin 46, 48 and 50,52, set to type 1, acceleration value 1

The used Arduino is a cheap Chinese clone: the USB driver for it is not automatically found by Windows 7, but after downloading a driver it works fine. It can be found on the internet by searching for ‘Arduino CH341SER.EXE’, but it’s also possible to download my copy here.


Although there are only a few patches required to the GPS PCB (which in fact are even unnecessary as there is no interface for the volume functions in X-Plane), a respin would have some advantages. In my original design the holes of the standard footprint that I picked for the push switches appeared quite narrow for the pins of the used switches.
Besides I meanwhile found other switches with the same dimensions that have a LED integrated, which is nice for better backlighting of the buttons.
And to make the PCB more suitable to interface with an Arduino board a jumper block was added to short the separate input and output grounds.

As I learned that very professional PCBs can be ordered cheaper at easyEDA than I can purchase double sided raw PCB board material I skipped the idea of creating the PCBs myself with the CNC router.
This also makes it easier to design double sided PCBs, which has become necessary with all the additional connections for the button backlight LEDs.

My initial GPS board design was routed manually, but during design of the EFIS and MCP boards I learned how to use the automatic FreeRoute router that be be used with KiCAD.

Unrouted MCP panel design in FreeRoute

With all these lessons learned a new v1.1 GPS double sided PCB has been designed with the COM and VLOC volume encoder connections fixed, larger holes for the switches with pins and routing for the LED backlights, additional backlight LEDs for the GPS panel, an extra connector to daisy-chain the unused connections of the 40-pin connector to some other cockpit board, a similar extra connector to daisy-chain the backlight power and ground and a jumper block to short all separate OpenCockpits grounds, for interface to an Arduino board instead.

I also thought about the possibility to make the GPS PCB an Arduino shield, for easy connection to the Arduino, but the video display driver board that is piggy backed to the GPS PCB is in the way.
Once the new PCB has been tested the files will be posted on this blog.

Meanwhile a first prototype of a 5mm 80% transparent opal plexiglass panel has been created with the CNC router and I’m practicing with spray paint to get an acceptable result. Next step will be engraving the panel texts. Most probably a second version of the panel will follow because the first one got a bit scratched after sanding because I wasn’t happy with the initial paint layer.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s