The wrap up 'to do' list

[lesthegrngo]

You will see in other threads that my rig is basically 99% finished, but it is the final 1% that will make the difference between a cool DIY project and a really useable flight simulator rig. That 1% can often be a lot of work, or difficult, or both, but it needs to be done. So, as I see it these are the issues that need to be resolved for this to be right. Apart from the first item, they are in no particular order of importance, but are all issues that detract from the experience.

Firstly and most importantly, the Altimeter. The one I made works OK in USB mode but doesn't want to know in RS485 mode. I need to redo this it is a critical instrument. I do have the digital OLED version that works perfectly so the fact that the physical needle isn't working is not a show stopper, but I want that to work. If anyone has a solution that preferably works with RS485 I am interested to know about it, My current version used an X27 stepper with the rotation limiter removed, an IR sensor and amplifier circuit and a slit cut into the gauge face matching a reflective needle for 0 homing. I'm not married to it, and am open to alternative ways, although clearly not having to procure any other hardware would be preferable

RS485 glitching - I have noticed that when I connect more slave devices to an RS485 slave line, it becomes more prone to glitching, The way it manifests itself depends on the device.

• With stepper driven gauges they flick full scale as if the Nanos are being momentarily depowered.
• With OLED devices they will stop displaying the data, or corrupt the data being shown, then come back to the correct date. 
• The CLP will show random lights 
• Devices with warning lights will have the warning light illuminate randomly
• Switch panels sometimes don't register the switch movement

All these devices work perfectly in RS485 on their own, and very often with other devices connected to the same line. However add one more and the glitching starts. I have to assume my circuit design is at least part of the issue, there's probably some filter capacitors or suchlike that I should have included but didn't. For info I run one Mega with three slave lines

Switch polling on connection - I did try this, but fell flat on my face. While not devastating it isn't perfect to have the sim start and you can see the physical mismatch between the on screen state and the rig switches. Some will never be able to be set (undercarriage lever anyone?) so there is a limit but I would like to be able to synchronise everything that can be

Batch Com port initialisation - I have the Mega, and four ESP32 devices that all need com ports starting before game start. I would be good to automate that

OLED device display issues - this is different to the glitching quoted above. This is where my sketches are probably not optimally coded due to differences in the way libraries work or some compromise in the design (like having to rotate the orientation of OLED displays). As a result I get artefacts on the screens, like instead of a decimal point a partial number, or in another instance where the number that appears is not centered correctly

Switch cross read - not a huge issue but a bit irritating, this is where you operate one switch and two switches move at the same time, one that is correct and another on the same panel that isn't. A good example is the YAW SYS switches, where the L YAW SYS switch will toggle both the L and R switches. I suspect this is something corrupted in the Arduino libraries when I compile

BCD switches refusing to work with RS485; the IFF BCD switches just refuse to play with RS485, which frankly is a minor issue as I am nowhere near competent to use them in game! Nonetheless with time I will get to the bottom of it.

I also noted that the left MFCD has a couple of switches that are duff, which I suspect is either dry joints or a damaged PCB, where I may have had a trace lift during soldering

So, quite a list of things to slowly knock off, if anyone has any input I'm keen to hear!

Les

[agrasyuk]

Work never ends, yes.

Batch Com port initialization: SOCAT has the multi com port batch file, just write in the numbers of your ports. Literally a minute time to do.

Switch sync on startup. I tried this and it caused more problems that it's worth. Was troubleshooting issue with HUD that wouldn't show. Took ages and a lot of frustration until I realized the AHCP day/night switch was causing it. For now I just set switches back after every flight (I don't usually do full proper shutdown)

OLED artifact display issue sounds like communication issue. The same that is causing jittery analog gauges.

good luck. You will get there

 

[No1sonuk]

Batch com port initialisation:

There's the multi com port .bat as mentioned above, but you might be able to write a version that will also trigger DCS after doing the socat things.

[Bucic]

@lesthegrngo Could you please post the link to the main project thread?

[lesthegrngo]

Sure, here you go

 

Les

 

[Bucic]

@lesthegrngo Thanks. I already follow this one

[lesthegrngo]

Thanks for the responses guys, let me check into that SOCAT thing

 

Cheers 

Les

[lesthegrngo]

Is there a guide on how to use the SOCAT? I've found the the SOCAT folder in the scripts / programs next to the com connect that I currently use, and there is an examples text file but it seems to be written in Martian.....

Cheers

 

Les

[Vinc_Vega]

I'm interested too.

Regards, Vinc 

[lesthegrngo]

I posted in this thread 

 that I had solved the glitching issues by the simple use of an additional master Mega. I have to report that it has also (apparently, subject to more extensive testing) seemed to get rid of the display corruption and artefacts, random warning light illumination, gauge flickering, and also more surprisingly the switch crosstalk issues. I no longer get another switch being activated when one near it is moved. The SAS panel was particularly bad, but now behaves perfectly

As a fix it was really good value for money, as it really has in one go removed a load of the issues. the only down side is it has increased the need for the SOCAT as I have to initialise 6 com ports on startup

So, now on to the Altimeter, as this is the biggest fail yet to be fixed. 

Les 

[lesthegrngo]

Those little details can bite..!

I got the biggie, the Altimeter all sorted, complete with the Pneu / Baro settings encoder and switch, so started to sort some of the other minor issues that needed finishing. I needed to connect up the ADI pitch trim adjustment encoder, plus the two encoders for the HSI course and heading set. No problem, just add those to one of the existing nanos and away we go, right? Nope, I got put through the wringer by those. Boy are they picky about what pins the encoders are connected to. The ADI was less fussy that the other two, but the course and heading set could not be used with pins 7 through 13, and for the course set seemingly 14 through 17 on my Nanos. I tied various Nanos and it was repeatable, I checked the hardware to make sure it was not a duff encoder etc, and eventually got them to work with the following sketch

//#define DCSBIOS_DEFAULT_SERIAL
//#define DCSBIOS_IRQ_SERIAL

#define DCSBIOS_RS485_SLAVE 101
#define TXENABLE_PIN 2

#include "DcsBios.h"

#include <SPI.h>
#include <Wire.h>



 DcsBios::RotaryEncoder adiPitchTrim("ADI_PITCH_TRIM", "-3200", "+3200", 8, 7); //was 8 7

DcsBios::RotaryEncoder hsiCrsKnob("HSI_CRS_KNOB", "-3200", "+3200", 6, 5); //was 9 10

DcsBios::RotaryEncoder hsiHdgKnob("HSI_HDG_KNOB", "-3200", "+3200", 18, 19);  // was 5 6

DcsBios::LED markerBeacon(0x10da, 0x0002, 10);

DcsBios::LED gunReady(0x1026, 0x8000, 11);

DcsBios::LED canopyUnlocked(0x10da, 0x0004, 9);

DcsBios::LED nosewheelSteering(0x10da, 0x0001, 12);

void setup() {
  
   DcsBios::setup();

 

}

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



  
}

I have no explanation as to why the wouldn't work - when you used any other pins, rotating the encoder would make the in game item tremble, but not move. I literally had to go through trying a pin pairing one at a time until I found ones that reliably worked. 

Anyway, done now, on to the next bit

Les

Edited October 10, 2023 by lesthegrngo