Jump to content

DCS-BIOS Discussion Thread


FSFIan

Recommended Posts

so tested it and it works as intended.

I think you talk about the Light over the Hook Handle?

 

After tested with the refpage. the light gives an 1 when on and 0 if light off (ARRESTING_HOOK_LT)

 

the Lever works inverted: 1 if Hook is raised 0 when lowered (HOOK_LEVER)

 

maybe you took the false "output name"? means you took the handle instead of the light

Link to comment
Share on other sites

so tested it and it works as intended.

I think you talk about the Light over the Hook Handle?

 

After tested with the refpage. the light gives an 1 when on and 0 if light off (ARRESTING_HOOK_LT)

 

the Lever works inverted: 1 if Hook is raised 0 when lowered (HOOK_LEVER)

 

maybe you took the false "output name"? means you took the handle instead of the light

 

Hi BlackLibrary,

 

Thank you for the response. Yes, I'm talking about the light physically located above the arresting hook handle. I think it's the only light associated with the arresting hook in the cockpit.

 

Can I ask what you mean when you say you tested it with the "refpage"? Because when I test it in the DCS-BIOS Hub (under control reference, think it's considered the "virtual cockpit connection", the only way I know how to test it), I'm showing the "Hook Light" indicating a "0" when ON and "1" when OFF. I can take screen shots if it helps you see what I'm talking about.

 

Also, I see strange behavior with the arresting hook in the virtual cockpit connection. The values don't change when I click on the virtual cockpit controls or the handle in game, they always read "0". However, when I click on the virtual cockpit "Toggle" or "INC"/"DEC" value, the hook lever in game will move, but no values change in the control reference (virtual cockpit) in the DCS-BIOS Hub. I've randomly checked at least 10 other controls in the hub control reference (virtual cockpit connection) and they are all working properly, both functionally and indications, so it's just the arresting hook and light acting weird.

 

One more thing that might help with this issue... I've noticed the arresting hook light seems to be incorrectly triggered by ONLY whether the handle is in the up or down position. But if you watch the behavior of the light in the cockpit, there is a delay when the light turns off as you raise the hook. So essentially, the hook light remains on anytime the hook isn't in the fully retracted position. In summary, drop the hook = light goes on immediately. Raise the hook and there should be a delay when the light turns off. I'm seeing not only reversed indication values but also a simple on and off command of the light based on lever position, not hook position.

 

and if it helps, here are the snippets I'm using from the control references:

 

DcsBios::Switch2Pos hookLever("HOOK_LEVER", PIN);

 

DcsBios::LED arrestingHookLt(0x74a2, 0x0100, PIN);

 

 

 

 

 

Thanks again for taking a look at this!


Edited by Sickdog

TM Warthog, Oculus Rift, Win10...

Link to comment
Share on other sites

i use the Flightpanel Fork of bios what is an expanded version on 0.7.xx Bios before the HUB thing.

 

This is todays most actual BIOS and in development by me. The HUB version planes have some errors. with a little work you can use the luas from our build in the hub version.

 

anyways the live preview shows me the corrert vales for the light as i descriped

Link to comment
Share on other sites

i use the Flightpanel Fork of bios what is an expanded version on 0.7.xx Bios before the HUB thing.

 

This is todays most actual BIOS and in development by me. The HUB version planes have some errors. with a little work you can use the luas from our build in the hub version.

 

anyways the live preview shows me the corrert vales for the light as i descriped

 

Thanks BlackLibrary. Maybe I'll revert back to the pre-Hub DCS-BIOS for my sim-pit anyway since my gear lever down-lock solenoid hasn't worked since switching to the hub.

 

One last thing- Just curious if you saw the same behavior I described with the light turning off (well, on for me) immediately when raising the hook? We can take this to a PM if you want so we don't spam the whole thread about this one little issue.

 

THANK YOU for all your work on this and helping me out!

TM Warthog, Oculus Rift, Win10...

Link to comment
Share on other sites

Does anybody have an up to date approach for utilizing I/O expanders with dcs bios on arduino? I'm trying to get it to work but man...

 

Not an updated approach but I tried to use MCP23017 chips in the very first version on DCS-BIOS, but never got it to work later. I believe that Ian said it should be possible, however some of the easy commands with DCS-BIOS would get lost.

ClayM tried to get it to work but unsure if he made it.

https://forums.eagle.ru/showthread.php?t=169462

 

There is a link to the centipede shield in post #5, which was the version I had running many years ago. I eventually went for a different a approach with one Arduino per panel.

 

Cheers

Hans

Link to comment
Share on other sites

Hey guys - I have a question.

 

I have 3 position switch that are on(mom)-off-on(mom). I occasionally like to use these instead of Potentometers or Rotary Encoders for lights. I've used these switches to toggle the brightness of lights up/down. I only need to hold the switch in the given position until I have the lighting I wish to use. I have several Ardunios that show up as USB Joysticks. Mapping is done through DCS itself and it is super easy.

 

In terms of DCS BIOS; how would I create this same logic? I initially thought using the RotaryEncoder function could work, but it does not for these types of switches.

 

here is an example of what I'm trying to do:

DcsBios::RotaryEncoder instPnlDimmer("INST_PNL_DIMMER", "-3200", "+3200", 30, 32);

 

I know these switches are not rotaries (obviously!) but in theory they are doing the same thing? sending a "pulse" on the given input...

Link to comment
Share on other sites

Encoders or pots are always at a certain value. Encoders usually add or subtract 4 from “x”. Pots you can read.

 

To mimic this with (on)off(on) switches you need to create the value - just call an int lightsVal and give it a value - and then add or subtract based on pulses or time. Then send the value as an axis position.

 

 

Sent from my iPhone using Tapatalk

Link to comment
Share on other sites

Encoders or pots are always at a certain value. Encoders usually add or subtract 4 from “x”. Pots you can read.

 

To mimic this with (on)off(on) switches you need to create the value - just call an int lightsVal and give it a value - and then add or subtract based on pulses or time. Then send the value as an axis position.

 

 

Sent from my iPhone using Tapatalk

 

Do you have an example of this? It makes sense, I'm just a bit confused on how to write the actual code.

Link to comment
Share on other sites

I'm not a coder but I suppose something like

 

void setup() {
long lightVal = 128;

 pinMode(14, INPUT_PULLUP);
 pinMode(15, INPUT_PULLUP);
 
}

void loop() {

if (digitalRead(14 == LOW) { 
     lightVal++; 
     }
if (digitalRead(15 == LOW) { 
     lightVal--; 
     }  

 Joystick.sliderLeft(lightVal);
 Joystick.send_now(); 
}

 

you obviously need to expand on this and make the numbers suit your situation.


Edited by longuich
Link to comment
Share on other sites

In terms of DCS BIOS; how would I create this same logic? I initially thought using the RotaryEncoder function could work, but it does not for these types of switches.

 

No, the inputs on an incremental rotary encoder and a switch are quite different. The switch you have listed of cause only input when you preset.

The incremental rotary encoder gives inputs on both but in a sequence, i.e. by rotating one way you don't just get pulses on one input but on both of them.

 

This is illustrated here:

https://en.wikipedia.org/wiki/Incremental_encoder#/media/File:Incremental_directional_encoder.gif

 

 

Encoders or pots are always at a certain value.

 

I may misunderstand but the incremental rotary encoders (the ones we would buy) don't give their position at all. And only by rotating them and having software analyse the pulse sequence it's possible to determine the direction of rotation.

You can get rotary encoder that give absolute position similar to a potentiomenter (absolute rotary encoders) but they are normally quite expensive.

 

Here is a little more on the difference between absolute and incremental encoders;

https://www.machinedesign.com/mechanical-motion-systems/article/21836107/whats-the-difference-between-absolute-and-incremental-encoders

 

Cheers

Hans

Link to comment
Share on other sites

Hi!

 

There's a "big" problem with the JF-17 dcs bios module.

 

some specific JF-17 switch/other won't run.

 

Ex :

 

DcsBios::Switch2Pos afterburnSw("AFTERBURN_SW", PIN); <= WORKS!

DcsBios::Switch2Pos aaAgSw("AA_AG_SW", PIN); <= DON'T WORKS!

DcsBios::Switch2Pos ag1Ag2Sw("AG1_AG2_SW", PIN); <= DON'T WORKS!

DcsBios::Switch3Pos masterArmSw("MASTER_ARM_SW", PIN_A, PIN_A); <= WORKS!

DcsBios::Switch2Pos phTestSw("PH_TEST_SW", PIN); <= DON'T WORKS!

DcsBios::Switch3Pos aarSw("AAR_SW", PIN_A, PIN_B); <= WORKS!

 

DCS bios read correctly the code but switch don't move.

 

Also, Yaw Trim Switch is a 3posSwitch not 2 . I don't have test all function. Just 5/6 for testing.

 

Thanks! :smartass:


Edited by Roger01
Link to comment
Share on other sites

@hans

What I meant to say was a pot can be read and produces a value. Turning an encoder produces a value of fours or eights or whathaveyou. In case of a button there’s just a pulse or state.

 

 

Sent from my iPhone using Tapatalk

Link to comment
Share on other sites

Thank you.

 

It seems that this code not run as it do :

 

void onBattSwChange(unsigned int newValue) {
     /* your code here */
  }
DcsBios::IntegerBuffer battSwBuffer(0x4828, 0x0080, 7, onBattSwChange); 

 

for exemple, this code works perfectly :

 

void onAfterburnSwChange(unsigned int newValue) {
   /* your code here */
}
DcsBios::IntegerBuffer afterburnSwBuffer(0x4804, 0x8000, 15, onAfterburnSwChange);

 

I think there's a lot of error with adresses.

 

Where can I check that?

 

Because some of number seems to be good between Mods\aircraft\JF-17\Cockpit\Scripts\clickabledata.lua and Saved Games\DCS.openbeta\Scripts\DCS-BIOS\lib\JF-17.lua but won't works.

 

 

[Edit] With some tests, all (all I test) "void XYZ (unsigned int newValue) {}" code who won't works, "DcsBios::Switch2Pos XYZ("XYZ_SW", PIN_A)" code won't works too.

 

So I think there's a real addressing problem . JF-17 module fault? wrong address written by developers on a .lua file? Other?


Edited by Roger01
Link to comment
Share on other sites

  • Recently Browsing   0 members

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