Protocol for YD-717 aka Sky-botz Mini UFO

I bought one of these because $23. It's a re-branded YD-717. Not great but some like the propellers .

Seems to me it might be decent if the controller wasn't a potato with two gherkins for sticks. Attached is a protocol description and protocol file for the yd717. It builds successfully but I can't test it because I don't own a Devo transmitter. So if you have a YD717 and would like to test (or have a Devo tx for sale cheap...)

A nRF24L01 is required (the stock tx has a Beken 2421). The protocol is simple - no frequency hopping, the stock tx always uses the same address, single byte channel values. There are some unknowns noted in the description file. In particular it might be possible to disable the auto-flips in high rates, which is not possible with the stock controller. I set up channel 5 to see if that works.

I used the v202 protocol file as a starting point. Currently the channel and tx/rx address are fixed pending testing to see if the receiver can handle different values.

Great, thanks! Was hoping someone could try it before I tear apart the tx : )

Good

I guess it should also work for the YD-712

I'll take a look and see if I can spot the problem. Thanks for checking.

I have a Devo 10 on the way so in a few weeks I'll be able to debug. It is way too easy to buy stuff online...

PhracturedBlue wrote: I got a reboot due to getting stuck in here:

while (!(NRF24L01_ReadReg(NRF24L01_07_STATUS) & BV(NRF24L01_07_TX_DS))) ;

I believe this will be fixed by replacing the line above with:
I also have this code in my (hexfet) bitbucket fork of deviation.

The YD717 is different from the V202 here. It uses auto acknowledge, and the bind packets end with retry failure instead of data sent because they are not acknowledged.

Another thing I just thought of is that it may be required to bind on every power up. At least the stock TX works that way. But it also uses the same address and channel every time...

PhracturedBlue wrote: I just committed the code. It'll be available in tomorrow's nightly, and in 4.0.1.

I'm not convinced the channels are right. but the gyro in this thing seems wonky, and I've had a lot of difficulty getting stable flight. This is true even using the stock Tx, so I am not sure that the issue is necessarily your code. Still, nice job.

I don't own any Attop (YD-71x), but I heard there are not very very stable. So I think too it's not coming from your code. Whatever it's a good news, another protocol added . Thanks both ....

PhracturedBlue wrote: I just committed the code. It'll be available in tomorrow's nightly, and in 4.0.1.

I'm not convinced the channels are right. but the gyro in this thing seems wonky, and I've had a lot of difficulty getting stable flight. This is true even using the stock Tx, so I am not sure that the issue is necessarily your code. Still, nice job.

Awesome, thanks! I looked at the Hubsan code for auto-binding and will work on that.

I think the wonkiness is due to an issue with the channel value encoding. Didn't check it carefully. In read_controls() the V202 sets rudder, aileron, and elevator to the negative two's complement of the converted channel value. I believe the YD717 just needs the unsigned byte value directly (*rudder/aileron/elevator = a). Hoping that'll make it a little improved over the stock tx...

SeByDocKy wrote: I guess it should also work for the YD-712

I looked at pics of the YD-712. It has a different receiver board, leds, and digital trims on the tx. Not sure it'll be the same protocol.

hexfet wrote:

SeByDocKy wrote: I guess it should also work for the YD-712

I looked at pics of the YD-712. It has a different receiver board, leds, and digital trims on the tx. Not sure it'll be the same protocol.

We will know soon I asked to MO who got a more or less working YD-712

PhracturedBlue wrote: I gotta say that the Hubsan is a lot nicer to fly though.

Agreed. This was a learning project and to salvage some of my $23.

The file in the doc directory is named YD712.txt, though the comment says YD717. Maybe wishful thinking?

Happy right now

Received my Devo 10 a couple days ago. Installed the tx module from the YD717 stock tx - and it didn't work. Fixed a couple items I'd missed in initialization. The previous version shouldn't have worked with an nRF module either as far as I can see (auto-ACK wasn't enabled). PB, if you have the time I'd appreciate it if you could make sure it still works with an nRF module.

I also needed to reverse the aileron and rudder channels to match the Deviation default directions. Pull request submitted.

The lower nibble of the flag byte does control the auto-flip enable. The protocol controls this through channel 5. Less than 0 is auto-flip disabled; greater than 0 is auto-flip enabled.

I tried toggling the upper nibble of the flag byte but it didn't seem to affect anything. So no code included to manipulate the upper nibble.

Still need to fix the tx id.

The YD717 flies really nicely with the Devo 10. Flying full rate without auto-flip is very responsive. This will be my office flier over the Hubsan X4 for two reasons: it's quiet, and the props are more durable than the X4. (caveat: I'm flying the X4 with its stock tx).

MUCH thanks to everyone who has contributed to this project. It was straight-forward to implement the protocol without knowing anything about the rest of the Deviation code-base

Some helpful info if you want to use the stock TX radio module. I couldn't find an exact match on the web, but it seems to be designed for wireless mice. I get more than 30m range, which is farther than I can see the copter anyway.

The YD717 stock transmitter uses a radio module containing a Beken 2421
transceiver chip.

The module pinout is:On the YD717 transmitter the /IRQ pad is not connected to anything.

The CE pad is tied to VCC through a 10K resistor on the stock tx. It
is okay to connect it directly to VCC.

Be careful soldering to the pads on the module. They separate from
the PCB very easily.

Annotated log of SPI data during initialization and bind.