One of the the challenges I face is to find the proper way of wireing all the components, so that the cockpits remains “maintainable”. When I started building the pedestal my central component, so to speak – was a bread board. The Arduino, the Multiplexer boards, the 7 Segment PCB, everything is connected to it. While this works, it’s not a robust and long term solution.
Especially now, that I want to start adding more inputs and also LEDs into the Pedestal (the Cargo Fire Panel will be the next instrument) i have to find a solution for that messy setup.
Speaking of LEDs. SimVim recommends a couple of LED drivers to use, which is nice. My personal problem is, that I like to order IC and other components via Digikey and they don’t offer any of the ICs listed to be used a LED drivers.
So I was looking for an alternative to the often mentioned DM13 LED driver and found the STP16CPC26MTR. The specifications are almost identical and they work like a charm with SimVim aswell.
For inputs I used the SimVim recommended CD74HC4067 multiplexer cards. Currently I am working on another PCB which will use the IC directly (CD74HC4067M96) to combine In- and Output functionality and hopefully the days of the breadboard and “messy” setup are over.
After getting the 7 segment LEDs working on my XPDR, I continued with my already existing COMM and NAV instruments. I used a breadboard aswell and they worked like a charm. The only problem was the sheer amount of cables to connect the segments to the drivers and frankly a breadboard + some cables didn’t really sound like a good permanent solution.
To fix that problem, I decided to design my own PCB for that case. I used kicad last year and started designing a PCB which I planed to use for a Boeing Style FMC, but I didn’t finish until now. Thanks to Chriz2600 , a colleague of mine (and by the way a real pro in the field). I got quite a lot of help from him in getting started with Kicad and PCB design. If you are into Retro gaming, you must check out his projects!
The idea for my PCB was to organize the 7 segments by Instrument and driver, meaning I’d use 1 driver per display (e.g. the COMM panel would need 2 ICs, one for ACT and one for STBY frequency). Since the drivers – as stated before – are actually pretty pricy, the conecpt is maybe not optimal, especially because you can drive up to 8 segments per IC, but I’d only need between 4 (for the transponder) and 6 (for COMM). In terms of structure on the board, I decided to place male pins left and right IC, the left side for the segments, the right side for the digit. The chips are aligned according to their position on the pedestal. In the end, I came up with the following design:
As you can see, the first row is reserved for COMM Panels. One on the Captain’s side, one on the FO’s side. Of course they can be used for other instruments, if needed.
The second row is for the NAVS (Captain’s and FO’s aswell) and the last IC is for the XPDR.
RV1 is reserved for a potentiometer, which allows to adjust the brightness of all the instruments used. MUX1 is used to connect the PCB to a multiplexer card. Numbers 1 through 9 correspond to the IC (from left to right. Meaning COMM1_ACT is MUX1 1 and XPDR is MUX1 9). DIN_CS1 are connected to the corresponding Outputs of the Arduino (aka D and L).
For manufacturing I decided to go with Aisler. From placing the order to receiving the PCBs it took around a week. The price is ok aswell: 3 PCBs cost 33 € (incl. shipping).
Soldering was easy for the most parts, since all connectors are just simple through hole. The SMD ICs were a bit tricky in the beginning though. What helped was to fix them in position with a bit of tape. You can leave it on until you’re completely done, since it can also act as an indicator if the chip maybe got a bit too hot and you should wait a bit before continueing to let it cool down.
Initially I just finished the transponder part to check if there were any general problems with the layout. This is what the first try looked like.
To be honest I was kinda surprised that it actually worked. 😀
Since I tested the functionality successfully, I continued with COMM1 and NAV1.
After soldering all required ICs + connectors I hooked up the instruments, to see if all of them worked as expected, and they did, safe one. NAV1_STBY did not show anything at all, not even one single digit.
I started checking if the digits were ok by connecting them to one of the other ICs. They were. Next thing was to check the cables. They were ok aswell.
So it was a problem with the PCB or maybe even the IC itself. So i got the card out the pedestal again and checked all connection between the pins and contacts on the IC. I turned out, that Pin1 (which is DIN) was not soldered correctly to the PCB. There was soldering on the foot – but only on the foot. No soldering tin between the connector and the PCB itself. It took me a while see that. I actually had to use a magnifying glass, it was almost impossible to see without it – at least for me.
After I corrected the problem, I hooked everything up again and finally all digits were up and running.
A problem that is still unsolved are the dot points. I the picture above you can see a single wire connected to COMM1_ACT segment nr. 8. The reason for that is, that I am using Opencockpit’s 7 Segment Display PCBs, which is a nice way of having an organized way of handling the connection to the digits. You just solder the digits to the board and you hook them up with 7 wires – for the segments – and n wires for the amount of digits you have on the PCB. The 8th segment – the dot point – is not wired. To get the dot point working – you have to directly wire the segment on the digit you want to use. When I used OC’s hardware, I wired both digits of ACT and STBY into one circuit and connected them to one pin of the outputs card. The MAX7219 IC can drive the dp seperately. For the moment ACT and STBY of both NAV and COMM are still in one circuit and are connected to the dp pin of the IC. This has the effect, that the dot point is brighter on the active side, than it is on the standby side. For the moment, this solution is ok, but I’ll need to rework that.
So after testing the Max7219 drivers and getting all desired digits to work, I gave Inputs a try. So the goal was to “migrate” my already working OpenCockpits instruments to SimVim.
In order to reach that goal, the easiest would have been to make OC’s Inputs card somehow compatible with SimVim, meaning I’d just need to find a way, of connecting the multiplexer cards. Well – it turned out, that the pin positions don’t correspond with the actual “Input” pin. In fact, they seem to be completely random (I guess they are not, but I didn’t really bother yet to dig deeper).
So instead I disconnected the wires of my transponder from the Screw Terminal crimped them and put a connector on them to try it out.
For the transponder we are talking about the following components, which needed to be connected and configured:
1 Momentary Push botton (used for IDENT)
2 rotary Encoders (used for outer and inner Squawk)
1 Rotary switch (Used for modes)
After hooking them all up to the breadboard I gave SimVim’s configurator a go, created the config, fired up X-Plane AAAAANDDD it worked. At least thats what I though initially. The rotary switch – well – switched through the modes. But when hitting ‘TA/RA’ (which was configured to be on ‘C5’ of the multiplexer Board, SimVim got input from IDT, which was configured on channel 9. I checked and double checked the wires an connectors, but only the ones from the instrument to the multiplexer board. It turned out,did a mistake hooking up the address lines to the multiplexer board, resulting in mixed up addresses. So, instead of address 0101, Arduino got 1001. In the end I decided to redo the wireing completely and the problem was solved (to be honest, I really need to improve my cable management).
It still looks like a mess, but hey, at least it worked!
After I had my SimVim config done and everything looked good that far, I also connected the 4 digits I previously used with the transponder to the prototyping PCB. Last time I soldered one Max7219 driver to a blank PCB, added some male pin header and starter connecting Segments and digits. As you could see in my previous post, I already had the segments working that far. I added them to the config and hey – I got my transponder working again!
Since this is just a prove of concept, I’m looking forward to redoing all cables, connectors, etc. in a nice, clean way.
Ok, here we go. 2 weeks ago I ordered a Arduino Mega which arrived within 2 days. After unpacking I installed the software following the installation guide and that was it!
The first problem I want to get out of the way is how to drive 7 Segment Displays! For that I ordered a couple of Max7219 display drivers. Initially I planned on using SN74HC595 and multiplex the 7 segment LEDs. I even had a working setup, which I implemented with an Arduino UNO + some NPN transistors (even though it took me a while to understand how Transistors even work :D). Well in the end I managed to get 4 7 Segment LEDs running with just 1 IC! Great!
One on of the very first tests looked like that (with 2 Segments connected)
BUT; there was a problem. The 74HC + NPN transistor solution worked as follows:
Set LatchPin LOW
shiftout Data via Output to ClockPin
Set LatchPink HIGH
Turn on first LED (by setting the Output pin connected to the first transistor to high)
Wait 2 ms turn LED off and continue with second Number + LED
As you may notice the information about every number I wanted to have displayed was sent via 1 Output pin (the one connected to the CLK pin). Which 7 segment LED was actually used to display [meaning which LED was to be turned on] this specific number was controlled via another OUT pin.
SimVim uses a different logic:
The configured Output pin is the connection to the CLK pin of the IC / driver, there would be no way to multiplex 7 Segment LEDs with just 1 IC. Since I used the 74HC ICs I’d need to use 1 IC per LED.
This is how I ended up buying a couple of Max7219 drivers. These drivers are pretty expensive, compared to the shift register I used before (around 8€, compared to around 0,50 €), but you can control up to 8 Digits with just one driver. They arrived at the end of last week, soldered one onto a protoyping board and it worked! (Pictures follow)
So for the moment I’m trying to figure out a nice way of soldering and wireing the LEDs: