Hey noobee,

Just coming here to say hello and let you know I have a V2 with all the apropriate cables and USB adapter for flashing fw when you have something ready for testing.

Cheers

Today I tried a DX8 and AR8000 receiver setup with an 11ms frame rate. We know that the RX3S takes about 18ms to construct and emit the 4 serial outputs so I had concern about this working.

I only tried one channel, aileron. What I found was that the RX3S appears to ignore inputs that occur while it is still working on constructing and emitting an output frame, half of the input pulses are just discarded. Thus the 11ms frame rate is back to 22ms for all servos connected to the RX3S.

11ms input does not seem to hurt anything, but why bother.

John

I have not spent any time on this, just an observation and I could be wrong.

The RX3S seems to always apply the error correction the same way. Reversing a channel on the RX3S to get the error correction applied in the proper direction also requires you to reverse the direction in the transmitter (assuming everything was working properly without the RX3S connected).

It seems to me the reversing switches should alter the method of applying the correction (such as change from adding to subtracting pulse time) without requiring a matching change in the transmitter. There must be some reason it was done this way.

How do you open "open the generated hex file FlightStab.cpp.hex" in extreme burn?

Originally Posted by flightdeck

How do you open "open the generated hex file FlightStab.cpp.hex" in extreme burn?

File->Open Flash and select proper file.

Do you plan on programming a V1 device?

Originally Posted by JohnRB

Today I tried a DX8 and AR8000 receiver setup with an 11ms frame rate. We know that the RX3S takes about 18ms to construct and emit the 4 serial outputs so I had concern about this working.

I only tried one channel, aileron. What I found was that the RX3S appears to ignore inputs that occur while it is still working on constructing and emitting an output frame, half of the input pulses are just discarded. Thus the 11ms frame rate is back to 22ms for all servos connected to the RX3S.

11ms input does not seem to hurt anything, but why bother.

John

I am curious on how it is doing the pwm input reads. Is it using a seperate PIC or using interrupts on pulse edges. If using interrupts, it would seem to take a fair amount of the mpu cycles especially at 11ms. Even if using interrupts, I would guess inside the handler it is setting a Var for that channel in ms. The main loop is sleeping after writes until wait stops and it loops to read the input vars/calc/write again. Could explain the 18ms wait time. It is sort of a half async half sync pattern.

Originally Posted by JohnRB

I have not spent any time on this, just an observation and I could be wrong.

The RX3S seems to always apply the error correction the same way. Reversing a channel on the RX3S to get the error correction applied in the proper direction also requires you to reverse the direction in the transmitter (assuming everything was working properly without the RX3S connected).

ahh. This would seem to hint at a logic error (i.e. bug). It is doing the error correction on input first, then applies the rev function before output to channel. It should be reversing first, then applying correction. Maybe not. Seeing some code will tell the tail.

just returned from vacation and will look into the v2 setup.

johnrb provided useful info for me to get started. i'll also need to build a programming adapter to connect the 6 edge connectors.

Originally Posted by Minimog

Hey noobee,

Just coming here to say hello and let you know I have a V2 with all the apropriate cables and USB adapter for flashing fw when you have something ready for testing.

Cheers

Originally Posted by noobee

just returned from vacation and will look into the v2 setup.

johnrb provided useful info for me to get started. i'll also need to build a programming adapter to connect the 6 edge connectors.

I bought this adapter. I came with my order of 2 ORX V2.
http://www.hobbyking.com/hobbyking/s...dProduct=27195

i think it should be applying the rev on the correction only and leave the input unaffected in terms of direction.

my v1 code (has changed somewhat since then) does this:

output[] is the correction factor (which may be reversed)
final servo output ail_out2 is dependent on input ail_in + correction factor.
so ail_out2 is always in the same direction as ail_in.

    for (i=0; i<3; i++) {
      output[i] = ((((int32_t)output[i] * vr_gain[i] >> 7) * stick_gain[i]) >> 8) * master_gain >> 9;
    }

    // mixer
    int16_t tmp0, tmp1, tmp2;
    switch (mix_mode) {
    case MIX_NORMAL:
      ail_out2 = ail_in + output[0];
      ele_out2 = ele_in + output[1];
      rud_out2 = rud_in + output[2];
      break;

Originally Posted by wjs

ahh. This would seem to hint at a logic error (i.e. bug). It is doing the error correction on input first, then applies the rev function before output to channel. It should be reversing first, then applying correction. Maybe not. Seeing some code will tell the tail.

Originally Posted by Minimog

I bought this adapter. I came with my order of 2 ORX V2.
http://www.hobbyking.com/hobbyking/s...dProduct=27195

ooh, i've not tried this one. i think ckleanth has one too.

what is your usbasp programmer? since you are connecting directly to the chip, i think you need either

1. a usbasp programmer that is capable of operating at 3.3v. the reason is that the vcc (3.3v) line of the atmel chip is also connected to the gyro (itg3205), which can only operate at 3.3v.

2. disconnect the vcc line from the chip adapter and power the rx3s board through the rx. the reason is that you'll use the onboard 3.3v regulator to supply the right voltages.

Originally Posted by noobee

ooh, i've not tried this one. i think ckleanth has one too.

what is your usbasp programmer? since you are connecting directly to the chip, i think you need either

1. a usbasp programmer that is capable of operating at 3.3v. the reason is that the vcc (3.3v) line of the atmel chip is also connected to the gyro (itg3205), which can only operate at 3.3v.

2. disconnect the vcc line from the chip adapter and power the rx3s board through the rx. the reason is that you'll use the onboard 3.3v regulator to supply the right voltages.

I have this one.
http://www.hobbyking.com/hobbyking/s...dProduct=21321

Originally Posted by noobee

i think it should be applying the rev on the correction only and leave the input unaffected in terms of direction.
[/CODE]

That would be ideal and the way it should work.

looking for opinions on device dip switch config for single/dual ailerons. i still plan to support v1 and v2 (since i now have both). my current plan is:

for v1:

single aileron mode = ele_sw norm, rud_sw norm
use AILR_OUT pin for AUX_IN (master gain)

dual aileron mode = ele_sw rev, rud_sw rev
use MOSI for AUX_IN
use MISO for AILR_IN
AILR_OUT remains as AILR_OUT (= AILR_IN + roll correction)

delta mode = ele_sw norm, rud_sw rev
vtail mode = ele_sw rev, rud_sw norm

for v2:

single aileron mode = all sw off (default)
AILR_OUT is a mirror of AILL_OUT

dual aileron mode A = (what sw to detect?)
use AUX_IN for AILR_IN (no remote gain possible)

dual aileron mode B = (what sw to detect?)
use one of the sw (detail_sw?) for AILR_IN (remote gain remains on AUX_IN)

delta mode = delta sw on (this precludes the single/dual aileron modes)
vtail mode = vtail sw on (this can still include single/dual aileron modes)

any suggestions on what is the simplest way to configure via dip switches? the alternate is using the stick to configure.

the current WIP code is at

https://github.com/noobee/FlightStab...FlightStab.ino

if anyone is interested..

Originally Posted by noobee

i think it should be applying the rev on the correction only and leave the input unaffected in terms of direction.

Over here switch reverses both servo direction and correction direction. I am confused on John's observation that error correction was always going the same way regardless of switch. Visually inspecting mine reverses the correction by flipping the switch and reverses servo. I am back to being confused as to why additional tx rev would be needed. Wouldn't a double rev bring us back to same place?