DCS-BIOS Discussion Thread

[Tekkx]

I have already built a device that ...

Is there anyone surprised about that? ;)

 

I am looking forward to your code. I have all(!) required hardware on hand.

But don't be disappointed, if I replace it later with DCS-BIOS 2.0 :)

Edited December 29, 2015 by Tekkx

[Warhog]

Is there anyone surprised about that? ;)

 

I am looking forward to your code. I have all(!) required hardware on hand.

But don't be disappointed, if I replace it later with DCS-BIOS 2.0 :)

 

:megalol: What can I say....:music_whistling:I like to build stuff. :D. I'll post pics as soon as I'm able but basically it's a 1" dia. X 30" long aluminum tube with a ping pong ball at each end with a bunch of green LEDs in one end and red in the other end. The high current white LEDs are at the Centre point and are being directed upwards. The glow or reflection off the walls from this contraption is just enough to let me know they are on, flashing or strobing. I don,t expect them to be in perfect sync with the screen image but it's certainly enough to create the effect and more importantly to communicate the state of the running lights when I can no longer see a virtual cockpit. I now have to figure out how to create an effect similar to an engine explosion/fire.

[Exo7]

Hi Ian, All

 

Happy New Year !

 

I have a question about adding module in "Control Reference Doc".

 

have you to write line by line the json script or have you a method to generate it ?

i don't find anything about it in dev manual...

 

Thanks.

[FSFIan]

The JSON file is just a serialization of the "documentation" property of the module object. It is rewritten automatically when DCS-BIOS is started.

 

Look at the function BIOS.util.document and how it is being used elsewhere (e.g. in the example in the developer guide or in BIOS.util.definePushButton()).

 

For most cases, you will use one of the functions in BIOS.util and those take care of adding the documentation entry.

[Exo7]

Ian;2626707']The JSON file is just a serialization of the "documentation" property of the module object. It is rewritten automatically when DCS-BIOS is started.

 

Look at the function BIOS.util.document and how it is being used elsewhere (e.g. in the example in the developer guide or in BIOS.util.definePushButton()).

 

For most cases, you will use one of the functions in BIOS.util and those take care of adding the documentation entry.

 

Thanks,

 

Ok, i see the function that take the description in the defineToggleSwitch (for example),

but when i launch DCSBIOS, nothing change in my control reference doc, the one in %SAVED GAMED%\DCS\Scripts\DCS-BIOS\Docs

 

is it right for new module or i have anything more to do ?

(i'm creating the M2000C module).

My commands works in the plane.

 

the other thing i need help it's for light indicators.

maybe it's due to the BETA state of the module, but i don't find the argument for them.

(i'm aware that you can't do anything for me for this point...)

and i don't understand, when i'm looking in the DCSBIOS A10C scripts, how do you use/find address and mask ?

ie : DcsBios::LED clA1(0x10d4, 0x0001, PIN);

 

Thanks

Edited January 2, 2016 by Exo7

[FSFIan]

If you follow the steps in the developer guide, you should get to the point where you have a M-2000C module in the control reference docs.

 

Here's an M-2000C.lua to get you started:

BIOS.protocol.beginModule("M-2000C", 0x2400)
BIOS.protocol.setExportModuleAircrafts({"M-2000C"})

local document = BIOS.util.document
local defineToggleSwitch = BIOS.util.defineToggleSwitch
local defineIndicatorLight = BIOS.util.defineIndicatorLight

defineToggleSwitch("BATTERY_POWER", 8, 3520, 520, "Electrical Power Panel", "Battery Power")

-- caution panel light argument numbers start at 525
defineIndicatorLight("CLP_BAT", 525, "Caution Lights Panel", "BAT")
defineIndicatorLight("CLP_TRW", 525, "Caution Lights Panel", "TRW")
-- increasing argument numbers from left to right, top to bottom
defineIndicatorLight("CLP_DSY", 551, "Caution Lights Panel", "DSY")

BIOS.protocol.endModule()

Note that the comments in devices.lua are misleading, you need to add 1 to each device ID (if you read through the code for the counter() function, you'll see that it starts counting from one, not from zero as the comments assume).

 

I think that the reason that the indicator lights are nowhere to be found in the Lua files is that they do not have tooltips, so there is no reason for them to interact with the mouse pointer in any way. They still have cockpit arguments.

 

The easiest way to find out which cockpit arguments are for which lights is probably to ask RAZBAM if they have a list of them.

 

Otherwise, use brute force!

Start with this code snippet in the Lua Console:

for i=1,1000 do
   GetDevice(0):set_argument_value(i, 1)
end

When you execute that, you will see all kinds of lights flashing briefly for one frame or so before they are reset again by the M-2000C code. Now you can do a binary search -- adjust the range of the loop until the only light that is flashing is the one you want.

Using that technique, I found out that the lights for the caution lights panel in the M-2000C start at argument number 525.

 

This code snippet (and my earlier post about how to export the M-2000C radar with MonitorSetup.lua) is brought to you by the M-2000C Test Key (I would not have bought a fast mover module), so thanks again to ED for making me a beta tester! :thumbup:

[Exo7]

Ian;2626815']If you follow the steps in the developer guide, you should get to the point where you have a M-2000C module in the control reference docs.

 

Here's an M-2000C.lua to get you started:

BIOS.protocol.beginModule("M-2000C", 0x2400)
BIOS.protocol.setExportModuleAircrafts({"M-2000C"})

local document = BIOS.util.document
local defineToggleSwitch = BIOS.util.defineToggleSwitch
local defineIndicatorLight = BIOS.util.defineIndicatorLight

defineToggleSwitch("BATTERY_POWER", 8, 3520, 520, "Electrical Power Panel", "Battery Power")

-- caution panel light argument numbers start at 525
defineIndicatorLight("CLP_BAT", 525, "Caution Lights Panel", "BAT")
defineIndicatorLight("CLP_TRW", 525, "Caution Lights Panel", "TRW")
-- increasing argument numbers from left to right, top to bottom
defineIndicatorLight("CLP_DSY", 551, "Caution Lights Panel", "DSY")

BIOS.protocol.endModule()

Note that the comments in devices.lua are misleading, you need to add 1 to each device ID (if you read through the code for the counter() function, you'll see that it starts counting from one, not from zero as the comments assume).

 

I think that the reason that the indicator lights are nowhere to be found in the Lua files is that they do not have tooltips, so there is no reason for them to interact with the mouse pointer in any way. They still have cockpit arguments.

 

The easiest way to find out which cockpit arguments are for which lights is probably to ask RAZBAM if they have a list of them.

 

Otherwise, use brute force!

Start with this code snippet in the Lua Console:

for i=1,1000 do
   GetDevice(0):set_argument_value(i, 1)
end

When you execute that, you will see all kinds of lights flashing briefly for one frame or so before they are reset again by the M-2000C code. Now you can do a binary search -- adjust the range of the loop until the only light that is flashing is the one you want.

Using that technique, I found out that the lights for the caution lights panel in the M-2000C start at argument number 525.

 

This code snippet (and my earlier post about how to export the M-2000C radar with MonitorSetup.lua) is brought to you by the M-2000C Test Key (I would not have bought a fast mover module), so thanks again to ED for making me a beta tester! :thumbup:

 

 

My mistake !!!!

 

i have add the <script> tag in the bad control-reference.html... it's working now...

as this, in your documentation is it write to add <script> tag in control reference.LUA ..

maybe you can modify it to prevent errors...

 

yes i have seen that the Devices address aren't good... my poor shoulders... ;)

 

Thank you so much for the CLP args and for the script to obtain the args !!

have a nice day !

Edited January 2, 2016 by Exo7

[jrsteensen]

Random question, and pretty basic - hoping I didn't miss something, but is the arduino due compatible with DCS BIOS?

[FSFIan]

It should work with any Arduino, so give it a try if you already have the Due, but I'd recommend ATMega328-based boards (Uno, Pro Mini, ...) and possibly the Mega 2560.

 

I test my code on Pro Mini boards and some future improvements for the Arduino library (interrupt-based communications and RS-485) will only work on the ATMega328 (and maybe the Mega 2560) unless someone else ports them to other platforms.

[Exo7]

I confirm that the Mega 2560 is fully compatible with DCS BIOS, i'm using it...

 

 

Cédric

[jrsteensen]

Okay. I was just looking at how to drive a TFT for my nav panel. I also was trying to drive two radio panels with a serial OLED character display on each. Mostly done with mechanical, and starting to look more closely at my electrical and I/O layers. Didn't know if the pro minis would have enough oomph for the application. Going to be able to drive the entire overhead panel off one Mega or Due.

[BravoYankee4]

Back to an old topic - the MIG-21 landing gear lights that are messed up (the red indicators for gear up are kind of inverted). Maybe this isn't a bug in the DCS-Bios code after all. Recently noticed that the behavior is exactly the same in the HawgTouch panel. So, should it then be adressed to LNS or ED as a bug in the export data?

[Hansolo]

[FSF]Ian;2627387']Released v0.4.2.

 

 

[*] A-10C: Add SET_VHF_AM and SET_VHF_FM commands to directly set the radio frequencies for the AM and FM radios. Only works for valid frequencies for the given radio.

[*] A-10C: add ALT_PNEU_FLAG export value (position of the yellow PNEU flag in the Altimeter)

 

 

 

 

 

Very nice Ian. Thanks a lot. Should make my life a hell of a lot easier. "Need to spread reputation around"

 

Cheers

Hans

Edited January 4, 2016 by Hansolo

[FSFIan]

A quick update:

I think I have most of the features I wrote about half a year ago working now (everything except the shift register and I/O expander support).

 

Before this can become an official release, I need to check and update all of the relevant documentation and do some minor modifications to the auto-generated code examples. Given my current university workload, that will probably take a while.

 

In the meantime, I plan to put some minimal documentation together (a short document listing the changes compared to the current version, a few instructions on how to use the RS-485 stuff, maybe a short video) and then release the current state of things as a beta version.

 

Assuming the headaches stop after Monday's dentist appointment, you can probably expect an update sometime next week.

[hegykc]

I'm about to join this party, big time.

 

Quick question, can dcs-bios be used with FC3 (flaming cliffs) in any capacity? If not for outputs (instruments/leds), at least for inputs (buttons/switches)?

 

I'm making a general military aviation panel for FC3 planes with a bunch of switches, encoders, selectors and buttons. Could I create FC3 dcs-bios profile for it?

[FSFIan]

Quick question, can dcs-bios be used with FC3 (flaming cliffs) in any capacity? If not for outputs (instruments/leds), at least for inputs (buttons/switches)?

 

I'm making a general military aviation panel for FC3 planes with a bunch of switches, encoders, selectors and buttons. Could I create FC3 dcs-bios profile for it?

 

You can add DCS-BIOS support for a FC3 aircraft, but it will be very limited compared to something with a clickable cockpit.

 

For output, you can export general information (airspeed, heading, altitude ASL and AGL, pitch, bank, roll); some of that is already taken care of for all aircraft by the CommonData module. Depending on the aircraft, you might have access to a little additional state, e.g. whether the autopilot is on or off.

What you don't get are the positions of switches and gauge needles or the state of indicator lights, because there is no known way to grab cockpit arguments from a FC3 aircraft.

 

For the input direction, DCS-BIOS (i.e. Export.lua) probably won't be able to do anything that doesn't also have a keybinding in the DCS options. This means that if all there is is a "toggle this switch" command, you won't be able to use Lua/DCS-BIOS to properly make a toggle switch work either.

See the attachment of this post for a list of all commands you can send to a FC3 aircraft (not all of those commands apply to all airframes).

[hegykc]

Thanks for the quick response. Now I have some homework to do...

[doveman]

It might be worth looking at Capt Zeen's F15 Helios profile, as I believe he used some tricks to export more than is normally possible with the FC3 aircraft http://forums.eagle.ru/showthread.php?p=2307634

[FSFIan]

I have pushed the current state of things to the rs485 branch on GitHub.

 

If you don't want to mess around with git, you can download a ZIP file of the contents of that branch here:

https://github.com/dcs-bios/dcs-bios-arduino-library/archive/rs485.zip

 

Here's a very quick overview of changes you need to be aware of:

• The DCS-BIOS Arduino library is now configured with #defines before including DcsBios.h. See the example sketches to see how this is done.
  
• onDcsBiosWrite() is gone. If you want to process an integer value, use the IntegerBuffer class like this:
  

  void onAltChange(unsigned int alt) {
     lcd.setCursor(0, 0);
     lcd.print(alt);
     lcd.print("    ");
   }
  DcsBios::IntegerBuffer altBuf(0x0408, 0xffff, 0, onAltChange);
  

  
  

• The template sketch has gotten much smaller, the communication code has moved into the library. This also means that once you have programmed and tested a sketch using a serial connection, you can quickly switch it to work as a RS-485 slave device by modifying the configuration #defines (see example sketches).
  
• I have quickly tested Switch2Pos, LED, StringBuffer and IntegerBuffer. Everything else could still be totally broken.
  

 

Quick RS-485 How To:

 

• Flash the RS-485 Master example sketch to an Arduino Mega.
  
• Connections on the Mega (MAX487 is the transceiver chip I use):
  TX1 ---- DI on first MAX487
  RX1 ---- RO on first MAX487
  2 ---- /RE and DE on first MAX487
   
  TX2 ---- DI on secondMAX487
  RX2 ---- RO on secondMAX487
  3 ---- /RE and DE on secondMAX487
   
  TX3 ---- DI on third MAX487
  RX3 ---- RO on third MAX487
  4 ---- /RE and DE on third MAX487
   
  If you do not connect a second or third transceiver, comment out the corresponding #define UARTn_TXENABLE_PIN line in the sketch.
   
  I think that up to two transceivers on the Mega should work without problems, I am not sure about three yet.
   
  
• For the slave device, start with the RS485Slave example sketch.
  Connections:
   
  TX ---- DI on MAX487
  RX ---- RO on MAX487
  2 ---- /RE and DE on MAX487
  

 

Between all transceiver chips, daisy-chain GND, A and B pins.

Run the connect-to-serial.cmd script with the Mega's COM port.

Edited January 9, 2016 by [FSF]Ian

[Guest]

A-10C and HSI

 

Which DCS-BIOS value is it that I need to listen for to get the current aircraft heading which the HSI follows?

(manual p114)

4. Lubber Line. This is a fixed line that runs from the aircraft symbol to the top of the gauge. This line represents current aircraft heading in relation to the compass card.

[FSFIan]

I think you want A-10C/HSI_HDG:

Output Type: integer Address: 0x104c Mask: 0xffff Shift By: 0 Max. Value: 65535

 

That is the rotation of the HSI compass card.

[Guest]

Ian;2636916']I think you want A-10C/HSI_HDG:

Output Type: integer Address: 0x104c Mask: 0xffff Shift By: 0 Max. Value: 65535

That is the rotation of the HSI compass card.

I tried that. The values for the HSI seem to be graphic based. I can't find any fixed values that doesn't change unless they are changed by the user, that are not connected to the graphics moving. For example the heading bug changes value (DCS-BIOS) as it rotates with the compass card although it's position relative to North stays the same. Would need something fixed to go from. Well I'll look more tomorrow.

[FSFIan]

Any value you get out of DCS-BIOS for a clickable cockpit will be based on a cockpit argument which controls some animation in the cockpit 3D model, so this is to be expected.

 

I am still not sure what you mean by "aircraft heading that the HSI follows". If you want the position of the heading bug in degrees, can't you just subtract

A-10C/HSI_HDG from A-10C/HSI_HDG_BUG, then divide by 65535 and multiply by 360 to convert to degrees?

 

If you want the course (set by the right knob), you can also look at A-10C/HSI_CC_A and A-10C/HSI_CC_B ("Course Counter A" and "Course Counter B").

Edited January 10, 2016 by [FSF]Ian

[Guest]

I did that and there is an 180° offset. Due west (W/270°) in the cockpit comes as 90° from DCS-BIOS. I will correct for this and use that value for all others. Thing is that I've done some days of programming without looking at DCS-BIOS' output and then got surprised how it was represented. My methods accept human readable values. :smilewink:

 

NOW I UNDERSTAND what you wrote. Rotation of the compass card. Got it! 90° rotation will produce 270° on the card.

 

_a10CHsiDataHolderClass.HsiHeading = (Convert.ToInt32(_hsiHeadingOutput.GetUIntValue(data)) * 360) / 65535;

Ian;2637349']Any value you get out of DCS-BIOS for a clickable cockpit will be based on a cockpit argument which controls some animation in the cockpit 3D model, so this is to be expected.

 

I am still not sure what you mean by "aircraft heading that the HSI follows". If you want the position of the heading bug in degrees, can't you just subtract

A-10C/HSI_HDG from A-10C/HSI_HDG_BUG, then divide by 65535 and multiply by 360 to convert to degrees?

 

If you want the course (set by the right knob), you can also look at A-10C/HSI_CC_A and A-10C/HSI_CC_B ("Course Counter A" and "Course Counter B").

[Exo7]

Hi Ian, All,

 

I have write a function for bcd wheel to send value to the mirage 2000 autopilot altitude selector.

 

function BIOS.util.defineBcdWheel(msg, device_id, arg_number, output_map, category, description)
local bcdWheelState = moduleBeingDefined.memoryMap:allocateInt{ maxValue = 1 }
moduleBeingDefined.exportHooks[#moduleBeingDefined.exportHooks+1] = function(dev0)
bcdWheelState:setValue(dev0:get_argument_value(arg_number))
end
moduleBeingDefined.inputProcessors[msg] = function(value)
		GetDevice(device_id):set_argument_value(arg_number, value)
end
end

 

it's working very weel, so i'm not able to add code to document function...

it's not needed to work, but i like to do the thing to the end.

 

i have try to understand the steps basing on the defineTumb function, but it's very hard for me...

 

can you help me ?

 

thx !!