Welcome to Cockpitbuilders.com. Please login or sign up.

May 09, 2021, 07:53:07 AM

Login with username, password and session length


Fly Elise-ng
21 Guests, 0 Users
  • Total Members: 4032
  • Latest: vasekg
  • Total Posts: 57011
  • Total Topics: 7593
  • Online Today: 24
  • Online Ever: 582
  • (January 22, 2020, 08:44:01 AM)
Users Online
Users: 0
Guests: 21
Total: 21



Will Depart in...



Segment displays

Started by Mach7, November 02, 2020, 04:55:31 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.


Back to details.

The photo of the thumbwheel switches showed that there are diodes fitted. Are there diodes on all of the thumbwheels? Only one diode is needed on the +/- switch, but it doesn't matter if there are four.


Yes, each set of thumbwheel switches has diodes, there are 4 on each of the 0 to 9 and two on the + and -.


Ok. Cool. For the pushbutton switches I will suggest another four diodes, then they can all be put in a matrix which will use the I/O pins efficiently. That means four I/Os are currently free.

So, for all switches there are four defined inputs, which will connect to all of the thumbwheel 'numbered' pins. Currently pin '1' on the thumbwheels is connected to D2 on Arduino. All thumbwheel pin '1's are connected together.

Similarly, all thumbwheel pin '2's are connected together and to Arduino D3.

All thumbwheel pin '4's are connected together and to Arduino D4.

All thumbwheel pin '8's are connected together and to Arduino D5.

Then, the 'C' pins on the thumbwheels are connected to other Arduino pins. Tref units 'C' pin to Arduino D6. Tref tens 'C' pin to Arduino D7. Tref +/- 'C' pin to Arduino D8.

D9, D10, and D11 are free at the moment.

Later, TGT thumbwheels can be connected. Pins 1, 2, 4, and 8 as before. 'C' pins to A0, A1, and A2.

I think the pushbuttons are as follows:
TO is a latching pushbutton.
MCT is a momentary pushbutton.
TEST is a momentary pushbutton.
TGT is a latching pushbutton.

Each pushbutton will be connected through a diode to another pin (in this case, D12).

So, from D2 through a diode to one pin of TO, then from the other pin of TO to D12.
From D3 through a diode to one pin of MCT, then from the other pin of MCT to D12.
From D4 through a diode to one pin of TEST, then from the other pin of TEST to D12.
From D5 through a diode to one pin of TGT, then from the other pin of TGT to D12.

Thus, when D12 is high the switches have no effect on anything else connected to D2-D5. When D12 is low, the state of the switches can be read by reading D2-D5. It's a classic matrix design.

Similarly, by grounding the 'C' pins of the thumbwheels individually we can read each thumbwheel by reading D2-D5.

The diodes stop other switches in the same row from affecting the switches in the selected column.

I could draw a schematic, but I haven't tested it all yet. When your Arduino arrives you can connect a single thumbwheel and test it, then add another and see that they work independently, and so on.

Although I have written the bulk of the firmware now I won't post it in one chunk. I will suggest that you test each part and then try the whole thing. That way you can see how all the parts work, and how they fit together.

I know you haven't done anything with Arduino, but have you done any programming of any type?


Hello Andrew, yes...a little bit of programming using 629 chips for PWM gauges using the Melabs programmer.

I have never written a word of code in my life, but I had a close friend of mine in the UK, (Peter Barnes) who would write the code in notebook format...i would run it though MPLAB IDE change it to gcode...then download it with the programmer from my laptop.

That is the beginning and end of my knowledge stream....although Peter did show me how to manipulate the code somewhat to change needle movement etc etc....,


And yes...you are correct about the switches

Takeoff is latching
MCT is momentary
TGT is latching
Test is momentary.

A diagram would be greatly appreciated when it is all said and done.

Not sure when the parts will arrive....the lead time is 15 to 30 days:(


Quote from: Mach7 on November 09, 2020, 08:26:20 AMAnd yes...you are correct about the switches

Takeoff is latching
MCT is momentary
TGT is latching
Test is momentary.

A diagram would be greatly appreciated when it is all said and done.

Not sure when the parts will arrive....the lead time is 15 to 30 days:(

Ok. Do the thumbwheels all have diodes?

Also, is this the first time you have ordered from AliExpress? Lead times were variable in the Before Times. Now, moreso.

Here in New Zealand we have some local stockists who sell on the local equivalent of eBay. The prices are a little higher for the same thing, and delivery is not free, but it's stocked locally so you can get stuff much quicker. Anything like that where you are?


Yes, all the thumbwheels have diodes...there are 4 diodes on each of the 1 to 9 digit wheels and two on the plus minus wheel.

We do have an electronics shop here, but they don't stock a lot of product:( I have checked with them in the past and they can order the items...but I can get them just as fast at a better price.


Ok. Now we wait.

Well, you do.

Sorry, I already asked about diodes, and you already replied.

If you were going to build a panel identical to the original I'd suggest the HT16K33 as it supports many more LEDs and has a matrix switch scanner. It only needs two wires back to the microcontroller. I'm going to use one for the KT76C I am working on in another thread in this forum. Waiting for parts from AliExpress...

However, your reduced requirements can easily be handled by the Arduino, and the TM1637 is very easy to use, so it's definitely a goer. I haven't been pushing the HT16K33 too hard as I have only used it with a Raspberry Pi. I haven't used it with Arduino yet, although I see there is a library for it, so it should work.

I hope that other people reading this thread will get curious about building standalone widgets to fit in the cockpit. It's probably as compelling as the 'connected' devices that are being made.


Andrew, you are absolutely correct on your comment regarding stand alone wigets versus connected devices.

for example, my hydraulic panel operates identical to the real aircraft, as does the landing gear selector lamps, however they do not communicate with flight sim, except for an output from the gear lever to the 836x joystick board for up and down information to FS9.

I have a number of items that work independent of the flight sim program, but to the operator it all appears seamless.


As i type this, my 3D printer is busy building me another TMS CDU...will inlcude a pic when it is done...should be another 26 hours or so of printing...


Quote from: Mach7 on November 09, 2020, 08:26:20 AMAnd yes...you are correct about the switches

Takeoff is latching
MCT is momentary
TGT is latching
Test is momentary.

A diagram would be greatly appreciated when it is all said and done.

Not sure when the parts will arrive....the lead time is 15 to 30 days:(

Do you want latching switches? I mean, are they latching on the original device? Or do you want to use momentary buttons for all four, and have the latching behaviour done in software?

Either is easy. Currently I have it set up as you specified, with two physically latching buttons.

Regarding a schematic, have you used any schematic capture software, or do you have a preference? My preference is for KiCAD, but I could dump it as a PDF very easily.


Hello Andrew, i think i will stick with the original plan regarding the switches, but thanks for asking.

I am not good at reading schematics, so to give you an example of what I did in the past with Peter Barnes...he would write the script and identify which output ports had to go where off the 629 chip, and after i programmed said chip i would draw out a plan on how i was going to solder it up...i'll include a pic of an example of one of my breadboards.

I am thinking (hoping) the Arduino connection(s) will be somewhat straight forward as well.



Ok. No worries.

Did your 3D print finish?

I hope your components arrive soon. The Arduino is the core, so when that arrives you can start getting up to speed.

Wiring is really up to you, but it can get quite untidy quite quickly. If you have any common techniques that you like to use then I am sure you can apply them here. In this project there are no special things to be careful about, just a bunch of wires from the Arduino to the other parts.

The Nano screw-terminal block is handy for prototyping, but you can solder wires directly to the Nano later to save space. You'll probably also need some way of connecting several +5V lines and GND because you can't jam many wires into the screw terminals.

I suggest that you will build everything as a rat's nest on the bench first, then figure out how to put it tidily behind the front panel. Luckily, although matrix wiring is a little more complicated, there are fewer wires.

You will see other examples of "behind the scenes" on this website, some tidy, some still a rat's nest. I am sure you have figured out how to hook things up and make them work.

I'll do a schematic and use it to talk about the actual components. I think it will become clear to you. I am enjoying helping on this project because it is very well defined and has a clear finish point.


Hello Andrew,

I actually ordered one of those nano boards with the screw terminals, so I might utilize that depending on available space.

The good think about the CDU is that i have all kinds of space behind the unit within the confines of the panel cutout.

I agree 100 percent with bench testing and setting it up before I tidy up the final product for installation...that is basically how I have approached the entire project.

The print is complete...i had some issues with the nozzle and print quality, so I ended up doing the entire print over again....that seems to be a normal aspect of 3D printing...for me anyway.

The TMS CDU was printed in basically three parts...the bottom portion holds my AML21 series switches, then there is the top face CDU, then the individual buttons which are designed to hold an LED.

The switches will be glued to the AML21 button so they don't fall out.

You might ask why I just didn't use the buttons directly...its a long story but suffice to say I wanted the unit to look as 146 specific as possible. I could have used the original switches form the real CDU..but they are dark, dirty and worn out...I wanted something fresh and new looking..

My current TMS CDU was constructed with the exact same principles, and nothing has fallen off or failed on it yet...so i stuck with what works.

The print will look a lot better after I sand down the rough edges and paint the unit....there is a lot of excess plastic on the buttons right now due to the printer brim...but after I clean them up they will slide nicely in and out.

I have included some pictures....

Just another question for you regarding the TREF thumbwheel input...we talked about N1 values in 5 degree increments...if the wheels are set at something in between...say 17 or 18 degrees...what will the LED value read?

I am assuming that it would read the +15 value at 16,17,18,19, then change to the 20 degree value at "20"...this is of course a perfect setup for me...just curious if we are on the same page.



November 11, 2020, 11:31:05 AM #64 Last Edit: November 11, 2020, 12:05:36 PM by ame
Nice print! It will look fantastic once everything is "animated" and things light up.

Regarding N1 display- the device will do what you specify it will do.

Currently you listed N1 per 5 °C steps. I used your list to derive a linear function. The function will return N1 for any input value of Tref. I showed some sample output where Tref was stepped up in 5 °C increments, but that was just to keep the message short.

I may have mentioned already that there is no magic. The output for any input can be specified in advance, or determined by examining the code.

If you want discrete values of N1 based on Tref changing by 1 unit, that's fine. If you want N1 to change only when Tref is on a multiple of 5 units that is also fine. If you don't specify it you get my interpretation of what I thought you wanted. If what you get is not what you want it can be changed.

While we (you) are waiting for parts we can discuss minutiae like this.

What range of Tref do you want to deal with? The thumbwheels will allow you to select -99 to +99. If your expected range is -40 to +40 then what do you want to happen if the thumbwheels are set beyond that range?

Then, specifically, what is the relationship between N1 and Tref? Do you want N1 to change when Tref changes by one unit? Do you want it to change only when Tref is a multiple of 5?

The function for N1 can be implemented as an algebraic equation (e.g. y=mx + c) or as a lookup table (literally a list of expected values of Tref and the corresponding value of N1). We talked about pressure being constant, but it could be incorporated into the formula even though it doesn't change.


I actually did not know we could be that flexible with Arduino...this is exciting!So yes...lets have the N1 change with each degree of temperature, hitting the target (listed) N1 values at every 5 degrees.

To answer some of your questions..if we could have a temperature range then -40 to +50 would be the temperature range we would need. Going outside of this range would never happen as it is outside the aircraft's operating limitations for takeoff and landing anyway.

If we were to go from -40 to +50, I will send you the complete thrust values within these temperature ranges based on a pressure altitude of between 0 and 1000 feet. (The chart is graduated in 1000 foot chunks of pressure altitude, and the temperature range is graduated in 5 degree increments)

Like you stated earlier, to get those in between N1 values would be nothing more than a applying a linear function between the temperatures to in order for the N1 to change a small amount in single degree increments.


Arduino is basically a tiny computer. It can read input pins, drive output pins, interface with other chips, communicate via serial and other means, and do maths.

If you ever had a home computer in the 80s, an Arduino has similar processing power. So it can do a quite a lot, but has limited resources.

I know that you won't select a value of Tref out of range, but I need to know what to do if you do. If you go above or below the top and bottom of the range the calculation for N1 can still be made, and the result can be displayed, but maybe that's not what you want.

You could, for example, clip the values to the range, so that anything over 50 is treated as 50, and anything below -40 is treated as -40. Or you could detect that Tref is out of range and display an error message, or three "-" signs, or blank the display. Or something.


Now you have me thinking....I flew the real 146 for 23 years and never dialed in any values above or below the limitation, so I am not sure exactly what would be displayed on the display....but for sure there must be something displayed.

I will dust off my TMS manual and see if it has information regarding this.

I am thinking maybe we can display ERR for error if a value below -40 (starting at 41), or above +50 (starting at 51).


Yup. Can do.

The same goes for all other weird but possible conditions. Even if no-one would actually do it I need to know what to do. Even if it's "do nothing".

A QA engineer walks into a bar...


November 12, 2020, 12:20:55 PM #69 Last Edit: November 12, 2020, 12:22:24 PM by ame
Ok, attached is a draft schematic. It looks a bit busy, but if you look at any individual component, or any single line to the Arduino it's pretty clear. I can talk you through it, but here are the key details:

TM1637 needs power, ground, and two data lines. The symbol shows four LED digits, but you will have replaced the 4-digit module with a 3-digit module.

The thumbwheels have diodes built-in, but I am showing them as discrete components so that you (or anyone else reading) will know they are supposed to be there. You can see that each switch line (1, 2, 4, and 8 ) is connected to the same line on all the other switches. i.e. all 1's are connected (to D2), all 2's are connected (to D3) etc. But, the C lines for each individual switch are connected to different pins on the Arduino. That way, we can turn on the C line for each switch one by one, read the switch value, then turn it off and move on to the next one. This forms a matrix, which is an efficient way to have many switches with a few I/O pins.

LED1 is the TO LED you asked for. It is turned on and off by D9 under software control.

RV1 is the dimming potentiometer that you didn't ask for. Its value can be read, and then a brightness command can be sent to the display.

That's it. I will send code later.


November 12, 2020, 02:01:47 PM #70 Last Edit: November 12, 2020, 02:03:58 PM by Mach7
Andrew...your schematic is a piece of art!..thank you!

Although I am sure I will have some questions, your drawing is very straight forward and easy for me to understand.

I have attached the thrust setting chart as promised. As you can see the chart goes beyond the -40 to +50 range, but the Aircraft certification does not, so I will stick with the -40 to +50.

As discussed, the -40 N1 value increases to it's peak at +15, (zero feet pressure altitude), then begins to decrease again.

I had a couple of emails over the last couple of days from Aliexpress telling me some of the parts have been shipped!



Andrew, let me know if the chart is legible, I saved it as a jpeg file assuming you could zoom in on the values.

I can try and send a better format if you want..let me know



Yup. Legible. Thanks.

Glad you like the schematic. It is drawn with KiCAD, which is a great free schematic program and PCB design package.


Andrew, just familiarising my self with the schematic as I can most likely begin connecting some of these items up while I wait for the parts, most notably the takeoff, mct and tgt buttons to the thumbwheel switches.

In reviewing  the diagram, i notice that all of the  aforementioned switches are connected to both the Tref and the TGT thumbwheels...

I was just curious as to why the takeoff button would need to be associated with the tgt thumbwheels and visa versa...but most likely that would be taken care of with t the programming software (?)



Good question.

I'd recommend holding off with construction until the Arduino arrives. I've drawn the schematic based on my understanding of multiplexing thumbwheel switches, but I don't have any to test it.

Since you do have the switches, I propose that you hook up a couple of them to the Arduino, confirm that they work, then carry on.

The principle is described here


and here


So I am confident that it will work.

I might have to put some code in to handle the case where the readings jump around during the change between numbers, but I have already thought of some solutions to try if necessary.

To answer your question, a switch is just a switch. Once the state of the switch has been captured we can assign meaning to it. The method of capturing the switch state is entirely independent of its meaning (and this is an important and key point).

The thumbwheels are essentially just four switches, mechanically and electrically bound together. Since I am using a common technique to read the thumbwheels (as a series of 4-bit reads) it was expedient to treat the other four switches as just one more group of switches like the four switches in the thumbwheels. The diodes are necessary to stop any actuated switches in one group from affecting the readings made from another group.

In the software I use the matrix scanning technique to get the state of all the physical switches, then assign meaning to them in groups (the thumbwheels) groups of groups (the value of Tref or TGT) or individual switch states (TO, MCT, TEST, and TGT).

Anyway, asking the question tells me that you actually read and thought about the schematic, which I thoroughly appreciate. Thank you.

Like the Website ?
Support Cockpitbuilders.com and Click Below to Donate