Duckling

Sign me up for one please

Well, in that case the myth is more of self induced based on hope and expectations, true that some 'expected' target dates been stated since first post. Then followed later on by disclamers and their reasons. Combine a vision of high quality, in depth know-how, low cost and fast time to market with cross reference to a compatible flora of products in one guy enterprise approach, there is bound to be exceptions and replaning. I looking forward to each update (and will in future also) regardless of if or when his products reach the market. When and if possible I'll buy in on any products within scope. As long the thread is here and not in a sale thread, it's a discouss and sharing of ideas in my view even if there has been dates, estimates etc stated. No disrespect to any intended, just a remainder to to keep faith and respect up (Disregard bad grammer above) Best /gus

Found this, not sure if it's applicable or not... http://www.electronixandmore.com/projects/vgatoscope/index.html

@hans: great info but I fail to locate currect thread in there, can you provide a link or thread ID on VP ? @John: a board setup somewhere about 200$ whould be really good cost if achivable. Several instruments in scope. Long way there though and also potential risks with the high voltage needed to drive the CRT. Could be a bit hazardous for both self and pit if not shielded proper. Link you posted to the "clockmaker" products seems robust and impressive. Quiz if its doable on a DIY basis (out of my league here but I check with a wiz I know) Cheers /B-O

Not sure where the breake-even is. The one in my pics is run in VGA and might be possible to enhance. In this case it's good enough but doubt it will be enough for the fine details on the RWR. There several micro projs on ebay but prize is high for HD quility with nice functions and Lumen and lowres cheep one tend to be bigger than coud fit in a 3" RWR tube. Watch up for proj that needs to be controlled by knobs on the shell, kinda hard to reach when built in. more viewports exported in high res dig into the GPU and CPU resources but for a good working standalone RWR it might be worth it. To bad SoftTH isn't supported on newer OS (or is it?) would be fun to test a low cost micro proj and see the result, with and without a green filter without going broke before christmas :-) I'll check if I can locate another proj for test setup and if someone beats me to it, please post some pics here A custom cut screen as DM says would be the best ofcose but way out of my leage currently

It's an internal forum within VästeråsFlygMuseum. Couldn't find any of my old original pics so I grabbed that instead One more that eagerly await LNS latest baby :-) Right behind you here but I think another build currently at home will get me ejected by Wify. We (Museum) been searching for 37 cabin (any version) for some years now but still no luck. The objects in our show area is 'sadly' in a no touch status. A bit envy of our closest collegues Swesim & Novelair here. :-) would be an option but it's a big no-no in our case, strive for as close to the real thing as possible, existing but not in place is the front bezel with moving "ILS" needels and some other stuff. True for avoiding pocketing the MIP for LCDs ofcouse. The main pain using back projection are to avoid reflections, light leakage from outside, space required behind the screen, low intencity and set of focus so yes, it depends on the rig. Me personal I'd go for a TFT anytime where possible but I have the same problem as 'Warhog' for the RWR. I got nowhere possible to squize in a 4:3 monitor to cover the 3" RWR whithout cutting my frame or movings the sorrounding instruments. This option might fit Cheers Gus

I post this in a separete thread to not clutter another thread where this topic popped up. Had a short discussion about using this type of setup for the A-10 RWR and likewise and like to share our approach. Very interested to see what other type of approches and the results been made. Here is one example of using rear projection with a micro projector for instruments where a TFT/LCD is impossible to fit. In this case its a A2A radarscope for a Swedish J35-Draken. The task is still WIP but the main build is ready and we use this in a X-plane based full size cockpit. Same approach should be possible with a viewport export from DCS such as RWR. Adding a green filter would be even better (I hope :- ) and a bit darker also. This micro USB projector is kinda weak on light, have a long throw (low angle) and low resolution VGA. We removed the tube itself and placed the projector with a custom 3D printed fixature where the 'neck' of the tube had been. Estimate distance from lense to lense about 300-400 mm so it was with a slight margin it fit with the required size of projected window. We first used a sheet of same material for backprojection we have on our big screens but found it a bit too dark and ended up using a lightgray paper instead. The pics shows it lighter then in real life. Note also the vid is taken from start of runway and shows heavy groundclutter the .zip is a (very) short video of the scope in action. Cheers Gus Fil 2016-12-06 12 13 27.zip

Very nice build Can you share some info on the front big projection screen, is it home built, molded or bought ready ? Best /Gus

A third option for a scope or tft/lcd is a rear mounted miniprojector in a tube. We hacked a radarscope (true 5" J35 Draken this case) and s simple media behind the lense good enough for backprojection. Low level graphic projection works well and the orig cathod tube is saved and out to show area. Proj screen is good enough but clearly not as distict as the true one or a crt Same approach should be doable with the RWR also. Got some pics stached from that build if interested /gus

:-) Thanks Nicklas. Seems we 35'pitters share the same problem. We'll check it out. Numbers of pc's, processes and devices kinda never get fewer

Hi John. Really nice work on those pedals and the complete setup.

Hi. A quick response while on the move Troubleshooting in an unknown config can be a mess, same goes for any suggestions by me. There are some way to import pit status (adressing mainpanel.lua) into SIOC and I don't know if you using any of these. Below is assuming you don't.. Can you do the following to clear the picture somewhat ?.. # Clickabledata.lua Find a verifed unedited 'last' version of your clickabledata.lua file, copy to correct place, use and stick to that. This avoid you introduzing new errs in the config or have version update that restore the original state. Edit the SIOC .ssi file or export, import.lua's instead (use siocexport.lua, sioc2dcs.lua and the .ssi file etc). To ease my understanding of your situation, can you respond to quiz below Say the following: # Prereq's: Using a verified unedited clickabledata.lua file: remove VAR initilize to "0" in your .ssi file (Var 645 and 890 earlier ?) Check the VAR IDs, seems you edited the script, target the VAR that is connected to SIOC export script, 890 and 900 probably) Startup the Sim on a 'cold' start mission - Is the levers in correct positions (left/right) ? - Using Physical switches to operate the levers, will they move both levers in the virtual cockpit ? - Are they working during several (on-off-on-off..) movements Startup the Sim on a 'warm' start mission - Is the levers in correct positions (left/right) ? - Using Physical switches to operate the levers, will they move both levers in the virtual cockpit ? - Are they working during several (on-off-on-off..) movements Using SIOCMonitor/Sioc Console Sending a value of "0", "1", "0", "1", "0", .. to each VAR645, VAR890 (the SIOC VARs that controls the output to DCS) - Do the handles on virtual cockpit move each time, at all or just once ? On first start after power on your PC, if a SIOC Var is not initilized (Var = 0, 1 or whatever), SIOC has no knowledge of what the physical switch is in. The position of same in virtual cockpit is in "default" state. If your physical switch is (by chance) in same position, SIOC VAR still missing a assigned value, operating the physical switch first time to get a SIOC value assigned you have to move that switch one step and then back if needed. The way to avoid the above is to cycle all switches prior mission prior start of mission and to their requested positions # function TwoPositionSwitch If this a still same as Oakes original, editing the line as below should invert the behavior of the handle in virtual cockpit (provided that the addressing is set up ok that is). Edit and check if this have any effect after the actions above. [890] = {TwoPositionSwitch, 4, 9, 1, 1}, -- Cut off Left Engine [900] = {TwoPositionSwitch, 4, 10, 1, 1}, --Cut Off Right Engine # AK-50 serial. Many thanks for your offer, can try it out # Site.. Total mess ;-) Site down now to several reasons but working on a solution when time allows. Pit building have been stranded again so no real updates there. Cheers Gus

Yes. Looking good. Great job

Hi, I'm still fumble in the dark here. Found the file reference at last rereading the complete post: SiocToDcs.lua ;-) and a reference to it in thread https://forums.eagle.ru/showthread.php?t=57094&page=5 Gillesdrone posted a "version10" of his setup posted in https://forums.eagle.ru/showpost.php?p=1630912&postcount=49 with a bunch of other related files, and Takeoff-For-Fun refer to the fileset you have I think. It's another variant of what I'm using so take the following with a grain of salt Post from IAN with related info: https://forums.eagle.ru/showpost.php?p=2440800&postcount=141 In Gillesdrones files, the mailpanel.lua (from that .zip) shows the left_engine_break_handle, Argument 554 accepts 0 or 1 as input so skip the "-1" a suggested earlier right_engine_break_handle Argument 555 accepts 0 or 1 do the same Whats seems a bit strange is info of right handle in clickabledata.lua, the same odd info for the right handle argument (different Argument "555" vs "55") I assume you address the "TwoPositionSwitch" function in a ExportSupport.lua from within a SiocConfig.lua or likewise (could be the SiocToDcs.lua): [890] = {TwoPositionSwitch, "Device", 9, 1}, ( -- adding the trailing ", 1" whould invert the outcome, like [890] = {TwoPositionSwitch, "Device", 9, 1, 1}, Could this be what you looking for ? --ExportSupport.lua: function TwoPositionSwitch(pValue, pDevice, pNumber, pOnValue, pInvert) if pInvert then if pValue == 1 then pValue = 0 else pValue = 1 end end GetDevice(pDevice):performClickableAction(pNumber + 3000, pValue * pOnValue) end Having the Module whould simplify the guesswork. Was some time since I juggled the gray cells but here are some suggestions. (As far I remember I don't have any arg_value with "directions" in the A10 and not sure how to address or adopt these) Focus on the EMERGENCY-BRAKE ENGINE-LEFT-PTR (due to the Right.. odd Argument "555,55", looks like a typo in clickable.lua to me but this is the second file I see that in) For the the differens between warn and cold start, cant say for sure but there are two options I think. - Scratch to initialize the Var (Ex. Var 0645, name Ej_SW1_val, >>>Value 0<<<< // Value of EJECT1 switch ) Delete the "Value 0" in the .ssi file Think that when you make a warm start, the handle is forced by script to the wrong state The state of the SIOC database is not initilized at first start (of your PC). It add each Values on first actions on the physical inputs, and remain in that state until changed or shut down of your PC). With no Initialize value on VAR after first start of PC you need to operate each switch/knob to desired position prior start of mission to be sure. It causes unpredictable behavior when restarting a mission from Cold to Warn and vice versa. Initilizing a VAR makes it return to a fixed state regardles of the type of mission you start in and that sounds like the other problem you have. A checklist for warm/cold start and manual setting each switch/knob etc to desired position prior missionstart is probably the best solution. There is a way to get the IOCard to update SIOC setting by soldering a cable between a selected port, one per each MasterCard, this getting an aotoupdate of current status of all switches to reflect positions. You loose one port per MC and it involved some scripting. Haven't used it myself: http://www.microsofttranslator.com/bv.aspx?ref=IE8Activity&from=fr&to=en&a=http%3a%2f%2fwww.simubaron.fr%2famelioration_master.htm (And you still need to manually verify each switch position prior start) Please ignore bad spelling/grammer above and if someone reading this with KA50 pit at hand, please chime in :-) (Edit: i.e. is the Arg "55" valid for the right handle release command and is working proper or is 555 used for both Activate and Release in your working pit?) Best Gus

Hi Don't edit the clickabledata file, even if you get it to work you'd be stuck if future release updates it, dependencies is hard to track so use SIOC and/or the export functions instead. Since I lack KA50 module and only have a limited knowledge about it, I could force you off track here :-), For the "typo" quiz is that you use the digit 1 (one) instead of the "I" (the letter) on VAR 610 (post #116) Might be of here and haven't verified if the "1" is a valid parameter syntax. From the first post #115. I did assume you had the VAR 0654 in use both as the VAR for input (Dev5 Inp 30) AND as the same VAR linked to DCS. Reason for asking was that you addressed the same VAR 0645/&Eject1 in the VARs dependent script: Separating these as seen in Post #116, VAR6010 for input for the OC/inputport and VAR 0890 connected to DCS enable you to set the later to a value of your chosing. The ["EMERGENCY-BRAKE ENGINE-LEFT-PTR"] switch itself is a 2-pos switch (or is at a 3-Pos ?) I assume a 2Pos here. You initilze it to be "0" (Var 0890, name C_off_val1, Value 0), Judging from the clickabledate.lua info above I'd say you need use an argument value of either "1" or "-1" to get'em to flip between the two endpoints. Can you try to push a 1 or -1 through SIOCConsole and see the outcome ? If that works, initilize the Var of the switch to have it set the same in the virtual cockpit to your choosing Remember thats it's no magic involved, just a complex flow of data involving several dependent files. I'm sure I read a reference your wrote above to a lua file named something like lotodcs.lua or something like it. Can't find that any more. You edited the post or am I getting delerious (or blind) ;-) Verify also the info in clicabledata.lua: elements["EMERGENCY-BRAKE ENGINE-RIGHT-PTR"] = { class = {class_type.TUMB,class_type.TUMB}, hint = LOCALIZE("Right engine cut-off valve"), device = devices.ENGINE_INTERFACE, action = {device_commands.Button_10,device_commands.Button_10}, arg = {555,55}, arg_value = {direction*1.0,-direction*1.0}, arg_lim = {{0.0, 1.0},{0.0, 1.0}}, updatable = true, use_OBB = true} I have a hunch that the "55" off-value should be a "555" If someone with a clear mind see an err, please chime in, It's getting late Cheers Gus

Hi Terrorvogel (above post is correct, Use a seperate VAR for the "Switch-input" and the "dcs value to change" make it lot easier to control the outcome. For the not working switches, here are some ideas: - Not sure how the DCS is addressed here. It's either a 'change state' command or an absolute value you write. What are the values required in DCS:KA-50 in clickabledata.lua for these switches ? (don't have that Module), If not "0" to disable or "1" to enable, the answer might be there and the function called may need to be changed or a new added (say if it's -1 and 1 for the act/deact or even a decimal value) Switch Input type "I" is mimicing a momentary input/button, State of the input VAR reflect the button position directly. A type "P" is latched, it flip the State On or Of for each time the button/toggle is activated (so probably not what you want) In the script above I see "Var 6010, name C_OFF_G, Link IOCARD_SW, Input 36, Type 1", Is this a typo ? /Gus

Hi. A QnD copy/paste of my setup. Must be a nicer way to script it. Got the Mode rotary inside it and some other junk but please ignore. Hope it be of some help.

Backtracked my orders and found I bought a piece from both sellers. Both popped up in resonable time. Biggest 'flaw' with this is I'm not able to change the I2C device ID on these so each has to live on a seperate bus. Neal, (had the same problem) if your 2x16 is for the CMSP, one option is to swap strings to 3 Chars like: ... newString.replace("CHAF","CHF"); newString.replace("FLAR","FLR"); newString.replace("OTR","OT"); newString.replace("PROG","PRG"); newString.replace("DISP","DSP"); newString.replace(" "," "); ... Not as neat but save time /Gus

Check if ebay item 191835417963 fit the need, a bit pricy though Cant get the link working but ebay search get the correct item

Jupp. Looks great. PM inbound /Gus

Can't agree more. The real thing is a complete different thing the plastic/rubber feeling of the TMs. Envy you on these

Great it worked out with the code. Was afraid I would make real (bigger) fool of myself otherwise ;-) I've earlier used helios (great software) but no longer due to focusing on another path. Problem you have I think is nested scripts, together with a lot of exporting the same values multiple times (I had same type of problem). I'm nowere near to a programmer and tries to stear throgh the djungle with best effort learning at best pace. For Helios and Oakes scripts coexisting I assume a single "export.lua" build were each set export a minimal set would be best, but not skilled enough to say for sure.

Fault is mine. Having only an iPad (hate typing on that thingy) and a bit distracted mean while piles up the problems. Now grabbed Jr's PC, downloaded SIOC and Notepadd++ and did it proper instead It's easier to track the syntax when intend lines for each function, see the notepad..jpg and sioc window. Exporting the .ssi to text looses the overview of the topology. Created a .ssi to verify just in case (in the .zip file). Sincerily hope this works now :-) Cheers Gus edit: dependencies for the sioc script is that OXY_LOW warning indicator work as intended. Issue is also that when first time the OXY LOW indicator start to "blink", the output port driving the relay would do the same until you push the master caution knob on the UFC, from there on the output port would remain off (cutting the power to your pump). A10_v1.txt A10C_v1.zip

Ahhh. My bad, Think this caused by the earlier var thread is not closed correct causing the complie error. Compare the numbers of { with } Var 8002 needs a trailing } at the end, same for var 9601. Nowhere near a sioc now but try it out

Nice find DM. Those 5 or 4 inch ?