Major Announcement: New software to to connect panels to DCS

[JaNk0]

...

 

Thanks! I understand the first 4 lines but I didnt yet encounter the ~ so I'll study that now and see if I make any progress.

 

It is known as bitwise complement - or NOT-operator, will invert the bits. For example:

 

    
  foo: 0 0 1 0 1 0 1 0
 ~foo: 1 1 0 1 0 1 0 1

Edited January 22, 2015 by JaNk0

[avidflyer]

Hello,

 

I have question regarding the

Micro Pro ATmega32u4 5V 16 MHz mini Leonardo Board Arduino AR01010J31 ATmega328

Can I use this board with DCS BiOs? The board comes with a usb micro and I was wondering can I use it and Do I have to press reset during up load like mentioned by Ian in his Video?

 

kind regards and thank you

[Gadroc]

Yes the Leonardo should work, and no you won't need to manually reset it.

[Felm]

Thanks Janko! I read up on them a bit yesterday, useful but I'm not sure if I'll need them since the register is setting the bits. Still, good to know.

 

Ian, I have encountered an issue: if I have the listener running without the game it reads the inputs fine ([ED:FIXED]well almost, it gets confused if I press the button too long or too fast[ED:FIXED]) but once I start up the game and the data starts flowing it will only catch the first input and then ignores the rest. If I press escape and give it a bit of time it starts working again fine (while the game is still paused). If I unpause the game the same behaviour starts again.

 

Does that indicate to a problem external to my code?

Edited January 22, 2015 by Felm

[Felm]

Small update:

 

I slowed the game down a lot (alt + z) and managed to send a message more than once. However at some point it still stops reading them. I don't know why...on some runs it was twenty or more, on others only once, or twice.

[FSFIan]

Ian, I have encountered an issue: if I have the listener running without the game it reads the inputs fine ([ED:FIXED]well almost, it gets confused if I press the button too long or too fast[ED:FIXED]) but once I start up the game and the data starts flowing it will only catch the first input and then ignores the rest. If I press escape and give it a bit of time it starts working again fine (while the game is still paused). If I unpause the game the same behaviour starts again.

 

Does that indicate to a problem external to my code?

Without the code in question and being able to reproduce the behavior on my end, I cannot answer that question.

 

Your bug report is a bit confusing.

What do you mean by "catching the input"? Do you mean having an effect in the cockpit or that you see the line of text appear in the command line window? Keep in mind that when the export data gets sent, any input you send may not show up in the command line window because the export data scrolls by so fast.

 

A complete bug report needs to answer three questions:

• What did you do? (including which Arduino board you are you using, what code it is running, and a description or schematic of the circuit)
  
• What happened? (even if you have a theory on what went wrong, always include the actual observations that lead you to that conclusion)
  
• What did you expect to happen instead?
  

 

Obviously, the first question is the most important. Without your code and schematic I cannot reproduce the problem on my end. The answer to the second question tells me when I have successfully reproduced the behavior you are seeing. The answer to the third question can be skipped if it is obvious (i.e. "the program should not stab me in the face"), but it is always a good idea to include it.

[Felm]

That was a bit confusing you are right. I meant that there is a a message in the command line and an effect in cockpit the first time I push the button but after that there is neither a message in the command line or an effect in cockpit. If I slow the game down then there is a a message in the command line and an effect in cockpit for several button presses, until at some point both cease to happen again.

 

Ill post the code and schematic when Im back from work tonight

[Felm]

the issues is internal to the code. The arduino resets for some reason when the data gets exported. I'm rewriting the whole thing so its useless to post code at this point.

[Felm]

I give up. I will take a break from working on this since it's taking up all my time and I'm not getting anywhere.

 

I'll make a post over at avrfreaks in a while but in the meanwhile here is some (faulty) code. I'll post the link so I don't flood this thread anymore.

 

If you scratch your head looking at this, it's because I have no idea what I am doing. I've probably tried a million different variations of what is in the code with no success.

 

Ian, if the code stabbed me in the face I wouldnt be surprised!

 

1)

 

http://pastebin.com/7W13Zycw

 

Here is the initial code that was giving me the "works only once unless I slow down the game". It also resets my arduino for some reason. I don't think that it's hardware related (checked the code with a printin function rather than a DcsBios and no resets).

 

2)

http://pastebin.com/JMEjH0vZ

 

This is the new code I was trying to write but it has consistently failed.

 

3)

 

here is a quick and dirty schematic http://i.imgur.com/HkqIn28.png

Edited January 24, 2015 by Felm

[FSFIan]

The weird behavior in the first sketch is because you are creating new Switch2PosSR objects in display_pin_values(). When the function ends, they are destroyed again, but pointers to them still exist elsewhere behind the scenes. When DcsBios::pollInputs() wants to call their pollInput() method, the objects have already gone, your sketch is executing arbitrary data as code and the behavior becomes undefined.

 

Your second sketch is very close. Take a look at line 37 in the pastebin:

int state = pinValues_ & (1<< srinput_);

You are fetching the pin values from the member variable pinValues_, which was set when the object was created, instead of the global pinValues, which is updated every loop().

I believe if you replace that with

int state = pinValues & (1<< srinput_);

, the button connected to pin P1 of your shift register should start operating the AHCP_CICU switch (not toggling though, that would need an ActionButtonSR).

[Felm]

You....you fixed it. You removed a _ and fixed it.

 

 

I have no words, thank you.

[FSFIan]

Congratulations! I think having a single character (other than a missing semicolon) standing between you and working code is kind of a rite of passage among programmers.

 

The most evil one I saw was when a buddy of mine wrote "i =+ 2;" instead of "i += 2;" -- fortunately this was Java code instead of C on an embedded system, so we could step through the code line by line in the debugger.

[Felm]

Thank you! I couldn't have done it without your help and everyone else who contributed. It was tough especially since it's my first time coding. It got really frustrating in the end because I knew it *should* work but it didn't...

 

Ouch, that i =+2 is evil...

 

So now I'm gonna do the rest of the classes. Shouldnt be much of a problem except maybe the Multiposition and rotary encoders.

 

Then I'll do the output shift registers.

 

Then.....I don't know. maybe I can do analog mux/demux for pots.

[Felm]

here is the code for the actionbutton class. the !=0 was tricky. not sure if there is a better way to do this

 

http://pastebin.com/gan5V9SR

[Felm]

all classes done for shift registers except the rotary encoders class. Once I'm done with the rots I'll post all the code. If anyone needs it NOW just post here.

 

I have some trouble understanding how to modify the read state and switch/quadrature case . I'm pretty sure the solution lies in there because I managed to get constant INC/DEC flooding by using > and < and ==0 (pressing button stops the flooding) operators instead of ==4/-4.

 

Two main issues I can think of:

 

1) Logic need to be inverted since we are not using the internal pullups

 

2) What values does "readState" return when using shift registers?

 

Solution is in here somewhere:

 

int RotaryEncoderSR::readState() {

return ((pinValues & (1<< SRpinA_)) << 1) | pinValues & (1<< SRpinB_);

}

 

void RotaryEncoderSR::pollInput() {

int 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;

 

if (delta_ == 4) {

sendDcsBiosMessage(msg_, incArg_);

delta_ = 0;

}

if (delta_ == -4) {

sendDcsBiosMessage(msg_, decArg_);

delta_ = 0;

}

}

 

 

Anybody have any ideas shoot

Edited January 25, 2015 by Felm

[Felm]

Ian;2295604']Felm: Thanks for the bug reports, the UHF .25 MHz selector description and the partial frequency string exports ("3 " -> " 3") are fixed now.

 

I released the changes as v0.2.3.

 

I could not reproduce glitches in the exports when changing the VHF frequencies. If it still happens after the updating, could you make a video?

 

 

C

 

Hey Ian the partial string exports are fixed but the glitches still occur (both with the control reference and without). It's still the same glitches: digits disappear and reappear or their values change to wrong ones . This affects both the digits receiving instructions and those who are not.

 

You still want a video?

[CodeToad]

Felm -

 

any chance you are running into the same issue I did (USB overwhelmed, reduce speed, captain !)

 

see http://forums.eagle.ru/showpost.php?p=2294113&postcount=101 how to set back baudrate to 115K or 250K (which still worked for me, but 500K which is the default in DCSBIOS did not)

[Felm]

Ouch, seems I missed a bug before (or maybe it's new).

 

The frequencies don't get updated if you are not in active pause mode. I was testing all this time on active pause for convenience but when the game is running the values are stuck on the freq set while on active pause.

 

Any values set during non-pause will be displayed again once I go in active pause and wait a bit .

 

It seems that the changes come one by one so If I got from 124.000mhz to 88.025mhz it will show the gradual changes of freq and not just jump to 88.025mhz.

 

using Control ref exhibits the same issue

[Felm]

I'll give that a try now, thanks!

[Felm]

CodeToad, lemme give you a kiss you sexy codehero you.

 

I knew I should have just tried that before screaming BUUUUUUUUUUUG!!!! kind of slipped my mind there

[Felm]

Tested it with a rot encoder (just one), very smooth and nice.

 

I wonder how 15 of them are gonna handle though

[G00dnight]

Hi I have CMSC,CMSP,UHF & Clock running on LCD Displays. How can I get the middle digits of the VHF Radios to display I have the 1st & last working fine..thanks George..

 

Felm for the Rots you may need external pullup resistors I saw a instruction using 3 resistors to make sure the Rots go high and low.

Edited January 29, 2015 by G00dnight

[FSFIan]

Example for the VHF AM Frequency Selector 2:

(in onDcsBiosWrite()):

if (address == 0x118e) {
   unsigned int vhfamFreq2Value = (value & 0x00f0) >> 4;
   lcd.setCursor(...);
   lcd.print(value);
}

This assumes that lcd.print() accepts an integer, I am pretty sure it does.

[G00dnight]

I get error: expected unqualified-id before 'if'.

I have only put vhfam 2nd digit in at the moment.

 

#include <DcsBios.h>

#include <Servo.h>

#include <Wire.h>

#include <LiquidCrystal_I2C.h>

 

 

LiquidCrystal_I2C lcd1(0x21, 2, 1, 0, 4, 5, 6, 7, 3, POSITIVE);

LiquidCrystal_I2C lcd2(0x27, 2, 1, 0, 4, 5, 6, 7, 3, POSITIVE);

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

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 onVhfamFreq1Change(char* newValue) {

lcd2.setCursor(0, 0);

lcd2.print(newValue);

}

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

 

if (address == 0x118e) {

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

lcd2.setCursor(2, 0);

lcd2.print(Value);

}

 

void onVhfamFreq4Change(char* newValue) {

lcd2.setCursor(6, 0);

lcd2.print(newValue);

}

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

 

void onVhffmFreq1Change(char* newValue) {

lcd2.setCursor(0, 2);

lcd2.print(newValue);

}

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

 

void onVhffmFreq4Change(char* newValue) {

lcd2.setCursor(4, 2);

lcd2.print(newValue);

}

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

/**** In most cases, you do not have to change anything below this line ****/

 

/* Instantiate a ProtocolParser object to parse the DCS-BIOS export stream */

DcsBios::ProtocolParser parser;

 

void setup() {

Serial.begin(115000);

lcd1.begin(16, 2);

lcd1.clear();

lcd2.begin(16, 2);

lcd2.clear();

 

}

 

/*

Your main loop needs to pass data from the DCS-BIOS export

stream to the parser object you instantiated above.

 

It also needs to call DcsBios::PollingInput::pollInputs()

to detect changes in the state of connected controls and

pass them on to DCS.

*/

void loop() {

// feed incoming data to the parser

while (Serial.available()) {

parser.processChar(Serial.read());

}

 

// poll inputs

DcsBios::PollingInput::pollInputs();

}

 

/*

You need to define

void sendDcsBiosMessage(const char* msg, const char* arg)

so that the string msg, followed by a space, the string arg

and a newline gets sent to the DCS-BIOS import stream.

 

In this example we send it to the serial port, so you need to

run socat to read the data from the serial port and send it

over UDP to DCS-BIOS.

 

If you are using an Ethernet Shield, you would probably want

to send a UDP packet from this subroutine.

*/

void sendDcsBiosMessage(const char* msg, const char* arg) {

Serial.write(msg);

Serial.write(' ');

Serial.write(arg);

Serial.write('\n');

}

 

/*

This subroutine gets called every time a message is received

from the export stream (you need to define it even if it

does nothing).

 

Use this to handle outputs which are not covered by the

DcsBios Arduino library (e.g. displays).

*/

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

 

}

Edited January 29, 2015 by G00dnight

[FSFIan]

As I said, that code belongs in the onDcsBiosWrite() function.