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

I think we are almost there!

I had to reverse the RUD channel, but other than that everything works as expected.
The throttle and picture taking has been straightened out. No more pictures on throttle and the assigned button I have takes pictures great.

The only thing is that it still seems to have a strong yaw drift (left) still. Durete... can you confirm?

Yes, Yes. I confirm.
Mine drift now to the left. Before this changes to the right.

I'm playing with the code now

@Greenfly. I assume you are testing with rudder trim totally centered at your Devo. Right?

Yes.

I played with the code a little bit. When you restore the right code at packet 6 (rudder), and restore the code at packet 8 (rudder trim), the rudder stick stops to work.
Restoring the code at packet 6 and packet 8 but with packet 8 reversed (scale_channel(CHANNEL4, -32, 32) seems to work. But when you reach extreme stick values to the left or to the right the quadcopter start to turn to the left and to the right ultra fast.
@Hexfet. According your first post decoding the data packet, the trim values goes from -20 to 20. I am right?
Could be related to this? Since we are trying to use -32,32?

Ok, I will play with the code and test

Durete, Just so you are aware... Hexadecimal 20 = Decimal 32.

Yep, I know. But we are not working with Hex values?

Ok, just tested.
Definitively I have no idea programming

OK, I just thought there might have been some confusion since the captures were in Hex.

But I'm having fun ...

With me previous test, using -20,20 as trim values, seems to work as with -32,32 values. When the rudder stick reach extreme position the yaw start to turn to the left and to the right ultra fast at some stick point.

Ultra-fast movement is the reason for driving the trims You can always slow it down with scale in the mixers. Sounds like maybe the trim channels were just reversed. There are 6 bits for control signals and 5 bits for trim. We don't know how they are combined by the receiver, but it's possible they were nearly canceling each other out. How does the yaw rate compare between the test version with only rudder trim and a version with regular rudder control?

Please try restoring the code for the other trims and reverse their limits in the call to scale_channel. Might want to do this in several steps, setting the channel value to 0x20 and verifying the direction of the trim signal. But it's also fun to go for broke

The 32 is the same as 0x20. Either should work. Using -20 to 20 won't use the full possible range.

Still puzzled by the yaw drift. With 64 possible values for the control byte there's no exact center value. The difference between 0x1f and 0x20 is about 1.5% - not sure how noticeable that would be. But doesn't seem to affect pitch or roll.

I think I explained bad... (my english )
I mean, at some point very near the extreme point, the rudder starts to make fast changes. Same as you move your rudder stick left-right-left-right.... very fast.

@Greenfly. Please, test this build.
I restored rudder control, rudder trims but reversed. Be careful when try the rudder and see what is going when move full rudder.

dl.dropboxusercontent.com/u/14941708/dev...n-devo7e-Unknown.zip

I tested now using -16,16 value at rudder packet. And now I see some interesting things...
The rudder works perfect, but slowly drift to the right. In fact the yaw rate to the right is faster than to the left.
@Hexfet. Could be possible the rudder trim packet is not centered at 0?. I thought maybe the trim packet value should be something like -14,18 or something similar...
Please, could you double check the SPI rudder trim capture?

Durete wrote: I mean, at some point very near the extreme point, the rudder starts to make fast changes. Same as you move your rudder stick left-right-left-right.... very fast.

Cool! My first guess is that max channel + max trim causes some kind of internal error in the receiver. I'd wondered about this but it hasn't shown up on other models. But with 6 bits of channel and 5 of trim it definitely seems possible.

Can you try setting max yaw trim on the stock tx, and then give it max yaw in the same direction? If it behaves the same as with deviation then it's very likely this is the problem and we can just reduce the trim min/max values. If it does not behave the same we'll need another SPI capture with the stock tx at max yaw + max yaw trim. The capture will show if the stock tx limits the total yaw + yaw trim that is sent to the aircraft.

Thanks!

That's my same thought!

Wait a moment, I found something...

Ok, just tried with stock TX.
I bind, move the Yaw trim to one side at max, and apply slow throttle. As soon I apply throttle the only 2 motors needed to turn for one side start. The other 2 motors don't start. I apply full yaw to the same side and definitively not the same as with Deviation . Only slightly faster this 2 motors, because they are near full speed.
I tested to the other side, and same.

I setting at your code rudder trim packet as -15, 17. With this values works perfect, about the same yaw rate than with stock TX. The rudder drift is slower but no 0 We are missing something...

@Greenfly. Please test this code. Only Rudder trim packet working with slightly out of center value.

dl.dropboxusercontent.com/u/14941708/dev...n-devo7e-Unknown.zip

I still have a pretty noticeable yaw drift to the left with no trimming.

Predictably... I almost correct (not completely) my yaw drift to the right side, so yours is probably worse because was for the opposite side