i used the drawing app in google docs.

Originally Posted by wjs

Side question. What drawing app is that? tia

hey

not yet, but i did list it on the first post to track features

i'm considering ways to reduce latency from the rx input to the servo output:

rework in the pipeline a little and move the mixer out of the pid block, so that if there are updated rx values, the servo output will also change based on the last computed pid corrections, instead of waiting for the next pid compute. currently, i think it doesn't really matter since the pid block runs every 10ms and the servo frame period is 20ms, but will matter on lower servo frame period.

will then add the lower servo frame period with that (and use the RUD_SW to determine the period).

Originally Posted by ckleanth

excellent. top man will check it when I come back from work.
BTW did u code in the faster servo pulse refresh rate?

a couple of notes on RX3S usage:

1. if you change the dip switches, you need to power cycle the device for the code to read in the new switch configurations. so, it's better to power off the device, flip the switches, then power it back on.

2. the VR pots can be adjusted with the power on. 7 oclock = max gain in one direction, 12 oclock = zero gain, 5 oclock = max gain in opposite direction.

3. on powering up the device, the code will perform a series of calibrations (total about 2-3 secs) and the led will flash accordingly.
- in the first phase, the code will perform a gyro calibration (led flashes at moderate rate). the gyro needs to be still for around 1 second.
- in the second phase, the code will perform a stick calibration (led flashes at fast rate). the sticks need to be still and at their neutral positions for around 1 second.

4. subsequently, the led will flash at a slow rate to reflect the mix mode (1=normal, 2=delta, 3=vtail). there is currently one other error code flash as well.
- 5 short flashes = gyro init error (terminal, code will not proceed)

I finally decided to solder wires to the RX3S board with a connector on the other end for the ISP. I was able to locate places on the board to solder the wires without getting solder on the etched ISP pins or on the processor.

First observation is that the output pulse train is completely asynchronous to the input channels.

The second observation is that the jitter is about twice as bad as with the HK firmware.

The third observation is that the output frame rate is mostly in the 20ms range but on occasion is jumps to about 22ms.

In addition to my scope connected to the inputs and the outputs I have a Hextronic 9g servo on the aileron output. This is not a high quality low dead band servo. It is always moving a little because of the output pulse jitter.

The aileron signal coming from my receiver usually has less than 1us of jitter. What I see at the output (with the RX3S laying flat on the table and steady) is about 33us of jitter. I cannot accurately measure the jitter on the input and output at the same time because they are asynchronous.

None of these things are show stoppers, just need to work on them one at a time.

I checked if the lock bits were set with the HK firmware and they were so I could not extract the existing firmware for backup before installing your new firmware.

thanks for the GREAT feedback!

the stages are currently decoupled, so we would expect the output to be async to the input.

the servo frame period is configured at 20ms. the code will keep rechecking in 1ms intervals until the 20ms window is met. in some cases, it will extend to 21ms if it the last check just misses (below) the 20ms mark and then adds another 1ms.

the jitter is interesting. mine has somewhat less (corona 939mg and hxt 900 servos) and very very little if i cause the rx to go into failsafe mode (which will generate very stable rx pulses).

can you try
- causing the rx to go into failsafe mode
- setting the aux gain to zero

and see if any of the two reduces jitter? i would like to trace the source of the noise.

i've some thoughts on how to reduce the cut through latency and improve the timing precision:
- use a true microsecond timer (eg timer1)
- keep the pid stage separate. right now, only the pid stage will sample and update the soft state of the rx and servo respectively. i think the main loop should more tightly couple (but still async) the rx to servo updates and use the last computed pid corrections until the next pid compute.
- implement the 10ms servo frame period support that ckleanth suggested.

thanks very much again..

Originally Posted by JohnRB

I finally decided to solder wires to the RX3S board with a connector on the other end for the ISP. I was able to locate places on the board to solder the wires without getting solder on the etched ISP pins or on the processor.

First observation is that the output pulse train is completely asynchronous to the input channels.

The second observation is that the jitter is about twice as bad as with the HK firmware.

The third observation is that the output frame rate is mostly in the 20ms range but on occasion is jumps to about 22ms.

In addition to my scope connected to the inputs and the outputs I have a Hextronic 9g servo on the aileron output. This is not a high quality low dead band servo. It is always moving a little because of the output pulse jitter.

The aileron signal coming from my receiver usually has less than 1us of jitter. What I see at the output (with the RX3S laying flat on the table and steady) is about 33us of jitter. I cannot accurately measure the jitter on the input and output at the same time because they are asynchronous.

None of these things are show stoppers, just need to work on them one at a time.

I checked if the lock bits were set with the HK firmware and they were so I could not extract the existing firmware for backup before installing your new firmware.

i managed to look at a servo out channel through a cheap scope and could visually observe two kinds of jitter on the pulse width.

1. those that are +- 5us occurring all the time, but do not seem to move the servo.
2. those that are around < -10us/-15us or > +10us occurring once in a while (1-2 per sec), which does seem to move the servo.

this is with a more aggressive main loop (which has a side effect of performing more atomic reads, which disable interrupts).

i'll look into using lock-free methods of accessing the shared vars (easier on rx in, harder on servo out)..

Originally Posted by noobee

can you try
- causing the rx to go into failsafe mode
- setting the aux gain to zero

and see if any of the two reduces jitter? i would like to trace the source of the noise.

With the TX off, Receiver in Fail safe and ran for 5 minutes. Total jitter deviation over that period of time was 44us on Aileron Output.

How do I set aux gain to zero in fail safe mode?

I am doing the test again with the TX on and aux gain set to minimum (1ms pulse width) and the total jitter is still 32us.

John

Originally Posted by noobee

i managed to look at a servo out channel through a cheap scope and could visually observe two kinds of jitter on the pulse width.

1. those that are +- 5us occurring all the time, but do not seem to move the servo.
2. those that are around < -10us/-15us or > +10us occurring once in a while (1-2 per sec), which does seem to move the servo.

this is with a more aggressive main loop (which has a side effect of performing more atomic reads, which disable interrupts).

i'll look into using lock-free methods of accessing the shared vars (easier on rx in, harder on servo out)..

I am quite sure the +/-5 are result of the micro() function resolution.

I suspect that the large errors are interrupt latency.

i hope you meant 44us

tx on, set gain to min, tx off. this should enable failsafe with min gain (assuming failsafe = hold last channel values).

from the code, i would expect jitter to be skewed towards +T (due to delay in interrupt processing, etc) values and not -T (which seem to occur more often). are you able to tell if the jitter variation is skewed?

how are you measuring total jitter variation over a long period of time (5min)?

Originally Posted by JohnRB

With the TX off, Receiver in Fail safe and ran for 5 minutes. Total jitter deviation over that period of time was 44ms on Aileron Output.

How do I set aux gain to zero in fail safe mode?

I am doing the test again with the TX on and aux gain set to minimum (1ms pulse width) and the total jitter is still 32ms.

John

Originally Posted by noobee

i hope you meant 44us

Yes, us not ms. I edited the post.

tx on, set gain to min, tx off. this should enable failsafe with min gain (assuming failsafe = hold last channel values).

I will check how the Orange RX I am using handles failsafe. Some RX's just put everything back to center except throttle.

from the code, i would expect jitter to be skewed towards +T (due to delay in interrupt processing, etc) values and not -T (which seem to occur more often). are you able to tell if the jitter variation is skewed?

Yes, the MAX values seem to be further away from nominal than the MIN value in most of the tests I have done.

how are you measuring total jitter variation over a long period of time (5min)?

The scope I am using has lots of math functions, I think it is Linux based. One of which is the measurement of positive or negative pulse widths and record MIN, MAX and MEAN values over the time the measurements are being taken.
That is why I am concerned about comparing input and output pulse widths when they are asynchronous. I may not be recording all of the pulses that I am not synchronous width (partial pulses at beginning and end of trace).

Maybe we need a test version of the firmware that keeps inputs and outputs synchronous.

Originally Posted by JohnRB

The scope I am using has lots of math functions, I think it is Linux based. One of which is the measurement of positive or negative pulse widths and record MIN, MAX and MEAN values over the time the measurements are being taken.
That is why I am concerned about comparing input and output pulse widths when they are asynchronous. I may not be recording all of the pulses that I am not synchronous width (partial pulses at beginning and end of trace).

Maybe we need a test version of the firmware that keeps inputs and outputs synchronous.

i didn't quite get this.

if you select one output channel and started measuring it's pulse width over time (min, max, mean), assuming it's corresponding input channel is static and there is no gyro correction, then the measured values would be due to the jitter on the output stage. i'm not sure why we would need to reference it back to the input channel pulse width?

alternatively, if you just disconnected the input channel (AIL_IN for example), the code sets it to 1500us by default and it will not change throughout the test. now, we just need to set gain down to zero and see the jitter due to the output stage. i'm going to try that next..

Originally Posted by noobee

i didn't quite get this.

if you select one output channel and started measuring it's pulse width over time (min, max, mean), assuming it's corresponding input channel is static and there is no gyro correction, then the measured values would be due to the jitter on the output stage. i'm not sure why we would need to reference it back to the input channel pulse width?

alternatively, if you just disconnected the input channel (AIL_IN for example), the code sets it to 1500us by default and it will not change throughout the test. now, we just need to set gain down to zero and see the jitter due to the output stage. i'm going to try that next..

The reason I check both is to see what error is being caused by the RX3S board. The difference between the MEAN pulse width of the input and MEAN pulse width of the output (with stabilization disabled) is the fault of the RX3S.
Ignoring the input variation makes the RX3S look even worse. However with my setup I only see about a 1us change in the input so it can be ignored. Different TX and RX combinations could induce different errors.

i think i found the source of the "significant" jitter, it is either the i2c or imu libraries (more likely i2c). i think it is disabling interrupts for long-ish periods of time. this is with my mpu6050 board, but the mpu6050 and itg3205 libraries are based off the same base in i2cdevlib.

so, i'll look into using alternate i2c access functions that does not use the arduino Wire library.

i'll also look into a lock-free implementation of shared vars access between the isrs and main loop. the current atomic access operations will disable interrupts (though it seems that the disable time is quite small).

the +/-5us-ish jitter is probably coming from the 4us micros() granularity as you indicated. using a true microsecond timer1 could help there..

Originally Posted by noobee

i think i found the source of the "significant" jitter, it is either the i2c or imu libraries (more likely i2c). i think it is disabling interrupts for long-ish periods of time. this is with my mpu6050 board, but the mpu6050 and itg3205 libraries are based off the same base in i2cdevlib.

so, i'll look into using alternate i2c access functions that does not use the arduino Wire library.

i'll also look into a lock-free implementation of shared vars access between the isrs and main loop. the current atomic access operations will disable interrupts (though it seems that the disable time is quite small).

the +/-5us-ish jitter is probably coming from the 4us micros() granularity as you indicated. using a true microsecond timer1 could help there..

They have Interlock.Exchange(...) ? Or that causing interrupt disable also. That is normally the fasted lock for anything needing sync. Or volatile if they have that. Have no clue on the memory model of that system.

Some read/write operations (i.e. 16bit ones) need to disable ISRs as they take two clock cycles to complete. that might be one reason you're seeing small ISR disable periods.

Why they're doing that in the I2C I don't know.

Edit: Just had a look at your code. Using micros() will give you a 4us best case resolution. Why not use TCNT1 like you have with Timer0?