NI HUI U207

Hi,


Just received this nice nanocopter.
Based on the Beken 2423, the RF designer is "ABE". Well this latter is known to design the YD717, SkyWalker, Syma, Xinxun protocols. Unfortunatly, they changed something (I guess it's a minor detail) and all these protocols don't bind this quad. I sniffed all SPI data in different configuration

mon-partage.fr/f/Xtlts1kY/

So if anyone want to add this one in the YD717 file (add a fourth option) it will be great . I am thinking to hexfet . I am sure ... in less than 10mm he can do that

Hi,

This one has new RX/TX address for bind procedure and a new bind packet:

1.817 11620 W_REGISTER(RX_ADDR_P0) 64 64 64 64 64
1.817 11621 W_REGISTER(TX_ADDR) 64 64 64 64 64
1.817 11624 W_TX_PAYLOAD 87 04 14 00 56 AA 00 00 60

It looks like its changing RF channels sometimes (switches to 0x02 and 0x21 on your first capture) - this seems to happens when reading the STATUS register returns 0x1E after writing payload (usually its 0x2E).
No fast and constant frequency hopping like V2x2 does, but it seems to have some "backup" channels for transmission (usually it stays on channel 0x3C).
Would be interesting to know whether receiver always 'sniffs' on different channels or if it follows sequence automagically after packets were missing ... latter one could be complicated.

Anyone ever observed that on other YD protocol variants ?
A sudden loss of control when flown with Deviation could be a sign of receiver switching channel (All YD protocol variants stay on RF channel 0x3C forever in current implementation).

btoschi wrote: Hi,

This one has new RX/TX address for bind procedure and a new bind packet:

1.817 11620 W_REGISTER(RX_ADDR_P0) 64 64 64 64 64
1.817 11621 W_REGISTER(TX_ADDR) 64 64 64 64 64
1.817 11624 W_TX_PAYLOAD 87 04 14 00 56 AA 00 00 60

It looks like its changing RF channels sometimes (switches to 0x02 and 0x21 on your first capture) - this seems to happens when reading the STATUS register returns 0x1E after writing payload (usually its 0x2E).
No fast and constant frequency hopping like V2x2 does, but it seems to have some "backup" channels for transmission (usually it stays on channel 0x3C).
Would be interesting to know whether receiver always 'sniffs' on different channels or if it follows sequence automagically after packets were missing ... latter one could be complicated.

Anyone ever observed that on other YD protocol variants ?
A sudden loss of control when flown with Deviation could be a sign of receiver switching channel (All YD protocol variants stay on RF channel 0x3C forever in current implementation).

No for all quad flown with YD717 and its variants, it was very solid ....

Thanks for the infos . I was quiet sure, they changed minor stuff. This compagny "ABE" is delivering RF board for a lot of toy quadcopter compagny.
I don't see them developping each time new stuff.

From what I can see btoschi's spotted all the differences from the SkyWalker protocol variant. The channel assignment, flip button, and packet checksum are the same as Sky Walker.

The frequency in the other captures is only changed to channel 2, but perhaps that's because they weren't long enough to see more changes. The 1E status indicates an auto-acknowledge timeout.

The packet before the 1E status is received is also strange. It has status 0E, indicating it's being read before any interrupt has been generated. Has the rx stopped auto-acknowledge in order to initiate a channel change? That seems problematical - if the rx missed a packet due to interference or out-of-range the tx would switch channels but the rx wouldn't know.

The channel changing is different from the existing YD variants. SeBeDocKy, two more captures would be helpful. One that is as long as you can make it with the quad always at close range. And another where you move the quad away from the tx until packets really are lost. Just walking away till the bind is lost should be fine. No need to capture the binding anymore.

hexfet wrote: The channel changing is different from the existing YD variants. SeBeDocKy, two more captures would be helpful. One that is as long as you can make it with the quad always at close range. And another where you move the quad away from the tx until packets really are lost. Just walking away till the bind is lost should be fine. No need to capture the binding anymore.

Hummm for the second point .... It will be a little bit tricky Hope to run enough with 1B samples

EDIT : Maybe for these strange behiavours, can come from my sniffing installation. Probe's wires are taped with saleae wires. So maybe there are some micro-cuts ... could happen even if the bench seems ok

Ok,

Here are the two new captures. Hope the second is ok .... I had to run fast

mon-partage.fr/f/7k35F2u4/

I have added the protocol with the mentioned changes and
SeByDockY already testet it and reported its working fine.

This diff is against PB's repository @2332:3b623a8d08f5


The channel-'avoidance' is not there, but whenever this state is reached, its printed to serial (for dev builds) that original TX would change channel.

Edit:
Thanks for the captures, second one shows all channels:
Sequence is

Great job !!!!!

You and Hexfet did great job

Nice work btoschi

Should be okay to implement the channel switching. Even if we don't know what the receiver is doing it's pretty clear the tx does the switching without regard to the rx.

Thanks a lot for your work guys.

Do you know how to turn the LEDs off? I've tried Channel 6 but it doesn't seem to do anything. Cheers.

It's all working now. Check this thread for more details. It was tested on the newer, orange version. I am not sure if there is LED control on the black model though.

Turns out the light control was on Channels 6 but it wasn't implemented in the protocol.