Question Full dropouts, one flap, Oscillation. Stops working mid game.

Hi guys

At first i wrote this off as some flukes but its becoming more and more of a nuisance. Its happening far to often. Everthing seems highly unstable.

At first, 2 was connected to a usb hub. Next, all Ardunios have their own cable directly into the computer via usb2 into usb 3 on comp.

x2 Ard + Sabertooth 2x32 back and bottom.
1x Ard + China 50 amp bridge. Belt tensioner

One flap will stop working. Need to go to SMC to get them back
Both flaps will stop working. Need to go to SMC to get them back

Backrest flap will oscillate, either right or left side, it varies. This only happens in the back where i have the hall sensors. So i suppose it has something to do with that but the mounts are very solid and ive put a 5 DZ in the SMC app. This can happen even when the flaps has been power off all session and then being turned on straight into oscillate. thats the strange part. If they didnt i would just have left it to vibrations and overshooting.



I have tried adding interface output to 15 MS for the backrest. No real change.

I have a usb disconnect/connect log. Nothing happening there.
I have watched the SMC graphs for quite some time and cant see any spikes that can result in it shutting down the axis.

Im at loss as to why this is happening and what i can do about it now.

Is there any logs?
Is there any way to test the different things that i can do to troubleshoot?

As far as I know this can only mean you're overshooting your set max limits.

Are you using soft start and have you attempted using a longer setting by increasing SSloop?

How much resolution do you have on your pots now with the added pulleys?

Overshooting the limits was also my first thought and i forgot to mention this. It can be working fine, i quit the game and go back in an hour or whatever time later and for the most part it wont work and i have to go trough the SMC routine for 3 interfaces again.

I am using the SSLoop sketches but i havent tried any softstart setting yet. I will see if they have an impact on stability when its all up and running but its doubtful.

For the resolution i have 90% use in axis limit for the hall sensors backrest and limit at 0 in SMC. 40% for my belt tension and 35% for the bottom ones. All of them suffer from the same dropout issue.

Not sure, ive reduced the hall sensors quite a bit but could go a bit further on PWMmax. the rest are as low as i can go for the oscillation. It's a minor issue really as the dropouts are far more frequent. Im actually going back pots and will try to find some good 180 degree ones which should clear this for good.

If you try this keep in mind it only works once when the arduino is started or when reset.

In the mean time I've noticed halls will fluctuate more when they don't receive a strong 5v. Check your soldering and make sure you don't have any "cold" joints. Another thing you can try is powering the pots from the Sabertooths 5v power output instead of from the arduino. It can supply 1a vs. arduino .5a and its not powering other stuff too like the arduino itself.

Ive managed to sort this out 95%

For the bottom its now solid. Ive reduced softstart to 0 in the sketch and for the sabertooth in describe.

For the back im still tuning and it seems to be some kind of information overload that makes it kick out and stop working. The best results are if i reduce the heave to 10% axis and keep 60% sway 30 surge. The surge can however still cause it to stop if i slam the brakes on the car or cause some sort of spike. Im guessing it just cant react fast enough and perhaps dependent on the load on the motors aswell as the bottom ones are rock solid with very fast movement over bumps. So much so that ive slightly sick in VR for the first time in a year.

On a side note the hall sensors are very noisy so that can have an effect. Ill be trying pots tomorrow.

Ill keep trying and post all my settings once i have sorted it out completely.

Just fyi hall pots are contactless so technically they are noiseless. What you do have though is hysteresis which can cause up to .2% drift (on magnepots) that looks like noise. My experience shows that hysteresis is larger when the hall sensor is under powered or has a fluctuating input voltage which is what lead to my recommendations in my earlier post.

Its what i understood to which is why i was very puzzled by the noise in the graph. it also makes the motor quite noisy. Not that its and issue. Its actually greater when connected to the sabertooth 5v output but i suppose its the drift that you mention.

Some screened cable and cap filtering may help. Pictures below are from one of my Hall feedback sabertooth 2 x 32's with Zero dead zone and a deadzone of 2. Everything is powered up.

Been trying to figure this out but it seems to be somewhat impossible. I have gone back to pots so i can rule out any noise etc.

For racing it can seem fine for one track but on the next with less bumps it will break. The bottom ones that i thought was rock solid has also stoppen on occation.

It can also stop working in DCS world with just slow forces applied. It makes no sense at all. What it also odd is that one force can stop working but the others still work but they are being hindered/counteracted with the broken force. If it was a HW issue i would think it would either work or not work. I am using the Softstart beta8 sketch.

Honestly im just about giving up on the whole thing.

Code:

void ReadEEProm()
{
    int evalue = EEPROM.read(0);
    if(evalue != 114) //EEProm was not set before, set default values
    {
        WriteEEProm();
        return;
    }
    CutoffLimitMin1 = 350;
    InputClipMin1 = 500;
    CutoffLimitMax1 = 900;
    InputClipMax1 = 800;
  
    DeadZone1=EEPROM.read(5);
    CutoffLimitMin2 = 350;
    InputClipMin2 = 500;
    CutoffLimitMax2 = 900;
    InputClipMax2 = 800;

    DeadZone2=EEPROM.read(10);
    Kp1_x100=ReadEEPRomWord(11);
    Ki1_x100=ReadEEPRomWord(13);
    Kd1_x100=ReadEEPRomWord(15);
    Kp2_x100=ReadEEPRomWord(17);
    Ki2_x100=ReadEEPRomWord(19);
    Kd2_x100=ReadEEPRomWord(21);
    PWMoffset1=EEPROM.read(23);
    PWMoffset2=EEPROM.read(24);
    PWMmax1=EEPROM.read(25);
    PWMmax2=EEPROM.read(26);
    PWMrev1=EEPROM.read(27);
    PWMrev2=EEPROM.read(28);
    PWMrev3=EEPROM.read(29);


    CutoffLimitMin3 = 350;
    InputClipMin3 = 500;
    CutoffLimitMax3 = 900;
    InputClipMax3 = 800;

    DeadZone3=EEPROM.read(35);
    Kp3_x100=ReadEEPRomWord(36);
    Ki3_x100=ReadEEPRomWord(38);

    Kd3_x100=ReadEEPRomWord(40);
    PWMoffset3=EEPROM.read(42);
    PWMmax3=EEPROM.read(43);
    Ks1=ReadEEPRomWord(44);
    Ks2=ReadEEPRomWord(46);
    Ks3=ReadEEPRomWord(48);

After spending 2 full days tweaking axis and smoothing for each ive finally come to a setup thats 95% there and rarely drops out.

Ive ordered some ferrite magnets and shielded wire in the hopes to get things even better. Like mentioned once im sure ill be including all settings and probably do a writeup in my build thread of all parts used and upload all the current profiles.

Did you ever figure out this issue? When it happens to you do you get a funny rattling frequency from the motor? I'm having similar issues. However it is intermittent and hard to diagnose. I have thought I had it fixed several times. I have checked and rechecked wiring, pots, solder joints, added ferrites, tried a different arduino, changed ports, and a different sabertooth, as well as SMC3 kp and kd changes, axis smoothing and DOF changes. I'm about to add a battery in hopes it is an issue with the PSU. The only other thing I can think of is that my #2 motor is gong bad as that seems to be the one dropping out.

Apologies for the late reply. been on vacation.

The oscillations have mostly been due to spiking i think and i still have not been able to sort this out properly. Im at a point now where im going to re design my setup and make sure no pot signal wire is anywhere near the power wires or psu's and see what happens then. Its really the only thing left to do.

I might have a possible solution for you, See my thread here: https://www.xsimulator.net/community/threads/help-to-diagnose-2dof-crash.13639/

2 People with very similar problems, followed BlazinH's suggestion in the thread with directions to change baud rate fixed the problem.

Thanks man, this seems to have solved it! (knock on wood) I was real close to just giving up on the whole thing.