DCS-BIOS Discussion Thread

[G00dnight]

Great news my 5 panels work great in DCS2, I have a radio stack am.fm & uhf, fuel pane with gear switch plus red/green leds t/o trim with led.

A weapon panel + Electrics + aux panel.

lighting panel.

And a panel with CMSP, Tacan & Ils using 1 4x20 lcd.

And a CDU button panel.

All works fine.

[Warhog]

SO......... where are the pictures????????:P

 

We want pictures. Most of us can't read so we need pictures.

 

:lol:

[FSFIan]

Ian, any progress regarding the RS-485 support in DCS-Bios?

 

The code is at the "theoretically, this should work" stage. It still needs a good look at the timing on a logic analyzer to see if it can work reliably, figure out its limitations (how many different outputs can a single Arduino support?) and I need to test over distances of more than 10 centimeters.

I also have not written any documentation on it yet.

 

The problem is that in this semester, as part of my computer science curriculum I am part of a "project group" where we try to build a solar-powered electronic doorplate. That means another 14+ hours a week of programming embedded systems. It's fun to do, but after I have spent several hours at uni chasing down some hard-to-find bug, I usually lack the energy and motivation to hack on DCS-BIOS in the evening.

 

My plan is to get things to a publishable state at the end of the year. From December 27th to December 30th, I will be in my dorm room to watch the video streams from the 32nd Chaos Communication Congress. I will not be distracted by family or university, so in between talks I hope to make significant progress on DCS-BIOS.

 

Note that this does not mean there will definitely be a release this year. I don't want to release any code unless I am convinced it is reliable, because once I release anything, I will probably have to deal with several reports of "It doesn't work", to which I want to be able to answer "check your wiring" with some confidence.

[BravoYankee4]

Ian;2582839']The code is at the "theoretically, this should work" stage. It still needs a good look at the timing on a logic analyzer to see if it can work reliably, figure out its limitations (how many different outputs can a single Arduino support?) and I need to test over distances of more than 10 centimeters.

I also have not written any documentation on it yet.

 

The problem is that in this semester, as part of my computer science curriculum I am part of a "project group" where we try to build a solar-powered electronic doorplate. That means another 14+ hours a week of programming embedded systems. It's fun to do, but after I have spent several hours at uni chasing down some hard-to-find bug, I usually lack the energy and motivation to hack on DCS-BIOS in the evening.

 

My plan is to get things to a publishable state at the end of the year. From December 27th to December 30th, I will be in my dorm room to watch the video streams from the 32nd Chaos Communication Congress. I will not be distracted by family or university, so in between talks I hope to make significant progress on DCS-BIOS.

 

Note that this does not mean there will definitely be a release this year. I don't want to release any code unless I am convinced it is reliable, because once I release anything, I will probably have to deal with several reports of "It doesn't work", to which I want to be able to answer "check your wiring" with some confidence.

 

Thanks for this update. I'm fully aware of that the extra time for hobbies can be very limited from time to time. Especially when there is a 2.5 year old smurf in the house and a second on it's way ;)

 

I also agree on that a stable version next year is better than something with bugs this year. Regardless of release date, I do appreciate your work.

 

By the way, is there any way that me (or the community) can help out when it comes to get support for more modules (like the MIG-15)?

 

Vielen dank!

[33rd_Elvis]

hi,

 

i have see in page 5 form this thread warhog use MAX7219 controller for 7 seg led´s. I have buy a 7segment tube whit the same controller ebay.

But i don´t know which code i can whrite.

 

void onIlsMhzChange(char* newValue) {

/* your code here */

}

DcsBios::StringBuffer<3> ilsMhzStrBuffer(0x116e, onIlsMhzChange);

 

void onIlsKhzChange(char* newValue) {

/* your code here */

}

DcsBios::StringBuffer<2> ilsKhzStrBuffer(0x1172, onIlsKhzChange);

thanks

 

I need a example for nother 7 seg displays (VHF,UHF,TACAN etc.)

Edited December 5, 2015 by 33rd_Elvis

[Exo7]

Hi Guys,

 

i have a question about radios.

Is it possible to send directly the frequencies over DCS Bios ?

I explain,

i have real radios for my pit project and i would like to use the coding wheels.

so them give a BCD code that i convert to decimal. so i would like to send over DCS Bios the decimal number of the frequencies. i don't want to use the increment decrement function.

 

thank you.

[FSFIan]

Unlike the UHF radio knobs and most other multiposition switches, the radio knobs in the A-10C only support commands for relative movement. Because DCS animates those knobs, I cannot send several of those in a single frame, so I can't fake a "set absolute position" command either.

 

Later, I learned that there is also the set_frequency function on the radio device, which can be used to instantly set a radio frequency, but that only works for frequencies in the supported range of the radio (e.g. it does not support setting the VHF AM radio to "31.000", which you can do when manipulating the knobs manually to get the "out of frequency range" warning tone). Since I wanted DCS-BIOS to mimic the actual cockpit controls as close as possible, I did not use that.

 

If it helps, I could add a hack to call set_frequency() for the VHF AM and FM radios, which would only work for frequencies inside the supported range of the radio.

[agrasyuk]

That would be a very welcome addition. Will this hack work only for VHF though (since you mention animated knobs of UHF)?

[Exo7]

Yes it should be a very good addition !

 

 

Cédric

[Exo7]

So, in re reading your reply i think i'm not very clear in my first question. I can send each part of the frequency : i.e. "2" , "4", "3", "0", "00" separatly...

 

 

Cédric

[spacenavy90]

I would like to help out anyway I can for getting the Mirage 2000C compatible when it launches.

 

Are there any plans in motion at the moment for its inclusion?

[BravoYankee4]

I would like to help out anyway I can for getting the Mirage 2000C compatible when it launches.

 

Are there any plans in motion at the moment for its inclusion?

 

And we are a couple of Swedes that would gladly offer our services for the future Viggen and HKP9 modules :)

[FSFIan]

I would like to help out anyway I can for getting the Mirage 2000C compatible when it launches.

 

Are there any plans in motion at the moment for its inclusion?

 

And we are a couple of Swedes that would gladly offer our services for the future Viggen and HKP9 modules :)

 

Thanks for the offers! To provide support for additional modules, help from people who actively fly the airframe in question is invaluable. Even if I had enough time to add all of them myself (which I don't), I couldn't test everything properly because I wouldn't know how it's supposed to behave (e.g. to test whether exporting a certain indicator works, you need to know what other things to do to turn it on and move it around).

 

Let's talk about this in two or three weeks. I plan to do a bunch of work on DCS-BIOS over the Christmas break. Depending on how far I get the way to add additional aircraft may change significantly, so any knowledge obtained now could become obsolete.

 

I have a few ideas about how to improve the debugging capabilities and automate some repetitive parts of the process.

[xray20]

DCS-BIOS Does what it says on the tin!

 

I just want to say thanks to all the contributors for the great work on DCS-BIOS. I got my Arduino yesterday and had seven cockpit lights working within about 3 hours. Its very encouraging and has opened up a whole new set of possibilities for the cockpit.

 

I have never used an Arduino before and the setup was very straightforward. I am an engineer by profession, so I am used to setting up systems, but nonetheless I had no issues following the excellent documentation and pre-made setup code.

 

If I were to add anything to the documentation it would be about the diagnostic lights on the board (not sure if all boards have them) but the action of the TX RX lights and the flashing status light now give useful clues to what the board is doing (or not).

 

I'll post my progress on my cockpit thread once I start to build the Arduino components in.

 

Cheers

Matt

[Tekkx]

Today I nailed my (not modeled this way in the Sim) FQIS-Panel together and there is a little issue left:

 

Using a Rotary Encoder (I explain the reason in the "original" post) the Switch in the simulated Cockpit do a strange jump every time I move the rotary.

 

Please rail against me if this issue is already discussed or even solved at other place.

 

I would like to insert some debouncing code at the right place.

I don't dare to write into the DcsBios.cpp without consulting the great artificer of DCS-BIOS or other members of this community :)

 

Would it be OK (didn't any testing yet) if I insert a small delay into DcsBios.cpp at line 220???

void RotaryEncoder::pollInput() {
char state = readState();
switch(lastState_) {
	case 0:
		if (state == 2) delta_--;
		if (state == 1) delta_++;
		break;
	case 1:
		if (state == 0) delta_--;
		if (state == 3) delta_++;
		break;
	case 2:
		if (state == 3) delta_--;
		if (state == 0) delta_++;
		break;
	case 3:
		if (state == 1) delta_--;
		if (state == 2) delta_++;
		break;
}
lastState_ = state;
[color="Red"]delay(20);[/color] // or some other value
if (delta_ == 4) {
	sendDcsBiosMessage(msg_, incArg_);
	delta_ = 0;
}
if (delta_ == -4) {
	sendDcsBiosMessage(msg_, decArg_);
	delta_ = 0;
}
}

 

Maybe there is a better place or methode to solve this issue.

 

Thank you very much.

 

Edit: (two hours later)

I did some tests meanwhile.

Maybe it's not an issue of BOUNCING, rather a kind of cross-talk.

Reading the stream data (while pause the Sim) showed occuring the code of the "Test" button if just the INC or DEC data have to occure. The Test-Button its self works as expected.

That could declare the strange behavior of the Fuel-Quantity-Gauge.

 

My FQIS panel is connected to the MEGA by a 50 cm ribbon cable.

I have no equipment to measure the cable its self.

I could replace the Encoder by a less cheap one but I'm worried to destroy the PCB. (it's a little bit tied there)

 

So my speculative question (before I destroy sth.): Did you ever encountered such cross-talk phenomens?

Edited December 20, 2015 by Tekkx

[FSFIan]

If you want to add a debouncing delay, I'd recommend adding it in your loop() function.

 

Are you sure that your problem is caused by bouncing signal lines? (Does it send multiple lines of text to DCS when you move the encoder by a single detent?)

 

The RotaryEncoder class in DCS-BIOS requires it to go through all four states in the right order before it recognizes a step, it should be fairly robust against bouncing already.

 

Do you have a datasheet for the rotary encoders? (Maybe they do something weird like send eight pulses per step.)

 

Can you describe the "strange jump" in more detail?

Does it also happen if you send the command through the interactive control reference documentation? (If it does, it's definitely not your Arduino code.)

[Tekkx]

Hallo Ian. Thank you for your concern :)

Live Data I never brought into business :/ Have to give that a closer look.

 

But this is, what connect-serial-port window shows:

FQIS_TEST 0
FQIS_TEST 1
< 2015/12/20 23:03:34.584844  length=12 from=1612 to=1623
FQIS_TEST 0
< 2015/12/20 23:03:34.616846  length=13 from=1624 to=1636
FQIS_SELECT D< 2015/12/20 23:03:34.617846  length=3 from=1637 to=1639
EC
< 2015/12/20 23:03:43.169335  length=36 from=1640 to=1675
FQIS_TEST 1
FQIS_TEST 0
FQIS_TEST 1
< 2015/12/20 23:03:43.243340  length=12 from=1676 to=1687
FQIS_TEST 0
< 2015/12/20 23:03:43.274341  length=16 from=1688 to=1703
FQIS_SELECT DEC
< 2015/12/20 23:03:44.865432  length=33 from=1704 to=1736
FQIS_TEST 1
FQIS_TEST 0
FQIS_TEST< 2015/12/20 23:03:44.867432  length=3 from=1737 to=1739
1
< 2015/12/20 23:03:44.870433  length=12 from=1740 to=1751
FQIS_TEST 0
< 2015/12/20 23:03:44.892434  length=36 from=1752 to=1787
FQIS_TEST 1
FQIS_TEST 0
FQIS_TEST 1
< 2015/12/20 23:03:44.986439  length=28 from=1788 to=1815
FQIS_TEST 0
FQIS_SELECT INC
< 2015/12/20 23:03:45.838488  length=8 from=1816 to=1823
FQIS_TES< 2015/12/20 23:03:45.841488  length=4 from=1824 to=1827
T 1
< 2015/12/20 23:03:45.972496  length=12 from=1828 to=1839
FQIS_TEST 0
< 2015/12/20 23:03:46.063501  length=16 from=1840 to=1855
FQIS_SELECT DEC
< 2015/12/20 23:03:47.214567  length=12 from=1856 to=1867
FQIS_TEST 1
< 2015/12/20 23:03:47.295571  length=36 from=1868 to=1903
FQIS_TEST 0
FQIS_TEST 1
FQIS_TEST 0
< 2015/12/20 23:03:47.328573  length=16 from=1904 to=1919
FQIS_SELECT DEC
< 2015/12/20 23:03:48.219624  length=12 from=1920 to=1931
FQIS_TEST 1
< 2015/12/20 23:03:48.221624  length=12 from=1932 to=1943
FQIS_TEST 0
< 2015/12/20 23:03:48.225625  length=12 from=1944 to=1955
FQIS_TEST 1
< 2015/12/20 23:03:48.336631  length=12 from=1956 to=1967
FQIS_TEST 0
< 2015/12/20 23:03:48.357632  length=16 from=1968 to=1983
FQIS_SELECT DEC
< 2015/12/20 23:03:50.028728  length=12 from=1984 to=1995
FQIS_TEST 1
< 2015/12/20 23:03:50.069730  length=28 from=1996 to=2023
FQIS_TEST 0
FQIS_SELECT INC
< 2015/12/20 23:03:50.840774  length=12 from=2024 to=2035

 

I just turned the Encoder to get this picture.

The "strange behavior" is explained by the FQIS_TEST 1 and FQIS_TEST 0 messages.

The pointers of the gauge snaps (or twich) unexpected.

 

As I wrote in my Edit (post before), bouncing issue seems to be obsolet.

It looks like I had another issue built in :doh:

 

PS: Datasheet: NO.

Edited December 20, 2015 by Tekkx

[FSFIan]

I am not an expert on analog stuff by any means, but on a 50 cm ribbon cable, with the internal pull-up resistor on the Arduino (which is somewhere between 30k and 50k), crosstalk sounds like a plausible explanation to me.

 

You can try a "stronger" pull-up resistor. Simply connect a resistor (anything between about 1k and 10k) between the FQIS_TEST Arduino pin and +5V. If a pull-up resistor value is too high, the line is more susceptible to noise. If the pull-up resistor is too low, a large current will flow through it when the button is pressed, which increases power consumption (important in battery-powered applications) and in extreme cases (less than 125 ohm) will exceed the current limit of 40 mA per pin on your microcontroller.

 

If that doesn't help, double-check your wiring and then post a link to the full sketch and a schematic (a photo will do as long as it's clearly apparent where the wires go).

[Tekkx]

Dear Ian.

I'm on my knees and bag your pardon.

I am so sorry wasting your time. PLS PM me with your Bank Account. You should have some beers (or sth. else) on me.

 

There is no problem with "my" code. There is no bouncing. There is no cross-talk.

Today, while pretending to do my work what I'll payed for, I did some thinking.

 

First thing at home was to change (just in the code) the PIN of the Test-Button (I use the push-button of the Encoder):

No Test-Function (as intended), but also no strange side-effect while turning.

 

So (after some tinkering with a Multimeter) came out my Encoder was broken. Everytime the Rorary did a "klick", the Push-Button gave also a very short impulse. Brandnew and clean soldered (without cruelty while soldering). Just cheap chinese scrap (Thow I know: Everything comes from there).

 

So I replaced it (broke my PCB this way) and after reconstructing circuit paths with thin copper wire it works fine.

[FSFIan]

Don't worry about it, component failure is evil and happens to all of us.

 

It's fun to help people like you -- people whom I can give a few hints and suggestions, and they go back and experiment some more on their own, and a few posts later the problem is solved. That's time well spent.

 

What annoys me are those who ask things they can look up in the first three Google hits, don't provide enough context for me to give a concise answer, and who, when pointed to other online resources, do not ask a sensible follow-up question but instead want me to explain everything from the ground up or write their sketch for them. Fortunately, those people are few and far between and given that I don't sell DCS-BIOS, I am free to ignore them :)

[Tekkx]

Hello, everyone. I hope (some of) you survived X'mas :)

 

Yesterday I did a short flight. Just one hour in the air.

While some looking around I got a plan: Few weeks ago I found some good old signalling lamps from an old broadcast station (known as "Red Light"). I think it would be nice to use some of them to build the external lights of the A10. As ambient lighting in my cabinet :)

 

So I encountered a little problem: I can't find a solution to export Anticollision Flashlights.

OK. Reading and exporting switch's position is easy (thanks to prebuilt code of DCS-BIOS) and I could easily code some blinking or flashing.

But this isn't the intention.

It would be nice, if my flashlights would flash synchron to the flashes at the wingtips (while dusty wheather or at night good to be seen from the cockpit).

 

Am I blind and so can't find the solution or is there no way?

Can someone give some advice?

Edited December 28, 2015 by Tekkx

[FSFIan]

DCS-BIOS does not export the state of any external lights. Currently, your best bet is to figure out their state based on looking at some combination of switches (battery power + light switch) and then implementing the blinking on the Arduino.

 

Since the external lights are not displayed in the internal cockpit model, there is no cockpit argument for them (and also no other way to grab them from Export.lua).

 

A few months ago, I discovered a roundabout way to grab the draw arguments for the external aircraft model, which to my knowledge also include the state of the external lights. I do plan to integrate that into DCS-BIOS 2.0 at some point, but that is still many, many months away.

[Tekkx]

Thank you Ian.

That's a pitty - not a problem :)

 

So I put these lights to the pantry (hope, not to forget them). Later is soon enough. Cause there are so many other things to screw and solder :)

[Warhog]

I see great minds think alike Tekkx. I have already built a device that includes a bunch of LEDs to simulate running lights and the strobe. They are driven with a Pro Mini and a couple of mosfets as the LEDs are of the high current type. The Pro Mini has a sketch uploaded to it that simulates the flash pattern of the running lights as well as the A10C's strobe. I spent half a day trying to get each flash pattern synced to the A10C's pattern and it's now damn close to the sim. Soon as I get out of the hospital, I can email the sketch to you if you like.

 

After that it's just a matter of Ian revising DCS-BIOS to include the external lights for this airframe. Hopefully he will be able to include the air brakes as part of the rewrite and then I'll add my own special indicator to show the position of the air brakes. Ian is an excellent programmer so I anticipate he'll solve that issue without breaking a sweat.

 

I would also like to add some WS2812B LEDs at the edge of my peripheral vision to simulate a bright explosion behind me and then a simulated engine fire behind me as well. :thumbup:

 

Isn't immersion a wonderful thing?:pilotfly:

 

John

[weeb]

Ian;2619336']DCS-BIOS does not export the state of any external lights. Currently, your best bet is to figure out their state based on looking at some combination of switches (battery power + light switch) and then implementing the blinking on the Arduino.

 

Since the external lights are not displayed in the internal cockpit model, there is no cockpit argument for them (and also no other way to grab them from Export.lua).

 

A few months ago, I discovered a roundabout way to grab the draw arguments for the external aircraft model, which to my knowledge also include the state of the external lights. I do plan to integrate that into DCS-BIOS 2.0 at some point, but that is still many, many months away.

 

Great to see you back Ian, I know things were hectic whilst you were doing university course and it only goes to show your strength of character. I remember doing my disertation and **** me, every day and night was "mind-bending", you never shut off, you wake up with an idea, then prove it. I for one will wait however long it takes for DC-Bios 2.0. My skills were in finding holes in network security, it's a different language to making software speak to an arduino intermediary. Stay frosty.

 

weeb