Experiments with stepper motor drivers for gauges

[lesthegrngo]

***** EDIT****

Please note that there is more information below, and due to changes in testing I have had to redo some of the tests to better reflect the actual stepping part in my second post. I will keep the original in there so people can see the progression, but the last post concerns some more empiric data that I hope will allow us to better understand the interrelation between DCS BIOS and stepper motors. Hopefully I don't bitch too much...:smilewink:

 

 

 

All, I had successfully made a load of gauges for my rig, and like a little kid I end up sitting in front of it every now and then playing with the throttles and so forth just to see the gauges all do their thing; it's rather compulsive!

 

However I am not completely happy with them, in as much that they don't move as smoothly as I would wish them to, and they are a bit noisy in action too.

 

I have a couple of setups currently, the changes of which are due to the evolution of the build.

 

When I first started I used Craig's great set of info he posted on his site to get me going, and as a result got myself the X27-68 stepper motors, and the EasyDriver stepper driver boards. My set of 12 engine and APU gauges all have that setup. They do work, however as mentioned I find them to be a bit jittery and noisy, but the biggest problem I had during development of the gauges was the sensitivity of the EasyDriver boards. I have them plugged directly into matching headers on the PCB's, which have headers for the (now unnecessary) Nanos and RS485 chips. Despite this relatively stable connection, I have four EasyDriver boards sitting on my desk that are no good. If the connection is not 100% they just blow, and they are irrecoverable.

 

I'd committed myself to the EasyDrivers for the engine gauges at an early stage, so as the large blank PCB's were not cheap (at least not here in Hungary) and the PCB's themselves quite a lot of work, I kept with them. I have them working and as documented on another thread was able to replace the Nanos with patch boards to allow me to connect all 12 gauges to one Mega. One advantage they have is that I don't have to connect the Arduino 5v and GND to them, the step and direction connections to each one is sufficient.

 

But they do have downsides. I've mentioned the jittery movement, the noise and the sensitivity but there is one other aspect that is a concern. They run hot, and I mean hot. I have left them connected for hours at a time to check them and they stay hot but don't cause issues, but I find myself being a bit nervous about it.

 

So during my development of the initial batch of gauges, I had a board I was using for testing blow, and as I still needed to do some testing but would have to wait for the replacement boards to come from China, I experimented with some A4988 boards I had as spares for my CNC router.

 

Straight out of the box I made the following observations

 

Firstly, the A4988 boards have a heatsink and when connected run a lot cooler. They are also smaller, with a pin layout that makes for a very solid connection using headers, although the heatsink makes them fractionally taller than the EasyDrivers. The other installation related issue is that due to the small form factor and close spacing of the pins I inadvertenly mis-connected it, and yet it continued to function, so is much more robust.

 

Once connected with the same sketch and stepper motor as for the EasyDriver, it was clear that the number of steps (maxsteps) needed for the A4988 is far less than for the EasyDriver in the basic setup. In function, once the steps were reduced to a correct value it seemed subjectively a bit smoother and a bit quieter. As a result, my subsequent designs have incorporated A4988 boards, and I will continue with this as I believe it to be better.

 

For info I briefly tried the AX1201728SG type stepper drive boards - actually they are surface mount chips I had to mount to adapter boards. Theoretically they are capable of driving four boards each and anecdotally provide very smooth operation for X27-86 type steppers using only a 5v feed, but I could not get them to work. Whether they were duff chips (bought from ebay) or that I damaged them mounting them to the adapter boards I can't say, but sadly I cannot give any info on how well they work.

 

But I did want to try and see if I could make the gauge movement with the A4988 drivers better, so today I played around with one using a trial gauge. One part of the stepper driver concept is that of microstepping, and I wanted to see if that would make a difference. There are three pins on the A4988 bords marked MS1, MS2 and MS3. Looking on the internet, there is a chart that shows the logic of the microstepping, so I used that to do some tests.

 

It may be obvious to many electronics engineers out there, but I had to look up what 'pull high' and 'pull low' meant on the charts, but thankfully it is as simple as pull high means connect to the input voltage (in this case 5v as output from the Arduino) and pull low means connect to ground.

 

So with a test circuit and some jumper leads I did some tests. I used the LENG oil pressure sketch (I'll attach in below when I can) that was being used on the main engine instrument panel as this was one that I could use with Bobobears testing software.

 

First up was it in unmodified form, and as expected the needle went full scale anticlockwise until it hit the internal stop, chattered there for a second or so then went full scale in the opposite direction to the opposing stop. In use with the diagnostic program, the max steps value made it impossible to use, so I dropped the max steps value down from 4900 to 400.

 

Immediately it was better, and the gauge ran within the 315 degree arc using the diagnostic program, but was still jittering in its movement and there was significant chattering sounds during operation. One characteristic that caught my eye was that sometimes during movement from low to high or vice versa when there was a significant change, the needle looked like it gets caught momentarily, with a distinct jerk in the movement.

 

Second up, I tried the intermediate steps of connecting MS1 to 5v (I was working on the assumption that if you do not connect relevant MS pin to 5v the internal wiring of the A4988 pulls it low).

 

With the pin connected, the gauge travel and speed became lower, and by no means smooth. If anything it seemed to be a more stop start movement. Changing the maxsteps value improved the travel, but the quality of the movement was still poor.

 

Connecting up MS2 decreased the travel and smoothness yet again, and when I connected all three MS pins, the movement was virtually eliminated (locically) until the maxsteps value was upped. With all three microstepping pins connected I could use a maxstep value of 10000, but the movement was painfully slow and gritty.

 

I then started playing with the acceleration and maxspeed values. In reality, these are much more powerful in their effect than the maxsteps value, and the microstepping levels. By increasing the maxspeed value, the movement became noticeably smoother up to a point. Beyond that point it degenerated again, as it seems that the pointer would move very fast, to a point where it would have to stop and wait for the command signal to catch up. The movement was horribly jerky. So it is clear that maxspeed is one where you can do too much. In my limited testing, Maxaccel needs to be increased in line with maxspeed, but whereas you can go too far with max speed, max accel seems to need to be high but seems indifferent to being set too high. Presumably the maxspeed value limits its effect. A point to note is that at the maximum microstepping setup the ill effects of too much maxspeed and maxaccel are attenuated, the problems are much more evident with lower microstepping.

 

In the end, once you have correctly set the three step values, there is not much difference when you use microstepping but it has shown me the following

 

The max steps value must be set as high as you can, but without the stepper going full range. Ideally it would be 99% of the max travel available

 

The intermediate microstepping levels are more susceptible to poor setups, and also seem to be prone to pointer bounce; fullstepping and max microstepping is more tolerant

 

Full microstepping does, when set up, give subjectively smoother movement, however it is not as much as I had hoped

 

The pointer seems to have more jitter at the moments of initial movement and when the pointer gets near the end of the commanded travel. I don't know if there is an in built algorithm in the accelstepper.cpp library that it uses, but it looks like when it starts to accelerate and slow down it loses control of the movement.

 

To conclude this, I have chosen to use the following parameters on my gauges where I can (ie those with A4988 boards)

 

sixteenth microstepping (all pins to 5v)

maxsteps set to circa 10000 dependent on individual calibration needs

maxaccel set to 6000

maxspeed set to 6000

 

I wish I could say I found a really good setup that eradicates the noise and jitter, but unfortunately all I could do was reduce it a bit, but hopefully this helps someone

 

Cheers

 

Les

Edited June 4, 2020 by lesthegrngo

[Lobinjaevel]

Great write up, fantastic progress!

 

Would a TMC2209 driver help with the noise? I don't know anything about gauges for cockpits, but the newest 3d printers with those driver are very silent. See Creality CR-6

 

Cheers

[No1sonuk]

I've been reading about the X27s recently, and there's some debate about the drive sequence.

 

As I understand it, while they can be connected directly to an Arduino, the Arduino libraries can only generate 4-state, full-step sequences. The datasheets, however, show a 6-step sequence.

Some people say the 8-state half-step sequences work better than full step.

 

I got some A4988s on your recommendation, and will be playing with them soon.

 

As for the noise: Turn up the engine sound. ;)

[lesthegrngo]

There was one thing I forgot to mention when I was writing this. I'd seen it but filed it away for a subsequent check, and went back to it this morning as it had been nagging at me.

 

The diagnostic software allows you to choose the input value via a slider between 0 and 65335, emulating what the game output sends to DCS BIOS. When you look at my maxsteps value in my final setup, logically and mathematically, for each 7 steps or so, you should get one microstep of movement. You can increment the slider value by one by clicking on the right hand side of the slider button.

 

In actual fact, it does not behave like this. What I found was that it took 27 steps before you got any pointer movement, repeatably.

 

So with that in mind, I did a few more tests, with the following results

 

@ 400 maxstep, fullstep with 1200 maxspeed 12000 maxaccel it needed 164 units for pointer movement

@ 800 maxstep, halfstep with 1200 maxspeed 12000 maxaccel it needed 84 units for pointer movement

@ 1600 maxstep, quarterstep with 1200 maxspeed 12000 maxaccel it needed 164 units for pointer movement

@ 3200 maxstep, eighthstep with 1200 maxspeed 12000 maxaccel it needed 41 units for pointer movement

@ 6400 maxstep, sixteenthstep with 1200 maxspeed 12000 maxaccel it needed 103 units for pointer movement

@ 10000 maxstep, sixteenthstep with 1200 maxspeed 12000 maxaccel it needed 7 units for pointer movement

 

So while there is some linearity in some of those results, it's not a direct rate

 

As a result I wondered what the difference would be changing the maxspeed and maxaccel values

 

So, keeping with sixteenthstepping these are the results

 

@ 10000 maxstep, sixteenthstep with 6000 maxspeed 12000 maxaccel it needed 20 units for pointer movement

@ 10000 maxstep, sixteenthstep with 12000 maxspeed 12000 maxaccel it needed 33 units for pointer movement

@ 10000 maxstep, sixteenthstep with 6000 maxspeed 6000 maxaccel it needed 27 units for pointer movement

@ 10000 maxstep, sixteenthstep with 500 maxspeed 12000 maxaccel it needed 20 units for pointer movement

@ 12000 maxstep, sixteenthstep with 6000 maxspeed 12000 maxaccel it needed 82 units for pointer movement

@ 12000 maxstep, sixteenthstep with 6000 maxspeed 6000 maxaccel it needed 22 units for pointer movement

 

So again, a very non-linear relationship apparently, and affected by all three parameters. I am not a mathematician, and don't intend to start to be now, but my feeling is that there is probably a direct relationship between the three numbers that means that some will divide better than others. It's probably some computer type number like 128, 256, 512, like memory counts or something. I'm not clever enough to know.

 

I also have to say that at least visibly I could not see any obvious relationship between the step value and pointer movement smoothness. However it is entirely possible that when the figures are all set correctly that it reduces mismatches and therefore makes for more accurate movement.

 

So I hope that there is someone out there that can use this or at least shed some light on why it behaves the way it does, it would be good if we had a way of empirically determining the best settings for the gauges

 

Cheers

 

Les

[lesthegrngo]

Back again after an evening pondering yesterdays results. The non linearity of the results bugged me so I starting wondering if I had actually collected enough test points to make a proper sample for each case, and maybe was distorting the results.

 

As a result I went back and redid 9 of the tests, and repeated them so that each one reflected ten separate pointer steps, in other words I kept clicking on the slider adding one unit until I had ten repeatable pointer movements. Each movement is small, and mostly detected by listening for the faint click, rather than having some fancy measuring equipment.

 

I had read somewhere that input cadence can have an effect on whether a step can be missed or not, so to counter this, I made sure that I clicked at as near a constant rate as I could, and I repeated the tests to make sure that they movements occurred in the same points. I would like to tell you it was interesting but it did get a bit tedious! For reference the last five tests using the progressively increasing microstepping value was conducted at 1200 max speed and 12000 max accel.

 

So the first discovery was that depending on the microstepping rate, the behaviour of the stepping changed dramatically.

 

For full stepping and half stepping, the steps were equally spaced, and matched the theoretical mathematical step ratio. So, for 400 steps at fullstep mode, mathematically it should be 163.34 per step, and I was getting 164, and 800 at half stepping is 81.67, and I was getting 82. So they correlate almost perfectly

 

But once you get beyond halfstepping, the picture changes. What I found was that the step spacing was not even, so for instance at quarterstepping, with 1600 steps, mathematically each step is 40.83 units. What you actually get is a step at 41 units, then a gap of about 122 units to the next step, equating to 3 times the step value, then 41 units to the next step, then 122, then 41 and so on. So essentially, it does a step, step, miss, miss, step, step, miss, miss repeating sequence

 

That is also the case for eighthstepping, mathematically it should be 20.42 per step, but again you get the repeating step, step, miss, miss pattern

 

Once you get to the sixteenthstepping, it changes yet again, as it goes to a two step, 14 miss repeating pattern. Mathematically it should be 10.21 per step, but in reality you get two steps about 10 units apart then a gap of about 140 units until the next step.

 

I have no idea whether this is correct behaviour, but in concept it seems that something is not correct. It may go some way to explain why despite microstepping being theoretically smoother, it does not give those benefits in practice.

 

For me, I would like to see why the microstepping is not using even steps and how the spacing of the steps is defined. I am going to try and get some advice on this behaviour, but if anyone has any thoughts as to why this is happening I would like to hear from you. I have one parting thought - I am assuming that it is the stepper driver controlling this, and it is not a characteristic of the stepper motor, as I assume the motor just does what it is told and the microstepping is all set by jumper pins on the A4988 driver. The Arduino and stepper cannot influence the microstepping, can it?

 

Cheers

 

Les

Edited June 4, 2020 by lesthegrngo

[No1sonuk]

That would kind of correlate with the datasheet suggesting half-stepping.

Maybe the design of the motor doesn't guarantee linearity beyond half-stepping. After all, they're not built like the NEMA motors, and in their intended application, do they really need more than half stepping?

[lesthegrngo]

Yeah, maybe I need to be a bit more thorough looking at the halfstep settings, see if they can be refined.

 

Considering the irregular stepping of the 16th stepping settings, it's pretty amazing that it is as smooth as it is

 

Les

[BoboBear]

I've also been looking at using X27 type car instrument steppers. From what I've read, their step requirements are a little different and I'm not sure the normal H bridge stepsticks are the way to go.

 

I found this website pretty helpful

 

https://guy.carpenter.id.au/gaugette/resources/

 

And found the driver chips on AliExpress

 

https://www.aliexpress.com/item/32548458025.html?spm=a2g0s.9042311.0.0.1fc14c4dN49EPU

 

These seem to drive these steppers pretty well (and bonus of 1 chip drives 4 steppers)

[lesthegrngo]

Yeah, I read the same article which is why I got some of the AX1201728SG chips - couldn't get them to work, which is a shame, as it would have been interesting to see if there was any difference

 

I still have three of them so maybe will have another go, but maybe the chips I got were no good

 

Cheers

 

Les

[lesthegrngo]

I have finally got the AX1201728SG chips working. A batch of five of them were bought from a German supplier, after the first couple of attempts using Ebay sourced items got nowhere. Once soldered to the SOP/SSOP to DIP Adapter boards I had previously bought, I was able to fire up the stepper with some test sketches.

 

However once I put in the DCS bios sketch (a test one using MiddleFart's sketch as a basis) while it would work in the game, it did not change the quality of movement measurably by eye. Now, I know this is early stages yet, as I haven't tried to play around with the settings in the sketch, and I need to sit down and try to understand how I am going to dovetail in the advanced controls to allow that. However what doesn't help is that for some reason the diagnostic program BoboBear produced doesn't work with this at the moment, so I am unable to do any empiric back to back tests

 

This is the test sketch

 

#define DCSBIOS_IRQ_SERIAL


#include "SwitecX12.h"
#include "DcsBios.h"

const int RESET = 10;

const bool InitToMax = true;

struct StepperConfig {
unsigned int MaxSteps;
unsigned int MinSteps;
unsigned int StepPin;
unsigned int DirPin;
unsigned int MaxAdjustment;
unsigned int MinAdjustment;
};



struct StepperConfig LeftFuelFlowConfig = {
3780, //315 degrees * 3 steps * 4 microsteps;
0,
8,
9,
0,
10
};



class X27Stepper : public DcsBios::Int16Buffer {
private:
SwitecX12& stepper;
StepperConfig& stepperConfig;
unsigned int (*map_function)(unsigned int);
unsigned char initState;
public:
X27Stepper(unsigned int address, SwitecX12& stepper, StepperConfig& stepperConfig, unsigned int (*map_function)(unsigned int))
: Int16Buffer(address), stepper(stepper), stepperConfig(stepperConfig), map_function(map_function), initState(0) {
}

virtual void loop() {
if (initState == 0) { // not initialized yet
digitalWrite(RESET, HIGH);
stepper.zero();
initState = 1;
}
if (initState == 1) { // zeroing
if (stepper.stopped) {
if (InitToMax)
stepper.setPosition(stepperConfig.MaxSteps - stepperConfig.MaxAdjustment);
else
stepper.setPosition(stepperConfig.MinSteps + stepperConfig.MinAdjustment);
stepper.update();
initState = 2;
}
}
if (initState == 2) { // running normally
if (hasUpdatedData()) {
unsigned int newPosition = map_function(getData());
newPosition = constrain(newPosition, stepperConfig.MinSteps, stepperConfig.MaxSteps);
stepper.setPosition(newPosition);
}
stepper.update();
}
}
};


SwitecX12 LeftFuelFlowMotor(LeftFuelFlowConfig.MaxSteps, LeftFuelFlowConfig.StepPin, LeftFuelFlowConfig.DirPin);


X27Stepper LeftFuelFlow(0x10ae, LeftFuelFlowMotor, LeftFuelFlowConfig, [](unsigned int newValue) -> unsigned int {
return map(newValue, 0, 65535, LeftFuelFlowConfig.MinSteps + LeftFuelFlowConfig.MinAdjustment, LeftFuelFlowConfig.MaxSteps - LeftFuelFlowConfig.MaxAdjustment);
});


void setup() {
pinMode(RESET, OUTPUT);
digitalWrite(RESET, HIGH);
DcsBios::setup();

}

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

}

 

If anyone wants to weigh in with suggestions for improvements to this, please feel free, as usual anything I find out or try will be reported here so that people can learn from my mistakes!

 

Les

[lesthegrngo]

Following on from this, I did a test yesterday using four X27-0168 steppers, each driven by an Arduino Nano via (respectively) an EasyDriver board, an A4988 driver board, the AX1201728SG driver and finally directly driven by the Nano. All were set with the DCS BIOS sketch for the APU temperature so that I could see how they performed with the different drivers at the same time. The result showed them all acting almost exactly alike, crucially including the jitters. At low pointer speed, they all virtually simultaneously stepped from one position to another, stopped together then stepped again. The steps were large relative to what the stepper motors are capable of.

 

As a result, I am now sure that the pointer movement quality is driven by the output from DCS BIOS rather than the interaction between the stepper motor and driver or Arduino and driver. Even the addition of a smoothing algorithm made no difference at the lower speed due to the slow position refresh rate. So I have come to the conclusion that in order to improve the quality of the movement, my focus has to be now directed towards what is actually being transmitted by DCS BIOS, and at what rate. If the requested rate of change is not sufficiently fast, then as the stepper is capable of moving faster than the rate of position change, then it will move to the new position, stop and wait for the next change.

 

If there is anyone in the community that is reading this that can comment of how to increase the data transmission rate, or position refresh rate I would like to know about it. I have looked through all the sketches I have used and cannot find any references to timing delays or such like in the ones for gauges, although I have seen them in ones for OLEDs. I remember seeing some expressions like Serial.begin(250000); being included in the void setup section, which I assume is something to do with the communication speed, however trying to splice into the current code just results in an error.

 

So, the big question is what can be done to increase the data refresh rate for the gauge movement?

 

Les

[Chuck1606689488]

Hey guys.

Im really stuck generating code for vid-28-05 stepper with 2x easydrives for A10c fuel gauge. Can you help?

[lesthegrngo]

What bit are you stuck with? I have sketches for the fuel gauge using X27 gauges, I can't imagine it would be too different? 

 

Les

[Chuck1606689488]

Hey Les!

I dont know whether they would be way different. But i would appreciate if you could share yours.  Maybe from there we can work it out to a functional panel.

 

I tried with John Hall example and tried to modify it. But the motor did 3x loops  and desperately tried to do 315 degrees.... So no logic behind the actual gauge in the game

 

#define DCSBIOS_IRQ_SERIAL
#include <MotorVID28.h>
#include "DcsBios.h"

int smDirectionPin = 8; //Direction pin
int smStepPin = 9; //Stepper pin
int TotalSteps = 180;
MotorVID28 motor1(20*4, 6,7,8,9);

  void onFuelQtyLChange(unsigned int newValue) { //the value we get from "onFuelQtyLChange" is placed in the variable "newValue" for us to use. 
  motor1.setPosition(map(newValue, 0, 65000, 0, TotalSteps)); //Here is where we are remapping the 475 steps to the total steps that are being exported.
}
DcsBios::IntegerBuffer fuelQtyLBuffer(0x10ca, 0xffff, 0, onFuelQtyLChange);

void setup(){
  /*Sets all pin to output; the microcontroller will send them(the pins) bits, it will not expect to receive any bits from thiese pins.*/
  pinMode(smDirectionPin, OUTPUT);
  pinMode(smStepPin, OUTPUT);
 
  DcsBios::setup();

}
 

void loop() {
  DcsBios::loop();
  motor1.update();

}

[lesthegrngo]

Hi

 

This is a development of Craig's stepper motor sketch that works, although you will have to play with the stepper config part to get the gauge moving in line with your own unit

 

#define DCSBIOS_IRQ_SERIAL

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

struct StepperConfig {
  unsigned int maxSteps;
  unsigned int acceleration;
  unsigned int maxSpeed;
};


class Vid29Stepper : public DcsBios::Int16Buffer {
  private:
    AccelStepper& stepper;
    StepperConfig& stepperConfig;
    unsigned int (*map_function)(unsigned int);
    unsigned char initState;
  public:
    Vid29Stepper(unsigned int address, AccelStepper& stepper, StepperConfig& stepperConfig, unsigned int (*map_function)(unsigned int))
    : Int16Buffer(address), stepper(stepper), stepperConfig(stepperConfig), map_function(map_function), initState(0) {
    }

    virtual void loop() {
      if (initState == 0) { // not initialized yet
        stepper.setMaxSpeed(stepperConfig.maxSpeed);
        stepper.setAcceleration(stepperConfig.acceleration);
        stepper.moveTo(-((long)stepperConfig.maxSteps));
        initState = 1;
      }
      if (initState == 1) { // zeroing
        stepper.run();
        if (stepper.currentPosition() <= -((long)stepperConfig.maxSteps)) {
          stepper.setCurrentPosition(0);
          initState = 2;
          stepper.moveTo(stepperConfig.maxSteps/2);
        }
      }
      if (initState == 2) { // running normally
        if (hasUpdatedData()) {
          unsigned int newPosition = map_function(getData());
          newPosition = constrain(newPosition, 0, stepperConfig.maxSteps);
          stepper.moveTo(newPosition);
        }
        stepper.run();
      }
    }
};

/* modify below this line */

/* define stepper parameters
   multiple Vid29Stepper instances can share the same StepperConfig object */
struct StepperConfig stepperConfig = {
  500,  // maxSteps
  1000, // maxSpeed
  1000 // acceleration
  };

// note cs im testing with 11 going to step (middle on easy drier) and 10 doing to direction (right on easy driver)
// cs so in the code going on the basis that the first named number is step and the second is direction
// define AccelStepper instance
AccelStepper stepper(AccelStepper::DRIVER, 11, 10);
// define Vid29Stepper class that uses the AccelStepper instance defined in the line above
//           +-- arbitrary name
//           |   +-- Address of stepper data (from control reference)
//           |   |       +-- name of AccelStepper instance
//           v   v       v        v-- StepperConfig struct instance
Vid29Stepper fuelQtyLBuffer(0x10ca, stepper, stepperConfig, [](unsigned int newValue) -> unsigned int {
  /* this function needs to map newValue to the correct number of steps */
  return map(newValue, 0, 65535, 0, stepperConfig.maxSteps);
}); 


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

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

 

Have a go and see if it works as is

 

Les

[DH14300]

A few years ago I invested in about $2000 worth of Flight Illusion gauges and use them with P3D and X-Plane. Does anyone know how or where I might find someone who might be able to create a software interface to drive them?

[lesthegrngo]

What are the interface types? USB, four pin connections? Any details you can give would help

 

Cheers

 

Les

[bnepethomas]

The Flight Illusion controller card uses a virtual serial  port - I found this document from many years ago - unfortunately I could find much else

/*

00 Start of frame
65 Device ID 101 – 65 Hex

Data
0 01 02  = 0
3 f5 13   = 5109 
2 31 4e  = 20016

4   Set Attitude Command

FF End of Frame

0 01 02  = 0
3 f5 13   = 5109 – 13F5
2 31 4e  = 20016 – 20017

MSB is +ve negative bit.
Commands for Flight Illusion Gauges

  Byte 1: Flag byte:&h00
  Byte 2: Address: 1-255; address zero forbidden!
  Byte 3: Command byte: Bit 3 always "1": CCCC.1SHL 
          H & L are the data bits to "repair" the "forced to one bits" in 
          byte 4 & 5), S= sign bit of the integer value)
          CCCC is the 4 bits command(0001-1111, so 1-15)
  Byte 4: Data Low; &h00-&hFF;  bit0 always 1 : XXXX.XXX1 -> XXXX.XXXL
  Byte 5: Data Hight:&h00-&hFF: bit1 always 1 : XXXX.XX1X -> XXXX.XXHX
  Byte 6: End byte:&hFF

Altimeter

Commands:
0= noop
1= Initialize
2= Set Instrument Address; Value 0-&hff (odd addr. only),second byte:&HAA
3= Set Scan frequency (Needle Speed)
4= Set Altitude (-9999 to + 50000)
5= Set AirPresure mode (byte1: 0= Inches HG, 1= Milibar), byte2:0=no connection, 1=connected to altitude)
6= Set Needle zero displacement; Number of steps between sensor and needle
7= Send info about instrument; Reply &h00, Address, Type, Model, Version, Airpressure
8= Switch lights: Low byte= DL00.0000; D=display on/off, L=light on/off
9= Set Instrument Model &Version, Low Byte=Model, High Byte=Version
10= Write an EEPROM byte (Blocked; is for debug only)
11= Direct Needle Control (0 to 1079); Sets needle independent from altitude
12= Set Airpressure value
*/