HMA's cockpit build

[Duckling]

For a single magswitch I found no problems but when all SAS panel mags released and tried to lock'en in close sequence They had to be held s "long" time to build up the needed power to stay in place (used a modded atx ps for the 12 V then). No problems yet with a separate 24V supply.

 

I made a Quick and dirty hold function within Sioc but haven't all dependencies implemented. Currently only monitor/export the on-> off movment of each logical switch and when it released by dcs, I cut power to the relay controlling each magswitch.

Then activate the relay/power to the coil with the physical switch position again, releasing it and if dcs trigger the off again, the cycle repeat again

 

But to build such in dcs-bios (if possible), its beyond me currently :-)

The option to export the state of the "coils" of each Magswitch would be great but I havent found any value accessible via DCS Witchcraft (not saying it's not there)

Edited January 17, 2017 by Duckling

[Hansolo]

Modifications to Potentiometer.h

 

When trying to setup DCS-BIOS with potentiometers I noticed that the potentiometers kept adjusting all the time. It was only small movements but movements i.e. value changes all the time.

I tried to apply low pass filter but didn't solve the issue to my liking.

Opened up DCS-BIOS Potentiometer.h file to see how it worked. Now take into consider that I am not a programmer so this is my interpretation and may not reflect how it actually works :lol:

 

What I found was that DCS-BIOS sent a new potentiometer value as soon as the new value wasn’t exactly same value as the previously sent;

if (state != lastState_) {

 

The Arduino takes the full scale of the potentiometer as 0-1023 (10 bits) which are converted into 0-65535 (unsigned int) I imagine that it is very difficult to measure the exact same value from time to time. I mean new value 32501 isn’t the same as last sent value 32500 although the change is very small (0.0015 % of full scale).

 

I altered the above mentioned line in Potentiometer.h to so that it would have a buffer zone (+/-500) around previously sent potentiometer value;

if (state < lastState_ - 500 || state > lastState_ + 500) { 

If new value is within the buffer zone of last sent value nothing happens. If new value is outside buffer zone of last sent value, a new value is sent.

Taking above example that last was 32500, then as long as the new value is within 32000-33000 then no new value is sent.

 

This causes my potentiometers to be rock solid.

Does this mean that my resolution or accuracy is less? YES

Does it matter? NO I do not think so.

 

 

Granted I am not fully aware whether DCS-BIOS only sends a new value to DCS if there is a change outside of the buffer zone or it just repeats the same value while inside the buffer zone. But that is just more to figure out :smilewink:

 

Please find the changed Potentiometer.h file attached.

 

Cheers

Hans

Potentiometers.rar

Edited January 18, 2017 by Hansolo

[MacFevre]

Great job Hans! Nervous? Never knew a nervous potentiometer! :D When you say nervous, are you talking about the hesitation that the pot is doing during it's movement? That's pretty cool that you got it fixed. Thanks!

 

You figure out, since your working on the light panel, how to use the real one yet? If you have, care to share the what the pinout is? I keep telling myself I'm going to do that one of these days. Yet, well, something else always seems to come up!

[Gadroc]

You're algorithm has just effectively dropped resolution. There are a couple of other techniques to deal with this that are better.

 

First apply filters to the raw ADC reading (0-1023) not to the expanding output (0-65535).

 

I'd start with super sampling. Read the ADC every 50ms and every 4th reading average the last 4 readings and pass that to DCS BIOS. This will increase the usable bitrate of the ADC instead of reduce it.

 

If that is not enough you take the supersample results from the above, but don't fully override the last reading. Do something like lastreading = (lastreading + lastreading + lastreading + newreading)/4. That will slow down change over time, so short spikes are reduced.

 

After those changes your should only see jidder of 1-2 in raw value which is common for the least significant bit of an ADC reading. If that's to much you keep track if you are with in 1-2 of the last output and if you are only pass it on if the last few readings also that way.

 

You would end up with something like the following (pseduo code).

 

super_sample_total += analogRead()
sample_count++
if (sample_count == 4) {
  sample_count = 0;
  new_sample = super_sample_total / 4;
  output = (output + output + output + new_sample) / 4;
  
  if (ABS(output - dcsvalue) > 2) {
     dcsvalue = output;
  } else if ((lastoutput - dcsvalue) < 2) {
     dcsvalue = output;
  }
  lastoutput = output;
}

 

Here are a few links on creating software filters for things like this:

Filters (long) forum post

A simple software lowpass filters

[Hansolo]

Great job Hans! Nervous? Never knew a nervous potentiometer! :D When you say nervous, are you talking about the hesitation that the pot is doing during it's movement? That's pretty cool that you got it fixed. Thanks!

 

You figure out, since your working on the light panel, how to use the real one yet? If you have, care to share the what the pinout is? I keep telling myself I'm going to do that one of these days. Yet, well, something else always seems to come up!

Mac, if you take a look at the YT you'll see in the first part of it that the potentiometer is constantly moving even though I am not giving an input. That's what I call 'nervous'.

 

Implementation of the real panel is still ongoing as I ran out of parts. You have to implement a MOSFET semiconductor in order to get the mag switch working. I have been using a IFR510. I know Warhog is using a different ones, I think 30n06LE.

I post what I have done when I am finished but the pinout is the least of your worries.

 

Secondly I will have to check how 'Signal light BRT - DIM' is going to work. In the DCS it's a 2-position switch ON-OFF but the real panel we have it's a 3-position (ON)-OFF-(ON) which kinda makes sense to increase - hold or decrease brightness.

 

Must be an error in the implementation of that switch. As I believe both our panels have the 3-position switch.

 

You're algorithm has just effectively dropped resolution. There are a couple of other techniques to deal with this that are better.

Yeap I know that the resolution has dropped but it's deliberate from two perspectives. One it was what I could manage. Maybe later when I learn more I'll be ale to more advanced stuff.

 

Secondly I can't really see the reason for 65536 steps resolution for a potentiometer. I very much doubt that I'll be able to see the difference in the 3D cockpit when comparing a light setting of e.g. 23400 with 23900.

 

Anyway many thanks for the examples and explanations. I'll definitely take a look at it.

 

Cheers

Hans

[Gadroc]

Yeap I know that the resolution has dropped but it's deliberate from two perspectives. One it was what I could manage. Maybe later when I learn more I'll be ale to more advanced stuff.

 

Secondly I can't really see the reason for 65536 steps resolution for a potentiometer. I very much doubt that I'll be able to see the difference in the 3D cockpit when comparing a light setting of e.g. 23400 with 23900.

 

Anyway many thanks for the examples and explanations. I'll definitely take a look at it.

 

Cheers

Hans

 

DCS Bios protocol has all values with 65536 steps (0-65535) or 16 bit resolution, but your arduino has no where near that capability in measuring analog values. It only has 1024 steps (0-1023) or 10bit resolution. What the firmware does is take the value from reading the pot (0-1023) and multiply it by 64 turning it into (0-65535), but there are still only 1024 possible values being returned (0, 64, 128, 172...). It does this so you can put in different hardware with better/worse ADCs (8bit, 12bit) and the protocol doesn't change just the multiplier in the firmware.

 

Reducing resolution is valid in many circumstances (this is probably one), but you've reduced it to about 131 discrete values (approx 7bit resolution). The two primary (outside flight controls) for pots are light levels and volume. At 131 you might see the stair step changes for light levels, typically I try to keep PWM to 8bit (256 values). Also the way you've reduced resolution will create inconsistent behavior on the pot. Turning the knob fast allows for a lot of different values to be generated since as long as the value is past the 500 difference mark any value is valid. Turning the knob slowly only allows for the above mentioned 131 discrete value.

 

The point of a pot is to have an absolute mapping of position to output, otherwise an encoder is a better choice. The way I'd reduce resolution is just divide the raw reading (0-1023) by 4 to get a value between 0-255, which essentially drops the lower 2 bits of resolution. If that value is within 1-2 of the last time you reported just report the last value. Then multiply that by 257 to get it to the range 0-65535. This will filter out nearly the same amount of noise but give you 256 values instead of 131, and be more consistent with output values to position. If the potentiometer is generating more than 2bits of noise it really needs to be replaced.

 

In this case these difference might not matter a whole lot, but they definitely will for something like a trim wheel.

[FSFIan]

Yeah, DcsBios::Potentiometer is still the same naive get-the-example-done-in-five-minutes implementation that I originally crammed in.

 

I'll take a look at the links Gadroc posted and add a version with supersampling, EWMA and rate-limiting. I might have to order some 10K pots to test with, the ones I have in my junk bin are all from old audio equipment with values between 80K and 170K and generate a lot of noise. On the other hand, if I can get the 80K pot to behave with some filtering, we'll know this is the way to go.

 

Your description of the Signal Lights BRT - DIM switch sounds like it's time to write a DcsBios::RepeatingActionButton class as well.

[Boltz]

Hi Hans, nice work

 

Regarding the Signal Lights switch this is what I have on it:

 

Signal Lights Switch.

The signal lights switch (Figure 1-157), placarded SIGNAL LTS, is a two-position spring-loaded toggle switch, powered by the auxiliary DC essential bus that provides for either of two illumination levels, BRT and DIM, for warning, caution,and advisory signal lights, except for approach indexer and air refuel status lights. The warning, caution, and advisory signal lights are reset to bright automatically when the FLT INST lighting control is initially turned on. As the control is turned,the lights will return to dim. All signal lights are reset to bright automatically when the thunderstorm lights circuit is energized,or the signal lights bus power is lost.

 

There are only 2 brightness settings (Bright and Dim) but since the brightness is changed by turning on instrument lighting, a 3 position switch is used to prevent there ever being a mis-match between the physical switch position and the brightness of the signal lamps.

 

I'm going to incorporate this feature even though it will be a pain to setup and rarely touched but it will be a fun little addition.

[Hansolo]

Ian;3024038']Yeah, DcsBios::Potentiometer is still the same naive get-the-example-done-in-five-minutes implementation that I originally crammed in.

 

I'll take a look at the links Gadroc posted and add a version with supersampling, EWMA and rate-limiting. I might have to order some 10K pots to test with, the ones I have in my junk bin are all from old audio equipment with values between 80K and 170K and generate a lot of noise. On the other hand, if I can get the 80K pot to behave with some filtering, we'll know this is the way to go.

 

Your description of the Signal Lights BRT - DIM switch sounds like it's time to write a DcsBios::RepeatingActionButton class as well.

 

Uhhh that would be so nice Ian :thumbup: I am stretched beyond my limits so there is no way I'll be able to make that happen :cry:

 

 

There are only 2 brightness settings (Bright and Dim) but since the brightness is changed by turning on instrument lighting, a 3 position switch is used to prevent there ever being a mis-match between the physical switch position and the brightness of the signal lamps.

That makes good sense. I found a virtual tour in an A-model where you can clearly see that it stands in the middle position;

http://www.nmusafvirtualtour.com/media/072/A-10A%20Cockpit.html

 

You can also see how small the AN/ARC-186's are compared to in the 3D cockpit.

 

Cheers

Hans

Edited January 25, 2017 by Hansolo
Link corrected

[Direwolf5]

Here is the correct link to the virtual cockpit, the other one did not work.

 

http://www.nmusafvirtualtour.com/media/072/A-10A%20Cockpit.html

http://www.nmusafvirtualtour.com/media/072/A-10A%20Cockpit.html

 

Direwolf5

Edited January 25, 2017 by Direwolf5

[Hansolo]

Thanks Direwolf5. Corrected now :-)

 

Cheers

Hans

[Hansolo]

SAS Panel

 

Alright I finally decided to try and install my mag switches into my old poorly build SAS panel using DCS-BIOS.

Instead of using just one input for the ON position I decided to go for the advanced solution and use two inputs. One for Off and one for ON.

E.g.

const byte saspPitchSasLPins[2] = {PIN_0, PIN_1};
DcsBios::SwitchMultiPos saspPitchSasL("SASP_PITCH_SAS_L", saspPitchSasLPins, 2);

The mag switches I have has this feature build in as they have a change-over set of contacts.

The coil for the mag switch is energized by the LED output via a MOSFET semiconductor, with 24VDC as drive voltage

E.g.

DcsBios::LED saspPitchSasL(0x1108, 0x1000, PIN);

 

The Monitor Test switch is a MIL spec one but not the correct type. It’s set up for simple solution, i.e. only two inputs instead of three.

 

T/O Trim push button is an Otto with really nice feedback. T/O TRIM led and YAW TRIM are not connected at this point

 

Anyway this the a poor recording of it;

 

At the end you can see that I power down the APU which causes all the switches to de-energize. It does same if I remove power supplied from the main generators.

 

So far the only difference I have found comparing with mouse clicking in the 3D cockpit are this:

1. When there is no generator online mouse clicking will cause SAS mag switches to flip ON then instantly OFF. With the real mag switches they do not move at all in 3D cockpit. I do not see this as an issue

2. Should you by mistake set SAS switches on in 3D cockpit using mouse clicks then turning them on via hardwire will have the 3D’s go to off position. Not really an issue since I’ll use the hardwired ones.

 

Apart from this it appears to be working like what they do from 3D cockpit, however I need to do more extensive tests to see if I run into other issues.

 

Cheers

Hans

[rreznik]

Nice damn work there Solo! :D

[Gadroc]

So far the only difference I have found comparing with mouse clicking in the 3D cockpit are this:

1. When there is no generator online mouse clicking will cause SAS mag switches to flip ON then instantly OFF. With the real mag switches they do not move at all in 3D cockpit. I do not see this as an issue

2. Should you by mistake set SAS switches on in 3D cockpit using mouse clicks then turning them on via hardwire will have the 3D’s go to off position. Not really an issue since I’ll use the hardwired ones.

 

Great job! That nice pop when the switches turn off has to be satisfying. I took a quick look through the DCS Bios code to check on those behaviors.

 

1) This is normal and as you said not an issue. In sim the magnetically held switches gets two inputs, one when you click the mouse button and the other when you release it. No matter the state of the magnet it will hold the switch in the on position while the mouse button is held down. When you release the mouse button it will snap back to off if the magnet was not turned on. DCS Bios sends both event but sends them instantaneously in the same video frame so the switch never has a chance to be drawn in the on position.

 

2) This is a problem. The 3D view in the sim is the only one that matters. That is the position that the sim thinks the switch is in and represents how it will calculate things in the simulation. This is something that would have to be fixed in DCS-Bios, it would have to check switch position before sending events.

[EntropySG]

Bravo!

[Deadman]

Great work !!!

[Duckling]

Congrats Hans. Well done ! I still struggling with my codebase.

Can you confirm that the SAS Mags function works as intended both in start in cold and running cockpit ? (I got it working in a "running" state but in a cold pit, the mags state export is not working currently)

[Warhog]

Well done Hans. This was by no means an easy feat and I applaud your efforts. I haven't decided whether I will use magnetic switches yet. It's more of a cost consideration now that I am 95% retired. But time will tell.

 

Meanwhile, I am looking forward to seeing more of your cockpit as it unfolds.

[Hansolo]

Great job! That nice pop when the switches turn off has to be satisfying.

Oh yes that is so nice to hear that 'smack' when they all disengage :smilewink:

 

Congrats Hans. Well done ! I still struggling with my codebase.

Can you confirm that the SAS Mags function works as intended both in start in cold and running cockpit ? (I got it working in a "running" state but in a cold pit, the mags state export is not working currently)

Thanks a lot Duckling, yes I haven't found anything which works differently. Apart from the fact that the toggle in the 3D pit won't move if I try and put the mag switches in ON while there is no power. Bu as you can see from Gadroc's reply in posr #139 that is normal. I can try and make a small YT showing the different situation both using 3D toggle and the mag switches for comparrision. Please allow for a day or two for me to make it.

 

Well done Hans. This was by no means an easy feat and I applaud your efforts. I haven't decided whether I will use magnetic switches yet. It's more of a cost consideration now that I am 95% retired. But time will tell.

 

Meanwhile, I am looking forward to seeing more of your cockpit as it unfolds.

Thanks a lot Warhog, I hope to be getting a little more done this year than I have the past few. To be honest I haven't really done anything but utilizing DCS-BIOS. Yeah they are not cheap compared to regular toogle switches. I'd gotten mine in fairly decent prices but even at the extremely low prices currently then it's still $120 for 7 pieces.

 

 

All the best

Hans

[Hansolo]

Comparrision test between 3D toggle and real mag switches

 

Hi Duckling,

 

Sorry for the delay, but now I had some time to make a small YT clip showing the differences between 3D toggle and the real mag switches;

 

 

Quality is not super but I think you get the idea. I tried to test different scenarios;

1. Without power

2. With Battery ON

3. With battery and Inverter ON

4. With battery, inverter and APU ON

5. Monitor test

6. Loss of APU power

7. Running on main generators

8. Loss of main generators

9. Loss of engines

 

I ran the sim last week during training for serveal hours and the mag. switches got really hot on 24VDC. I didn't measure the temperature but when at sea we had a rule of thumb that if you could touch an item then it was less than 60º C. If it was too hot then it was above. Not fool proof but my estimate is that they were near 60ºC. Even the bat itself got hot.

 

I now run them off a 12VDC ATX PSU and now they are temperated. Hope you can use the YT otherwise let me know if there is anything else you want me to test. It'd be my pleasure.

 

 

 

Cheers

Hans

[Duckling]

You the Man Hans ! And surely Ian too :-)

That presentation was the best sim "porn" I seen in years. Thanks for taking the time to put it together.

I can't see any flaws in it and points to get my mags running with DCS:BIOS instead. Also that I need to review the power supplied config for the Mags (12V isn't sufficient for my Mags so I probably have some issues to solve there.

 

Striving for working Mags for so long I lost count :-)

Well earned rep inbound

 

Thanks to both of you

 

Cheers

Gus

Edited April 25, 2017 by Duckling

[MacFevre]

Hans,

 

That was... Man, that was beautiful! Absolutely incredible work. Here I am, still working on the physical portion of my pit, (new consoles, etc.) and I am simply humbled by your electronics work. Again, incredible job Hans.

[Hansolo]

Thanks guys. I wouldn't have been able to pull it off without advanced mode of DCS-BIOS :thumbup:

 

It's not too bad Mac. This is the seup I have used;

 

Q1 is a MOSFET. I have used an IFR510 but others may be better suited.

D1 is a flyback diode. I have used 1N4004

K1 is the coil of the magnectic toogle switch.

R1 is a pull down resistor.

X1-3 is output 3 of the Arduino using this

DcsBios::LED saspPitchSasL(0x1108, 0x1000, PIN);

 

X1-4 & X1-5 are inputs 4 & 5 to the Arduino using this;

const byte saspPitchSasLPins[2] = {PIN_0, PIN_1};
DcsBios::SwitchMultiPos saspPitchSasL("SASP_PITCH_SAS_L", saspPitchSasLPins, 2);

PIN_0 is off, and PIN_1 is on so in above example it should look like this;

DcsBios::LED sasp_PitchSasL(0x1108, 0x1000, 3);
const byte saspPitchSasLPins[2] = {5, 4};
DcsBios::SwitchMultiPos saspPitchSasL("SASP_PITCH_SAS_L", saspPitchSasLPins, 2);

 

Please notice that I the LED has been renamed from saspPitchSasL to sasp_PitchSasL. Otherwise it will not compiles; https://forums.eagle.ru/showpost.php?p=3111882&postcount=724

 

Full SAS code

/*
 The following #define tells DCS-BIOS that this is a RS-485 slave device.
 It also sets the address of this slave device. The slave address should be
 between 1 and 126 and must be unique among all devices on the same bus.
*/
#define DCSBIOS_RS485_SLAVE 5

/*
 The Arduino pin that is connected to the
 /RE and DE pins on the RS-485 transceiver.
*/
#define TXENABLE_PIN 2

#include "DcsBios.h"

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

//Right Pitch SAS
DcsBios::LED sasp_PitchSasR(0x1108, 0x2000, 3);
const byte saspPitchSasRPins[2] = {4, 5}; //off, on
DcsBios::SwitchMultiPos saspPitchSasR("SASP_PITCH_SAS_R", saspPitchSasRPins, 2);

//Left Pitch SAS
DcsBios::LED sasp_PitchSasL(0x1108, 0x1000, 6);
const byte saspPitchSasLPins[2] = {7, 8}; //off, on
DcsBios::SwitchMultiPos saspPitchSasL("SASP_PITCH_SAS_L", saspPitchSasLPins, 2);

//Right Yaw SAS
DcsBios::LED sasp_YawSasR(0x1108, 0x0800, 9);
const byte saspYawSasRPins[2] = {10, 11}; //off, on
DcsBios::SwitchMultiPos saspYawSasR("SASP_YAW_SAS_R", saspYawSasRPins, 2);

//Left Yaw SAS
DcsBios::LED sasp_YawSasL(0x1108, 0x0400, 12);
const byte saspYawSasLPins[2] = {14, 15}; //off, on
DcsBios::SwitchMultiPos saspYawSasL("SASP_YAW_SAS_L", saspYawSasLPins, 2);

DcsBios::Switch3Pos saspMonitorTest("SASP_MONITOR_TEST", 16, 17);

DcsBios::Switch2Pos saspToTrim("SASP_TO_TRIM", 18);

DcsBios::Potentiometer saspYawTrim("SASP_YAW_TRIM", 19);

DcsBios::LED takeOffTrim(0x1026, 0x0400, 13);
                                                                                                              
void setup() {
 DcsBios::setup();
}

void loop() {
 DcsBios::loop();
}

 

I think in next prototype board I will probably incorporate a small fuse to the 12VDC line for shortcircuit protection. Right now I have a small common 1A circuit breaker for all 12VDC.

 

Later I dream of designing a common board and then have it manufactured so it will be more compact than the prototype board I am using right now.

 

Cheers

Hans

Edited November 19, 2017 by Hansolo
Additional explanation, Full code added

[MacFevre]

Thanks Hans! Appreciate you sharing your finds and work. It makes it much easier for everyone, and I know it would take me forever to get back into that level of electronics again. Hard to believe I used to do it for a living! :D

[Hansolo]

LASTE & AAP

 

Slow but steady progress.

 

 

Managed to get a prototype of the LASTE panel up and running. The dimensions have been taken from the antenna panel as it looks like they are same size.

 

 

The light wasn't too good thus phones wasn't able to do a very good recording.

 

Also got the AAP up and running on the old poor panel layout. This time its running with correct switches for CDU and EGO PWR as well as STEER selection

 

Both are running DCS-BIOS over RS-485

 

Cheers

Hans