Cockpitbuilders.com

sign up .

November 27, 2020, 11:37:36 am

Login with username, password and session length

PROUDLY ENDORSING


Fly Elise-ng
13 Guests, 2 Users
Members
Stats
  • Total Posts: 56376
  • Total Topics: 7506
  • Online Today: 29
  • Online Ever: 582
  • (January 22, 2020, 08:44:01 am)
Users Online
Users: 2
Guests: 13
Total: 15

COUNTDOWN TO WF2021


WORLDFLIGHT TEAM USA

Will Depart in...

Recent

Welcome

Segment displays

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

Previous topic - Next topic

0 Members and 2 Guests are viewing this topic.

Mach7

Thanks Andrew...good idea...ill wait for the other parts to show up and then we can bench test.

Also, I am not going to put a dimming circuit as per schematic, as I have no room to install it on the CDU...if I leave out the dimming potentiometer from port 26 (A7) on the Arduino board do we have to revise that connection?

Jim

ame

Glad you agree. I am confident that the individual sections of the design will work, but I don't want you to build everything in one go and then become disappointed because I overlooked something. Plus, it's going to be a bit fiddly.

Regarding the dimming pot. You have several options, but it's there because I wanted to play with the dimming function of the TM1637 driver :)

Options include, but are not limited to:

Fixed brightness value in software. If you want to change it, edit the code and upload it to the Arduino again.

Software variable brightness. Change the brightness somehow in software. This could be by hooking up the Arduino to a PC via USB and sending a command through a serial terminal program to change the brightness. Or something devious like "hold down the TEST button at power-up and use the lowest digit of Tref to set the brightness" or "hold down TEST and MCT at the same time any time". We can store the last chosen setting in permanent memory so it's the same the next time the Arduino is powered up.

Hide the pot. You could keep the pot, so that you can alter the brightness freely, but put it behind the panel, so you have to unscrew the panel to change it. Or run longer wires to a hidden part of the cockpit. Or mount the pot in a way that is accessible by a screwdriver through a tiny hole in the panel.

To be honest, I expect you will want to alter the brightness at some point, so it's worth thinking about how you might do it. In general terms the brightness is a number from 1 to 8 (or 0-7 if you like) and it has to come from somewhere. It can be a constant that is loaded once at startup, but if it is intended (or required) to be changed then the method of changing it must be decided and implemented.

ame

I entered the data for N1 into a spreadsheet and drew a graph (attached). It's quite interesting.

It looks like the left side of the graph (before the inflection point) is linear, and on the right side, mostly linear. I know you only want one line of data, but it would be worthwhile to consider how to implement the function for Tref and PA inputs (and why!? Why is one parameter metric, and the other is not?!?!!).

Currently I have a linear formula, but it does not deal with the inflection point, so I need to re-implement it. I will start with a lookup table (with 5 degree resolution) and consider interpolating it later.

The lookup table is basically a two-dimensional array. One dimension would be PA (from -1 to 15, in steps of 1), the other dimension would be Tref (from -50 to 60 in steps of 5). Given Tref and PA we can round Tref to the nearest multiple of 5, then use it with PA as an index into the table. The table contains N1 for that combination of PA and Tref.

Even if PA never changes, the table approach is worth investigating although, obviously, the function will always select the same row of the table.

I'll probably return zero for N1 if PA is out of range, or Tref is out of range, or Tref lands in one of the blank spaces in the table. Then, the display function can display the actual returned value or '---' if the result is zero.

In programming terms there are good reasons for implementing things like this as tables, or as mathematical functions. There is always a trade-off, so you have to decide what's "best". Tables are really fast, for example, but take up a lot of space. Functions are small, but can take a lot of time to execute. As for which is best, as always "it depends".

ame

I can't attach an Excel file, so here's the raw data. I'd appreciate if you could confirm the numbers match the chart you posted, although only the Alt=0 row is important.

    Tref (°C)
Alt -50  -45  -40  -35  -30  -25  -20  -15  -10  -5    0    5    10   15   20   25   30   35   40   45   50   55   60
15      96.7 96.7 96.7 96.7 96.7 96.3 95.7 95.1 94.7 94.3 93.9 93.5 92.6 91.7 90.8 90.0 89.1
14      96.7 96.7 96.7 96.7 96.7 96.4 95.8 95.1 94.8 94.3 94.0 93.6 92.8 91.9 91.0 90.2 89.3
13           96.7 96.7 96.7 96.7 96.5 95.9 95.2 94.9 94.4 94.1 93.7 92.9 92.0 91.1 90.3 89.5 88.4
12           96.7 96.7 96.7 96.7 96.5 96.0 95.3 94.9 94.5 94.1 93.8 93.0 92.2 91.3 90.5 89.6 88.6
11           96.7 96.7 96.7 96.7 96.6 96.1 95.3 95.0 94.6 94.2 93.9 93.1 92.3 91.4 90.6 89.8 88.7 88.2
10                96.7 96.7 96.7 96.6 96.1 95.3 95.1 94.7 94.3 94.0 93.3 92.4 91.5 90.7 89.9 88.9 88.3
 9                96.7 96.7 96.7 96.6 96.2 95.4 95.2 94.7 94.4 94.0 93.4 92.5 91.7 90.8 90.1 89.1 88.4
 8                95.5 96.4 96.7 96.6 96.2 95.5 95.2 94.7 94.4 94.1 93.5 92.6 91.8 90.9 90.2 89.2 88.5 88.0
 7                94.3 95.2 96.1 96.7 96.2 95.5 95.2 94.7 94.4 94.1 93.6 92.8 91.9 91.0 90.3 89.3 88.6 88.1
 6                93.0 93.9 94.8 95.7 96.2 95.5 95.2 94.8 94.4 94.1 93.6 92.8 92.0 91.1 90.4 89.5 88.6 88.2 87.7
 5           90.8 91.8 92.7 93.6 94.6 95.5 95.5 95.2 94.8 94.5 94.2 93.6 92.9 92.0 91.2 90.5 89.6 88.7 88.3 87.8
 4      88.6 89.6 90.5 91.4 92.3 93.2 94.1 95.0 95.2 94.8 94.5 94.2 93.7 92.9 92.1 91.1 90.6 89.8 88.8 88.4 87.9
 3      87.5 88.4 89.3 90.3 91.1 92.1 92.9 93.8 94.7 94.8 94.5 94.2 93.7 92.9 92.1 91.2 90.6 89.8 88.9 88.5 88.0 87.6
 2 85.3 86.2 87.1 88.0 88.9 89.8 90.7 91.6 92.5 93.3 94.1 94.5 94.2 93.7 92.9 92.1 91.3 90.7 89.9 88.9 88.5 88.0 87.6
 1 84.0 84.9 85.8 86.7 87.5 88.4 89.3 90.2 91.1 91.9 92.7 93.6 94.2 93.7 92.9 92.1 91.4 90.7 89.9 88.9 88.5 88.1 87.7
 0 82.8 83.6 84.5 85.4 86.2 87.1 87.9 88.8 89.7 90.5 91.3 92.1 92.9 93.7 93.0 92.2 91.4 90.7 89.9 88.9 88.6 88.1 87.7
-1 81.7 82.5 83.3 84.1 84.9 85.7 86.6 87.4 88.2 89.0 89.9 90.7 91.5 92.3 93.0 92.2 91.4 90.7 89.9 89.0 88.6 88.2 87.8

ame

Ok, well it looked fine until the forum software squeezed it into a narrow column.

Mach7

Actually, hiding the pot behind the CDU is a great idea...so we will go with that and implement the dimming circuit!.

Yes...aviation is a bit odd...but it has always been that way...altitude is always in feet and weather reports, thrust calculation etc etc have always been in celcius.

with respect to the pressure altitude calculation, I think i will stick with a constant on that one,(that being the discussed 0 feet).

The chart values do not have to be 'exact' as well...for example if the N1 chart says 93.7 and we decide that a linear constant will equate to 93.4, then that is fine as well.

Ill take a look at the chart tomorrow...at first glance it appears confusing to me due to the format...but I will try and figure it out...

I am assuming that the values correspond to zero feet pressure altitude line that I sent you...as long as the 5 degree increment numbers are close to accurate, then the linear constant between those values does not have to be exact, as long as it shows an increase up to +15 degrees C, then a decrease as oat increases to +50
Jim

ame

Yes, the forum squished the result. It's actually the whole chart, with all N1 values for all pressures and all temperatures.

I've implemented a lookup table for this, although only one row of the table (PA=0) will be used.

I will look again at the PA=0 row and see if I can implement it as two linear equations, for the left and right part of the graph. That will allow you to have N1 values for any value of Tref, and not just for 5 degree steps.

Glad you agree to use the pot. Even if you only adjust it after you finish building it is useful to have and probably frustrating to not have.

ame

This is the same table, but printed from within the firmware. If you copy and paste it into Notepad or something, with a fixed-width font, it should all line up.


  0 967 967 967 967 967 963 957 951 947 943 939 935 926 917 908 900 891   0   0   0   0   0
  0 967 967 967 967 967 964 958 951 948 943 940 936 928 919 910 902 893   0   0   0   0   0
  0   0 967 967 967 967 965 959 952 949 944 941 937 929 920 911 903 895 884   0   0   0   0
  0   0 967 967 967 967 965 960 953 949 945 941 938 930 922 913 905 896 886   0   0   0   0
  0   0 967 967 967 967 966 961 953 950 946 942 939 931 923 914 906 898 887 882   0   0   0
  0   0   0 967 967 967 966 961 953 951 947 943 940 933 924 915 907 899 889 883   0   0   0
  0   0   0 967 967 967 966 962 954 952 947 944 940 934 925 917 908 901 891 884   0   0   0
  0   0   0 955 964 967 966 962 955 952 947 944 941 935 926 918 909 902 892 885 880   0   0
  0   0   0 943 952 961 967 962 955 952 947 944 941 936 928 919 910 903 893 886 881   0   0
  0   0   0 930 939 948 957 962 955 952 948 944 941 936 928 920 911 904 895 886 882 877   0
  0   0 908 918 927 936 946 955 955 952 948 945 942 936 929 920 912 905 896 887 883 878   0
  0 886 896 905 914 923 932 941 950 952 948 945 942 937 929 921 911 906 898 888 884 879   0
  0 875 884 893 903 911 921 929 938 947 948 945 942 937 929 921 912 906 898 889 885 880 876
853 862 871 880 889 898 907 916 925 933 941 945 942 937 929 921 913 907 899 889 885 880 876
840 849 858 867 875 884 893 902 911 919 927 936 942 937 929 921 914 907 899 889 885 881 877
828 836 845 854 862 871 879 888 897 905 913 921 929 937 930 922 914 907 899 889 886 881 877
817 825 833 841 849 857 866 874 882 890 899 907 915 923 930 922 914 907 899 890 886 882 878

ame

This is the data from PA=0

828 836 845 854 862 871 879 888 897 905 913 921 929 937 930 922 914 907 899 889 886 881 877

There should be a decimal point there, but it's easier to use integers in Arduino, so that's N1 x 10.

Here's the same line from Excel (actually, I am using LibreOffice):
82.8   83.6   84.5   85.4   86.2   87.1   87.9   88.8   89.7   90.5   91.3   92.1   92.9   93.7   93.0   92.2   91.4   90.7   89.9   88.9   88.6   88.1   87.7

And, attached is a graph of the two sections of the data either side of the inflection point.

As you can see, the left side is pretty much linear. But the right side its a bit off.

Are my numbers right? If they are then you can choose linear-with-differences-from-the-original, or table-lookup-with-interpolation-between-5-degree-points. Neither of which I have implemented yet...

Mach7

Hello Andrew...wow...the graph looks amazing, and yes...your values are spot on.

Why don't we go with the 'linear with differences from the original'

I am assuming that if we go with the aforementioned there will still be values displayed between 5 degree intervals...like at -12 or +14 etc etc ?

Also another question...since Arduino is calculating in integers, will it still display the decimal point when all is said and done...ie 937 or 93.7?

ame

Hi Jim,

The graphs were just plotted in LibreOffice Calc. Nothing special. I added a "best fit" line to show me the equivalent linear function.

The input will be Tref, which can have any unit value, so yes, the calculation will produce results for values in between the 5 degree points in the original table.

Regarding the display. Well, if you haven't realised by now, everything is an illusion. To convert integers to decimal I will just light up the appropriate decimal point. Don't be disheartened that it's all trickery. After all, nothing in the simulator is real.

I sent you a PM with a link to a draft of the code. Did you get it? A bit much to take in in one go, but everything we discussed so far is there, except the linear function we are talking about now.

Mach7

Yes!...got your PM and was reviewing the program...It sort of looks similar to the melaps program that I have been doing with 629 chips.

If I haven't said it yet I greatly appreciate the work you are putting in here..this (to me) is no small task!

With respect to line 110

DISP_TEST, // Test button is pressed. Show test value until it is released.

can we change that so when the test button is pressed and released, the fault code of F14 remains on for 6 seconds?

Looking at your code I might be able to figure that out myself....lets see how intuitive I am...

ame

Quote from: Mach7 on November 14, 2020, 07:28:04 amYes!...got your PM and was reviewing the program...It sort of looks similar to the melaps program that I have been doing with 629 chips.

If I haven't said it yet I greatly appreciate the work you are putting in here..this (to me) is no small task!

You're welcome. I enjoy this sort of thing, and it gives me something to do. In particular, I hope that others who are reading can see the steps involved and see that it's all possible.

QuoteWith respect to line 110

DISP_TEST, // Test button is pressed. Show test value until it is released.

can we change that so when the test button is pressed and released, the fault code of F14 remains on for 6 seconds?

Looking at your code I might be able to figure that out myself....lets see how intuitive I am...

But! That's not what you asked for... :)

The answer is yes, of course. Just think about what should happen if someone holds the button down for longer than 6 seconds, or presses the button again during the 6 seconds. Obviously, if you don't think about it it will do something, which might be what you want, or might be tolerable, or might be no good at all.

I'll leave the code alone for now. I still have to implement the two linear functions for N1, and I will implement this change for the Test button if you get stuck.

You can load the code into the Arduino IDE if you've installed it. You'll be able to compile it, but obviously not upload it to an actual Arduino, which in your case you have not got.

If you want to compile the code you will need to add the TM1637 library. Google around for how to do that.


Mach7

Hello Andrew,

I will be back to work tomorrow, but will check our thread from time to time through the week. Should be back on Saturday.

-Jim

ame

No worries. There's not much to be done until the hardware shows up.

Mach7

Andrew, as I wait for the parts, I am studying your schematic and working out ways in my head on how to wire up my switches.

I find the best way for me to understand is to make a simplified drawing with the parts in basically the same geographic location that they would be on the CDU.. and then draw connection lines as to how it would all connect up.

I have included a draft for your review, (excluding the diodes on the thumbwheel switches for simplicity,

Jim

Mach7

I realize your schematic says the same thing...but it helps me to understand what goes where when I draw it out a couple of times for myself.

ame

That's fine. The schematic is a logical representation, so the layout doesn't have to match reality, although it's handy if it does. I wasn't sure precisely where things would be, so feel free to move them around.

I could give you the KiCAD files if you like.

I have acquired three thumbwheel switches (actually they are pushwheel switches- turns out they are slightly different). I will add diodes (they are not present on mine) and I can test Tref input or TGT input, and either in conjunction with the pushbuttons to confirm they don't interfere. Will report back later.

Also I will study your schematic and let you know if you have overlooked anything.

ame

Ok. TO LED is missing. DIM pot is missing.

Tref_sign switch only needs pin 1 connection. Pins 2, 4, and 8 can be left disconnected.

TGT_units needs all four pins connected. You have missed 1 & 2.

Other than that, you have exactly the right idea. If the re-arrangement helps you picture how you're going to assemble it then you're on the right track.

I'll hook up the pushwheel switches I got sometime soon and test them out.

Mach7

Thanks Andrew...made the changes thanks.

Yes, i left the LED and dimming pot off this particular diagram just to concentrate on how I was going to route the wires between the switches, thumbwheel, and arduino.


Mach7

Hello Andrew, I have attached my draft wire drawing for your viewing with the corrections.

Also...I am looking at the best ergonomic way to wire the thumbwheel switches and the AML21 switches (TO, MCT, TGT, TEST),

Here is my plan and tell me what you think....

First off, I noticed that the TGT thumwheels each have two output lead wires off of ports 1..2..4..and 8 whereas the Tref thumbwheels only have one output wire at that same locations.

The Tref will be located at the top right of the CDU and the TGT located at the bottom left.

My plan is to connect the single output leads off the Tref wheel to the corresponding (second) output lead on TGT...so wire 1 Tref output connects to wire 1 output TGT, wire 2 tref output to wire 2 output TGT etc etc....

This leaves another wire output from all three TGT wheels at locations 1..2..4..and 8 which will connect direcly (through a diode) to there respective switches.

Since the 'common' wire(s)all go to different ports are arduino...these will be wired separatley

what do you think?

ame

Looks better now, and still ok, except you need a ground connection for the TO LED.

If some of the switches have two solder pads for each connection then it would be practical to take advantage of them. But, if not you can always jam two wires into one hole.

Don't forget, I haven't tested the thumbwheels in a matrix configuration, although I do expect them to work.

ame

Ok, I made a mock-up. It was no trouble, and better than having wires untidily over the bench. Instead, the wires are hidden away.

The panel is made from FAA-approved cardboard and hot glue. The purpose was to show the correct operation of the switch matrix. I only have one set of three thumbwheels, but they can be read independently of the four pushbuttons (and each other).

As you can see, no attempt has been made to cram everything in to as small a space as possible, nor to make the wiring even slightly neat and/or tidy.

But, currently everything works, although TGT is not tested. I haven't made the change to "TEST" you suggested, and I haven't sorted N vs Tref using a formula, but if you can get the hardware going then the software can be changed independently.

Mach7

Hello Andrew...still waiting on parts...but i think they are getting close.

ame

Quote from: Mach7 on November 23, 2020, 04:19:40 amHello Andrew...still waiting on parts...but i think they are getting close.

Referring to an earlier post you made: this is why people spend $30 on an Arduino they can get locally the next day instead of $3 on one that willmay arrive in three weeks...

I always find it to be a careful balancing act, although I generally decide to wait.

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