DCS-BIOS Discussion Thread

[Tekkx]

Hallo, friends.

I have a situation here that shows (again) how noob I am. :doh:

 

After an issue with some Trojans and relationship (more than 250k hits by AntiMalWare) I had to renew something here on my mashine.

 

The problem occours now, I can start just one instance of connect-serial-port.com. Second one spits:

... Address already in use...

 

It has been a long time, I did my first steps with DCS-BIOS, so I forgot the right things (another example of "Make a f...n log of all of your steps. It could be essential some day." Sorry for disobey this simple rule.

 

My ..Saved Games\DCS\Scripts\DCS-BIOS\BIOSConfig.lua looks this:

BIOS.protocol_io.connections = {
BIOS.protocol_io.DefaultMulticastSender:create(),
BIOS.protocol_io.TCPServer:create(),
-- BIOS.protocol_io.UDPSender:create({ port = 7777, host = "192.168.1.177" }),
BIOS.protocol_io.UDPListener:create({ port = 7778 })
}

 

My connect-serial-port.cmd looks this

REM Specify the number of the COM port your Arduino is connected to:

set COMPORT=35 (with different ports, offcourse :))

set /A TTYNUM=%COMPORT%-1
mode COM%COMPORT% BAUD=250000 PARITY=N DATA=8 STOP=1 TO=off DTR=on

Which of these two lines (with -> ) are the right one. None of them works. While second one is direct copied from Github.

-> socat\socat -v UDP4-RECV:5010!!udp-sendto:localhost:7778 /dev/ttyS%TTYNUM%
-> socat\socat -v UDP4-RECV:5010,ip-add-membership=239.255.50.10:127.0.0.1,reuseaddr!!udp-sendto:localhost:7778 /dev/ttyS%TTYNUM%

pause

 

It looks I went completely ga ga.

Please point me to the right place (in some manual e.g.).

I am ready to go the very first steps again.

 

Thank you.

Edited October 16, 2016 by Tekkx

[FSFIan]

help please with adding...

 

On the DCS-BIOS website you will find a link to the developer guide. It describes how to add an aircraft to DCS-BIOS. It assumes you have at least a basic understanding of the Lua scripting language, so you'll probably have to learn that first.

Edited October 16, 2016 by [FSF]Ian

[FSFIan]

It looks I went completely ga ga.

Please point me to the right place (in some manual e.g.).

I am ready to go the very first steps again.

 

Thank you.

 

Usually, the second line should work (as long as all other scripts use it as well).

 

I vaguely remembered that you had problems with UDP before and had to use TCP instead. Found it again with the forum search: link to the german thread

 

Try the connection script from that post (but change the baud rate from 500000 to 250000).

[Tekkx]

Ian;2927914']

I vaguely remembered that you had problems with UDP before and had to use TCP instead. Found it again with the forum search: link to the german thread

 

Try the connection script from that post (but change the baud rate from 500000 to 250000).

 

Thank you to remembering my own question... this guy... :)

Brought it to life, but have to make some deeper examinations. Something is still strange. Will open a new thread, cause it seems to be a very special problem of my mashine here. Maybe tomorrow.

So no further discussing of this here, please.

 

By the way: Is it meanwhile possible to config MEGA or even DUE as Slave? Would help me with my TFT-task.

(This is NO pushing nor an urgent request!!!)

[ClayM]

Thanks Ian!

 

Changed sketch to include

 

void setup() 
 DcsBios::setup();
 
 //use only one of the following memset lines   uncomment your choice
 //use this line to set all indicators to on at power up
 //memset(max7219_rows, 0xff, sizeof(max7219_rows)); 
 
 //use this line to set all indicators to off at power up
 memset(max7219_rows, 0x00, sizeof(max7219_rows));

 lc.shutdown(0,false); //turn on the display
 lc.setIntensity(0,15);//set the brightness
 lc.clearDisplay(0); //clear rthe display and get ready for new data
}

 

I agree that all on at power up can be useful. For taking pictures!

 

And confirmed all works as intended!

 

Thanks

 

I posted a pic at pitbldrs thread. His recently posted dimensions means my panel is wrong. His thread has great info for CLP!

Edited October 16, 2016 by ClayM

[FSFIan]

By the way: Is it meanwhile possible to config MEGA or even DUE as Slave? Would help me with my TFT-task.

 

It won't work on the Due, but it should work fine on the Mega 2560 (added on April 5 in this commit).

[kadda]

Execution error:

...sers\??????\Saved Games\DCS.openbeta\Scripts\BIOS.lua:2: attempt to index global 'lfs' (a nil value)

[FSFIan]

Execution error:

...sers\??????\Saved Games\DCS.openbeta\Scripts\BIOS.lua:2: attempt to index global 'lfs' (a nil value)

 

Works for me in DCS: World OpenBeta 1.5.4.57288.

Is anyone else seeing this?

[kadda]

"ADI_TURN": {

"category": "ADI",

"control_type": "analog_gauge",

"description": "ADI Turn Needle",

"identifier": "ADI_TURN",

"inputs": [ ],

"outputs": [ {

"address": 4152,

"description": "gauge position",

"mask": 65535,

"max_value": 65535,

"shift_by": 0,

"suffix": "",

"type": "integer"

} ]

}

},

 

 

 

need some explanations with this...:pilotfly:

[FSFIan]

I don't know where you got the idea that you need to mess with that autogenerated file.

 

Have you followed along the DCS-BIOS Developer's Guide? If so, where did you get stuck?

[kadda]

hi, here s what i did...

 

--Open AircraftList.lua. If your aircraft has a clickable cockpit, add a("Your Aircraft Name", true).

 

code:

a("TF-51D", true).

 

--Create a new Lua file with your aircraft name in the lib subfolder. ...

 

code:

BIOS.protocol.beginModule("TF-51D", 0x1200)

BIOS.protocol.setExportModuleAircrafts({"TF-51D"})

 

local document = BIOS.util.document

local documentation = moduleBeingDefined.documentation

local parse_indication = BIOS.util.parse_indication

local defineFloat = BIOS.util.defineFloat

local defineIndicatorLight = BIOS.util.defineIndicatorLight

local definePushButton = BIOS.util.definePushButton

local definePotentiometer = BIOS.util.definePotentiometer

local defineRotary = BIOS.util.defineRotary

local defineSetCommandTumb = BIOS.util.defineSetCommandTumb

local defineTumb = BIOS.util.defineTumb

local defineToggleSwitch = BIOS.util.defineToggleSwitch

local defineToggleSwitchToggleOnly = BIOS.util.defineToggleSwitchToggleOnly

local defineFixedStepTumb = BIOS.util.defineFixedStepTumb

local defineFixedStepInput = BIOS.util.defineFixedStepInput

local defineVariableStepTumb = BIOS.util.defineVariableStepTumb

local defineString = BIOS.util.defineString

local defineRockerSwitch = BIOS.util.defineRockerSwitch

local defineMultipositionSwitch = BIOS.util.defineMultipositionSwitch

 

dofile(lfs.currentdir().."mods/aircraft/TF-51D/Cockpit/Scripts/devices.lua")

dofile(lfs.currentdir().."mods/aircraft/TF-51D/Cockpit/Scripts/command_defs.lua")

 

 

definfloat("Accelerometer_main",171,{0,1},"INSTRUMENTS","GENERAL")

 

 

 

BIOS.protocol.endModule()

 

 

 

--After creating a file for your export module, add a dofile(…​) call in BIOS.lua and a <script> tag in control-reference.lua (you will see what to do from the existing entries).

 

 

 

 

code:

dofile(lfs.writedir()..[[scripts\dcs-bios\lib\TF-51D.lua]])

 

 

<script src="json/TF-51D.jsonp"></script>

 

 

at this point, i thought that i ve to create that type of file manually due to miss understanding from me to this "(you will see what to do from the existing entries)", so i m stuck at the point adding my aircraft :(

Edited October 23, 2016 by kadda
writing mistake

[Tekkx]

Good Morning, Friends :)

 

Today I made a test of some brandnew "Interface- and Control-Boards". The testbed consisted of a Master with 3 activated RS485-Chains. All 3 Slaves are connected daisy-chained on just one Chain. All RS-485 Devices are equipped with TVS-Diodes. TXenable-Pin is connected to a Pulldown-Resistor to GND by 10k on each Slave-Board. All Bus members are linked by CAT5 SFTP Patch cables. Bus length over all is less than 2 meters (< 10 ft).

This hardware configuration runs commonly very stable and safe against stress (disconnecting/connecting new Slaves, removing AVR-Boards, touching wires and PCBs) - as latest tests have shown.

 

Everything ran fine. Communication worked as intended in both directions. No strange side effects. I am very happy with that.

 

After stopping the mission in DCS (and than also DCS) I let the hardware still running. Now I watched some strange thing happen (see screenshot of connect-serial-port.cmd just after stopping and about 15 minutes later). Every few seconds something(?) is sending one byte of code. The interval is not constant.

 

My BIOSConfig.lua is

BIOS.protocol_io.connections = {
--BIOS.protocol_io.DefaultMulticastSender:create(),
--BIOS.protocol_io.TCPServer:create(),
BIOS.protocol_io.UDPSender:create({ port = 5010, host = "127.0.0.1" }),
BIOS.protocol_io.UDPListener:create({ port = 7778 })
}

My connect-serial-port.cmd is

REM Specify the number of the COM port your Arduino is connected to:

set COMPORT=35

set /A TTYNUM=%COMPORT%-1
mode COM%COMPORT% BAUD=250000 PARITY=N DATA=8 STOP=1 TO=off DTR=on

REM socat\socat -v UDP4-RECV:5010!!udp-sendto:localhost:7778 /dev/ttyS%TTYNUM%
REM socat\socat -v TCP4:127.0.0.1:7778 /dev/ttyS%TTYNUM%

socat\socat -v UDP4-RECV:5010,ip-add-membership=239.255.50.10:127.0.0.1,reuseaddr!!udp-sendto:localhost:7778 /dev/ttyS%TTYNUM%

pause

Questions:

Is there a feasible assertion for this?

Have I to go after this?

Should I report this to the SETI-Project?

Edited October 23, 2016 by Tekkx

[FSFIan]

definfloat("Accelerometer_main",171,{0,1},"INSTRUMENTS","GENERAL")

That syntax error (missing 'e' and lower case 'float' in 'definefloat', should be 'defineFloat') might be what caused your earlier problem.

 

--After creating a file for your export module, add a dofile(…​) call in BIOS.lua and a <script> tag in control-reference.lua (you will see what to do from the existing entries).

I meant that you could copy the syntax for that <script> tag from the other existing tags. You don't have to create the JSON files; they are written whenever DCS-BIOS starts (assuming it gets to that point and doesn't crash beforehand).

 

 

Questions:

Is there a feasible assertion for this?

Have I to go after this?

Should I report this to the SETI-Project?

Curious. I don't even know where to start debugging that... does it happen without any slave devices attached? I wonder if there is a slave device that sends an empty message (i.e. just a newline) every few seconds, or if it is some thing the master does by itself.

[Tekkx]

Ian;2927914']Curious. I don't even know where to start debugging that...

Please stop starting debugging that.

It was indeed some kind of Alien: ME! :doh:

 

I have tried to repeat this experiment today.

I can't explain, what exactly went up there inside that conglomerate of devices, but I can tell you the reason:

It was the first time, I had to test more than 2 Slave-Devices. And there aren't enough sketches available. So I took (in a kind of inebriation - means: euphoria) a working one and flashed it to several slaves....

...

and forgot to set different Bus-Adresses. :music_whistling:

 

This shows, how rugged RS485 is: It worked well, thow this mistake.

Maybe it worked faultless just in one direction (DCS -> Slave-Device). On most slaves were no buttons connected to. Just PWM-backlight. My AAP (complete installed) inside the chain worked well.

 

Sorry for wasting your time.

Edited October 24, 2016 by Tekkx

[FSFIan]

Don't worry, I didn't spend any time investigating yet. Now that we know the cause though, I wonder if I can make DCS-BIOS 2.0 detect that pattern (or more general, anything that goes wrong on the RS-485 bus) and warn the user. Setting two slave devices to the same ID is an error that is easy to make (especially when "flashing a known good sketch" during testing), but can potentially cause intermittent, hard to debug problems.

[kadda]

Hi friends... i did it ... i added a new modul

 

 

Thank u all for helping

[Tekkx]

Ian;2933889']... Setting two slave devices to the same ID is an error that is easy to make (especially when "flashing a known good sketch" during testing)' date=' but can potentially cause intermittent, hard to debug problems.[/quote']

 

So arise a question to me: Is there a way to read out the Device ID from a running (or: Ready-To-Run) device?

I ask because I have a NANO here with a faulty programmer (don't ask, how it died. Please). The last loaded sketch works. So I can still use it for my AAP and nothing else (instead of throwing it "to the others"). I programmed it a few months ago and don't remember the ID.:music_whistling:

 

Maybe the answer (or the How-To) will help others.

The cleaner way would be making a Log and using Stickers...

 

If you say "No!" it'll be at least a motivation to keep everything "in best order" :)

 

@kadda: Fine. Good to hear, you solved it.

Edited October 25, 2016 by Tekkx

[FSFIan]

Is there a way to read out the Device ID from a running (or: Ready-To-Run) device?

 

Hook it up to the master as the only connected slave device. Use another MAX487 chip that has RE and DE pulled low and is connected to a USB-to-Serial adapter to view the data on the RS-485 bus. Then see which device ID gets polled over and over again.

 

If you have a logic analyzer, you can also watch the TX pin on the master and the TXENABLE on the slave, find a time when the slave transmits a reply, and see which address was polled by the master immediately before that. That will even work on a bus that has several devices connected to it.

 

Assuming the slave address is 42 and it has been running for a second, you'd see something like the following byte sequence on the RS-485 bus:

 

1 // target address

0 // message type

0 // payload length

0 // reply payload length

42 // target address

0 // message type

0 // payload length

0 // reply payload length

2 // target address

0 // message type

0 // payload length

0 // reply payload length

42 // target address

0 // message type

0 // payload length

0 // reply payload length

3 // target address

0 // message type

0 // payload length

0 // reply payload length

42 // target address

0 // message type

0 // payload length

0 // reply payload length

 

etc.You get the idea.

The master will poll a device by sending a zero-byte message. The device responds with the length of its reply, which is zero if it doesn't have anything to say. After polling all devices it knows about, the master will poll one unknown device. That device won't answer (unless you plugged it in in the meantime), so after a small timeout (two milliseconds IIRC) the master will send the 'zero payload length' reply byte itself to avoid confusing the other devices on the bus and then start polling its list of known devices again.

[stelios2000]

Hi friends... i did it ... i added a new modul

 

 

Thank u all for helping

 

 

 

:thumbup: :thumbup: :thumbup:

[Tekkx]

There are two short questions to answer before I go the next step (increasing speed is the goal):

 

1. Is DCS-BIOS library compatible to Teensy 2.x (Teensy 3.x are not easy to buy ATM in germany).

2. Is it worth to give Teensy-family a try?

 

I have encountered problems to drive a 3.5 LCD with RS485. It works basically, but many strange things happen on the screen. I blame it (at my stage of knowledge) to the low calculation power of my UNO.

If I find some time I'll open a thread for this issue with detailed description of what I did.

[BravoYankee4]

Perhaps a Nextion HMI panel (or similar) could be a feasible option?

Then the HMI panel takes care of the presentation and the only thing the Arduino has to do is shuffle plain serial data.

[kadda]

hello there!!!, can some one tell me where im wrong ?:helpsmilie:

 

 

 

#define DCSBIOS_DEFAULT_SERIAL

 

#include <DcsBios.h>

#include <Servo.h>

 

DcsBios::ServoOutput accelerometer(0x2600, 9, 544, 2400);

 

Servo Myservo;

 

int PIN_Myservo = 9;

 

 

 

 

/* paste code snippets from the reference documentation here */

 

void setup() {

DcsBios::setup();

}

 

void loop() {

DcsBios::loop();

}

 

 

 

___________________________

exit status 1

'ServoOutput' in namespace 'DcsBios' does not name a type

 

:pilotfly:

[FSFIan]

Reverse the order of your #include statements. You need to include Servo.h before you include DcsBios.h.

 

Also, no idea why you have the "Servo Myservo" and "int PIN_Myservo" lines, they seem to be unrelated to the rest of the program?

[kadda]

Ian;2938974']Reverse the order of your #include statements. You need to include Servo.h before you include DcsBios.h.

 

Also, no idea why you have the "Servo Myservo" and "int PIN_Myservo" lines, they seem to be unrelated to the rest of the program?

 

 

 

thank you IAN, and you re absolutly true that two lines had nothing to do there, i was just lost and tryed to find to find the sollution by my self ....

 

thank you another time for your help, :pilotfly:

[G00dnight]

Hi I have just started to upgrade to latest build and I am having a problem with my lcd displays.

I have a radio stack using a 16x2 for UHF and Clock and a 16x2 for the 2 VHF radios.

All the buttons,encoders work fine even the 2 for Uhf Load and cover that come up in red on upload. the lcds light up and have a cursor flashing, they didn't used to do that, I use I2C boards connected to SDA/SCL on mega. my code follows. Thanks.

 

#define DCSBIOS_IRQ_SERIAL

#define BACKLIGHT_PIN 3

#include <LiquidCrystal_I2C.h>

#include <Wire.h>

#include <Servo.h>

#include <DcsBios.h>

LiquidCrystal_I2C lcd1(0x21, 3, POSITIVE);

LiquidCrystal_I2C lcd2(0x27, 3, POSITIVE);

 

/**** Make your changes after this line ****/

const byte uhf100mhzSelPins[3] = {10, 11, 12};

DcsBios::SwitchMultiPos uhf100mhzSel("UHF_100MHZ_SEL", uhf100mhzSelPins, 3);

 

 

DcsBios::RotaryEncoder uhf10mhzSel("UHF_10MHZ_SEL", "DEC", "INC", 52, 53);

 

 

DcsBios::RotaryEncoder uhf1mhzSel("UHF_1MHZ_SEL", "DEC", "INC", 50, 51);

 

 

DcsBios::RotaryEncoder uhfPoint1mhzSel("UHF_POINT1MHZ_SEL", "DEC", "INC", 49, 48);

 

 

DcsBios::RotaryEncoder uhfPoint25Sel("UHF_POINT25_SEL", "DEC", "INC", 47, 46);

 

 

DcsBios::ActionButton uhfCoverToggle("UHF_COVER", "TOGGLE", 8);

 

DcsBios::ActionButton uhfLoadToggle("UHF_LOAD", "TOGGLE", 9);

 

const byte uhfFunctionPins[4] = {28, 26, 24, 22};

DcsBios::SwitchMultiPos uhfFunction("UHF_FUNCTION", uhfFunctionPins, 4);

 

const byte uhfModePins[3] = {6, 5, 4};

DcsBios::SwitchMultiPos uhfMode("UHF_MODE", uhfModePins, 3);

 

DcsBios::RotaryEncoder vhfamFreq1("VHFAM_FREQ1", "DEC", "INC", 45, 44);

 

DcsBios::RotaryEncoder vhfamFreq2("VHFAM_FREQ2", "DEC", "INC", 43, 42);

 

 

DcsBios::RotaryEncoder vhfamFreq3("VHFAM_FREQ3", "DEC", "INC", 41, 40);

 

DcsBios::RotaryEncoder vhfamFreq4("VHFAM_FREQ4", "DEC", "INC", 39, 38);

 

const byte vhfamFreqemerPins[4] = {A8, A9, A10, A11};

DcsBios::SwitchMultiPos vhfamFreqemer("VHFAM_FREQEMER", vhfamFreqemerPins, 4);

 

const byte vhfamModePins[3] = {A0, A1, A2};

DcsBios::SwitchMultiPos vhfamMode("VHFAM_MODE", vhfamModePins, 3);

 

DcsBios::RotaryEncoder vhffmFreq1("VHFFM_FREQ1", "DEC", "INC", 37, 36);

 

DcsBios::RotaryEncoder vhffmFreq2("VHFFM_FREQ2", "DEC", "INC", 35, 34);

 

DcsBios::RotaryEncoder vhffmFreq3("VHFFM_FREQ3", "DEC", "INC", 33, 32);

 

DcsBios::RotaryEncoder vhffmFreq4("VHFFM_FREQ4", "DEC", "INC", 31, 30);

 

const byte vhffmFreqemerPins[4] = {A12, A13, A14, A15};

DcsBios::SwitchMultiPos vhffmFreqemer("VHFFM_FREQEMER", vhffmFreqemerPins, 4);

 

const byte vhffmModePins[3] = {A3, A4, A5};

DcsBios::SwitchMultiPos vhffmMode("VHFFM_MODE", vhffmModePins, 3);

 

 

 

 

 

void onUhfFrequencyChange(char* newValue) {

lcd1.setCursor(0, 0);

lcd1.print(newValue);

 

}

DcsBios::StringBuffer<7> uhfFrequencyBuffer(0x1180, onUhfFrequencyChange);

 

 

 

void onClockHhChange(char* newValue) {

lcd1.setCursor(0, 1);

lcd1.print(newValue);

}

DcsBios::StringBuffer<2> clockHhBuffer(0x10fe, onClockHhChange);

 

void onClockMmChange(char* newValue) {

lcd1.setCursor(3, 1);

lcd1.print(newValue);

}

DcsBios::StringBuffer<2> clockMmBuffer(0x1100, onClockMmChange);

 

void onClockSsChange(char* newValue) {

lcd1.setCursor(6, 1);

lcd1.print(newValue);

}

DcsBios::StringBuffer<2> clockSsBuffer(0x1102, onClockSsChange);

 

void onClockEtcChange(char* newValue) {

lcd1.setCursor(9, 1);

lcd1.print(newValue);

}

DcsBios::StringBuffer<3> clockEtcBuffer(0x1104, onClockEtcChange);

 

void onVhfcommFreqChange(char* newValue) {

lcd2.setCursor(1, 0);

lcd2.print(newValue);

}

DcsBios::StringBuffer<7> vhfcommFreqBuffer(0x14d4, onVhfcommFreqChange);

 

void onVhfamFreq1Change(char* newValue) {

lcd2.setCursor(1, 0);

lcd2.print(newValue);

}

DcsBios::StringBuffer<2> vhfamFreq1StrBuffer(0x1190, onVhfamFreq1Change);

 

 

void onVhfamFreq4Change(char* newValue) {

lcd2.setCursor(8, 0);

lcd2.print(newValue);

}

DcsBios::StringBuffer<2> vhfamFreq4StrBuffer(0x1192, onVhfamFreq4Change);

 

void onVhffmFreq1Change(char* newValue) {

lcd2.setCursor(1, 1);

lcd2.print(newValue);

}

DcsBios::StringBuffer<2> vhffmFreq1StrBuffer(0x119a, onVhffmFreq1Change);

 

void onVhffmFreq4Change(char* newValue) {

lcd2.setCursor(8, 1);

lcd2.print(newValue);

}

DcsBios::StringBuffer<2> vhffmFreq4StrBuffer(0x119e, onVhffmFreq4Change);

 

void onDcsBiosWrite(unsigned int address, unsigned int value) {

 

 

if (address == 0x118e) {

unsigned int vhfamFreq2Value = (value & 0x00f0) >> 4;

lcd2.setCursor(4, 0);

lcd2.print(vhfamFreq2Value);

}

 

if (address == 0x118e) {

unsigned int vhfamFreq3Value = (value & 0x0f00) >> 8;

lcd2.setCursor(6, 0);

lcd2.print(vhfamFreq3Value);

}

if (address == 0x119c) {

unsigned int vhffmFreq2Value = (value & 0x000f) >> 0;

lcd2.setCursor(4, 1);

lcd2.print(vhffmFreq2Value);

}

if (address == 0x119c) {

unsigned int vhffmFreq3Value = (value & 0x00f0) >> 4;

lcd2.setCursor(6, 1);

lcd2.print(vhffmFreq3Value);

}

 

 

 

}

 

void setup()

{

 

DcsBios::setup();

 

lcd1.begin(16, 2);

 

lcd2.begin(16, 2);

 

 

 

}

 

void loop() {

DcsBios::loop();

}