Protocol for YD-717 aka Sky-botz Mini UFO

So is this running with an NRF24L001, or only with the transplanted Beken module? (I realize the latter is cheaper, but I have the former sitting unused)

cstratton wrote: So is this running with an NRF24L001, or only with the transplanted Beken module? (I realize the latter is cheaper, but I have the former sitting unused)

with nRF24L01+

I'm making the (hopefully) final changes and have a question.

The trim pots on the stock transmitter don't affect anything on the transmitter. Separate trim values are sent to the receiver in each data packet. Investigation showed that the trims change the motor drive endpoints on the receiver. So max rudder plus max rudder trim in the same direction results in a significantly faster yaw rate than max rudder plus a neutral trim value.

I'd like some guidance on how best to incorporate this into the protocol. Currently I've implemented a "high-rate" mode by driving the trim values with a scaled version of the channel value, which keeps the response curve linear. This does reduce the control resolution, so I added an on/off on channel 6.

Two thoughts come to mind:

- You could scale the overall value to the sum of stick range + trim range, it would seem like that would make the controls more responsive, and then they could be slowed down with DR or expo to user taste

- You could phase in the use of the trim channel, sort of as an expo itself, but that may break abstraction models to have an expo in the protocol (not that actual control mechanisms on models are necessarily linear to begin with)

If I even get an STM8 SWIM interface going under Linux, I have half a mind to experiment with new firmware for the onboard side - they are certainly cheap platforms to hack on.

PhracturedBlue wrote: Is there a benefit to having low-rate mode? given that we can easily program such a thing with reduced range, your linear solution looks reasonable to me without the extra channel-6 input.

I tested this and it works great. With the trim code enabled, using a scale of 80 makes it fly about the same as without using the trims. I'll make the change to always drive the trims.

You could also choose to use a scale of 125 or 150 as the max range (and map 150% to 100%+full trim).

Don't think I've learned enough yet to understand this. Are you referring to tx scale settings, or scaling the channels in the protocol code?

cstratton wrote: If I even get an STM8 SWIM interface going under Linux, I have half a mind to experiment with new firmware for the onboard side - they are certainly cheap platforms to hack on.

There's an unused pad on the rx labeled LED+. It doesn't seem to ever be active no matter what you send to the rx.

From the data sheet I think the nRF24L01 should work as well.

PhracturedBlue wrote: which would map 'CHAN_MAX_VALUE (100%) to ~80% on the tx. That would mean that a value of 125% shown on the tx would give you full range on the protocol.

But there really is no need. it is probably more inturitive to use 80% to mean 'low rates' than to use 125% to mean high rates.

Thanks for the explanation. That makes sense. I'll just let the full range be 100%.

Questions about two more items I could add. These are possible because the tx receives ack packets from the rx. An overall question: is the extra code required worth it for a small indoor flyer?

It's possible to detect a bind failure and restart the bind process. The only benefit I can see is this would let you turn on the tx first, then connect the battery on the quad. It would require re-working the current bind code. How long should the tx keep trying?

The tx is set to retransmit a packet several times if it doesn't get an ack within a timeout period. The chip keeps a count of retransmissions, and the data sheet suggests using this as a measure of channel quality. How would this measure be reported to the user?

I'll take a look at the Hubsan code. If it doesn't take many lines that method sounds better. The current code flashes the bind message just for a second.

The reception of the ack packets is done automatically through the Enhanced Shockburst feature, so there's no manual mode switching. It's interesting that it's missing from the nRF24L01 datasheet's state diagram, but it's mentioned in the section on Enhanced Shockburst (love that name). The 2421 datasheet does show these transitions. The YD717 protocol even sets up the data pipes such that the rx could include a payload in the ack packets, but it doesn't. Some telemetry would've been nice.

Since the retransmit info is available I'll see what it would take. Would be a fun thing but not very useful for a quad that can't be seen more than 100 feet away.

I've got the telemetry working using the DSM FRAMELOSS field. When I go to the telemetry monitor screen the F and H fields both show the packet loss count. Is that correct?

I noticed that clicking through the binding screen does not stop the code that's still trying to bind. Would implementing the DEINIT command change that? I powered up the tx first to do some config, then powered the quad expecting to then hit the re-init button. But the quad bound as soon as I plugged in the battery and the throttle wasn't quite at zero. I added a throttle cut switch...

The stock tx does not start sending data packets after binding until the throttle is at zero. Would that logic be appropriate to include in the protocol?

It's the other way in deviation: you can not start the binding process as long as the safety conditions (like throttle=min) are not fulfilled. This means: a short move to the bottom will start binding; the throttle stick can be moved after starting and a non-zero / non-minimal value could be sent first. Often the receivers and ESCs catch this and do not start the motor until throttle was down once. But the YD might behave different.

Nevertheless I propose to keep this behavior consistent as long as there is no technical reason.

Sounds good. Not much of a safety issue on quad this small.

The latest merge wraps it up I believe. Thanks for the help! I'll be happy to update the manual if that's the process. Here's what I know in the manual style.


The YD717 protocol supports the YD717 and Skybotz UFO Mini quadcopters. No other models have been tested with this protocol, but it is likely to work with other re-branded YD717 models. NOTE: This protocol requires the addition of an ‘nRF24L01’ or equivalent hardware module to function. See the following document for more information: www.deviationtx.com/repository/Documenta...uleInstallation.pdf/

The YD717 protocol supports 5 channels and only supports auto-binding. The fixed ID can be used, but does not prevent auto-binding during power-on. The protocol stays in bind mode until successful.

The first four channels represent Aileron, Elevator, Throttle, and Rudder. The fifth channel enables the auto-flip function when greater than 0. Additionally to enable auto-flips left and right the aileron channel scale must be 87 or greater. Likewise for the elevator channel and front/back flips. When auto-flip is enabled, moving the cyclic all the way in any direction initiates a flip in that direction. The YD717 requires at least four seconds between each auto-flip.

Frame loss telemetry is supported.

The YD717 only calibrates its accelerometer on power-up. An excessive wobble indicates the quad was not level and motionless when powered on. It is difficult to initialize it properly with the canopy installed. Best to power-up, then install the canopy.