Jump to content

Major Announcement: New software to to connect panels to DCS


FSFIan

Recommended Posts

Quick update:

 

I pulled the latest master ( 2e316564b8 ) from github (with your _ACFT_NAME fix.)

 

Aircraft name now works, but I am almost never getting updates for other parameters like clock HH, MM, SS, ETC. (in the order of minutes, at first I got none and thought they would never update)

 

Strange because the code is the same for aircraft name, and the other stuff (as per templates)

 

My LCD is a 20x4. (I use underscores in this post for empty spaces so vBulletin doesnt mangle)

 

Intended:

 

[CSMC Text___________] eg ACTIVE/NONE

[A/C NAME___________] eg A-10C/NONE

[HH_MM_SS_ETC______] eg 11 25 34 ETC

[Hdg:295___Alt:9326___]

 

instead, when I start the connect-serial-port.cmd (DCS is already running) I get

 

[____________________] missing ?

[A-10C_______________] works !

[____________________] missing ?

[Hdg:295___Alt:9326___] works !

 

Heading and Alt are updated correctly and frequently (they are done in the onDcsBiosWrite() call back not using the StringBuffer snippets) Aircraft name is correct also.

 

But what is weird - where is my CMSC text and my clock ?

 

It stays like that for quite a while (>1 min I estimate) and after a while longer I have stuff like this (Not always the same, U's seem to come up often, but other chars appear also, so this is just an example):

 

[AC_________________] note missing "TIVE"

[A-10C&UUUU________] what are those chars behind the name ?

[16_00_UU___U_______] randomly other chars instead of numerals

[Hdg:295___Alt:9326__] these keep working fine

 

The Stringbuffer based methods seem to be called back far too infrequently and sometimes contain garbage characters (U's, umlaut, and graphic symbols on my LCD)

 

I also still saw the OFTIVE issue (ACTIVE overwritten by first two chars of OFF). Likewise vice versa ACF (ACtive + ofF) There is something about "2 character updates" vs the whole buffer it seems in the StringBuffers

 

When I throw my countermeasures panel switch (to force a ACTIVE/OFF toggle, it takes at least 5 seconds (sometimes way longer) to get the callback to trigger updating the LCD. (Is it missing packets in between ? Is the stream corrupted ?)

 

Occasionally I also see my TACAN test LED go on when I am not touching anything in the cockpit, further making me suspicious that garbage data is coming across or the parser got confused.

 

I tested my LCD's display hardware with constant strings in a separate sketch and found it to be functional, so I dont think wiring or pixel problems are an issue, it is something in the updates/callbacks or parsing?

 

Just in case it helps illuminate things, I attach a section of the socat dump - at the end the plane crashes and the name of the aircraft should change to "NONE". On my LCD I have NONECU ( = NONE + leftover C from A-10C + stray U)

 

If I can provide any additional information / do other tests, I am happy to.

 

 

#include <DcsBios.h>

#include <Servo.h>

#include <LiquidCrystal.h>

 

#define TACAN_TEST_BUTTON 2

#define TACAN_TEST_LED 3

 

LiquidCrystal lcd(7, 8, 9, 10,11,12);

 

// ------------------------------------------------------------------------------

 

DcsBios::LED tacanTest(0x10da, 0x0400, TACAN_TEST_LED);

DcsBios::Switch2Pos tacanTestBtn("TACAN_TEST_BTN", TACAN_TEST_BUTTON);

 

// CMSC Status on line 0 (ACTIVE/OFF)

void onCmscTxtMwsChange(char* newValue) {

lcd.setCursor(0,0);

lcd.print( newValue );

}

DcsBios::StringBuffer<8> cmscTxtMwsBuffer(0x12b0, onCmscTxtMwsChange);

 

 

// aircraft name on line 1 (A10C/NONE)

void onAcftNameChange(char* newValue) {

lcd.setCursor(0,1);

lcd.print( newValue );

}

DcsBios::StringBuffer<16> AcftNameBuffer( 0x0000, onAcftNameChange);

 

 

// clock on line 2 (HH MM SS ETC)

void onClockHhChange(char* newValue) {

lcd.setCursor(0,2);

lcd.print( newValue );

}

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

 

void onClockMmChange(char* newValue) {

lcd.setCursor(3,2);

lcd.print( newValue );

}

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

 

void onClockSsChange(char* newValue) {

lcd.setCursor(6,2);

lcd.print( newValue );

}

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

 

void onClockEtcChange(char* newValue) {

lcd.setCursor(9,2);

lcd.print( newValue );

}

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

 

 

// ------------------------------------------------------------------------------

 

DcsBios:: ProtocolParser parser;

 

void setup() {

Serial.begin(500000);

 

lcd.begin(20,4);

lcd.clear();

}

 

void loop() {

while (Serial.available()) {

parser.processChar(Serial.read());

}

DcsBios:: PollingInput::pollInputs();

}

 

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

Serial.write(msg);

Serial.write(' ');

Serial.write(arg);

Serial.write('\n');

}

 

 

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

 

// show heading and altitude on line 3 of LCD

if (address == 0x040a) {

unsigned int hdgDegValue = (value & 0x01ff) >> 0;

String s(hdgDegValue);

lcd.setCursor(0,3);

lcd.print( "Hdg:" + s + " " );

}

 

if (address == 0x0408 ) {

unsigned int altMslFtValue = (value & 0xffff) >> 0;

String s2(altMslFtValue);

lcd.setCursor(10,3);

lcd.print( "Alt:" + s2 + " " );

}

 

}

 

dump.zip


Edited by CodeToad

Working on an open source "kneeboard" app (browser based, so runs everywhere) for DCS world: maps, checklists, reference, glossary, calculators.

Link to comment
Share on other sites

  • Replies 398
  • Created
  • Last Reply

Top Posters In This Topic

CodeToad:

The _ACFT_NAME string is not space-padded but null-terminated, so you have to take care of clearing the old value from the display yourself. The reasoning behind that decision is that you are unlikely to display that info anywhere; it is more likely to be used in a comparison like "if (strcmp(acftNameStr, "A-10C") == 0)" to check whether a particular aircraft is active.

 

Regarding the rest of the erratic behavior you are seeing:

I think all the LCD updates are taking too long so the serial receive buffer fills up in the meantime, causing data to be lost and parser confusion.

 

Instead of calling lcd.print() whenever a value change has been transmitted, try updating a variable instead.

 

Then add something like this to onDcsBiosWrite():

if (address == 0xfffe) {
 lcd.setCursor(...)
 lcd.print(altMslVariable)
 etc.
}

 

The idea is to delay the actual display updates until a write access to address 0xfffe (the update counters) has been received. The value at that address is always changed in every update and it is guaranteed to be the last thing to be "written to", so it also serves as an "end of update" marker. After the end of an update, you have about 30 ms without having to worry about receiving new data.

 

Also make sure to update your Arduino library to the current master branch if you have not already. It changes the time when StringBuffers call their callbacks from the beginning of the next update to the end of the current one. I am pretty sure this works, but I did not have an opportunity to test it yet. If that version of the library works for you, let me know and I will release it as v0.1.4.


Edited by [FSF]Ian
Link to comment
Share on other sites

Another way to solve the "serial receive buffer full" problem is to increase its size as described here. 256 bytes should be plenty to hold a typical update, which is about 100 to 200 bytes long.

 

I wouldn't necessarily recommend it (avoiding the problem in the first place is smarter), but it is a good way to confirm what causes the weird behavior.

Link to comment
Share on other sites

Quick update:

 

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

 

// show heading and altitude on line 3 of LCD

if (address == 0x040a) {

unsigned int hdgDegValue = (value & 0x01ff) >> 0;

String s(hdgDegValue);

lcd.setCursor(0,3);

lcd.print( "Hdg:" + s + " " );

}

 

if (address == 0x0408 ) {

unsigned int altMslFtValue = (value & 0xffff) >> 0;

String s2(altMslFtValue);

lcd.setCursor(10,3);

lcd.print( "Alt:" + s2 + " " );

}

 

}

 

[/font]

 

I might just be stupid blind here but where did you get these values? I can't find them in the control reference.

Link to comment
Share on other sites

@Ian:

 

Tried using your suggestion to only update LCD when MetadataEnd (0xfffe) gets encountered.

 

Did not fix the problem. Still seeing junk bytes, strings too short (like empty HH/MM/SS), very rare updates (possibly due to corrupted stream => missing MetadataEnd packets) and likewise TACAN test light on wrong (which is independent of LCD mechanics, pointing to a software rather than hw updating issue)

 

Code pasted below.

Tricky to debug because I can't use Serial.print because the serial port is obviously being used by the socat cmd.

Is there a way to "debug dump" what is being sent over the serial port by socat ?

 

Additional info:

I verified again that your chrome extension with live data display shows the data coming from your DCS BIOS export correctly, so the issue is likely downstream of that.

 

Curiously I noticed that when I put the A10 into autopilot flying straight, things start looking better on the LCD soon after: updates happen more frequently and the text looks more correct !

Could it be that if I fly manually that causes more cockpit display data changes and thus more required updates and that may flood socat or my serial interface ?

This is reversible: if I go out of autopilot, I once again get more garbage chars, fewer updates.

 

 

 

----------

 

Second, following up on your suggestion that the LCD might be overwhelmed w too many updates, I also looked into that a little bit, and to save others this particular trip down debugging lane:

 

My LCD display, a 20x4 liner (http://www.adafruit.com/products/198) is based on the HD44780 chip which is also used by many other character displays.

They all have similar pinouts:

VSS, VDD, V0, RS, RW, E, D0, D1, D2, D3, D4, D5, D6, D7, LED+, LED-

 

General info and hookup instructions can be found here.

 

The tutorials all show a wire & pin conserving 4-data wire hookup of the display, rather than all 8. Quoting from that page:

 

There is also a way to talk to the LCD using only 4 data pins instead of 8. This saves us 4 pins! Why would you ever want to use 8 when you could use 4? We're not 100% sure but we think that in some cases its faster to use 8 - it takes twice as long to use 4 - and that speed is important. For us, the speed isn't so important so we'll save some pins!

 

I did try hooking up all 8 data lines (since we are testing whether LCD speed might be a culprit) and used the full 8 dataline constructor for the LCDLibrary

 

LiquidCrystal(rs, enable, d0, d1, d2, d3, d4, d5, d6, d7)

 

That however did not work at all (nothing shows up on the LCD) So I assume there is a bug in the library and left that experiment alone. Just FYI.

 

 

-------------

 

As per Ian's suggestion, modified Arduino code that collects telemetry as usual but only updates the LCD when a MetadataEnd packet (0xfffe) is encountered (which by design should be about every 30ms).

See onDcsBiosWrite() and updateLCDDIsplay() below.

 

 

#include <DcsBios.h>

#include <Servo.h>

#include <LiquidCrystal.h>

 

#define TACAN_TEST_BUTTON 2

#define TACAN_TEST_LED 3

 

LiquidCrystal lcd(7, 8, 9, 10,11,12);

 

unsigned int altMslFtValue;

unsigned int hdgDegValue;

 

// ------------------------------------------------------------------------------

 

DcsBios::LED tacanTest(0x10da, 0x0400, TACAN_TEST_LED);

DcsBios::Switch2Pos tacanTestBtn("TACAN_TEST_BTN", TACAN_TEST_BUTTON);

 

void onCmscTxtMwsChange(char* newValue) {}

DcsBios::StringBuffer<8> cmscTxtMwsBuffer(0x12b0, onCmscTxtMwsChange);

 

void onAcftNameChange(char* newValue) {}

DcsBios::StringBuffer<16> AcftNameBuffer( 0x0000, onAcftNameChange);

 

void onClockHhChange(char* newValue) {}

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

void onClockMmChange(char* newValue) {}

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

void onClockSsChange(char* newValue) {}

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

void onClockEtcChange(char* newValue) {}

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

 

// ------------------------------------------------------------------------------

 

DcsBios:: ProtocolParser parser;

 

void setup() {

Serial.begin(500000);

 

lcd.begin(20,4);

lcd.clear();

}

 

void loop() {

while (Serial.available()) {

parser.processChar(Serial.read());

}

DcsBios:: PollingInput::pollInputs();

}

 

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

Serial.write(msg);

Serial.write(' ');

Serial.write(arg);

Serial.write('\n');

}

 

 

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

 

// show heading and altitude on line 3 of LCD

if (address == 0x040a ) {

hdgDegValue = (value & 0x01ff) >> 0;

}

 

if (address == 0x0408 ) {

altMslFtValue = (value & 0xffff) >> 0;

}

 

if (address == 0xfffe ) { // end of DCS BIOS update marker (~every 30ms)

updateLCDDisplay();

}

}

 

 

void updateLCDDisplay()

{

lcd.setCursor(0,0);

lcd.print( cmscTxtMwsBuffer.buffer );

 

lcd.setCursor(0,1);

lcd.print( String(AcftNameBuffer.buffer) + " " );

 

// assemble clock string here so we dont hammer LCD more than necessary

String c = String(clockHhBuffer.buffer) + ":" + String(clockMmBuffer.buffer) + ":" +

String(clockSsBuffer.buffer) + " " + String( clockEtcBuffer.buffer );

lcd.setCursor(0,2);

lcd.print©;

 

String s(hdgDegValue);

lcd.setCursor(0,3);

lcd.print( "Hdg:" + s + " " );

 

String s2(altMslFtValue);

lcd.setCursor(10,3);

lcd.print( "Alt:" + s2 + " " );

}

Working on an open source "kneeboard" app (browser based, so runs everywhere) for DCS world: maps, checklists, reference, glossary, calculators.

Link to comment
Share on other sites

@Ian:

 

Tried using your suggestion to only update LCD when MetadataEnd (0xfffe) gets encountered.

 

Did not fix the problem. Still seeing junk bytes, strings too short (like empty HH/MM/SS), very rare updates (possibly due to corrupted stream => missing MetadataEnd packets) and likewise TACAN test light on wrong (which is independent of LCD mechanics, pointing to a software rather than hw updating issue)

 

Ok, new theory: data bytes on your serial connection get corrupted or go missing with a certain probability or after a certain message length (due to clock drift). The values in the CommonData module display fine because they are transmitted at the very beginning of the update, so they have a higher chance of being transmitted before the corruption hits. They also change frequently, so if they do get corrupted, that tends to be corrected in the next update.

 

This could be a hardware problem, but I cannot rule out software either (maybe your system does not like your USB-to-Serial converter).

 

Code pasted below.

Tricky to debug because I can't use Serial.print because the serial port is obviously being used by the socat cmd.

Is there a way to "debug dump" what is being sent over the serial port by socat ?

 

Additional info:

I verified again that your chrome extension with live data display shows the data coming from your DCS BIOS export correctly, so the issue is likely downstream of that.

 

socat -v UDP4-RECV:5010,ip-add-membership=239.255.50.10:127.0.0.1,reuseaddr CREATE:exportstream.dump

This will log what DCS-BIOS sends via UDP (and the connect-to-serial script forwards to the serial port) to the file exportstream.dump, although if the control reference docs show everything correctly, I doubt the problem is here.

 

EDIT: What you could try is to write a "SerialEcho" Arduino sketch that reads data from the serial port and simply sends it back. Send it the DCS-BIOS export stream, write what it sends back to a logfile, then compare that to the logfile produced by the above command.

 

Curiously I noticed that when I put the A10 into autopilot flying straight, things start looking better on the LCD soon after: updates happen more frequently and the text looks more correct !

Could it be that if I fly manually that causes more cockpit display data changes and thus more required updates and that may flood socat or my serial interface ?

This is reversible: if I go out of autopilot, I once again get more garbage chars, fewer updates.

 

This is interesting! It is plausible that when on autopilot, there are a lot less changes (especially on the engine instruments and HSI). That means the updates for the other values are closer to the beginning of an update, so they have a higher chance of being sent before the corruption hits.

 

Maybe the combination of your Arduino and USB-to-Serial converter do not like to communicate at 500000 bps (e.g. due to clock drift).

 

Try lowering the baudrate by changing 500000 to 115200 in the Serial.begin() call in your sketch and in the connect-serial-port.cmd script.

 

If you want to go even slower, you should also add the following two lines to BIOSConfig.lua (example for 9600 bps):

BIOS.protocol.maxBytesPerSecond = 900 -- 960 / 10 bits per byte minus a safety margin
BIOS.protocol.maxBytesInTransit = 1000 -- defaults to 4000, 1000 should be more than enough to buffer the very first update that includes all the values

This will cause DCS-BIOS to skip some updates in order to avoid sending data faster than the serial connection can handle it.


Edited by [FSF]Ian
Link to comment
Share on other sites

Quick update!

 

I testing things right now and managed to export some frequencies to the 7seg very easily. However this only works for the 0-9 frequencies. Now I am trying to see how to get the >9 frequencies broken down in 0-9 numbers and assign each to a different 7seg. So for example a frequency of 75 will become '7' and sent over to digit0 (7seg digit) and '5' sent over to digit1.

 

I believe this has to do with breaking down strings into integers and then sending those integers to different leds. I have to look into how to do that now.

Link to comment
Share on other sites

If you look at the reference docs in Advanced mode, you will see that for those dials where the integer output does not correspond with the label, DCS-BIOS helpfully supplies an additional string output :)

 

For example the VHFAM_FREQ4 control has this:

Output Type: string Address: 0x1192 Max. Length: 2 Description: possible values: "0" "25" "50" "75"

 

You should also take a look at the setChar() method in the LedControl library if you have not already.

Link to comment
Share on other sites

I'm a bit stuck.... I got everything to work but I have an issue where my digits will shift to the left when less that 10. so for example a 1-15 frequency selector, 10-15 are displayed fine but 3-9 become 30,40,50,60,70,80,90 and then it goes normally to 10,11,12,13,14,15 and then back to 30,40 etc [edit: removed the10,20 since freqs start at 3]

 

here is the relevant code :

 

void onVhfamFreq1Change(char* newValue) {

for(int i=0;i<2;i++) {

lc.setChar(0,i,newValue,false);

}

}

 

I thought of maybe telling it to check if the value is less than 10 then to write directly to digit 2 (the physical 7seg digit I mean) and if its more than 10 to write to both digits but I didn't manage to make it work.

 

something like this:

 

for(int i=0;i<2;i++){

if (*newValue <9) {

lc.setChar(0,1,newValue,false);

}

else {

lc.setChar(0,i,newValue,false);

}

I tried many variations of the above but I'm lacking some fundamental understanding on how it works so I end up with compiler errors when trying to convert char* to int. Or it compiles ok but to no effect. I tried to use "atoi" and a=b-'0' but no luck.

 

My code looks like shit, I know :(


Edited by Felm
Link to comment
Share on other sites

Felm: The string values for the VHF AM/FM selector 1 do not follow the usual convention for most string outputs to always have a fixed length. I will fix that as soon as I have access to my DCS computer again (probably Monday or Tuesday).

 

In the meantime, if you update to the current master branch (https://github.com/dcs-bios/dcs-bios/archive/master.zip), it should at least read "3 " instead of "30". After I get around to fixing this, it will read " 3" instead.

Link to comment
Share on other sites

it works like you said "3 "

 

but now the onVhfamFreq4Change (the last two numbers on am/fm freq) only displays "0 " instead of "00".

 

25,50,75 work ok so far (no missing values).

 

It used to work ok before I upgraded to the new version so I shouldnt blame my code right?

Link to comment
Share on other sites

One more issue I noticed is that there are some small glitches here and there:

 

when changing values sometimes the digit will switch off for a second or so and then the new value will be displayed.

 

sometimes when changing values of one frequency another one will change briefly to a wrong value and then come back to the correct one.

 

so far I tested the vhf am and uhf. the ufh seems to be a bit less affected by this (ed: seems to be affected the same)


Edited by Felm
Link to comment
Share on other sites

here is today's work:

 

VHF AHM code

 

#include <DcsBios.h>

#include <Servo.h>

#include <LedControl.h>

 

LedControl lc=LedControl(12,11,10,1);

unsigned long delaytime=250;

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

 

 

void onVhfamFreq1Change(char* newValue) {

for(int i=0;i<2;i++) {

lc.setChar(0,i,newValue,false);

}

}

 

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

 

void onVhfamFreq4Change(char* newValue) {

for(int i=0;i<2;i++) {

lc.setChar(0,i+4,newValue,false);

}

}

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

 

 

 

 

 

DcsBios::ProtocolParser parser;

 

void setup() {

Serial.begin(500000);

 

 

lc.shutdown(0,false);

/* Set the brightness to a medium values */

lc.setIntensity(0,1);

/* and clear the display */

lc.clearDisplay(0);

}

 

 

 

void loop() {

// feed incoming data to the parser

while (Serial.available()) {

parser.processChar(Serial.read());

}

 

// poll inputs

DcsBios::PollingInput::pollInputs();

}

 

 

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

Serial.write(msg);

Serial.write(' ');

Serial.write(arg);

Serial.write('\n');

}

 

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

 

if (address == 0x118e) {

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

lc.setChar(0,2,vhfamFreq2Value,true);

}

 

if (address == 0x118e) {

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

lc.setChar(0,3,vhfamFreq3Value,false);

}

 

}

 

 

UHF CODE (with a rotary encoder for testing)

 

#include <DcsBios.h>

#include <Servo.h>

#include <LedControl.h>

 

LedControl lc=LedControl(12,11,10,1);

/* we always wait a bit between updates of the display */

unsigned long delaytime=250;

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

 

 

DcsBios::RotaryEncoder uhf10mhzSel("UHF_10MHZ_SEL", "DEC", "INC", 6, 7);

 

 

void onUhf100mhzSelChange(char* newValue) {

for(int i=0;i<1;i++) {

lc.setChar(0,i,newValue,false);

}

 

 

}

DcsBios::StringBuffer<1> uhf100mhzSelStrBuffer(0x1178, onUhf100mhzSelChange);

 

void onUhfPoint25SelChange(char* newValue) {

for(int i=0;i<2;i++) {

lc.setChar(0,i+4,newValue,false);

}

}

 

DcsBios::StringBuffer<2> uhfPoint25SelStrBuffer(0x117a, onUhfPoint25SelChange);

 

 

DcsBios::ProtocolParser parser;

 

void setup() {

Serial.begin(500000);

 

/*

The MAX72XX is in power-saving mode on startup,

we have to do a wakeup call

*/

lc.shutdown(0,false);

/* Set the brightness to a medium values */

lc.setIntensity(0,1);

/* and clear the display */

lc.clearDisplay(0);

}

 

 

 

void loop() {

// feed incoming data to the parser

while (Serial.available()) {

parser.processChar(Serial.read());

}

 

// poll inputs

DcsBios::PollingInput::pollInputs();

}

 

 

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

Serial.write(msg);

Serial.write(' ');

Serial.write(arg);

Serial.write('\n');

}

 

 

 

 

 

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

 

if (address == 0x1170) {

unsigned int uhf10mhzSelValue = (value & 0x3c00) >> 10;

lc.setChar(0,1,uhf10mhzSelValue,false);

}

 

if (address == 0x1178) {

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

lc.setChar(0,2,uhf1mhzSelValue,false);

 

}

 

if (address == 0x1178) {

unsigned int uhfPoint1mhzSelValue = (value & 0xf000) >> 12;

lc.setChar(0,3,uhfPoint1mhzSelValue,false);

}

 

 

}

 

 

 

so far so good I guess. it's not perfect but it works. there might be some refreshing or serial comm issues. when testing the rotary it did miss quite a few turns or lagged a bit until updating.

Link to comment
Share on other sites

but now the onVhfamFreq4Change (the last two numbers on am/fm freq) only displays "0 " instead of "00".

That is expected (caused by the same bug).

 

It used to work ok before I upgraded to the new version so I shouldnt blame my code right?

 

One more issue I noticed is that there are some small glitches here and there:

 

when changing values sometimes the digit will switch off for a second or so and then the new value will be displayed.

 

sometimes when changing values of one frequency another one will change briefly to a wrong value and then come back to the correct one.

 

so far I tested the vhf am and uhf. the ufh seems to be a bit less affected by this (ed: seems to be affected the same)

 

Could you check if the same behavior happens in the

If it does, it's a bug in DCS-BIOS itself, if it doesn't, it could be a bug in the Arduino library, in your code, or a hardware problem.

 

You are the second person (besides WarHog) who is experiencing trouble with radio frequencies. The frustrating thing is that I was not able to reproduce any of these errors so far.

 

when testing the rotary it did miss quite a few turns or lagged a bit until updating.

That is normal. While DCS is animating the rotation of the knob, it will ignore additional commands.


Edited by [FSF]Ian
Link to comment
Share on other sites

I checked with the interactive reference and managed to reproduce the same behaviour.

 

- lag (it will miss an input and refresh the digit with the correct value a bit later)

- it will change to a wrong value and then revert back to the correct one

- other digits will change value and then revert to the correct one

- other digits will switch off and on

- the digit you are interacting with will switch off and on

 

I noticed that if you do it (ed: do it = change frequencies) slowly there's less glitches. Lag still occurs but the other glitches not so much (they still happen though). The faster you do it the more glitches. I didnt experience a digit getting stuck on a wrong value though, they all eventually display the correct values.

 

I could upload a video if you want tomorrow if you think it will help.


Edited by Felm
Link to comment
Share on other sites

I have been messing around with encoders and the Arduino recently and found them a little tricky. They need either hardware or software debouncing ( and possibly both ? )

 

I have given up because in my application ( not for a flight sim ) I can't miss a count and have things working the way they need to.

---------------------------------------------------------

PC specs:- Intel 386DX, 2mb memory, onboard graphics, 14" 640x480 monitor

Modules owned:- Bachem Natter, Cessna 150, Project Pluto, Sopwith Snipe

Link to comment
Share on other sites

I checked with the interactive reference and managed to reproduce the same behaviour.

 

- lag (it will miss an input and refresh the digit with the correct value a bit later)

- it will change to a wrong value and then revert back to the correct one

- other digits will change value and then revert to the correct one

- other digits will switch off and on

- the digit you are interacting with will switch off and on

 

I noticed that if you do it (ed: do it = change frequencies) slowly there's less glitches. Lag still occurs but the other glitches not so much (they still happen though). The faster you do it the more glitches. I didnt experience a digit getting stuck on a wrong value though, they all eventually display the correct values.

 

I could upload a video if you want tomorrow if you think it will help.

 

After reading the existing code again, I am now pretty sure it is caused by the animation in the cockpit. I should be able to fix it.

Link to comment
Share on other sites

I have been messing around with encoders and the Arduino recently and found them a little tricky. They need either hardware or software debouncing ( and possibly both ? )

 

I have given up because in my application ( not for a flight sim ) I can't miss a count and have things working the way they need to.

 

If you absolutely cannot ever miss a count, you want interrupt-based encoder handling with software debouncing. If you have not tried that yet, find an example online and test if that works for your application.

Link to comment
Share on other sites

Ian;2293877']After reading the existing code again' date=' I am now pretty sure it is caused by the animation in the cockpit. I should be able to fix it.[/quote']

 

Great! How does the animation interfere with the exported values? Or does it interfere with the inputs?

 

If I can tomorrow I will give a shot to the shift register thing...although it might be harder than the 7segs. To be honest it was very easy (10mins) to get the integers out. The hard part was figuring out the i++ for the newValue strings (that's actually a character array no?) and spending something like 3 hours fighting the surprise 30,40,50 etc bug...

 

By the way if anyone has any optimizations for the code I posted feel free to contribute :)

Link to comment
Share on other sites

  • Recently Browsing   0 members

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