Major Announcement: New software to to connect panels to DCS

[Puma]

A solution for even noiser Potentiometers

 

I solved this problem by implementing sort of a hysteresis between input and reported value, similar to the debouncing of switches.

 

I added two more private variables in Potentiometer : PollingInput...

unsigned int lastState_;
unsigned int lastRepState_;

 

...and then used a two-stages approach. First detect, if the difference between actual and last state is greater then 3, then apply some sort of rounding for the reported value and compare if it differs from the last reported value.

 

void Potentiometer::pollInput() {
   unsigned int state = (analogRead(pin_));
   if (abs(state - lastState_)>3) {
       int rep=(state/4)*256;
       if (rep != lastRepState_)
       {
         char buf[6];
         utoa(rep, buf, 10);
         sendDcsBiosMessage(msg_, buf);
         lastRepState_=rep;
       }
       lastState_ = state;
   }  
}

 

By doing that, the accuracy is reduced to a 4th, but I do not get these constant output flows.

 

Hope that helps,

Dirk

 

Good start Dirk. I found my pots were much noiser than that. I cut my resolution down by a factor of 20 and still found some pot settings generating a constant stream. I added a second averaging filter to approximate a low-pass, and for my setup, I'm in the money. Here goes:

 

Potentiometer::Potentiometer(char* msg, char pin) {
msg_ = msg;
pin_ = pin;
pinMode(pin_, INPUT);
lastState_ = analogRead(pin_);//map(, 0, 1023, 0, 65535);
memset( aLastStates, 0, HISTORY_DEPTH * sizeof(unsigned int) );
}
void Potentiometer::pollInput() {
unsigned int state = analogRead(pin_);

if (abs(state - lastState_)<=3)
	return;	// Completely ignore very small changes

// Calculate the running average of the most recent changes
unsigned int uSum = 0;
for( int i = HISTORY_DEPTH-1 ; i > 0; i-- )
{
	aLastStates[i] = aLastStates[i-1];
	uSum += aLastStates[i];
}

aLastStates[0] = state;
uSum += state;

unsigned int uAverage = uSum / HISTORY_DEPTH;

// Report change IFF the running average is significant enough (/20 => 51 steps, which is good enough for DCS!)
if (abs(uAverage - lastState_)>20)
{
	char buf[6];
	utoa(map(uAverage, 0, 1023, 0, 65535), buf, 10);
	//utoa(state, buf, 10);
	sendDcsBiosMessage(msg_, buf);
	lastState_ = uAverage;
}
}

[Puma]

Emergency trim

 

I wired up my emergency panel via DCS-BIOS. Almost flawless. Thanks for the "reverse" setting as that saved me on a few this time!

 

The emergency trim hat is weird. Visually it works perfectly. I.E. When I hold a direction, it stays in that direction in game. However, it doesn't actually trim the stick. Clicking in the pit does though, so I am convinced this is a DCS-BIOS issue.

 

My 4 way didn't have a center-position wiring, so I set center as the default pin. I.E.

[code}
const byte efcpEmerTrimPins[5] = {-1, 2, 1, 3, 0};
DcsBios::SwitchMultiPos efcpEmerTrim("EFCP_EMER_TRIM", efcpEmerTrimPins, 5);
[/code]

.

 

In the DCS-BIOS serial stream. I see posX when I push a direction, and pos0 when I release.

 

What am I missing? Is DCS-BIOS supposed to support push&hold interfaces like this??

[SkyKnight]

Curious if anyone has any experience running Aries Airborne Radio along with DCS-BIOS? Alone, they run fine, but when I try to run DCS-BIOS with Aries, DCS-BIOS stops working. Both require entries in Export.lua.

 

Thanks!

[FSFIan]

Both work fine at the same time for me. Any errors in DCS.log?

[SkyKnight]

Update: I finally got both working together. I had to completely wipe and re-install DCSW. Always the "nuclear option"... go figure.

[voki]

Hi all,

 

I have faced strange issue during my tests with CMSP panel.

I have connected one 3-position ON-OFF-(ON) switch to my uno.

I am using following code for it - DcsBios::Switch3Pos cmspDisp("CMSP_DISP", 7, 8);

Basically switch works, I can see it moving up and down in cockpit.

Problem is, it is not doing what it should be in the up(2) position.

It should enter "menu", but it doesn't, as it is happening when I do mouse right click on it.

Am I missing something ?

 

You can see it here, last click is done by mouse and it enters conf page:

[FSFIan]

I have connected one 3-position ON-OFF-(ON) switch to my uno.

I am using following code for it - DcsBios::Switch3Pos cmspDisp("CMSP_DISP", 7, 8);

Basically switch works, I can see it moving up and down in cockpit.

Problem is, it is not doing what it should be in the up(2) position.

It should enter "menu", but it doesn't, as it is happening when I do mouse right click on it.

Am I missing something ?

 

Connect a wire to ground and touch pin 8 with the other end. If that switches the virtual cockpit switch to position 2, there is something wrong with how your switch is wired up (double-check with a multimeter that the switch connects the pins the way you think it does and/or take another look at the switches datasheet if you have one).

 

EDIT: Sorry, I didn't watch closely enough the first time. I have reproduced the bug here, will take a closer look with the Lua Console.

Update (02:43): Found the bug, too tired to fix it properly right now. Of course they had to make a variant of rocker switches that uses 0.0, 0.1 and 0.2 for the argument value instead of -1, 0 and 1 like all the other ones, so I will have to add an option to defineRockerSwitch() to specify the range and change all the places where it is currently used.

Edited April 12, 2015 by [FSF]Ian

[voki]

Thanks Ian, glad I could contribute to the testing :)

[Oesau]

TF-51 / P51 BIOS FILE IN DEVELLOPMENT.

 

Hi Darkwolf - so this is now part of DC-BIOS?

[TheSnark]

Is anyone currently working on the Ka-50? I am about 70% through with hooking up all the controls(rotary's, switches, etc) to DCS BIOS and I was wondering if anyone else already had made any efforts to handle the indicators(Gear LED, weapon LED, Gauges, etC).

 

What is the recommended way to test the export data? Listen in on a UDP port? Or hook it up to a Arduino and see what happends?

[FSFIan]

Is anyone currently working on the Ka-50? I am about 70% through with hooking up all the controls(rotary's, switches, etc) to DCS BIOS and I was wondering if anyone else already had made any efforts to handle the indicators(Gear LED, weapon LED, Gauges, etC).

I know that several people have started on Ka-50 support (got some questions via PM), but I have not heard back from any of them, so I don't know how far any of them got or if they have all given up. I asked them to start a thread on the public boards, which no one did.

 

Maybe they didn't want to show unfinished code. But publishing things as early as possible is the only way to prevent duplication of efforts and later merge conflicts! (I won't put three different versions of Ka-50 support into DCS-BIOS.)

 

Please start a separate thread for DCS-BIOS Ka-50 support and link to your existing code.

 

What is the recommended way to test the export data? Listen in on a UDP port? Or hook it up to a Arduino and see what happends?

 

The definitive way to test this is the

 

When I developed UH-1H support, I had a Chrome open on another monitor. One tab had the interactive control reference for testing, the other tab contained the DCS Witchcraft Lua console which was pointed at the export environment.

I would edit UH-1H.lua, reload the UH-1H part with the following snippet of Lua code, then hit F5 in the control reference and test my changes.

dofile(lfs.writedir()..[[scripts\DCS-BIOS\lib\Util.lua]]) -- in case I changed / fixed stuff in Util.lua
dofile(lfs.writedir()..[[scripts\DCS-BIOS\lib\UH1H.lua]])

[TheSnark]

Ian;2397992']

Please start a separate thread for DCS-BIOS Ka-50 support and link to your existing code.

 

Will do! That explains it I suppose. Not a lot of love for the Ka-50 around! I'll make a thread soon, I need to setup GitHub first.

 

Ian;2397992']

The definitive way to test this is the

 

When I developed UH-1H support, I had a Chrome open on another monitor. One tab had the interactive control reference for testing, the other tab contained the DCS Witchcraft Lua console which was pointed at the export environment.

 

Interesting, I've been using the changes in the Ka-50.json to confirm the lua code was valid and then test it in-game by sending UDP commands but this seems much easier!

 

Any dangerous pitfalls/advice I should adhere too? So far it's been pretty smooth sailing.

[FSFIan]

Any dangerous pitfalls/advice I should adhere too?

 

Not yet. Once people are actually using your code, you have to be aware of how the address allocation works when making changes to keep backwards compatibility.

 

A good example is this commit.

The buggy ENVCP_TEMP_PRESS switch was defined as having 30 positions, so DCS-BIOS had allocated 5 bits (2^5 = 32) to it. The fixed one has only 3 positions, so 2 bits (2^2 = 4) are sufficient. To avoid shifting the addresses of everything that is defined after this line around, we allocate an integer with a maxValue of 7, which takes up the remaining 3 bits in the address space.

Verifying that it worked is easy though -- the diff of the JSON file should only show changes for the controls that were actually modified.

[TheSnark]

Ah excellent, that makes perfect sense! I suppose I should break some things on purpose to test that.

[TheSnark]

I finished all the switches, rotary's, potentiometer. 99% has been checked to function as well.

 

https://github.com/SirWigglyBottom/DCS-BIOS-KA50

 

I am now working on the exporting bit of the data(radio's, gauges, indicators etc.).

[Adrian_gc]

Hey guys, some time ago I started using the DCS-BIOS to build my cabin A-10c, so far have had no problems with LED and buttons and gear servos with engine instruments. The problem I have with the altimeter needle, I have no idea how to do that is constantly moving over 360 degrees, with a servo 180 is impossible, with 360 either, I've seen your stepper motors, but arduino Uno R3 serves for that type of engine? what would be the lua code to move the "100 ft Pointer", if someone could lend a hand would appreciate, thank you very much.

[agrasyuk]

Warhog will probably chime in with more details, but for now have a look at this - http://m.aliexpress.com/item/837031970.html?tracelog=storedetail2mobilesitedetail

360 motor with optical 0 sensor.

[Warhog]

Warhog will probably chime in with more details, but for now have a look at this - http://m.aliexpress.com/item/837031970.html?tracelog=storedetail2mobilesitedetail

360 motor with optical 0 sensor.

 

Hi Adrian

 

Welcome. I see you have been busy. Very impressive. I look forward to seeing more of your work. Please do not hesitate post lots of pictures, descrpitions and code, etc. Adding to the collective knowledge of this forum is what helps to make this place very special.

 

As Anton pointed out, you will need to use Vid60 stepper motor. It is a continuous rotation stepper motor. Furthermore, it also incorporates an IR receiver and optical encoder disk that is very nicely integrated into the design of the plastic housing of the motor. As much as it already contains an IR reciever, you will still need to provide an IR emitter.

 

If you can wait a couple of days I will post a full description of my altimeter and all of the code for it. If you also plan on modelling some of the engine instruments, compass, HSI and the ADI you should think about stocking up on the VID60. BTW, this is the motor that's used for automobile clocks. It has 2 shafts, one for hour movement and the other for minute movement. Both originate from the same shaft but they geared differently. That is a rather special feature for us as it gives us two quite different rotational speeds which can come in very handy.

 

Keep watch for my post detailing my Altimeter build. It shouldn't be more than a few days from now.:)

[Adrian_gc]

Hey guys, thank you very much for the answers,i will be eager to see your post in the coming days Warhog, becouse resolve the issue of 360 degrees will help me a lot in many things.

 

Thank you very much for the link engine with zero position, Could you recomended to me a IR emitter for the VID60? ( i understand that this IR emitter will have to be placed in the pointer).

 

The link was not working properly for me, would these?

 

http://es.aliexpress.com/item/Weili-Clock-stepper-motor-VID60-02-100-new-stock-offet/837031970.html?isOrig=true#extend

 

 

I will be posting all the progress that go by on the way to help and be helped !!!! Thank you !!!!

Edited June 24, 2015 by Adrian_gc

[Warhog]

Yes those are the same ones I use. The IR emitter is something I cannot comment on as I have no idea what to recommend. I just had a couple lying around in my junk box of electronics stuff and tried them. They worked!

 

BTW the IR emitter is placed at the window opening of the stepper motor.

 

Here is a link to what might help.

 

http://startrobotics.blogspot.ca/2013/05/how-to-use-ir-led-and-photodiode-with-arduino.html

Edited June 25, 2015 by Warhog

[Adrian_gc]

Thank you very much Warhog , very interesting, I had no idea how it was done for the stepper motor start from zero. The construction of the altimeter will be in this post or in another?

[Warhog]

Thank you very much Warhog , very interesting, I had no idea how it was done for the stepper motor start from zero. The construction of the altimeter will be in this post or in another?

 

I was going to do a separate post in detail but it is taking a lot longer than I thought. How far into the altimeter are you. Do you have the VID60 and some IR emitters yet? If your in a hurry and just need the code for it, this is what was put together for it. I made a poor attempt at some of it but Ian came to my rescue and wrote all the important stuff which is still mostly over my pay grade. I am learning though and definitely getting better.:thumbup:

 

// include AccelStepper library
#include <AccelStepper.h>

// include DcsBios library
#include <DcsBios.h>
#include <Servo.h>

// DcsBios-related declarations
DcsBios::ProtocolParser parser;

#define STEPS_PER_REVOLUTION 240
#define ZERO_OFFSET 0

AccelStepper stepper; // Defaults to AccelStepper::FULL4WIRE (4 pins) on 2, 3, 4, 5
int currentStepperPosition = 0; // current stepper position (in steps, from 0 to STEPS_PER_REVOLUTION-1)
signed long lastAccelStepperPosition;

void setup()
{  
  Serial.begin(250000);
 
  pinMode (12,INPUT); // LOW when in zero position, HIGH otherwise

  
  // set up stepper motor for zeroing
  stepper.setMaxSpeed(1000);
  stepper.setSpeed(500);
  // run clockwise until we detect the zero position
  while (digitalRead (12)==1) {
      stepper.runSpeed(); 
  }
  
  // add zero offset
  stepper.runToNewPosition(stepper.currentPosition() + ZERO_OFFSET);
  
  // tell the AccelStepper library that we are at position zero
  stepper.setCurrentPosition(0);
  lastAccelStepperPosition = 0;
  // set stepper acceleration in steps per second per second
  // (default is zero)
  stepper.setAcceleration(1000);
  
}

void loop()
{
 // handle DcsBios communication
 while (Serial.available()) {
     parser.processChar(Serial.read());
 }
 DcsBios::PollingInput::pollInputs();
 
 // move stepper motor
 stepper.run();
}

void onDcsBiosWrite(unsigned int address, unsigned int value) {
 if (address == 0x107e) {
   digitalWrite (13,1);
   unsigned int alt100ftValue = (value & 0xffff) >> 0;
   
   // convert data from DCS to a target position expressed as a number of steps
   int targetPosition = map(alt100ftValue, 0, 65535, 0, STEPS_PER_REVOLUTION-1);

   // adjust currentStepperPosition to include the distance our stepper motor
   // was moved since we last updated it
   int movementSinceLastUpdate = stepper.currentPosition() - lastAccelStepperPosition;
   currentStepperPosition += movementSinceLastUpdate;
   lastAccelStepperPosition = stepper.currentPosition();
  
   if (currentStepperPosition < 0) currentStepperPosition += STEPS_PER_REVOLUTION;
   if (currentStepperPosition > STEPS_PER_REVOLUTION) currentStepperPosition -= STEPS_PER_REVOLUTION;
   
   int delta = targetPosition - currentStepperPosition;
   
   // if we would move more than 180 degree counterclockwise, move clockwise instead
   if (delta < -(STEPS_PER_REVOLUTION/2)) delta += STEPS_PER_REVOLUTION;
   // if we would move more than 180 degree clockwise, move counterclockwise instead
   if (delta > (STEPS_PER_REVOLUTION/2)) delta -= STEPS_PER_REVOLUTION;
   
   // tell AccelStepper to move relative to the current position
   stepper.move(delta);
 }
}

 

This code was written to assume that the IR photo-transistor is keeping pin 12 high until an opening occurs in the encoder disk inside the motor. When IR light hits the phototransitor (IR reciever) it cuts the voltage to pin 12 and the pin goes low. Thats the zero point. Set up your circuit to do that and your all set.:)

 

We did a quick test with it connected to DCS the day we finished it and it zeroed and it as with the virtual altimeter it continued through 360 degrees without a hiccup. In fact it mirrored the DCS altimeter perfectly. I haven't had a chance to do any more with it than that.

 

BTW, I noticed you have some sketches with your baud rate running at 500,000. You might want to step that down to 250,000 as the former caused issues running that fast.

 

Hope that helps Adrian.

 

Don't forget to post your results. Please use a separate thread when you do so. It will get lost in a mega (pun:smilewink:) thread like this one. As a matter of fact to any other posters, I would suggest we stop using this thread as it's just to large to maintain any semblance of easy to access information.

[agrasyuk]

That is some good stuff John.

[Adrian_gc]

Thank You Warhog !!! I start with it to work right now, as soon as it will put the results in a new post !!!!! Let's do it !!!!!

[Warhog]

That is some good stuff John.

 

It sure is Anton but the real credit must go to Ian. Although I did the hard stuff...I added this part::lol:

#include <AccelStepper.h>
#include <DcsBios.h>
#include <Servo.h>

Ian did the rest.:thumbup: This guy is just fantastic. :thumbup: Thank you Ian.