Jump to content

Where do You purchase your Magnetic Switches?


Tekkx

Recommended Posts

Can I chime in here? If you really desire mag switches, why not use modified 5 volt relays?

A pin on top of the relay with a 45° cut off from the underside working against the spring. In its off state, the relay uses no current and so will be easy to implement.

I will conjure up a sketch of it later today.

Anything with a Rotary Wing is fun and challenging.

Use SRS radio.

Saitek X55 Modding

System Specs

 

Mixed Metals: i7 4790K@4.6, 32GB Kingston HyperX ram@2400Mhz, Gigabyte GA-Z97MX Gaming 5, ASUS Vega 64, 3xSamsung SSD drives, FSP Aurum 1000W PSU, Custom watercooling with EK blocks, Vive, Virpil MT 50, X55 throttle.

 

Link to comment
Share on other sites

This is a little bit tight to our matter, should work, but 100° to 120° would be perfect to reach the "snap point" secure and reliable (I keep tracking the FAA-License).

 

Adding 2 resistors in servo PCB you can make then turn 180 degrees.

 

http://fpvlab.com/forums/showthread.php?111-180-degree-servo-modifications

 

http://www.rcgroups.com/forums/showthread.php?t=629294

Link to comment
Share on other sites

 

That's a really good hack. (Watched the vid)

 

I allready did some tests with servo connected to arduino instead of servo tester: Conclusion is I came up (depending of kind of servo) with an angle of exactly 120 degs with the Servo of my choice. 120 is the magic angle.

 

And this is a lucky matter!!!!

I try to imagine to hack this micro-servo. I would need a clean room and a mid class microscope :)

 

My tax-case is almost solved (means: sent to the gov after a few days w/o sleep) so I can do further tests and tinkering next days :D

Also I cleaned up my cabinet* some. So there is also some place for this ;)

 

* Cabinet: A special room with computers, some kind of workshop, an ash-tray and my pilot's place.


Edited by Tekkx

Manual for my version of RS485-Hardware, contact: tekkx@dresi.de

Please do not PM me with DCS-BIOS-related questions. If the answer might also be useful to someone else, it belongs in a public thread where it can be discovered by everyone using the search function. Thank You.

Link to comment
Share on other sites

  • 3 weeks later...

Yesterday the brandnew PCB delivered.

Right now I have no time to saw and solder them.

 

Status of our project is attached ;)

Look at the Pics... I may need new glasses. Tho' it works I'm not in danger to win an award for beauty.

 

In the center of the Control- and PWM-PCB are 4 Pins to be seen (last pic). These are PWM Slave-OUTs (or INs). So there is just one (1) MOS-FET needed if other MagicSwitches (or other Backlights) present and to be lighted.

 

But: I'm still on it :)

 

Right now I have to spit some code and make a first test run.... maybe tomorrow :music_whistling:

837702054_20151107_221125PCB.thumb.jpg.53b4e23010f86ce5dbcbcd5039255493.jpg

1628757562_2015-11-0811_30_30.thumb.jpg.a563fb194d3338a6523bee3a1459cf9f.jpg

1668262219_2015-11-0811_31_25.thumb.jpg.1ecf9c55c661c7b40c7df0649cfde631.jpg

1055219270_MagASwPCBwRandReed.thumb.png.38c0222d6fa5a06bf58b40d8c903b463.png

1399195335_MagASw_PCB_wLED.thumb.png.8878919297eff9dd769f37a997044fcc.png

145994709_MagASwde-assembled.thumb.png.0ac37f7d6b3a7b29c1ff75bf3ecaee3e.png


Edited by Tekkx

Manual for my version of RS485-Hardware, contact: tekkx@dresi.de

Please do not PM me with DCS-BIOS-related questions. If the answer might also be useful to someone else, it belongs in a public thread where it can be discovered by everyone using the search function. Thank You.

Link to comment
Share on other sites

  • 1 year later...

Took the liberty to revive this thread in case the Ebay sales thread is not monitored.

 

For thoese interested in mag switches at $50 for 3x then this seller has them;

http://www.ebay.com/itm/Lot-of-3-NEW-Honeywell-Micro-Switch-6ET22-T-Aircraft-Avionics-Military-/252794602851?hash=item3adbbb8563:g:O98AAOSwB-1YuAMX

 

Or $23 a piece;

http://www.ebay.com/itm/252777454409?_trksid=p2060353.m1438.l2649&ssPageName=STRK%3AMEBIDX%3AIT

 

 

Cheers

Hans

Link to comment
Share on other sites

Took the liberty to revive this thread ...

...

Cheers

Hans

You did right to do this. :)

 

My "magic switch"-Project is "on ice" ATM.

It came out (Ian opened my eyes) that it'll become some difficult to connect MagneticHoldSwitches to DCS (no matter if serial or RS-485). DCS reports (exports) just the status of switch's lever, not of the switched device. If I understood Ian's speech well.

 

So if you actuate the (hardware-)switch, DCS (even in CaD cockpit) reports that movement back to your hardware. This produces a back coupling which prevents DCS-induced release of your switch. (e.g. SAS_PitchLeft_Coil holds lever in ON position while DCS can't realize if this switch is held by magnetic force or by hand.)

 

So is my theory. I stopped further examination of that caused by lack of time and some appeared mechanical problems. My plan has been to deliver something that could anyone reproduce at kitchen's table. Each approach to a suitable solution ended in a battle of material. Far away from my intended goal :(

 

Now, after the awareness of the (described above) paradox, I have to reconsider this matter. Right now I make a board with (ON)-OFF-(ON)-Switches and LEDs, which "tell" the status of the "Mag-Switch" to the pilot.

If there is anyone with a useful hint regarding driving a coil without recoupling: You are welcome! :)

BTW: The linked offer (post above) is very inviting anyway.


Edited by Tekkx

Manual for my version of RS485-Hardware, contact: tekkx@dresi.de

Please do not PM me with DCS-BIOS-related questions. If the answer might also be useful to someone else, it belongs in a public thread where it can be discovered by everyone using the search function. Thank You.

Link to comment
Share on other sites

Took the liberty to revive this thread in case the Ebay sales thread is not monitored.

 

For thoese interested in mag switches at $50 for 3x then this seller has them;

http://www.ebay.com/itm/Lot-of-3-NEW-Honeywell-Micro-Switch-6ET22-T-Aircraft-Avionics-Military-/252794602851?hash=item3adbbb8563:g:O98AAOSwB-1YuAMX

 

Or $23 a piece;

http://www.ebay.com/itm/252777454409?_trksid=p2060353.m1438.l2649&ssPageName=STRK%3AMEBIDX%3AIT

 

 

Cheers

Hans

 

Thanks for sharing this Hans - my Wallet has just been suitably depleted in Prep for a Hornet build :)

 

Cheers

Peter

Link to comment
Share on other sites

Thanks Hans for lighting up this thread again.

(and those links are the best prices I've seen in years for Mags)

 

 

I feel kinda an old dog barking up the same empty tree here so please ignore bad spelling, grammer and result of a numb brain

 

 

@Tekkx/Ian/Any:

For a DCS:BIOS approch, Does the"DcsBios::LED saspPitchSasL(0x1108, 0x1000, PIN) command provide a working solution and is active as long the DCS Cockpit switch is in 'On' state, and DCS:IOS sets that to 'off' state if the virtual switch falls to 'off' ?

 

If DCS:BIOS triggers and maintain that output as long the physical switch is in on state (hold be the Magswitch) and drops the 'LED' output when the "DCS" switch falls to 'Off state', it's much simpler to adopt then what is described below. The wiring and solder stuff is the easy part here (for me at least)

 

 

My current setup is a manual quick and dirty config of the Mags in my Pit

(Running Opencockpit cards & SIOC). I activate the coils on script start and then check if any of the GEN switches are in 'On' state,

if so I mantain the power to the coils and manually deactivate them if any fall to 'off state' in the Sim. The word is quick and dirty here :)

 

 

 

 

A summery from the true flightmanual (not errorchecked):

 

 

 

2 SAS Channels are Powered by Left AC and DC Busses

These in turn supply the hydralic preassure and are a prereq for SAS channels function.

"Excessive diff between L and R channels disables SAS'

(quiz is how much is excessive ?? ;-)

Emerg Disconnect lever on Stick disengage SAS channels

"Monitor Test" trigger a failure on SAS YAW and Pitch Channels that in turn release the coils

both SAS Switches, (YAW or Pitch) are actuated simultaneously and momentarily heldy

 

## PITCH SAS

both electrically released to OFF if the monitor circuit signals a failure

if the SAS emergency disengage switch is actuated

When either switches goes to OFF (manually or triggered by a faliure),

both switches are disengaged (released)

PITCH SAS caution light will come on.

PITCH SAS switches are ->powered by the right DC bus<-

 

## YAW SAS

- Both are electrically released to OFF if the monitorcircuit signals a failure

- If the SAS emergency disengage switch is actuated

- Yaw SAS will be disangaged on 'excessive' diff between SAS channels (again the same quiz of how much is much)

- When either swiich goes to OFF (manually or triggered by a faliure), both will disangage

Flight with single yaw SAS channel can be pursued under most flight conditions,

..ones the failed channel is found or disengaged. (How is the SAS Channel disangaged ?)

A hard faliure on active (remaining) channel will cause a rudder deflection to 8-10 degrees depending on KIAS,

to either side (depending on the active SAS channel)

IF running under HARS, YAW SAS will disangege on failure in HARS roll or Pitch servos.

The 'Power'Red flag on HSA and ADI will show, roll tabs missing on HUD,

HARS Caution light shows on disangeging Yaw SAS.

Yaw trim and Yaw rate dampning can be reenabled by setting the HARS/SAS override switch to OVERRIDE and reenabling the SAS switches.

YAW SAS caution light will come on.

YAW SAS switches are ->powered by the right DC bus<-

HARS/SAS Override switch

Powered by right DC bus

Set switch to OVERRIDE to eliminate HARS roll error checking and provide YAW SAS engagement

(Guess this referes to only when running under HARS controll.

But above taken into account, I probably left the 'true' path along the way (or if I ever been on it at all)

 

Returning to the subject, using SIOC, one way could be to build a simple function to react on the switches state on the panel instead.

 

It should be doable in SIOC IF I could export the state of each switch (up till now I only used Oakes script to send commands to the switches/deviceIDs)

but not reading the value out of specified switches / device

 

Think about it like this, When DCS Sim start,

- Set the physical coils to activated (individually) regardless of what the state the Sim is in.

Setting the Physical switch to on (the actived coil will hold it). SIOC sends a "1" to the VAR that itself trigger the set command to DCS (it not continously repeat that value to the VAR).

-Check the DCS Device:Switch state on next export cycle,

- If the Sim switch falls to the 'off' position in DCS, Drop coil power and cockpit Switch will do the same

- Set a Delay/Timer (10-20 ms) then activate the coil again

 

 

As long as DCS have the logical coil poweredand hold the switch. the physical switch is held by the Mag coil.

If DCS doesn't and decide that the virtual one is unpowered, The physical switch will fall after a short delay, triggered by the switch in DCS that is released.

 

 

Same approch should be applicable to EAC, AntiSkid and Anto Collision Mags also but as always remain to be verified and only if I could get the correct status of the switches / device exported. All mainpanel exports flows with minimal pain.


Edited by Duckling

- - - -

Link to comment
Share on other sites

Thank you for your interest in this matter.

 

Let me explain with Ian's writing (his english and knowledge is much better than mine):

Ian;3058484']The function ("defineElectricallyHeldSwitch" - cited from post above there) is still there, it's in Util.lua now. Electrically held switches are implemented, but there is no separate output that tells you when to power the coil -- from the Export.lua viewpoint, the state of an electrically held switch looks like any other toggle switch. It just happens to be changed by the sim on its own from time to time.

 

Most users will use normal toggle switches for these and can treat them like any other toggle switch (DcsBios::Switch2Pos).

 

If you actually have an electrically held switch, you can monitor the switch state (check the control reference in Advanced view for the IntegerBuffer code examples). You'll have to figure out the exact logic yourself -- I have never done it because I don't have such a switch to test with.

 

It might be sufficient to have a normal DcsBios::Switch2Pos monitoring the toggle switch and just turn the coil on whenever the switch in the virtual cockpit is in the on position.

 

No matter what you do, there will be some edge cases that won't behave like the real thing. For example, when you push and hold the physical switch, the switch in the virtual cockpit will always be in the ON position and your coil will engage. Export.lua cannot tell the difference between the coil being on or off while the switch is being held in the on position, because the only info we get is the switch position (which is the only thing the rendering engine cares about).

 

If we don't find a way to either

1. decouple switch and coil (what doesn't solve problem 2) or

2. export the real DCS-intended coil(!)-state (instead of Lever's position as it is right now) or

3. make a logical construct that reads out any/all conditions which brings the coil into ON-position

we can't implement a good working MagHoldSwitch.

 

That's my knowledge of the matter at THIS moment.

Manual for my version of RS485-Hardware, contact: tekkx@dresi.de

Please do not PM me with DCS-BIOS-related questions. If the answer might also be useful to someone else, it belongs in a public thread where it can be discovered by everyone using the search function. Thank You.

Link to comment
Share on other sites

Hehe, you are very welcome yourself.

 

Did you get that it describe a solution for how to 'decoupling' the switch from the coil ?

(In a way that will solve the problem)

 

 

edit:

And then again, this might be the old dog venting the same message all over again and I fail to get the prerecs

Been struggling with these for longer time then I wish to remember

 

 

If the logical switch is in an on state (1) and held in place either by coil or manually, and the Argument of that logical switch can't be set to to off (0) by any means, it's a usolvable by any approach, right ?

Or is there ANY way to circumvent this restraint

 

 

Forth option not listed is a request to ED to expose the the state of the Mags coils through either Mainpanel or the deviceID (.autopilot. for the SAS switches)

 

 

In essence, how hard could it be for ED considering the time this module been around and the knowledge they have of it

Limited user has any issue with this but time 'unsolved' might count for something..

 

 

 

Cheers

Gus


Edited by Duckling

- - - -

Link to comment
Share on other sites

Good morning Gus.

Meanwhile I did some thinking and (just think) I found a solution. Owners of MagneticHoldSwitches (following called: MHS) won't be amused by that.

 

Attached is what I squeezed out of my brain this morning at the kitchen table, consuming 3 pots of coffee and about 5 cigarettes, before I woke up my little girl (meanwhile I sit at work):

 

We need a special MHS which can execute 3 conditions:

1. Lever in OFF-position

2. Lever in halfON-position (explanation follows)

3. Lever in ON-position

 

This description should work on any/all MHS in the A-10C.

- Pilot actuates Hardware MHS, lever has to pushed into ON (T1 closed).

- if DCS accepts ON: coil is fired and holds lever in halfON, T1 opens if pilot releases lever, DCS holds still at halfON. Inside Sim the lever stays at ON position

- if pilot decides to switch lever to OFF: DCS recognizes and releases coil.

- if DCS declines status ON: coil is fired as long pilot holds lever in ON. As pilot releases lever, lever will follow releasing finger until halfON position, T1 opens, DCS no longer sustains condition ON, coil is no longer fired, lever falls back to OFF.

 

Zack fertich.

 

T0 is closed, if MHS is coil-actuated. No further action required (I think so).

 

My example works, if we use following code:

const byte saspPitchSasLPins[2] = {PIN_0, PIN_1};
DcsBios::SwitchMultiPos saspPitchSasL("SASP_PITCH_SAS_L", saspPitchSasLPins, 2);
DcsBios::LED saspPitchSasL(0x1108, 0x1000, PIN_3);

Pin_0 is connected to T2 at my sketch

Pin_1 is connected to T1

Pin_3 is connected to the coil (LED) with adequate amplification (MOSFET or Darlington)

 

 

I could act out some more examples.... I think it's clear.

 

To reach an almost true-to-life situation, Lever-Stages ON and halfON should be as close as possible. Lever's tip shouldn't move more than 2 mm back after "removing" your finger off the lever (down-left corner of my sketch).

 

Your fourth option (a request to ED) is still subject to discuss :)


Edited by Tekkx

Manual for my version of RS485-Hardware, contact: tekkx@dresi.de

Please do not PM me with DCS-BIOS-related questions. If the answer might also be useful to someone else, it belongs in a public thread where it can be discovered by everyone using the search function. Thank You.

Link to comment
Share on other sites

It is a long time since I looked at this so I might be wrong.

In DCS there is an event for both putting pressure on the switch to push it into position and another for releasing pressure. Pushing the physical switch from off to on simply needs to send both commands with a short delay. Coil position is then controlled by the switch position export.

 

If you push switch into on position and coil should not be on then it will send both push and release commands. DCS will then return the switch to off position. As this drives the coil your cool will flip back to off position

 

As long as you don't set the switch up like abnormal toggle switch where you are simply writing the 2 switch positions to DCS there will be no problem with this.

 

I do not know how Dcs bios handles these but this setup should work correctly

IIRC this is what we had figured out for these switches


Edited by Boltz
Link to comment
Share on other sites

... Pushing the physical switch from off to on simply needs to send both commands with a short delay. Coil position is then controlled by the switch position export.

 

If you push switch into on position and coil should not (yet - ed by Tekkx) be on then it will send both push and release commands. DCS will then return the switch to off position. As this drives the coil your cool will flip back to off position

The problem could accrue, if you - pushing the button - miss the delay. Once the coil is fired, DCS can't differ, if YOU press the Switch or DCS its self - HW-switch is the same status: ON. So the Switch (physical and virtual ones) will stay in ON position, no matter if SAS (or other switched device) is ON or OFF.

 

Don't know, how it works in the real bird, but if I hold a button (or momentary switch) in the ON position, it will be in the ON position as long as I press my finger on it. No matter if there is a current or voltage on the line.

 

It looks really like the only working way is to request this feature (export coil-status) from ED. Or we have some hackers slob out here :music_whistling:


Edited by Tekkx

Manual for my version of RS485-Hardware, contact: tekkx@dresi.de

Please do not PM me with DCS-BIOS-related questions. If the answer might also be useful to someone else, it belongs in a public thread where it can be discovered by everyone using the search function. Thank You.

Link to comment
Share on other sites

Very nice discussion here.

 

I believe this stuff should be solvable, although a workaround may be needed.

I am already using a two pole Battery switch to send a signal to DCS as well as hot-wire an ATX power supply. I can use the ATX power supply going online to power up a 24VDC power supply which is needed to energize the mag switches.

 

Anti-collision light:

Instead of monitoring the switch state in the sim it should be possible to make a workaround. Fair enough I plan to implement a real throttle which gives me a few extra possibilities. IIRCC then anti-collision light switch will de-energize when throttle pinky switch is not in aft position.

  • So it should be possible for me to hardwire the pinky switch so that in aft position it will energize a small two pole 5VDC relay. One set is used to tell DCS that pinky is in aft. The other is used to supply voltage from the 24VDC PSU to the mag switch.
  • If pilot moves the mag switch into off position then the input to DCS changes and the 3D switch should also move.
  • If pilot moves the throttle pinky switch into mid/fwd positions then the small relay will de-energize and remove 24VDC to the anti-collision mag switch causing it to flip into OFF position and the 3D switch should therefore also move.

 

This may also be possible with DCS:BIOS if the pinky switch state is available from DCS. If so DCS:BIOS could send anti-collision mag switch hold function “1” in case the throttle pinky switch is in aft position then a similar setup should be possible, i.e. energize a small 5VDC relay that will supply voltage from 24VDC power supply to the anti-collision mag switch.

 

Most likely there are more logic behind needed, e.g. battery power switch is on OR one of the generators are running, but this is just as an idea.

 

Anti-skid:

Make DCS:BIOS monitor the state of the Anti-Skid alarm on the caution panel.

  • If anti-skid alarm state changes from no alarm (dark) to alarm (lit) then anti-skid mag switch hold function changes to “0” for 250ms, then set to “1” again.
  • If anti-skid alarm state changes from alarm (lit) to no alarm (dark) then anti-skid mag switch hold function remains “1”.
  • Anti-skid mag switch hold function is used to energize a small 5VDC relay which will provide voltage from 24VDC power supply to anti-skid mag switch. I.e. as long as anti-skid mag switch hold function is “1” then the mag switch can be held in position by 24VDC.
  • After one second pilot can re-engage the switch again. In case alarm is blinking then it will drop out again as the alarm state changes again from no alarm to alarm.

 

EAC:

Make DCS:BIOS monitor the state of the EAC alarm on the caution panel, similar to above used for anti-skid

 

YAW SAS:

Make DCS:BIOS monitor the state of the YAW SAS alarm on the caution panel, similar to above used for anti-skid

  • Using this logic there may be an issue if the real A-10 system is capable of turning just one of the YAW SAS switches into off due to failure. If this is a possibility then the behaviour will not be correct as both switches will de-energize when YAS SAS mag switch hold function cannot differentiate as it is just looking at the alarm.
  • Also there is another inaccuracy but this is already present. IIRCC then you can force the YAW SAS into ON using real real switch (non mag switch). As soon as you set it ON then the 3D one will follow, even though you cannot set it via the 3D cockpit.

 

PITCH SAS:

Would be done similar to YAW SAS function.

 

Note!

If DCS is started with a running aircraft there is already a problem using real non-mag switches. In case the real switch is set as ON then as soon as the sim is un-paused switches will disengage.

 

 

Cheers

Hans


Edited by Hansolo
Additional explanation
Link to comment
Share on other sites

@Tekkx, yupp agree on that it introduce some issues for existing Mags, the approach itself looks workable but as you say, it require some extensive tinkering

 

@Bolts, Within the existing (DCS provided) function for the Mag switches, there is no release command stated, just the absolute On or Off.

There are some stated in the newer DCS:Bios but haven't tried to see if that could work. Read some note from Craig and Ian that the switch in on state still overrides the possibility to let DCS disangage the coil. (not sure if that was written prior or after Ian posted the DCS:BIOS 'new' Magswitch function.

 

Currently got all my Mags but the Anti-Collision (remain to be connected) switch hooked up to Opencockpit boards/SIOC.

 

 

@Hans. Great post and concise written,

some diff from the 'real' guide but thats a minor. Question is also how much of the EAC, SAS, etc functionallity that have been implemented in A-10C module in DCS.

 

Disengage says to loss of Hyd pressure, caution indication etc that relate to the SAS channels not allways trigger a release.

Single channel reengage possible under some circumstances and induced rudder effect will be seen and so on.

 

Have to reread posts again a calm environment, dogs and kids running wild all over ;-)

 

Any option to slave the Mags to DCS I think would be preferable over the other way around even if some functionallity is lost on the way.

 

I been tinkering to get the Magswitch state into my scriptbase in SIOC, but failed first attempts but think I found the way, in a attempt to see if I could mimmic the switch state of DCS.

 

This must be basic scripting and I think I found the way but remain to be verified

Haven't given up yet and learned that even if it's 'basic' scripting, it's better in the long run to try it out oneself prior posting a plea for help.

Got a few hours peer week availiable for this so it's a long running task.

 

 

Cheers

Gus

- - - -

Link to comment
Share on other sites

Thank you Gus, for your efforts. I'm shure you'll share if you find something useful out :)

...

Got a few hours peer week available for this so it's a long running task.

Similar here :/

So it happens I push some matters noteless to the siding: E.g. my brandnew laser-cutter is still unpacked in it's card-box for half a year consuming place and catching dust. Not even I know if there is really a laser-cutter inside :doh:

 

Hold on and tell us about. So I'll do.

Manual for my version of RS485-Hardware, contact: tekkx@dresi.de

Please do not PM me with DCS-BIOS-related questions. If the answer might also be useful to someone else, it belongs in a public thread where it can be discovered by everyone using the search function. Thank You.

Link to comment
Share on other sites

To early to say for sure but it looks good so far :-)

Got one of the SAS switches state exported into SIOC (was barking up the wrong tree as suspected earlier) and made a test script that seems ok.

Will rig it end of week to test it. 4 SIOC Variables used.

# 1: Has the DCS cockpit switch state

# 2: Input from the physical switch position (just On or Off)

# 3: Controls the relay that energizes the Coil

# 4: Status Var, Used to send the Command into DCS to set switch position (through Clickabledata)

 

The theory (so far ;-)

- The Var #3 / Coil is allways (almost) On/Energized

 

 

- Var #2 (Physical switch) set status of Var #4 to On/Off

 

(The physical switch (hold by force or MagCoil in On position) send an impulse to Var #4 to go to On position or Off (placed mnually or by the coil release)

 

- Var #4 send its state that sends the command to DCS to set the "DCS" switch to on (and stay there if nothing else is detected on Var #1).

- DCS export of the switchstate into Var#1 (if the SIM sense a release/return to Off state), Var#1 trigger Var#3 to go low (release power to the coil), and releases the Physical switch that will go to Off, THEN energizing the coil with a short delay.

 

Var #2 sense the 'Off' state (physical switch goes low) and send a '0' to DCS (that is allready in that state (just to close the loop of thought)

 

In other word, even if the Coil is active and holds the switch for some milliseconds, DCS switchstate will release the switch if the hold is not allowed.

 

Only tested it as far as with the 'monitor test' switch on the SAS panel and with one of the Mags through SIOC Console but looks good so far. Struggling with a SIOC Delay function and some logic handling DCS vs SIOC.

 

and as said before, I might be way off target here but future will tell

 

 

Cheers

Gus


Edited by Duckling

- - - -

Link to comment
Share on other sites

It looks good but only 'almost' :-)

 

 

All SAS switches and EAC connected and works but yet only when enter a live cockpit. Haven't yet found the cause but pretty sure it caused my myself in the scripting mess. work ongoing. I get an invaled state reported back from DCS on the SAS Pitch Right switch (or more likly I've f-d up my script that grab that arg val of it)

Starting a mission in a cold/dark pit stops all SIOC/DCS communucation so it seems the err is in my scripts somewhere (disabling the Mags part and I'm back to normal status again)

 

 

It's four variables per switch so far

 

 

#1 Imported value of DCS cockpits switch dev(0) Arg 185-188

if DCS reports switchstate = 1 (on), set Var #2 high/enable

if DCS reports switchstate = 0 (off),

wait a few millisec, set Var #2 to 0,

wait > 40 millisec, set Var #2 to 1/enable, (this causes the Coil to release and the enable again shortly after: The physical switch position changed to off, is sensed by Var #3 and fed back to DCS throgh Var #4)

 

#2 outputport to enable the relay that powers the Mag Switch Coil)

 

#3 physical 2-pos switch (of the Mag) position is sensed and set "#4" accordingly

 

#4 Variable to to send switch position to DCS

 

 

The loop looks like this:

Start SIOC, Var #2/Coil are enabled on script start

Start of DCS to 'push pause to continue"

Set all Mags Switches to desired poition

Start DCS (un-pause)

If DCS says the Mags are in On position, nothing changes, all system go

If DCS says the Mags are in Off position, Coils are recycled (On->Off->On) and the physical switch is returned to DCS reported state.

 

If I manually set switch to Hold/On, (when the DCS switch is set to released), the switch will be held a few millisec by the Mag, then released again when DCS set it to 0, and the cycle continues.

 

a slight offset in timing of the delays between switches seems to be needed, The OC cards misses (some times) when all switches is set on/off at the same exact time.

 

My USB expansion card for left panel is bad, and has been for some time, pops up as unrecognized device more and more and needs to be replaced. Will be some weeks until that made so I'll put this in pending until then.

 

 

 

edit: function verification is made by the SAS Monitor test switch (on sas panel) in DCS cockpit and the physical switch itself. SAS switches goes 'off' and shortly after the EAC follows so it should be a valid test. Not sure of best way how to induce an error/fault into the environment that triggers an error in one or both of the SAS channels. Any suggestions ?

 

Cheers

Gus


Edited by Duckling

- - - -

Link to comment
Share on other sites

  • 2 weeks later...
  • 2 weeks later...

Hi

 

Managed to get the SAS up and running with real mag switches, much easier than anticipated, Initially I though of making a one-shot timer for the ON position but seems like this is not necessary at all with DCS-BIOS. Nice work Ian :thumbup:

 

 

I have just been using DCS-BIOS with advanced setup, i.e. two inputs per mag switch, as well as a single output via a MOSFET semiconductor.

 

I can see only very small differences between mouse clicking in 3D cockpit compared to using the real switches.

 

 

Cheers

Hans

Link to comment
Share on other sites

  • 1 month later...

As time went by (meanwhile) I realized a cheap (not really cheap but also not quick and dirty) solution without the use of MHS (You'll remember: Magnetic Hold Switch).

 

I use a simple (ON)-OFF-(ON) switch and report the state of the SAS channel to the pilot by a LED.

 

As I coded the sketch (coding means - thanks to Ian - dully copy and paste of code snippets) I encountered a problem. Maybe it is solved meanwhile somewhere sometime. I searched the forum, but I doesn't manage to find it:

 

...
const byte saspYawSasLPins[2] = {A6,A5};
DcsBios::SwitchMultiPos saspYawSasL("SASP_YAW_SAS_L", saspYawSasLPins, 2);
DcsBios::LED saspYawSasL(0x1108, 0x0400, 4);
...

Complete code I'll post if this problem is solved.

Compiling gives the error "conflicting declaration" 'DcsBios::LED saspYawSasL' Which makes sense to me.

 

My concept forces the use of SwitchMultiPos and the LED. (LEDs state symbolizes the switchs state of the SAS channel).

I attached two photos of my skeletton. There aren't the final switch-levers yet. The crater-like holes are for the backlite. Lightplate is not mounted yet. On top you see the 4 Status-LEDs.

 

While I spent last months with these mechanical details I lost some of my knowledges about DCS-BIOS.

Is there someone with a helpful hint?

1255726115_20170527_2139451.thumb.jpg.3be12541f56ec875d82a044e4c7baf66.jpg

1429659007_20170527_2140161.thumb.jpg.afc067f1b956dd78d7f5342e9585c410.jpg

219247902_20170527_2236281.thumb.jpg.0aee35726db5ade217882f6914318f7e.jpg


Edited by Tekkx

Manual for my version of RS485-Hardware, contact: tekkx@dresi.de

Please do not PM me with DCS-BIOS-related questions. If the answer might also be useful to someone else, it belongs in a public thread where it can be discovered by everyone using the search function. Thank You.

Link to comment
Share on other sites

The variable names for your DcsBios::SwitchMultiPos and DcsBios::LED instances are both "saspYawSasL", and the compiler complains because you can't have two variables with the same name. Just rename one of those variables and it will compile. The name of those variables does not matter, as they are not referenced anywhere else in your code anyway.

Link to comment
Share on other sites

Ian;3150958']The variable names for your DcsBios::SwitchMultiPos and DcsBios::LED instances are both "saspYawSasL",

...

The name of those variables does not matter,

...

This is the key.

Thank you, Ian. (Good to know, you are always here :) )

Now, as I read your lines, I remember I scanned similar somewhere before...

 

And here is the code:

/*
 The following #define tells DCS-BIOS that this is a RS-485 slave device.
 It also sets the address of this slave device. The slave address should be
 between 1 and 126 and must be unique among all devices on the same bus.
*/
// ******************************************************************************************
// A-10C SAS
// adopt ID to your actual bus architecture.
#define DCSBIOS_RS485_SLAVE 20
// ****************************************************************************************** 

/*
 The Arduino pin that is connected to the
 /RE and DE pins on the RS-485 transceiver.
*/
#define TXENABLE_PIN 2 // hard coded on PCB

#define consoleBltPin 3 // PWMout for controlling Backlite, hard coded on Tekkx' ICB
#include "DcsBios.h"

// modified variable by deleting "p" (for panel)
const byte saspYawSasLPins[2] = {A6,A5};
DcsBios::SwitchMultiPos sasYawSasL("SASP_YAW_SAS_L", saspYawSasLPins, 2);
DcsBios::LED saspYawSasL(0x1108, 0x0400, 4);

const byte saspYawSasRPins[2] = {A4,A3};
DcsBios::SwitchMultiPos sasYawSasR("SASP_YAW_SAS_R", saspYawSasRPins, 2);
DcsBios::LED saspYawSasR(0x1108, 0x0800, 5);

const byte saspPitchSasLPins[2] = {A2,A1};
DcsBios::SwitchMultiPos sasPitchSasL("SASP_PITCH_SAS_L", saspPitchSasLPins, 2);
DcsBios::LED saspPitchSasL(0x1108, 0x1000, 6);

const byte saspPitchSasRPins[2] = {9,10};
DcsBios::SwitchMultiPos sasPitchSasR("SASP_PITCH_SAS_R", saspPitchSasRPins, 2);
DcsBios::LED saspPitchSasR(0x1108, 0x2000, 7);

DcsBios::Potentiometer saspYawTrim("SASP_YAW_TRIM", A7);

DcsBios::Switch3Pos saspMonitorTest("SASP_MONITOR_TEST", 11,12);

DcsBios::LED takeOffTrim(0x1026, 0x0400, 8);
DcsBios::Switch2Pos saspToTrim("SASP_TO_TRIM", 13);



void setup() {
 DcsBios::setup();
}

void loop() {
 DcsBios::loop();
}

// Backlight Control
void onLcpConsoleChange(unsigned int alt) {
  analogWrite(consoleBltPin, alt/256); // alt = 0...65535 (could also use map()...)
} 
DcsBios::IntegerBuffer lcpConsole(0x1150, 0xffff, 0, onLcpConsoleChange);


Edited by Tekkx

Manual for my version of RS485-Hardware, contact: tekkx@dresi.de

Please do not PM me with DCS-BIOS-related questions. If the answer might also be useful to someone else, it belongs in a public thread where it can be discovered by everyone using the search function. Thank You.

Link to comment
Share on other sites

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...