UDI R/C U816 / U818 Protocol

Since I'm stuck with MJX protocol for now, I've started reversing the protocol of my UDI Ufos, as I've got three of them and like them very much (U816A is great to fly in my rooms, canopy is easy to glue if broken, only TX is not the best and U818A is my first video quad luckily shot at eBay for not too much money).

I can confirm that the TX of U816 and U818 can be swapped w/o problems, protocol is the same, both are using BK2421 chip. RX boards are technically speaking very good (6-Axis Gyro/Acc , ARM CPU), besides basic drift due to (in my opinion) imprecise sticks these really 'stick' in the air.

Protocol does not use channel hopping, but makes use of the RX/TX Address feature of Nordic chipset, which acts somehow like a MAC Filter, letting the chip discard any mismatching dataset (Actual transmitted payload is preamble + this address + real payload send via SPI command).
Binding is a bidirectional process where TX sends out bind packets containing its own 3 byte ID using the common RX/TX Address E7 7E E7 E7 E7 and sending on RF Channel 00.
It then receives a reply from the receiver which contains its 3 byte ID, and the TX sends out packets containing this ID twice.
Then the RX/TX Address is set to this ID (Address width is set to '01' = 3 bytes) - this is not 100% true ! - and then data packets are send six times, then it switches to RF channel 07 and sends around 55 packets per seconds.

Payload is always 7 bytes: First one is status (5A = bind, A5 = TX reply, AA = RX ID confirm, DD = RX Ack -> TX knows its bound and switches address, 55 = Actual data packet) followed by 6 bytes which I have not yet fully deciphered.

Sample packet is:no checksum, first two should be throttle and rudder, but that's easy to find once I can bind using arduino.

Tricky part here is the RX channel which is choosen.
1. TX ID seems to be partially random (tested one yet, observed 39 CA F6, 19 CA F6 and 19 EA F6 as ID)
2. RX ID seems to be 'stable' (my U816A has F0 F2 F3, one U818 has F9 18 39)
3. I have seen the TX choose its own ID as RX/TX Address, looks there was no RX Ack packet (DD) before (-> bind did not succeed). In this case the whole procedure started again after ~ 150ms and did succeed then (using RX ID as address)

I'll give arduino code a try with this ... stay tuned

Some updates:

After binding, it does not always switch to the same RF channel. As far as I can see its based upon RX and TX IDs which channel is selected, I need to check more combinations for that to tell anything useful.

Arduino code is up an running, but not working as expected (I do not receive replies from RX Board - need to check code and/or hock-up logic sniffer to receiver board)

btoschi wrote: Some updates:

After binding, it does not always switch to the same RF channel. As far as I can see its based upon RX and TX IDs which channel is selected, I need to check more combinations for that to tell anything useful.

Arduino code is up an running, but not working as expected (I do not receive replies from RX Board - need to check code and/or hock-up logic sniffer to receiver board)

Great job ....

SeByDocKy wrote: Great job ....

Thanks, hope I get it working soon ...

edit:
Seems like one receiver board will send different IDs, but always use the same RF channel, regardless which TX is used.

I sniffed these IDs send by my U816A board and it always used RF Channel 07:seems thats some kind of 'randomness' intruduced by time between power on and receiving of first bind packet (maybe something else).

With my U818A receiver I sniffed IDand RF Channel 23 (hex) was used.

With that knowledge I should be able to connect to known boards easily with my arduino - since that's what I'm trying already I must have messed up the timing somehow.
Sniffing SPI on receiver side is not possible at all on U818 (I could easily solder all pins at once with my iron !) and challenging on U816 board, I would only try on broken one.

I'll re-check timing tomorrow then, stay tuned for real progress ...

I've checked arduino code many times and it looks that I'm unable to switch NRF into RX mode.

I'm sending the very samy payload on same RF channel and using same Address as original transmitter.
Then I write 0x7B into CONFIG register and poll STATUS register for bit 6 getting high, but nothing happens.

Either the receiver board does not reply as expected (I need partially broken U816 boards to sniff SPI on receiver side, as soldering can easily go wrong here) or, which I believe is the truth, I fail to tell NRF to switch into RX mode. Datasheet is unclear whether I have to let CE go low in between or not (I'm using victzh's code thus /CE is set to low in nRF24::begin() and stays so).

That may be a problem. I recall that to switch TX to RX mode you need to deassert CE first, or go through power down (PWR_UP bit set to 0). Check the datasheet to verify ( www.sparkfun.com/datasheets/Components/S...ecification_v1_0.pdf ). Even worse, as I read the state diagram, you can get to RX (through Standby-I) only after packet transmission when CE=0, so the proper way is to keep CE=0, then after packet is in FIFO shortly assert it (for 15us).

It also will create a problem with porting code to Deviation - we don't have an extra pin for CE there, so the only way to switch (without extra hardware support) is to go through power down state, which adds start up time 1.5ms. For UDI with packet every 22ms it is probably OK.

NRF looks like a beast, or I'm completely messing something up, or they are using Beken features which are not possible on original nordic chip...
Note that they are using the 'Enhanced ShockBurst' magic (Auto resend/ACK) feature.

I tried with CE low, wait 130us, CE high, to change from RX to TX and vice versa, no data received.
I implemented a 'listen' mode where it waits for any data to arrive in listen mode - it does not receive ANY data from TX and RX binding procedure.

I tried with going through power down state, letting CE stick to high and waiting 1.5ms+130us - still not working, still no data of bind procedure captured.

I think I'll try tomorrow with the 'RF24' arduino library and the simple ping/pong example (I have two nRFs and two arduinos here) which should at least teach me whether my wiring is okay and proof that RX is working at least. Though I adapted that code to toggle to listen state, which does not work here. But that MAY be an overseen UDI protocol / Beken feature.

Also note that they are programming some of the special Beken bank 1 registers in another way than V2x2 and in another way than the Beken datasheet says:
edit:
Seems they are using values from RFM73 datasheet: www.hoperf.com/upload/rf/RFM73_Datasheet.pdf - is that one fully compatible to nordic/beken ?

UDI TX init:
Maybe I should try this with a real Beken attached to arduino ...

@victzh: Do you know what these special beken registers do ? Possibly mis-tuning the RF channels ?

I have an 816 that flies horribly, so did some sniffing of my own on it recently and wrote it up at: www.rcgroups.com/forums/showthread.php?t=2069017

Also, have you seen the yd717 support in deviation? I only found that after doing my experiments, but I'm am 99% sure it is the same chipset, though a different protocol.

Two things I can offer in the way of help:

- I removed the module from the transmitter and remoted it on a ribbon cable plug assembly. If you have Arduino code you want to try against the OEM tx module, I could probably connect that into a 3.3v-modified UNO sometime this week and see if it makes a difference vs an NRF24L01. (Back when I'd somehow convinced myself that the chip was a Hope RF73, I found in their data sheet that there are some RF configuration registers that should be set differently for RF70 vs RF73, so there may be similar differences between the NRF and its various clones).

- I should be able to get wires on the STM8 SPI pins of the receiver and sniff those if need be (already did it on the yd717, only did i2s pins of the 816 so far)

I'd hacked something to feed sigrok output from the CYC68013A analyzer into a little spi decoder I wrote, so I could get nearly "live" packet dumps as I moved the sticks. That lead to this:

Breaking down the UDI "a0 55 00 84 60 60 20 20" transfer:

Byte 0 - Always a0, this has something to do with writing to the transmit fifo

Byte 1 - Usually 55, but there's periodically an f7 packet not yet undertood

Byte 2 - Throttle, ranging from 0 to 0x64, ie, 0-100

Bytes 3-4 16 bit big-endian value with three 5-bit stick positions: RRRRREEE EEAAAAA0

Byte 5 Directional flip on bit 7, Lights on 6, Rudder trim on bits 5-0

Byte 6 Mode2 sets bit 7, 360flip sets bit 6, Elevator trim on 5-0

Byte 7 Aileron trim on 5-0

Using only 5 bits per stick seems a bit limiting, especially when more bits are provided for trim position than for stick position!

Of course the real mystery to me is why mine is 10x more unstable than either of my other little quads (sky botz/yd717 and Syma x1) - frankly it makes my old 4#3b's seem easy to fly. Under close inspection there looked to be unsoldered pins on the MPU6050 so I touched those up, but it made no difference (also saw the same thing on a photo of a replacement board).

ACTIVATE(53) is a bank switch which exists only on Beken. The reason for this is that they simplified the design used by Nordic, so it does not have embedded processor and can't properly initialize its own registers. So you need to do so for them. The values are usually coming from the datasheet, they should not influence protocol functioning.

The proper way of handling it is in my code, after ACTIVATE(53) you should check, whether it's Beken, and in any case issue this ACTIVATE twice to return to normal mode.

The autoacknowledge on the other hand is a bit tricky, I had a problem with it myself. If by overlooking AA in the register you accidentally turn it off (which I did) nothing works because AA changes packet flags and receiver on the model just does not understand your packets.

@cstratton:
Interestingly I have read many ppl writing these bad experiences on U816 which I cannot understand. I blame the TX for not properly returning to center position, but I find my U816A the best controllable mini quad I own (besides the center issue). That's indoor flight - but even using the U816 canopy it was fun to fly outdoors (in woods - many obstacles I was able to avoid).
Nevertheless thanks for writing down your findings, as that may help me a lot. As victzh wrote, the issue should not arise due to BK242x (btw: I found that RF70 module uses BK2420 and RF73 module uses BK2423), thus there is another issue - I still suspect that I fail to kick NRF into RX mode.
Note that the mystery signal you write about should be CE - which is required to switch between RX and TX for NRF and clones. I'll check if my U818A board's RF board uses the same pin layout.

@victzh:
Thanks for clarification, that sound like I should ensure that I can listen to own traffic using NRF and my code first before concentrating on UDI/BK issues. And AA is enabled using the init sequence shown above (which I simply translated into arduino code) - but still there is a chance that AA on NRF is not fully compatible with Beken ... should consider this.

I'm beginning to suspect that UDI has a quality control problem. The sky botz (yd717) is about the same size, half the cost, and is 10x more stable... But with the MPU6050 onboard, the 816 it has all the parts to be a decent flyer, so I suspect something is wrong with some of them, including mine.

I've spent some more time on this - I cannot get this chip to receive data.

I can tell for sure that I do not get any ACK packets (status gets 1E where original TX reads 2E) - even that I have compared my SPI traffic to the original TX one (its 100% the same besides the missing replies). And Carrier detection does not detect anything at all (ongoing bind process with original TX using same RF channel ...).

Either my NRF is broken or its pinout is not correct (I'm sniffing SPI at the pin I suspect to be CE).
I'll try with another module tomorrow, but I'm running out of ideas ...

Also note that the thing with RX / TX IDs is that there seem to be real RX IDs which are used as initial seed for the address counter and all bytes are decremented by one (underflowing, after 0x00 comes 0xff) until first bind packet is received - and this one gets send to TX.
TX seems to do similar things, but slower / with different scheme.

RF Channels are not affected by the IDs, but they are using 10 different channels (plus 'bind' channel) - depends on when TX receives receivers acknowledge (not auto-ack !) of RX.
Seems that they are switching channels like 00, 07, 00, 23, 00, 4F, ... (just sniff SPI on TX after triggering bind w/o having receiver turned on).
Channels I have discovered are:
07, 23, 4F, 0E, 3D, 14, 2C, 46, 1C, 34

Do you use CE? I read nRF24L01+ datasheet once more and figured that deasserting CE is the ONLY way to switch modes, because the config register can only be written in power down or standby.

Yes, you're right - there is Standby-II where the TX mode eventually goes when FIFO becomes empty. And CONFIG register modification is only possible from Standby (I or II) or Power Down. There are words in datasheet describing these transitions, but they're not that clear (for me, at least).

Currently I'm setting CE to low in my update routine and after programming stuff set it to high again, so radio is active. This is roughly what original TX does, too.

I had tried with power down but was not successfull with that, though I'm not too sure about proper timing.

The thing that puzzles me most is that the auto-ack does not work, while it does on real TX, and SPI trace is identical, even timing is accurate.
Do you know a way to let the SPI decoder add the state changes on CE pin when exporting the trace ? (Plugins are not freely programmable in Salaea Logic, am I right ?)

Also note that a simple SPI replay won't work as the RX board always sends a pseudorandom (well - decremented from starting bytes) ID - though getting so far that I receive the RX ID would be much further than I am now.

@btoschi, can you post the initialization code here? Or may be even better, the whole Arduino code. I'd like to take a look.

No problem, hope its somehow readable.
My arduino code is a mess, sorry, but any structure it had was swept away by trial-and-error coding plus nightly hacking ^^ (plus I have never seen such an featureless IDE like arduino ... code completion, browsing, bookmarks, ... ? I really miss QtCreator )

I'm not too sure if all is right with init code, as I was trying to let it act as RX just to find another bug which could have caused the issues.
And as always I regret that I haven't set up a local git repo for that 'small' project (which would have taken me minutes and saved me years )

I recently found out that the U818A RX/TX exist in two different versions.
All protocol stuff I have written down before is for the 'old' U818A, U817x and U816(A), and most probably not for any U818A you'll buy today ("Model 2013").

I have two U818A which PCB is labeled "UD-U817OG, 2012-11-30*LF" and has a BK2421 and the antenna on main PCB. Binds fine with U816 TX.
Since one of these has a self-desoldered FET (and, sorry, I have no fine solder iron), I've ordered a replacement PCB at banggood, which looked different (Small RF PCB with epoxy blobbed chip, same as used in U81x transmitters) and did not bind with my TXs at all - so I though it was simply dead. Then I've ordered another one in germany, fine packaged - same PCB ("UD-U818B, 2013-5-29*JD") and still this does not bind with any of my transmitters.

The seller told me that U817 and U818 is NOT compatible. As such I believe UDI first sold U81x compatible U818As (which I have two of) and then changed PCB and protocol, I'm trying to get a working transmitter to sniff what's different ...

Note: I'll have to wait for the new power supply for my Linux Laptop before I can continue work, as I'm doing all my sniffing and coding on it and power supply failed (how bad, it was only 5 years old and used daily ).