HontaiTec Quadcopters (HT F801, HT F803,...)

The trim values range from -32 to 32 as a signed (two's-complement) integer. So the hex values range from 0xe0 to 0x20, with 0 for the center in the stock tx.

The 0xdf value is slightly out-of-range, but I remember seeing it in the stock tx captures. But the video looks like some internal value is changing abruptly suggesting an overflow or underflow of some value. Perhaps try reducing the range of the trims to -30 to 30 and see if the behavior is still there.

Yep, I tested using different values, and the maximum value without this behaviour seems to be -16,16

Don't have any good ideas on pursuing the difference between the stock tx behavior at max channel + max trim vs the behavior with deviation sending the same values. The only thing that occurs to me is changing both at the same time is confusing the receiver, but that sounds far-fetched.

Does having the trims driven with -16 to 16 limits improve the flyability at all? More authority on roll and pitch? If not, let's just fix the trims at zero. If so, we can leave them at -16 and 16 and stop there unless and until there's progress on investigating the different behavior from the stock tx.

I think doesn't improve at all So maybe could be better to fix at zero value.
It's night here, and can't test properly outside.
@ Greenfly, please could you test this builds?
This build has trim packets with value -16, 16:
dl.dropboxusercontent.com/u/14941708/dev...devo7e-16%20trim.zip
And this other one, with trim packets at zero value:
dl.dropboxusercontent.com/u/14941708/dev...o7e-Zero%20trims.zip
Did you notice any improvement on rates over stock TX?

@Hexfet.
With this changes the only strange behaviour is the damn yaw drift

Durete wrote: @ Greenfly, please could you test this builds?
This build has trim packets with value -16, 16:
dl.dropboxusercontent.com/u/14941708/dev...devo7e-16%20trim.zip
And this other one, with trim packets at zero value:
dl.dropboxusercontent.com/u/14941708/dev...o7e-Zero%20trims.zip
Did you notice any improvement on rates over stock TX?

Will do. ASAP. Thanks!

Durete wrote: With this changes the only strange behaviour is the damn yaw drift

Try setting all the channel values to 0x20 and all the trims to 0. That will send exactly what the stock tx sends with directional controls and trims centered. If the quad behaves differently with stock tx and deviation...then gremlins

You might try changing PACKET_PERIOD from 15000 to 13500. Looking at the captures that will be closer (a little faster ) to what the stock tx does most of the time.

I've pushed code that has that change, sets a random txid, and has the tx address lookup cleaned up. Please test those changes when you have the chance. Thanks!

This build has trim packets with value -16, 16:
dl.dropboxusercontent.com/u/14941708/dev...devo7e-16%20trim.zip

Seemed to perform the best., but there is quite a noticeable yaw drift to the left. What kinds of test do you want me to perform?

You could try the test above - force the channel values and trims the same as the stock tx center values, and change PACKET_PERIOD. Fly with that, and with the stock tx with sticks and trims centered. If they behave differently...I don't know. Be careful - you won't have any directional control.

In protocol/hontai_nrf24l01.c send_packet() change to this:

hexfet wrote: You could try the test above - force the channel values and trims the same as the stock tx center values, and change PACKET_PERIOD. Fly with that, and with the stock tx with sticks and trims centered. If they behave differently...I don't know. Be careful - you won't have any directional control.

In protocol/hontai_nrf24l01.c send_packet() change to this:

     packet[3] = (scale_channel(CHANNEL3, 0x00, 0x7F) << 1)        // throttle
                | GET_FLAG(CHANNEL_PICTURE, 0x01);
      packet[4] = 0x20;              // aileron
      packet[5] = 0x20;              // elevator
      packet[6] = 0x20;               // rudder
      packet[7] = 0; // aileron trim (range -32, 32)
      packet[8] = 0; // rudder trim
      packet[9] = 0; // elevator trim

With the PACKET_PERIOD already at 13500, I made the above changes and of course the quad would do nothing but throttle up.
The stock TX worked fine however. I guess I don't know what we were comparing.

Oh wait... it may have dawned on me what you meant. Did the quadcopter behave the same as when with the test Devo code (above) and when I just throttled the quad up with the stock TX (no direction/no trim)?

The answer is yes. The both appear to ascend in the same pattern, no noticable direction changes.

I hope that's what you wanted me to test.

@Hexfet,

What if I did this...

If I was to fly that, wouldn't I have no rudder control? If that's the case, then why is it that the reality is that I do. It's hard to test, but I can yaw both directions with the above build.

greenfly wrote: Oh wait... it may have dawned on me what you meant. Did the quadcopter behave the same as when with the test Devo code (above) and when I just throttled the quad up with the stock TX (no direction/no trim)?

The answer is yes. The both appear to ascend in the same pattern, no noticable direction changes.

I hope that's what you wanted me to test.

Yes, that's perfect. And a relief since it makes sense. Hopefully Durete will get the same result with the same test.

We're actually sending 0x1f on the elevator and rudder channels with sticks centered just because of the way the value is calculated. Wouldn't seem like that's enough to cause the drift being described, but maybe. It's about 1.5% of the total range. If you restore the previous code do you have a yaw drift at center stick?

greenfly wrote: If I was to fly that, wouldn't I have no rudder control? If that's the case, then why is it that the reality is that I do. It's hard to test, but I can yaw both directions with the above build.

You have yaw control because packet[8] is the yaw trim value. The receiver is responding to the changing trim data. How does the max yaw rate with this code compare to the max yaw rate without the "fixed rudder"?

hexfet wrote: If you restore the previous code do you have a yaw drift at center stick?

Which code?

hexfet wrote: How does the max yaw rate with this code compare to the max yaw rate without the "fixed rudder"?

It seems slower.

When I load this...

Strangely, it has a yaw drift to the left. Not dramatic but noticeable.

greenfly wrote: It seems slower.

As it should since only the trim is being changed.

greenfly wrote: Strangely, it has a yaw drift to the left. Not dramatic but noticeable.

Please try forcing the elevator byte to 0x20 also. Wondering if there's some interaction with yaw since we're sending 0x1f as center for elevator as well.

Hi guys.
A will start my tests in a while (too much job today )

I will test with trims and direction channels fixed at center (0, 0x20 ), and later with every single channel fixed to figure out what channel is related with the yaw drift.

Thanks for your hard work guys

Just finished my tests. I tested using fixed neutral value at every channel.
Aileron channel doesn't produce yaw drift.
Elevator channel doesn't produce yaw drift.
The only channel producing yaw drift is the rudder channel.
With my build compiled with trims (all trims) and rudder channel at fixed stock value (0x20) the yaw is perfect. Doesn't drift at all.
So maybe these slightly out of center value (0x1F) at rudder channel is the reason.
@Greenfly. Please, test this build:
dl.dropboxusercontent.com/u/14941708/dev...rudder%20neutral.zip

With this build you will have all directional controls but rudder (fixed at perfect neutral stock value 0x20)

Please, if you have yaw drift with this build, could you try to calibrate the quadcopter's gyro/acc using stock tx? I explained to you by private some days ago.

Just double checked. Zero rudder drift with my previous build
Now I will add trim packets (using -16,16) and test...