Introducing the DFDT Cockpit Project

[Maraudeur]

Sorry for posting theses pictures lately Wasserfall, Here are:

 

One picture with the lights operating

One with a close look to the front armament panel

One with the pit #1 "in action" ;-) (at that time the stick was still not twisted)

And a last with a "top" wiew

As you can see there it's far less sexy thant yours, but at least it worked. On these pics the front panel has no LCD display for the instruments, as it's still a "prototype" for my MK2 pit...

Edited November 26, 2011 by Maraudeur

[wasserfall]

Thank's Maraudeur, great pit!!

no problem posting these pictures!

What io card did you use and is it via Lua?

The switches on the front armament panel, are they all working as in reall life?

or as in my case assigned with a function i like?

My French is very bad (absent) so it's no use for me to visit the Checksix forum(:

Edrom has the same vision on working switches as you i think. i use an Arcaze board

but i think it is limited only for keyboard emulation and analog joystick

Let's hope FC3 has more functions!!!

 

Salut,

[wasserfall]

More pics

 

Because i needed a bigger screen i chose a 32Inch Led tv from Samsung that does the job perfectly

 

 

 

A close up of the Hud, which i really like to have functioning, but as far as i know it's impossible in Fc2

i made it in such a way that i can upgrade it in the future (Fc3?)

 

 

On this pic you can see the LOVP working, the waypoints on the "crt" are still pictures on a photo frame,

i have several images from radar scope etc.

 

 

Finally, an overview were you can see some of the frame i made, painted in yellow aircraft primer. The ejectionseat (k36d) is still without headrest and is in basic form, but all in time!!

 

 

Hope you like it!!

 

Wasserfall

Edited November 10, 2014 by wasserfall

[Maraudeur]

Thank's Maraudeur, great pit!!

no problem posting these pictures!

What io card did you use and is it via Lua?

The switches on the front armament panel, are they all working as in reall life?

or as in my case assigned with a function i like?

My French is very bad (absent) so it's no use for me to visit the Checksix forum(:

Edrom has the same vision on working switches as you i think. i use an Arcaze board

but i think it is limited only for keyboard emulation and analog joystick

Let's hope FC3 has more functions!!!

 

Salut,

No problem for english (as I manage to avoid errors :music_whistling:) I also discussed a lot with Edrom to exange our tips and trick, and of course our solutions.

I used 3 mastercards plugged on a USB expansion card. One o the three mastercards was used for the SPO (not seen on the pictures) that uses 50 leds for itself. This part is still a prototype, but "Gillesdrone", a collegue of my squadron (the 3rd Wing), has built a SPO fully fonctionnal for his SU-25T cockpit.

I also worked with Lecreole that made the first fonctionnal export.lua that communicated with the SIOC.

On the countrary of what you guess, it's not only a matter of key emulation, it's far more than this as the SIOC is also a quite powerfull tool.

The wyring of the switches, rotaries, leds, 8digit displays if far simplier than other devices, for you don't have to add diods, or follow a matrix.

Yes, the armament front panel is quite fully operationnal as its realife conterparty (due to the limitations of LockOn). The selected ammo and the remaining ammunitions are not working.

For the rest, it's just a matter of "basic" SIOC programmation (IF, THEN, ELSE, GOSUB and so on) that permits to emulate functions that are not present in LockOn. As for example:

- Emergency jettison: I just "tell" SIOC to make 5 individual jettison separated by 0.5 second

- Fully operative Chaff/Flare panel: I "tell" the SIOC to perform individual Chaff or Flare jettisonning in function of what is set on the rotary switches (rate and number of countermeasures)

- HUD contrast changed on the front panel switch buy cycling the Ctrl-H

- Autopilot functions are also more easy to operate rather than with the use of key combinasons

 

Unfortunately, as you may already know, many informations are not exported by the LUA, such as mechanics states (flaps, slats, trim value, gear up/down) that complicates the programming of a cockpit. You then have to cheat, but it's not always fully satisfying :cry:

But the SIOC permits to fill may lacks of LockOn, the only limit is your imagination (I also plan to command the TARS, and therfor Team Speak chanels and frequencies displays in the cockpit, with volume tuning). I also plan to use a LCD bar display to have a fully fonctionnal fuel gauge (with LCD expansion card), or to enadle the display of messages on block 23-01.

 

The only counterparty is that like the "Pringles": Once popped, ou can't stop :smilewink:

 

Oh, I just forgot to say: I'm really jealous of you so real-looking cokpit :-)

Edited November 28, 2011 by Maraudeur

[Joe Kurr]

[...]

Unfortunately, as you may already know, many informations are not exported by the LUA, such as mechanics states (flaps, slats, trim value, gear up/down) that complicates the programming of a cockpit. You then have to cheat, but it's not always fully satisfying :cry:

[...]

 

It has been a while since I last posted in this topic, but in the meantime I have been working on a mechanical system indicator.

At the moment it shows the state for flaps, gear, FOD shields and airbrake, all read from lockon!

No cheating necessary, just plain lua.

 

Here is how you do it:

 

In the export.lua, there is a function LoGetMechInfo(), which gives you loads of interesting data.

For the above indicator, I use the following:

- LoGetMechInfo().gear.value

- LoGetMechInfo().flaps.value

- LoGetMechInfo().speedbrakes.value

 

These will give you anything between 0 and 1, so if you're only interested in the up or down position, you can do this:

 

local gearState = LoGetMechInfo().gear.value and 1 or 0

 

I plan on updating our DFDT Wiki with the complete code to make this work.

[Maraudeur]

That's a very good new!! I just missed these informations. This is a real great improvement for the cockpit building. Do you confirm that we actually get these informations (I mean, really operative while simulation is running).

 

I've tryed the Canopy position with:

LoGetMechInfo() -- mechanization info

result_is =

{

gear = {status,value,main = {left = {rod},right = {rod},nose = {rod}}}

flaps = {status,value}

speedbrakes = {status,value}

refuelingboom = {status,value}

airintake = {status,value}

noseflap = {status,value}

parachute = {status,value}

wheelbrakes = {status,value}

hook = {status,value}

wing = {status,value}

canopy = {status,value}

controlsurfaces = {elevator = {left,right},eleron = {left,right},rudder = {left,right}} -- relative vlues (-1,1) (min /max) (sorry:(

}

 

but unfortunately there was no result in the LUA!

[Joe Kurr]

I haven't tried the canopy position yet, but this is what I use for the mechanical systems indicator:

 

function ExportCockpitData()
if LoGetMechInfo() then
	local RawGearStatus = LoGetMechInfo().gear.value
	local RawFlapStatus = LoGetMechInfo().flaps.value
	local RawBrakeStatus = LoGetMechInfo().speedbrakes.value
	--[[
		RawGearStatus == 1 --> Gear Down
		RawGearStatus == 0 --> Gear Up
		RawGearStatus > 0 < 1 --> Gear Retracting / Extending
	--]]
	local GearWarning = (RawGearStatus > 0 and RawGearStatus < 1) and 1 or 0
	local GearStatus = (RawGearStatus > 0.5 and GearWarning == 0) and 1 or 0
	local FlapStatus = (RawFlapStatus > 0.5) and 1 or 0
	local BrakeStatus = (RawBrakeStatus > 0.5) and 1 or 0
	local FodStatus = ((LoGetMechInfo().gear.main.left.rod + LoGetMechInfo().gear.main.right.rod) / 2 > 0) and 1 or 0
	local MasterWarning = LoGetMCPState().MasterWarning and 1 or 0
	
	local returnString = string.format("leds %d%d%d%d%d%d%d%d\n", 0, 0, MasterWarning, GearWarning, BrakeStatus, FodStatus, FlapStatus, GearStatus)

	if connection then
		socket.try(connection:send(returnString))
	end
	-- io.write(returnString)
end
end

 

As you can see, everything is exported as a value between 0 and 1, where 1 = extended and 0 = retracted.

When parts are moving (e.g. raising or lowering flaps), you get decimal values indicating the current position of the parts, all the way from fully raised to fully lowered.

 

In the code above I also use gear.main.left.rod and gear.main.right.rod. These values indicate the pressure on each wheel (both main landing gear in this case), which I use to determine whether the FOD shields should be up or down.

 

In the next version, I will also incorporate blinking leds for the airbrake and flaps, but for that I have to change my interface software a bit.

[edrom]

Hello joe,

 

Did you find a way to connect two TCP client (host, port) has the Same time with lofc2?

I think a connection to lovp and one other to the hardware (SiOC in my case)

 

it is possible with lofc1 with losioc (from lecreole), but impossible for me to find the way with lofc2 :(

[Joe Kurr]

I haven't worked with two TCP clients yet, but I think it should be easily possible.

This is what I use to connect to my interface application:

 

socket = require("socket")
host = "localhost"
port = 10309
connection = socket.try(socket.connect(host, port))
connection:setoption("tcp-nodelay", true)
socket.try(connection:send("start"))

 

I see no reason why something like this would not work:

 

socket = require("socket")
host1 = "localhost"
port1 = 10309
host2 = "localhost"
port2 = 10310
connection1 = socket.try(socket.connect(host1, port1))
connection1:setoption("tcp-nodelay", true)
connection2 = socket.try(socket.connect(host2, port2))
connection2:setoption("tcp-nodelay", true)
socket.try(connection1:send("start"))
socket.try(connection2:send("start"))

[Maraudeur]

@Edrom: as far as I've understood the changelog, the new version of SIOC (4.0) include spécial network procedures that may solve your problem: "The new version implements an special communications protocol via UDP, that allows the remote control of all electronic cards connected to any SIOC in the same network."

 

@Joe Kurr: that's an other great new to be able to get the hydraulic pressure values! It means that I would be able to make a functionnal HYD PRESS indicator, and to manage the failures (as long as I want to complicate my life with failures not taken in account in FC2 ;-))

 

I do have already a working routine for the SIOC to make the indicators Blink, if your're interested in!...

 

For the gear, I though that: "gear = {status,value,main = {left = {rod},right = {rod},nose = {rod}}}"

returned the individual states of each landing leg (in case of partial extension of the landing gear)

[Joe Kurr]

Someone from ED correct me if I'm wrong, but if I'm correct, the rod values indicate spring pressure, not hydraulics pressure.

You can test this by logging the gear.nose.rod and apply full throttle while holding the brakes.

You will see that it is ~0.5 at rest, and increases as the nose is pushed down.

 

Currently I do not work with IOC hardware, but I'm very interested, because I want to replace my current interface board (velleman K8055) with IOC boards in the near future.

[edrom]

socket = require("socket")
host1 = "localhost"
port1 = 10309
host2 = "localhost"
port2 = 10310
connection1 = socket.try(socket.connect(host1, port1))
connection1:setoption("tcp-nodelay", true)
connection2 = socket.try(socket.connect(host2, port2))
connection2:setoption("tcp-nodelay", true)
socket.try(connection1:send("start"))
socket.try(connection2:send("start"))

 

Joe, you are right, it is ok now. thanks.

i have sioc and lovp :) at the same time on lofc2.

 

i always intent to resolve this with two dofile : one for sioc and one for lovp...but not ok :cry:

your idea is to use one export with the two conections and report the specific lua for lovp on the first. it is the good way. many thanks.

 

@Edrom: as far as I've understood the changelog, the new version of SIOC (4.0) include spécial network procedures that may solve your problem: "The new version implements an special communications protocol via UDP, that allows the remote control of all electronic cards connected to any SIOC in the same network."

i don' know that, need to see , thanks maraudeur :thumbup:

[Joe Kurr]

You can also put the connetion code inside your include file.

Just remember to give it a unique name.

So you could use a variable named SiocConnection for one, and LovpConnection for the other for example.

(using "connection" in both will overwrite one with the other)

[Sov13t]

@Maradeur

 

Are you aware of Russian spelling issues on the panels? (srry if it has already been brought up... haven't been following this thread, just randomly looked at the pics)

Edited November 30, 2011 by Sov13t

[Joe Kurr]

Already posted in the "Post your setup" topic, but it also fits in here.

 

This is my mechanical systems indicator prototype, together with some inputs.

Note that the LEDs are all controlled from Lockon via export.lua, and don't necessarily reflect the position of the gear and flaps switches.

(for this picture Lockon wasn't running, I used my test-application to control the LEDs)

 

 

The Flare Quantity selector isn't working yet, because I need a 10-bit analog input for that, which I don't have (although I do have two 8-bit inputs)

 

If someone has an idea whether two 8-bit inputs can be combined in a clever way to 'emulate' one input, please let me know.

[Maraudeur]

@Maradeur

 

Are you aware of Russian spelling issues on the panels? (srry if it has already been brought up... haven't been following this thread, just randomly looked at the pics)

 

Yes, I've managed to understand a big amount of the russian acronymous in the cockpit, nearly the totality of the ones used in FC2, and many others, in particular for specific panels such as the chaff/decoy, the ECM, etc... I also have succeeded in understanding the way it works in the real a/c to be able to emulate it in my cockpit. Just send a snapshot of the acronymous you want to identify, and I'll explain it to you (as far as I can...)

 

@JoeKurr: I'm still wondering why you need an alog 10-bit for that panel.

Using SIOC and its language I completely manage the Chaff panel, including the LEDs bar displays.

For my gear and flaps panel, it's already managed by the SIOC; I mean that the indicators only depend on the switches position, by I use dirrerent tests (such as the IAS<500km/h, the hyd pressure, etc) to make sure the lights will be in accordance with the panel in FC2. A SIOC only reacts to state changings (0 or 1) the gear won't extend if I initialize in flight with my pit gear handle down :smilewink:)

Edited December 1, 2011 by Maraudeur

[Maraudeur]

Fot your information Sov13t, a rough tranlation of the Chaff and Flares control panel, I left this one just as it, for I translated the "nicest" one in french...

You'll find it there:

http://server.3rd-wing.net/public/Maraudeur/Chaff%20and%20IR%20decoy%20dispensing%20device%20APP-50.doc

[Maraudeur]

@JoeKurr:

As an example, here is my SIOC routine for the fuel tanks level indicators:

 

Var 1025, Link IOCP, Offset 0, Value 0 // Fuel internal (KG)

{

IF V1025 > 8400

{

&8400_ind = 0

&5200_ind = 0

&4300_ind = 0

&150_ind = 0

&500_ind = 0

}

ELSE

{

IF V1025 > 5200

{

&8400_ind = 1

&5200_ind = 0

&4300_ind = 0

&150_ind = 0

&500_ind = 0

}

ELSE

{

IF V1025 > 4300

{

&8400_ind = 1

&5200_ind = 1

&4300_ind = 0

&150_ind = 0

&500_ind = 0

}

ELSE

{

IF V1025 > 500

{

&8400_ind = 1

&5200_ind = 1

&4300_ind = 1

&150_ind = 0

&500_ind = 0

}

ELSE

{

IF V1025 > 150

{

&8400_ind = 1

&5200_ind = 1

&4300_ind = 1

&150_ind = 0

&500_ind = 1

}

ELSE

{

&8400_ind = 1

&5200_ind = 1

&4300_ind = 1

&150_ind = 1

&500_ind = 1

}

}

}

}

}

}

 

Here is my Emergency payload jettison:

Var 0303, name Emer_jett, Link IOCARD_SW, Input 3 // Emergency jettison

{

IF &Emer_jett = 1

{

V0999 = DELAY 529 ,10

V0999 = DELAY 529 ,20

V0999 = DELAY 529 ,30

V0999 = DELAY 529 ,40

V0999 = DELAY 529 ,50

}

}

The landing gear routine with the indicators:

 

Var 0313, name Gear, Link IOCARD_SW, Input 13 // Gear Handle

{

IF &Gear = 0 // Gear handle UP

{

&Gear_Fail_ind = 1

&Gear_ind = 0

&Gear_Fail_ind = DELAY 0 ,700

V0999 = 546

}

ELSE // Gear handle DOWN

{

IF &IAS < 500

{

IF V1043 = 1 // If gear U/S

{

&Gear_Fail_ind = 1

}

ELSE // If Gear is OK

{

&Gear_Fail_ind = 1

&BlinkLed = 10

&BlinkLed = TIMER 0 ,-1 ,50

&Gear_ind = DELAY 1 ,600

&Flaps_ind = DELAY 1 ,600

&Gear_Fail_ind = DELAY 0 ,600

V0999 = 32802

}

}

}

}

And the small routine to make the leds blink:

 

Var 0100, name BlinkLed

{

L0 = MOD &BlinkLed ,2

IF L0 = 0

{

&Flaps_ind = 0

}

ELSE

{

&Flaps_ind = 1

}

}

Edited December 1, 2011 by Maraudeur

[Joe Kurr]

@Maraudeur:

 

I need a 10-bit input because the Flare Quantity selector is basically a variable resistor (like a potentiometer), with 1000 possible values.

An 8-bit input only has a resolution of 256 values, so it doesn't 'see' most of the numbers I choose.

A 10-bit input has a resolution of 1024 values, which as a result can detect all 1000 possible numbers.

 

As for your SIOC code, it looks simple enough :)

Are in/outputs directly coupled to your variables? (e.g. &Flaps_ind, V0999, etc)

With the lua code I posted earlier, you can drop the code to calculate whether the gear and flaps should be up or down ;)

 

The lua code gives you accurate gear and flap positions, even when lockon puts the flaps up or down automatically.

 

My setup constantly reads the position of all switches, which enables me to put the gear-lever up while still on the runway, and have the gear retract automatically when I rotate :)

This works perfectly in the Su-27 and MiG-29.

With the Su-25T on the other hand, it has resulted in some embarrassing moments when the gear retracted right after I spawned on the platform...

[Maraudeur]

Yes, indeed, the sioc variables are linked to whatever you want: a switch, a rotactor, a led, an analogic entry (up to 4 on the USB expansion card that return a value between 0-255), a LCD display, and so on. You can also define local variable that are used to count some values, make some basic operation on them, or use them as a flag.

ON THE REAL su-27 the selector is a cotactor with some discrete values, just look there http://server.3rd-wing.net/public/Maraudeur/Chaff%20and%20IR%20decoy%20dispensing%20device%20APP-50.doc

this is the reason why i used a 12 position rotactor.

A swtich changing its position from opened to closed will change the value of the assiociated variable from 0 to 1, but only when the siwtch changes its satus (meaning that a switch continuously closed will not contiuously send a 1; this is just its related variable that changes its value) As for an example, if I set the gear lever UP before taking off, it won't move, even when airborne. To have the gear retractiong I must set the lever back DOWN, then UP, to have the command returning 0 and then sending the order to LockOn

Its funnig that you pointed out the variable V0999, because this one is the one used to send informations to the LUA, and thus to LockOn.

A friend of mine (Lecreole) choose to make the LUA calculate everything, but it lead to a slowdown while the export.lua was used for Lotact+Lovp+Lomod and so on... This is the reason why he reverted on my solution to make the lua calculate the basic values, but let the SIOC deal with these values.

But nevertheless we need to have informations about the actual status of the different devices of the SU-27 (position of the flaps, gear legs, airbrake, trims values, hydraulic value, canopy position, and so on)

[Maraudeur]

@JoeKurr: this activity in this topic just made me more impatient to build my cockpit SU-27 MK2 ;-) Would you be kind enough to send me your "blueprints" (just for panel size purposes, not to make a copy of your so nice work), as you may have seen on my photos, my pit #1 was obviously too narrow!

I'd like to start building my different panel, starting by the chaf/flare dispenser and then the SPO/ECM panel

Edited December 2, 2011 by Maraudeur

[Joe Kurr]

I think you're mixing me up with Wasserfall ;)

 

You just gave me a new project to work on with your previous post.

When I have the USB Extension and Master board from OpenCockpits, I'm starting work on the PPD-SP panel :)

[Maraudeur]

Oups! My mistake :music_whistling:

 

Indeed, I just mixed you up :cry:

 

Anyway, I so send the same question to wasserfall :smartass:

[wasserfall]

Parts?

 

Hi all,

 

Here are some parts that i will need to build,.... any idea??

 

 

 

First public reveall will be at the Milsim event in Soesterberg!

 

http://forums.eagle.ru/showthread.php?p=1487534#post1487534

 

See ya.

 

Wasserfall

Edited November 10, 2014 by wasserfall

[Alfa]

Yeah K-36DM :)

 

There is a "lumb" missing in the middle on those chute canisters though.

 

Note also that the headrest "block" has a much more rounded profile at front(where the pillow is attached) than at the rear end.

 

Sorry for the nitpicking, but I just spent the last two weeks battling with this seat(in 3D), so my head is filled with these details :D