

|
IOCards step by step
By Claude Kieffer http://www.simucockpit.com Translate : José Olliver |
|
|
|
|
|
|
|
In this tutorial We will see:
|
1
- Master
card assembly |
|
IOCards
is a non commercial design. It development was possible thanks to
Manuel Vélez, el main designer. You
can make the order of the IOcards cards in kit, or mounted and tested, in
Opencockpits
web site . All cards are sold to cost price without lucre... This tutorial non dispensation the mandatory reading of the annexes that you can
download from
Opencockpits
web site. Mainly the annexed I and II.
|
|
|
|
1 – Master card assembly |
|
The Master
card is the "heard" of the IOCards system. It provides inputs, that can be connected
to any type of switches, and also outputs for to connect Leds or to show information in the
displays.
Alone the Master card could work if it was connected to the parallel port of the computer. This is even possible... to the condition that their computer still takes that port type. The truth is that the parallel port goes being more and more scarce since the printers take all the USB. Today is better to connect the Master card in the USB port. For that an additional card is needed but it is worthwhile for quantity of reasons.
|
|
|
|
2 – USB card assembly |
|
Of course, for the assembly of the
USB card will follow the same phases exactly that for the Master. |
We will begin welding the small components: the resistors, the condensers, and then the socket of ICs. Remember that the condenser C1 that give it for 220 nF (or 0,2 µF) in the nomenclature this proportionate one for O,1 µF. The correct value is this last one (0.1). |
|
|
|
|
|
|
The Display II
card
|
The
keyboard emulator USB Keys
|
|
|
|
Each people
has their method to avoid made a mistake with the multitude of wires that leave the
IOCard card. I personally, appeal to plane cables of 40 wires that they go distributed by the whole
cockpit. Each panel (as well as that of the landing gear, EFIS, etc.…) it should be independent and easily
unmounted. Therefore, the wires of switches, LEDs, displays of each pane,l they will be gathered and connected in a male connector HE10 of 2 x 20
pins (it is very easy to get them in the electronic store).
My method is the
following: the Master card provides the HE10 male connectors J3 and J4. In each one, I connect a plane cable of 40
wires with a female connector. One goes toward the right part of the cockpit and another toward the left. When arriving the plane cable near an I modulate (for example that of the landing
gear), It is connected to a HE10 female connector thru a grimp tools. Then as the
wires of the landing gear panel are welded in a HE10 male connector because single lack that to connect it to the female connector that there is
grimped. Good, keep in mind that alone 10 wires of the plane cable were used for this module. The other ones continue but far, for example until the EFIS that
It needs 15 wires. And we continue this way since to grimp several HE10
female connectors is been able to the plane cable. Each female connector corresponds to a panel. This way to proceed has several
benefit: it is clear wired. It is also this way easier to modify it and to extend it. Let us say that the inconvenience is that there is that
grimped the connectors and it is better to have a special tool for it. It can also give to one the waste impression since they take few
wires some connectors. But, they are cheap the HE10 connectors. With these pictures it is but explicit: |
|
|
It is never necessary to weld the wires directly on the pins. It is necessary to weld the pins on a piece of printed circuit and then the wires on this circuit. |
|
|
|
Well,
We have mounted our cards, and clever the wires. First We will have to check that everything works correctly. For that,
We need a power source of 5 V cc. As say in the "Annexed I", page #16, if we want to use as
power source one of computer´s. There is but you solve. We should keep in mind that the
IOCards cards use a little current. But that of more consumption are the Leds and the displays that can be connected. A Led consumes 10
miliampers approximately, a 7 segments display (alone a "it calculates" to show a frequency for example) it can consume more 10 times. To be comfortable, a feeding of 5Vcc 2 amperes will be enough. Care: some
power source have a "current of quite" high and that can damage some
ICs. To avoid that risk, it is always necessary to use a plug with taking of
ground to connect those feedings to the line. The "Controller." The
"Controller" program that forms part of the group of the software IOCards, because as it seems logical, it will be good us to check the correct operation of the
Master card and also to locate the inputs and the outputs. It seems interesting to gather the programs and the files in an unique
folder, for example in Program Files \ IOCards.
[ fichero de configuración
para el programa CONTROLADOR ]
[ Uso de Expansión USB ]
[ Múltiples USBs ]
[ Número de periférico para
el USB ]
[ Activar en modo SIMULADOR
yes/no]
[ Numero de tarjetas Master
inter-conectadas ]
Now, We run the "Controlador" program.. We do a click in the "Comenzar" button: the program display this screen. Only We use at this moment the red box info:
In the
upper side "IOCardUSB running" will show. That means that the
Master card and the USB Expansion card is working. With the USB port, no longer interests us all that refers to the parallel port and its address. Anything should appear in the
"Inputs" box. Neither in the white window below. If it leaves some series of
numbers in this window, it can mean that there is a short circuit in the inputs
of the master card or a faulty connection cable. We activate
an input now. Prepare a piece of plane cable of 40
pins of 30 centimeters. In an end of the cable, put a HE10 female connector 2 x 20. Care with the color thread (the
#1) that should be on the side of the a small triangle is recorded in the HE10).
The other end of the cable it removes the first 10 wires, remove the plastic
cover and connect to a switch among the color wire (#1) and the #10 wire. To activate the
input #1, connect the HE10 connector in the J3 connector of the master card
(below, in the left), and close the switch, immediately will appear the
"001" in the box and window below. Perfect! The input #1 works.
Leave welded the switch with the wires that it will be necessary later. Next we expose a diagram with the correspondences: J3 Connector:
J4 Connector:
As they can already see it, the
inputs go for groups of 9. The first input takes the number 000. In total, the two connectors J3 and J4 provide 72
inputs. They are activated when join one of the pins of oneself group with the
ground pin (GND) of the same group. We have discovered that the
input #001 was activated when join with a switch the pin 1 with the pin 10 of the
J3 connector. Equally, the input #009 was activated joining the #17 and #20
pins, etc... Now we can
test them the #000 thru #008 joining the wires of our plane cable with the #10
wire of GND. If everything works, that is to say if each
input this located correctly in the white window the rest it also worked Of course anything prevents us us to make the same thing with the connector J4. At the moment alone we will make this with the Controller. |
|
|
|
Config IOCard As same of the "Controller", ConfigIOCard has a configuration file called: ConfigIOCard.ini This file es very import and it should show us the following thing. Change it if necesary:
[ fichero de configuración
para el programa IOCARD ]
[ Múltiples USBs ]
[ Número de periférico para
el USB ]
[ Número de A/D a usar de la
placa de Expansión USB ]
[ Dirección IP local para el
protocolo IOCP (UDP) ]
window = "a.txt - Bloc de notas"
La first screen is the following:
This program is
that we use to create all the programming instructions that we will use. We will go
slowly. We will think about a first very modest objective: to select the control of the landing
gearn. Nothing else. For their internal operation, the Flight Simulator uses "variables". All the functions of the simulator, and not alone those that are about the flight, refer to a variable. Peter Dowson has been able to crumble the code of Flight Simulator and it has taken out the list of those variables. This way, a software just as IOCard can negotiate them and for mediation of FSUIPC they will be been able to send to SFC. Alone they are given an address… AND there they go! The variables list of Flight Simulator goes included in the IOCards documentation, in the annex IV, and also in the Peter Downson web. There are hundreds (the annex IV consist of 43 pages), but calm because if we leave aside the variables that are about the meteorological service, geographical coordinates, or physical characteristics of an airplane, what composes a booth is really quite less important.
We return to Config IOCards. In the "Variables" folder, We can see the following columns :
NAME : here we will put the name that we want to give to the first VARIABLE. For the landing gear, we will call it for example GEAR. This name will assign to an address and from now one will be able to only use to define the function to retract or extend the landing gear, and anything. For that reason it is important to choose a sufficiently representative name. For example, if We call to a variable BRAKE, it is certain that we don't go that is after a little time if it is the left Brake, of the right or of the control of parking brake. In the NAMES column, we will put GEAR for example. We have just defined a name of VARIABLE. DIRECCIÓN : The address that We should use for the variable that We have defined provides it to us Peter Dowson in the list of FSUIPC offsets (Annex IV). We cannot put the one that want, We have to remit ourselves to the defined ones in the FSUIPC. In the list, We can see "Gear Control". Because that it is the one that We need.
We have to remit ourselves to the address
0BE8. But still lack something: We have whenever the prefix sign "$"
to each address. Then in the column ADDRESS, we will put: $0BE8 LENGTH
: it is the number of "bytes" that has each variable (that is to say the name of "words" of 8 bits).
We trust Peter's word Dowson and We will put the longitude that gives us and that in this case for the landing
gear will be 4. At the moment We will leave aside the two following columns: Then We
have: Because not this wrong for start ! For our landing gear control, We will use a switch "normal" of type micro-switch, with a Closed position and an Opened position. We make a click in the SW-NORMAL folder.
NAME
: We don't should mistake with the previous NAME. Here We will give a name to the
landing gear switch and not to the variable of the gear. For example We will take GEAR_SW, or INTER_TREN. INPUT
: We put the input number of Master card on which We will connect the landing
gear switch. It can be the first one, that takes the number 0, or the input
#1. Let us put the #1 for example. VARIABLE
: Here We find the name of the VARIABLE that We have defined in the previous
folder. It is not necessary to change it. We had chosen GEAR, because We will put GEAR in that column. Council: to avoid errors when
rewrite us the name of the variable, because it would be cause for not being recognized, make a double click in the Variable column. Then, the list of the variables that
We have already used will come out and alone We will have to choose. VALOR_ON AND VALOR_OFF: this part
is interesting. Here We have to indicate that value should take the variable when the switch
is closed (Valor_ON/Key) and when is open (Valor_OFF/Key). We have several options, according to the control type. We will already see then some examples. For the landing
gear, the simplest solution is putting ON=1 and OFF=0, then switch closed =
landing gear down and switch open = landing gear up. Nothing else. The program understands what means 0 and 1 perfectly. Good, We can
make this in a different way. Notice again in the offset line of Peter's Dowson
offsets : And that we see? Gear Control: 0=UP, 16383=Down.
When having defined a variable and a control by means of a switch,
We have just programmed the first input of the master card. Now We have to make two very important things: 1°
The Config IOCard program have received the informations of an important file, the
". dat". This is the file to the one that the main program, IOCard.exe,
it will refer to know which is our programming. But before, it is necessary to record it, because at the moment, like they can see it IOCard it arrives of the window of Config,
it calls himself "sin_nombre.dat". We execute File/Save then like and we
save that new "file.dat" with a name anyone, aeris.dat or... mi_avión.dat. This new
file.dat stays together with the other ones that We gave as examples, in the
IOCard folder. 2° Very important:
We should inform to IOCard.exe that is with this file. dat that should act. For
We execute it again the file ConfigIOCard: when arriving to the the last lines of this file this the following group of
lines:
[ Nombre y localización del
fichero de configuración ] Edit the last line and write ConfigFile=.\aeris.dat (o ConfigFile=.\mi_avion.dat) From now IOCard knows that it is that configuration file to which will have to refer. Observe that “\ before it names him of your file it means that the file.dat is inside the same folder that We have left IOCard.exe. Only that to execute the Flight Simulator, and IOCard.exe whose window should indicate us that it has found among other things FS2004 and FSUIPC. IOCard minimize in the taskbar. In four phases: define a variable, define an input, record a file. dat and configure ConfigIOcard for that “. dat” We have programmed the first function of the IOCard system. A example way, now they can program the
battery switch. The variable address is $3102, the longitude 1 and logically the Valor_ON will be 1, and the Valor_OFF
will be 0. They will have noticed that when We execute the ConfigIOCard
program, it shows us a blank page, open the file.dat that We want to use in
File/Open. AND don't forget save it every time that modifies something! The programming of the
battery switch is specially conclusive: it is much more realistic to control it with a switch that with the keyboard or with
push buttons. Now, we add the parking brake control ($0BC8) Comment 2: When
We modify something in the file ConfigIocard, it is always necessary to safeguard that file with File \ to Keep. But if this being also executed
IOCard.exe, so that they are effective the modifications, it is necessary to make click in
RELOAD. Comment 3: The window of beginning of IOCards sometimes indicates us errors, and the program cannot be executed. The most frequent errors are: “it is not a whole value”: IOCards closes with EXIT, execute it again and don't make click in the button to RELOAD, but in START. We can have
"erroneous Variable in Exit lines". That happens mainly when an or several programming lines have been open with ADD, but dropshots in
blank. Suppress the empty boxes, IOCards execute again and everything will return to the normality. |
|
|
|
We have already seen that some variables have values ON-OFF that pass from 0 to 16383. It is this way the example of the landing gear. It could be the same thing for the controls. It is also this way for the control of the flaps with the address $0BDC (page 14 of the annex IV). We can read: "Flaps control: 0=UP, 16383 = Full". In the flaps example, this gives us interesting possibilities. It is that perfectly we can assign, for example, three switches to the variable of the flaps. Corresponding each one to a position. A flaps control with 3 positions, is what is usually in the Beech 1900D, Baron 58, ATR 72 etc. is very average. The first switch will correspond to the value ON=0, that is to say Flaps UP. The third switch will correspond to the value ON = 16383. That is to say that when we close this switch (value ON) the variable will take the value 16383, and the
flaps will go to full down. As for the switch of the
middle, we will give him a value ON of half of 16383, that is to say, rounding, 8191. We will have this way 3
positions, for example 0 - 15° - 30°. In the physical aspect those switches can be micro-switches, but they can also be the contacts of a
12 positions rotary switch. Each one of the contacts will be connected to
a master input, the common contact wil be to ground of the same group. For our programming test, we will use the
inputs 0, 4 and 5 With this programming principle, it is no longer necessary to detect the sense of rotation of the lever of the flaps. The switch of the position 2 will correspond to flaps=2. In the VARIABLES folder of ConfigIOCard shows us, from now on the following thing
The SW-NORMAL folder, now will be as following :
Therefore we will notice the following thing:
- We find three times the name of the
FLAPS variable, in three different inputs: 0, 4 and 5.
|
|
|
|
The previous example is
very easy : 0, 15, 30. We already imagine that the value 15 are half of the value 30. The things are more complicated when we have more
positions. In all cases, the value of the variable $0BDC will be 0 for
FLAPS UP and 16383 for FLAPS DOWN. The general rule is that
each flap position (increase the value of the variable from a position to
other one) this divided by steps all to the samediference. If the effective unfolding of the flaps is not made regularly from a
position to the other, the file Aircraft.cfg takes charge of making the necessary thing. Calculation of the step: it is divided 16383 by the number of
positions minus one Example: a 767 with 7
flaps positions, from 0 to 30. We will divide 16383 for 6 (7-1) what will give us 2730 for each step.
Good, we could leave it this this way already, but we will take advantage to see like they work and that useful they are the bellboys to READ and to SAVE in the lower part of ConfigIOCards:
These functions allow to visualize the values that
take the variables when it changes in Flight Simulator, a flaps position for example,
(READ button) and inversely when it puts on a value in the box Value, it can be sent
to Flight Simulator to see that it makes (WRITE button). We will see what happens with the
flaps control. The variable $0BDC has to already be introduced in the list of the variables. We execute
MSFS with the initial B777, we throw ConfigIOCards with a file.dat that takes 7
flaps positions. We open IOCards.exe. In the screen of ConfigIOCards, the right window is empty. We make click in READ, it shows us the values of all the variables that we have foreseen:
Alone the last line: FLAPS will interest us for our example. At the moment mark the decimal value 0. With the
MSFS, we put the flaps in the first position: flaps 1. In ConfigIOCards, we make click in
READ: the value that shows is 2730. Contrary confirmation. We have three empty boxes: Offset, Length and Value. In Offset, we put the variable $0BDC of the flaps, the length is 4, and in Value we put 2730.
We make click in
WRITE and we observe what passes in the MSFS: The flaps puts on in the position 1. Also, if we make click in
READ, the new value that will show is 2730. We can check this way the correct operation of the flaps controlling the variables directly in FSUIPC, without having to play the lever of control of the flaps. If then the flaps left
unschedule, one won't still be able to suspect the programming. Alone we will have to go investigating the
wires. This function READ / WRITE is very useful to check or to understand the operation of any variable of FSUIPC.
|
|
|
|
9- « Bit to bit » Variables |
|
Sometimes, we will give a little with
"strange" variables. They don't change their value in a global way but modifying one of their "bits"
(numbers or letters that compose it). We have a good example here with the address $0D0C : the several lights of an airplane.
With
only an address, We have 10 lights. The selection will be made being changed the value 0
to 1 of the #0 bit, of the #1, etc. It is very easy, we will also limit to the first 6
lights. In ConfigIOCard, the definition of the variable will be made as of habit. We will call to this variable LIGHTS:
In the SW-NORMAL
folder, we will have a switch. What means an input for each light in the Master. We add the
line necessary line with the ADD, DELETE and INSERT buttons, under the window of ConfigIOCard. So that it is easier the I wire, we will
join all these inputs in the "blue" group of the inputs from 009 to 017 (they see the previous diagram). The common
ground is the #20 pin.
All the
"values _ON" will be 1 and all the "OFF" showed 0. It is logical. On the other hand,
it is necessary to change in alone a Bit. For that reason it is the
"B" letter in the "valor_ON" and "OFF" columns. The
"+" or the "-" that it shown us of the action that we have to make, to
enable or disable, and finally, the number from 0 to 5 in our example corresponds to the bit whose value will have to modify. Which is? Peter
Dowson tell it to us: when we want light on the navegation lights, there will be
to change in the #0 bit, if they are the landing lights, it will be in the
#2 bit, etc... This is very simple and very effective because we will already see soon, with the use that each
switch will be "down". for example, the lights are always ON, although we
start the MSFS with a situation where they were OFF. And when we put the
switch "up" they always OFF. The messes finish this way that are with the controls by means of keys or switches (ON)-OFF-(ON). Comment
: There is more variables with several values in the P. Dowson´s list. Notice
the 2F80 for example, for the AutoBrake. Here Peter Dowson no longer gives bits values to change, but
absolute values: 0 = RTO, 1=OFF, 2=Brake 1 etc... it is another way to define those
"value ON" of a variable, and in this case we will have a switch (in fact a position of a
rotary switch) for each positions with value ON =0 for the position RTO, or 1 for the position OFF, etc... So much but all that
they can associate to those functions witness LEDs to indicate us the state of the controls. So that we don't forget of
turn off the landing lights when we go flying in cruise. We will treat that topic now… we will no longer send instructions to Flight Simulator, but rather
It will send us informations. We leave the Inputs, and we go now with the
Outputs.
|
|
|
|
The Master
card provides two connectors for outputs: the J2, in the left, is a connector male HE10 of 40 pines. It provides us the 38
outputs from the #11 to #48. Don't confuse it with the J1 in the right!. It also provides us exits, but they are for the displays
cards. Up, in the right, the P2 connector is a DB9 male that provides 7
outputs from #49 to 55.
To check where the
outputs are located in the J2 connector, we will use the Controller again, but the other way. When
We test the inputs, let us connect the #1 to #10 pins and let us check that it was the
#001 input indeed. The
wires can be connected in the cockpit and to look later with the Controller to that number corresponds
to each connection. We aim that number that will be put in the file.dat of ConfigIOCard. That is it we will make here. The
outputs order in the J2 connector pins is different from that of the inputs in the
J3 or J4 connectors, more simple. Indeed, the #1 pin is the +5 v, and #2 is
ground. And the other pins? We will do it with the Controller. We take
a flat cable of 30 cm that we had prepared again. Remove the switch and weld a
270 or 330 ohms resistor with a LED. Don't forget: the shortest pin of the
LED is the NEGATIVE, the longest is the POSITIVE. We will weld the other end from the resistor to the #2 wire (pin 2) of the flat cable, that is to say to the ground. To avoid a short circuit, we will hit with adhesive tape. The #1 wire (colored) is the +5 volts along the flat cable. The other pin of the LED will be welded to any of the other threads, for example to the thread n°3. The Controller will tell us to that left it corresponds this connection.
We start up the Controller (START button). In the IN/DPLAY box, we put 11, the number of the first output. We make click in ON. If the LED lights then good luck !. That indicates us that the #3 wire correspond to the #11 output. We make click in
OFF to light off the LED, and we put 12. We make click in ON
again, the LED doesn't light. It is normal. Keep in mind that alone it can
turn off the LED with OFF if the marked number corresponds to the active
output. One is not able to, for example, when the #15 are active to make click in - ON to return to
#13 and to make click in OFF. It didn't work this way, it will be necessary to return again to 15 for
do it. Therefore we can give with the
outputs numbers that are already connected. Let us suppose that our
LED this now connected in the #20 output. We close the Controller, and we open ConfigIOCards. We load our file.dat and we open the label OUTS_CONFIG, or outputs configuration.
In the NAMES
column, we will give a name to the output. For example, LED_LDG_LIGHTS to differentiate the name of the
switch input and that of the variable correctly. In N.Output
column will put the number of the output that we want to activate when close the
LDG_LIGHTS switch. The #20 in our example. In the Variable column, we will give the same name of the variable that we put in the
VARIABLES label. In our example : LIGHTS. Care with not programming an LED
output for a variable that was not in the VARIABLES list. It would be an error ("erroneous Variable in it lines
output") in the window of start of IOCards. Finally, in the
Value ON column, we will indicate that value of this variable goes to activate the
#28 output and light on our LED. In the SW_NORMAL label, had to activate the
#2 bit to turn on the lights. Then we will put B2 here (and non B+2). no
more! We save
our file.dat and close ConfigIOCard. Start
the Flight Simulator, set the time to night. We open IOCard.exe. we Close the switch of the
#11 input putting a wire among the #12 and #20 pins of the J3 connector. Then we see that the lights
turn to on and that the LED also light up. We have made a
witness LED for the switch of the landing lights. Alone we have left to make the same thing for the other
LIGHTS switches, even for the Pitot heat, Yaw Damper, Spoilers armed, good, everything that that doesn't jump visible and that a visual witness needs to remember it. The LEDs very often goes included in the
rectangular pulse switch. Then they put 2 or 4 in each switch. Comment 1: Every time that we add an
output LED, is good to check that the VARIABLE exists well in the first
folder and that we have written its name correctly (it is the main causes of
errors). Comment 2: when
that the variable exists, the LED that we have configured in output lights when we work a switch. But, of course, also when we control the action with the keyboard, and also with the
USB Keys card. That means that if it is more practical to control Slew for example with the key
"Y" generated by USB Keys, it is not necessary to have a switch programmed in the
SW_NORMAL folder. Nevertheless we will be able to put a control
LED. |
|
|
|
The USB expansion card USB
add 4 A/D inputs (analog/digital inputs) for potentiometers that can manage for example, the
throttles or the speedbrakes. The first thing that we should make is, of course, to extract the offset of the Dowson´s list. For the throttles, they are divided in two parts, the $088C for the throttle #1 and $0924 for the throttle#2, and $0BD0 for the spoilers.
In the VARIABLES
folder, we will put a name for those variables, for example THROTTLE_1, THROTTLE_2 and SPOILER, then their address, their
lenght, 2 and 4. In the column
FUNCTION we will put so that they will serve those axes: we can take the same name again that that of the variable, as THROTTLE_1, or a different name, as SPOILER_CTRL. Those names are alone a reference point for
us. We open the DEF.FUNCIONES: folder, it is supposed that those variables vary from 16384 to 0.
If
value > means: if the value is higher to. we will say higher or same because it seems difficult for a variable limit of 16384 of having a
higher value. We have to understand that the Value > it refers to the state of the
potentiometer and in such a case we can read: "if the value that gives us the state of the
potentiometer is higher or same to 16384, " Then Value = "
the value of the variable will be 16384. That is to say the throttles or spoilers
are full. On the contrary,
If Value <, if the state of the potentiometer is lower or same to 0, then the variable will have to take the value 0 Finally, it is the column
Value = Value for : it is a coefficient multiplier that derives of the fact that the Analogical/digital
converter works with 8 bits. To explain in a simple way, we will say that the reference value is 64,25, when the
ends values are 0 and 255. When we increase that value and that we put 80.3137 for example, we change the high end of the
potentiometer, that is to say that we gauge it, then it will set to the maximum value of the variable before arriving to their maximum value in
ohms. Last phase, we go to the folder ANALOG INPUT :
In NAME we inform a name anyone to define our
analog axis. We can use THROTTLE_1 and 2, and SPOILER_CTRL again. In the column
INITIAL INPUT, we will put the number of the analog input of the
USB Expansion card. That in the following way: #1 for #1 input, the one that is beside the
USB connector toward the PC, then #2, #3 or #4 if we had more. In the
VARIABLE column, we will take the variable´s name that we have defined in the
VARIABLES folder exactly. Then, we define the
potentiometer travel that it goes from 0 to 255. If it should be linear, like
it has to be for our three examples of axes, the middle of the travel will
be 255:2=127. To determine which is the potentiometer travel in a special installation, we can refer to the Controller: below they are the values A/D [1], A/D [2], etc... we Put the levers in the high and low end, and we copy the suitable value here in Left and Right position We save
the changes in the file.dat. We also have to go to the
IOCard.ini file and in the lines [Number of A/D to use of the
USB Expansion card] we will indicate the number of analog inputs that we should
use, in our case they will be 3. Alone we have left to execute
MSFS, IOCard.exe and to check that in the 737, for example, these three axes usually
work...
|
|
|
|
One of the
IOCards functions, of course, to be able to show and to modify the data
(NAV, COM freq, altitude, transponder code, etc...) All those data have a common point: they modify in the cockpit by a rotary encoder. Rotating it in a sense values was increased and rotating it in the opposed sense will decrease. According to the operation
mode, there are several types of encoders. We have
rotary encoders with phase detection that are two disks that will commute one after the other one but with a tiny delay. When connecting them in a special electronic circuit,
it will be able to be distinguished which made contact the first one of the disks and to interpret all that to generate a correct sign. The
Encoder II card of IOCards this dedicated for this encoders type. A lot simple and
same of effective, we have "Gray type" encoders as the CTS 288. They are very strong (totally of metal), not very voluminous and they can be gotten in the Web of OpenCockpits. This encoder type doesn't need the card Encoder II. It is connected directly in the
Master and it needs two inputs. It is an excellent solution that you can use for a whole
cockpit if it has one enough free inputs in the Master or another Master. Encoders also exists "mechanics" that can be connected directly in an Keyboard emulate card: for example the MRP1-20 and the MRP 11 of Knitter Switches. They are quite cheap but I find personally a little fragile.
A very particular encoder also
exists: one can be manufactured in some minutes with a 12 positions rotary
switch. And they are not also expensive. The first thing that we have to make is to cut the end of the
#12 position, so that it can the switch to give all the turns that are needed. Then, we will
connect the pins like it show them the following diagram:
The #1,
#2 and #3 outputs of the rotary will be connected to three consecutive
inputs of the Master. The center pin welded to the pin of ground of the same
group. We will make our first tests with this
very easy encoder. We return to ConfigIOCard
Good we already know that before everything it is necessary to open the
VARIABLES folder. We have to indicate now so that we want to use our encoder. Because we will use it so that it shows us the frequency of the NAV1.
We look to Peter Dowson's list, and we give with what we are looking for: it is exactly the address
$0350. In the NAME
column, we will give a name to the function of our encoder, for example ROT_NAV1 (ROT means
rotary...) The address is $0350, and length 2. FUNCTION: to some functions assigned to an encoder, a name can be given freely. That is it we made for the
analog axes. (THROTTLE_1 for example). However, there are very average functions of which it is part the NAV1 that need a special treatment. To check it, make click in the
FUNCTION column it is a expanded list then. We see NAV: we make click in the
expansion line of this function "it allows to select a VOR...
" and the NAV function appears in the box corresponding of our variable. It is necessary to get used to always look for in the list of functions because the fact of making click in a defaulted function causes frequent and automatically
unknow internal process. It would be this way the case for ALT that has limits, or QNH that loads a calculation formula. We have left the column
"INITIAL VALUE". Here we will indicate that value will have to be shown in the
7 segments digits in our cockpit. We already know that the frequency NAV initial is 108.00. Then, to avoid of to begin at 000.00 and to be a lot of time rotating the encoder until arriving
to 117.60 (for example) we can choose the value 108.00 as initial value. But anything impedes of beginning with the frequency of the VOR of their favorite airport. For example
117.60. An important comment: all the frequencies NAV, COM etc... they always begin with a 1. Then it is useless
to use resources of the IOCards to show a figure that will never change. The 1 of the first "digit" (it calculates of our display) it will be fixed. It is very easy: nothing else will have to unite the 2 segments of the digit that form the figure 1 in a
7 segments display to the feeding of 5 volts thru a resistor. They will always remain ignitions (we will already see then this). Leaving of this principle, our initial value 108.00 will be 0800. And the point of the decimals?
It is also a fixed segment. If we wanted to begin with the frequency 117.55, because we would indicate 1755.
INITIAL
INPUT: since an encoder is a group of switches, we will have to assign him
inputs in the Master card. It needs three and that they are consecutives. A
glance in the SW-NORMAL folder to remember that we had used the inputs up to
#18. Logically, we would have to take the 3 following. But it is impossible,
because the #19 is of a group (the blue group in the J3 connector diagram that we saw
before), the #20, it is ground of group, and the #21 it is in the following group, the brown. Now then, we need 3
inputs of the same group, to have a common ground. We will leave the #19 then and we will indicate in
Initial Input the #21. The program will know that like we need 3 inputs, automatically
it should leave us the #21, #22 and #23. In the VARIABLE column, we see the name that we have given to the variable
$0350, again that is to say ROT_NAV1.
The ACCELERATION column discovers it now. We will indicate here if the turns of the
rotary will be very quick or not. Will have to make tests. If we see that when rotating the
rotary quickly, the program inform us imprecisely, we will have to increase the
value to get a good action speed. With our homemade encoder, very quick turns cannot be given. It will be enough the value 1. With an encoder of
32 positions surely that we would put 8. The CTE.INC column is "the
increase". That is to say the value that we will add or subtract to the variable
by each click that we turn our NAV1 encoder. In the first case, we will
change the decimal part. It will increase of 2 in 2, for example the COM frequencies: 121.90 then 121.92 then 121.94 etc... In this case, we would put 2 in the column Cte.Inc. Like in our example it is a NAV, the frequencies will increase of 5 in 5: 108.00 then 108.05 etc...
We will put a 5. Our example allows us to act in the frequency active NAV but not in a
STAND BY frequency. For that it would be necessary another variable ($3123). there are several examples of interesting configuration files in
OpenCockpits WEB.
Finally in the TYPE column, we will indicate that encoder type uses. If it is a mechanical encoder, as the modified
12 positions switch, we won't put anything. If it is a
Gray encoder, we will put 2 If it is a
unshift fase encoder that needs the card Rotary Encoder II, we will indicate 1.
The first encoder will change the decimal part, we will call him ROT_NAV_1_DC, its
change will be of 25 in 25, then -2. Their exits will be connected to the #21,
#22 and #23 inputs. The second, ROT_NAV_1_EN will
change the whole part, it changes will be 100. The wires of this encoder will go connected to the
#24 at #26 inputs, being the common wire of the center together to the GND
pin of the group, the pin #30 of the J3 connector. Our two encoders can be separate, or concentric according to the
developed by Pedro Bibiloni in OpenCockpits. Many airplanes take automatic pilots whose control
with single encoders. It shows the information directly of the instrument. It is this way in the Beech 350, 1900D etc... In this case, our simple encoders will be enough. |
|
|
| An important selection of digits exists. Frequently they are of red color digits, sometimes named "HER" that means High Efficiency Red. For example the HDSP-7503 model whose number measure is 7,6 mm of high and the bodyof the digit measure 12,7 mm of high. These dimensions are ideal for the radios, MCP etc... it is a lot difficult to find yellow digits. We can buy it in OpenCockpits. A good idea that they have had it has been of buying them in great quantity and of proposing them for sale in their catalog of products. These two displays types suit well for the printed circuits for 3 and 5 digits that you can get in OpenCockpit. En both cases, they are digits of
common cathode, essential condition to be able to use them with the
Display II card of IOCards. You also have to keep in mind, to the elergilos moment that to be able to use the printed circuits of OpenCockpits, the common cathodes should be located in the pines 1 and/or 6 of the digit. Next the internal diagram of a HDSP-7503 that gathers the previous
conditions.
All the segments
"a" of all the digits are united among and connected to the
"a" pin of the J6 connector located up to right. And this way for all the other b, c etc... The
Common cathode of each digit goes together to one of the pins of the J2 connector of the right
side, The card has 16 pins, that is to say 16 digits for each Display card. The
40 pins connector will be connected by a flat cable to the J1 connector
of the Master.
The tests. The same as with any LED, the segments cannot be connected directly to a source
feeding of 5 volts. It is necessary to place a resistor of about 330 ohms in series so that it goes down the
voltage to about 2 volts. However, when we connect the digits to the Display
card, it won't be necessary any resistor, since the card provides the
correct voltage except for some particular cases that we will already see. Before welding on the printed circuit, we can check the segments position connecting the common cathode to the "-" of 5V feeding, and successively each one of the anodes wires to the "+" with a 330 ohms resistor. It is recommendable to check the digits before welding them because sometimes we found some defectives. It is useful to
check the pinout, for example: the segment "a" the pin 1, the
"b" to the pin 2, etc... AND the same for the cathodes. Once the
digits are welded, it is more difficult to locate them. But we can look the printed circuits are very well designed because the numbers are
correlatively.
The preliminary. The
assembly of the displays is very easy if We use the Opencockpits printed circuits that they are
double layer card and support 3 ,5 or 6 digits. They are cheap and it is not
convenient to manufacture them. Of course, they go connected among all the segments and they are connected to a
connector type HE14 of 8 pins (undoubtedly they are 8 with the decimal point). The cathodes go together to a HE14 of 3 or 5 or 6
pins.
The
fixed number: it is the same thing. In all the cases, the frequencies beginnig with 1. Then, we will light the
b and c segments permanently of the digit of the hundreds units it to the +5 volts. It is also necessary to isolate him of the other digits. Here we have two
options: be we connect each segments with a 330 ohms resistor, or we
connect the two segments in series and we connect the one that this more far from the mass to the +5 volts with a resistance of 150 ohms approximately. The purists will put adjustable resistances instead of the fixed ones to be able to adjust them with the same luminous intensity that the other digits.
The "-5" volts will be the #1 and #6 pins, common with the other segments.
To weld in the printed circuit is simple, the only caution that we should take is of checking that the decimal points are all below to right. Programming.
We execute ConfigIOCard now.
We have already defined the NAV1 VARIABLE, $0350, but it goes assigned to
rotary encoders. We will define this $0350 variable again, giving him a you specify, that is to say that it shows us information: we will call it DIS_NAV_1 (Display).
We will open the page now DISPLAYS 7S:
- in the NAMES column, we will put the name that we want to give to our display, for example D_NAV_1
- the 1er DGTO column is important. We already know that the Display II
card can control up to 16 digits, each one having their connected common cathode to the
16 pins connector in the right side of the card. The #1 pin corresponds to the first digit that is... the number 0. The sixteenth
pin it is then the #15. We will put in 1er DGTO column the number that corresponds to the first digit of each display. This way, our display of 5 digits will go connected to the
digits #0 at #4. we will Put 0 in the 1er DGTO column. When we want to connect the second
display then the first digit it will be the #5, and if it takes 3 digits it will be connected to the
digits #5, #6 and #7, and so forth.
Attention: It is that the Display card manage the less significant
number in the first place, that is to say those that are more to the right. If we take the direction that takes a digit for the hundreds, for example one for the dozens and one for the units, the "first
number" for the Display card is that of the units that then will be connected to the
digit #0, then the dozens to the #1 and the hundreds at #2. We Begin then always with the end. In the contrary case, instead of showing the direction 349 it would show 943. Equally, it would show 570.11 a
NAV frequency instead of 110.75.
- in the NUMBERS column, we will inform how many numbers or digits will compose
the NAV1 frequency display. In this case 4 since the first is fixed.
- in the OPTIONS column, we won't put anything. In this column we can sometimes find the
"N" option that we put when we want that a provisionally disabled display recovers the last value that showed. It is like a memory. It is useful, for example, when a display can show several values, as the
IAS / Mach. Without the option N, when we use a display again, it shows us their initial value, and not the last observed value.
We will be able to this way to observe the page DISPLAYS 7-S of Config Iocards:
The assembly circuit will look as this :
We have left to connect the wires and to admire the result of our work:
It is not that it is
a good picture but We can observe that the 1 (fixed) it is more luminous than the other segments. This is normal since
it goes fed permanently while the other digits are connected to the Displays
card one after other one. So that it is more beautiful, we can feed the fixed digits of the 1 by
thru a higher value resistor, preferably, if we have place, a potentiometer.
Also, it is recommended to add this resistor so that more durability time. Be what is, to rotate an encoder and to see change a frequency in "its" display is something mágic…
|
|
|
|
With this we have seen the essential of the IOCards. Since I was writing these notes as
I went experiencing this project, my personal conclusion is that a person as me that
didn't understand absolutely anything of programming of the IOCards can leave difficulties without great
effort. Undoubtedly without the help of some friends with more experience the things have been more complicated for me and a lot but you release. The whole documentation of IOCards that came out at the beginning has the merit of existing but, to the long thing,
It has left turning obsolete. In my opinion it is too much general
information and it doesn't take enough concrete examples. I hope they can be these notes a help for all those manufacturers that will decide to choose IOCards. With the IOCards
We can do many more things than those can be made that have tried in this tutorial. As it was the first steps here, we have left aside as the servos control,
Step by step motors, LCD displays. I have not mentioned the Controller's use to check the displays, neither the variables "Free" that we can assign like like, neither neither of the functions that allow to stop a display or an encoder when another has to take the relief, neither of the frequencies in stand-by that can transform in active, neither neither of many more things than they can be very useful. But when one has understood the bases, it is not difficult to continue but ahead. Neither I have spoken of the protocol SIOC that is another
program for relationship IOCard and Flight Simulator. The SIOC is more guided to "programmers" and it is capable of unpublished logical functions. The
IOCards cards, without leaving aside the keyboard emulator USBKeys that is indispensable from my point of view, allows
to manage all the functions of a cockpit. They are at the same time reliable and of a remarkable robustness. They are able to fit without damages all them programming errors. When one realizes that Iocards is a project
freeware, him less than we can make it is to thank very much to Manuel
Vélez having put to our disposition this powerfull tool. |
|
|
|
|