- Posts: 46
UDI R/C U816 / U818 Protocol
- cstratton
- Offline
You don't actually need a particularly tiny iron for most SMT work, as the key is to use plenty of flux and let surface tension of the solder create the desired connections while avoiding the undesired ones. A little fine copper braid will clean up mistakes.
It's 0402 passives and trying to touch up the edges of QFN IC's where I do break out the really tiny tips.
Please Log in or Create an account to join the conversation.
- btoschi
- Topic Author
- Offline
- Posts: 151
If it had been the FET at the other end (4 in a row, near each motor connector), I would have resolderd it already.
And since I want to have a look at the SWD debug port and use it for binding tests, I scare to toast the remaining parts when trying the impossible (I've already tested with cold iron that I'd touch at least the motor connector and the resistor with my 25W iron).
I've ordered a brand new U818 transmitter for 15€ and then I'll see if it binds with the new boards. As last resort (w/o too much hope though) I have contacted UDI with my problem, lets see if they reply (and If it has any value)
Please Log in or Create an account to join the conversation.
- btoschi
- Topic Author
- Offline
- Posts: 151
I was able to solder wires to RF PCB and sniff SPI - and found that its using frequency hopping.
Channel sequence is (switches every 0.009975s when waiting for bind packets)
21 49 0B 39 10 25 42 1D 31 35 14 28 3D 18 2D 07
Init sequence is
0.000 1 W_REGISTER(RX_PW_P0) 08
0.000 2 W_REGISTER(STATUS) 70
0.000 3 W_REGISTER(RF_SETUP) 27
0.000 4 W_REGISTER(SETUP_RETR) 3A
0.000 5 W_REGISTER(SETUP_AW) 01
0.001 6 W_REGISTER(EN_RXADDR) 01
0.001 7 W_REGISTER(EN_AA) 3F
0.001 8 W_REGISTER(CONFIG) 0F
0.001 9 R_REGISTER(FEATURE) 00
0.001 10 ACTIVATE(73)
0.001 11 W_REGISTER(FEATURE) 00
0.001 12 W_REGISTER(DYNPD) 00
0.001 14 ACTIVATE(53) bank switch to 1
0.001 15 W_REGISTER(00) 40 4B 01 E2
0.002 16 W_REGISTER(01) C0 4B 00 00
0.002 17 W_REGISTER(02) D0 FC 8C 02
0.002 18 W_REGISTER(03) 99 00 39 21
0.002 19 W_REGISTER(04) F9 B6 8A 1B
0.003 20 W_REGISTER(05) 24 06 7F A6
0.003 21 W_REGISTER(0C) 00 12 73 00
0.003 22 W_REGISTER(0D) 46 B4 80 00
0.003 23 W_REGISTER(0E) 41 10 04 82 20 08 08 F2 7D EF FF
0.004 24 W_REGISTER(04) FF B6 8A 1B
0.004 25 W_REGISTER(04) F9 B6 8A 1B
0.009 27 W_REGISTER(07) 70
0.009 28 W_REGISTER(10) A4 84 65
0.009 29 W_REGISTER(0A) A4 84 65
0.010 31 W_REGISTER(07) 70
0.010 32 W_REGISTER(05) 21
0.010 33 FLUSH_RX
0.010 34 W_REGISTER(00) 0F
Thus it listens for 8 bytes payload being send with 250kbps using default RX address 0xE7E7E7 (address width is 3 bytes) on one of these channels.
Anyone knows what the
ACTIVATE(73)
edit:
answering myself, the BK2421 datashee tells us:
activates the following features:
• R_RX_PL_WID
• W_ACK_PAYLOAD
• W_TX_PAYLOAD_NOACK
Since I never sniffed RX side of U817OG board (found in U818A) and U816 boards I cannot tell for sure whether these are hopping too, or not. (That would involve soldering to MINI54ZAN or BK2421, which is out of reach with my soldering skills).
But I now that the transmitter sends on different channels (see Post #18809 ) and it uses address 0xE77EE7 for transmission, thus they cannot work together.
Please Log in or Create an account to join the conversation.
- SeByDocKy
- Offline
- Posts: 1016
The UDI 839 is coming next .... and it would be great if it can be also "deviationed"
Please Log in or Create an account to join the conversation.
- btoschi
- Topic Author
- Offline
- Posts: 151
Anyway, at least I was able to get a Transmitter which speaks that U817B protocol. Same housing and even same PCB (with same text printed on) like the other U818A Transmitters I have. An guess what ... its from a rebranded U816 (not "A").
Multimod nRF isn't working properly and my port of Deviation protocol stack to Arduino (AVR C to be precise) did not it far yet.
Another thing is that I'm almost sure that it will use another variation of this protocol ... (U820 also speaks a slightly different protocol) *gosh*
Please Log in or Create an account to join the conversation.
- SeByDocKy
- Offline
- Posts: 1016
btoschi wrote: Sorry, but my family (two kids, three in two month ) and my job keep my quiet busy ...
Anyway, at least I was able to get a Transmitter which speaks that U817B protocol. Same housing and even same PCB (with same text printed on) like the other U818A Transmitters I have. An guess what ... its from a rebranded U816 (not "A").
Multimod nRF isn't working properly and my port of Deviation protocol stack to Arduino (AVR C to be precise) did not it far yet.
Another thing is that I'm almost sure that it will use another variation of this protocol ... (U820 also speaks a slightly different protocol) *gosh*
Ok Ok ......
Maybe it's completly out of topic .... but maybe it can help you to debug your Arduino implementation
hackaday.com/2014/05/10/reading-2-4ghz-t...ers-with-an-arduino/
Please Log in or Create an account to join the conversation.
- SeByDocKy
- Offline
- Posts: 1016
Please Log in or Create an account to join the conversation.
- PhracturedBlue
- Offline
- Posts: 4402
Alternatively, you can (carefully) scrape off the covering on the traces and solder to those. I don't like doing so, but sometimes it is the easiest way.
Please Log in or Create an account to join the conversation.
- SeByDocKy
- Offline
- Posts: 1016
PhracturedBlue wrote: you can hook the probes to the MCU which likely has much wider pitch (I can see it in the bottom of your pic)
Alternatively, you can (carefully) scrape off the covering on the traces and solder to those. I don't like doing so, but sometimes it is the easiest way.
Clearly easier options Thanks
Please Log in or Create an account to join the conversation.
- SeByDocKy
- Offline
- Posts: 1016
I captured 2 1.1.15 sessons
First : TX on and quad off. I armed the TX then play with right stick, flipping button and then left stick and speed button
mon-partage.fr/f/oPrZM7zm/
Second : quad on, TX on. Binding and armed the TX then play with right stick, flipping button and then left stick and speed button
mon-partage.fr/f/YGxQqtgd/
Please Log in or Create an account to join the conversation.
- btoschi
- Topic Author
- Offline
- Posts: 151
I'm back from holiday and you have SPI traces ready, great job !
Anyway, for the future, its best to export them using hex values from scana logic (MOSI/MISO are ASCII, non-printable characters encoded as e.g. '255', but some 'special rules').
I had to hack Victz' script to cope with that input
Anyway, the protocol looks very familiar.
Basic facts:
8 Bytes Payload
RF Channel 0x23 and RX/TX Address E7 7E E7 used for binding procedure, TX sends its 'Fake random ID' and waits for RX to send back a packet with TX ID and the RX ID (as far as I can tell this is also some kind of random).
After that is starts to use the RX/TX Adress as sent by receiver and ackowledged before (here: D7 C1 B7) and makes use of channel hopping on these channels, takes ~ 5 Seconds for one round.
37 16 2A 3F 1A 2F 08 23 48 0D 3B 12 27 44 1F 33
Looks mostly like the more recently discoverd protocol (note that init sequence slightly differs), but the RX/TX address for bind is e7 7e e7, like in the old protocol. I'll have to re-check that one.
Could you be so kind to capture some more traces of actual bind process, with varying times of rx/tx being powered up ? I just want to be sure that the TX/RX ids vary as I know from my quads and ensure that the channel sequence stays as it is ...
so far it looks like its an easy option for UDI protocol, once I get it started ...
I'm attaching the modified script so everyone can work with it.
Please Log in or Create an account to join the conversation.
- SeByDocKy
- Offline
- Posts: 1016
btoschi wrote: Hi SeByDocKy !
Could you be so kind to capture some more traces of actual bind process, with varying times of rx/tx being powered up ? I just want to be sure that the TX/RX ids vary as I know from my quads and ensure that the channel sequence stays as it is ...
so far it looks like its an easy option for UDI protocol, once I get it started ...
I'm attaching the modified script so everyone can work with it.
Hi great
Yes the UDI U839 is the last model (I guess with the U830, a X4 clone)
Ok I will start to capture more binding process asap (give 2h maximum
More I should receive a second U839 in few days. So a good news in the case if there is a special algorithm for multi users.
Please Log in or Create an account to join the conversation.
- SeByDocKy
- Offline
- Posts: 1016
Please Log in or Create an account to join the conversation.
- btoschi
- Topic Author
- Offline
- Posts: 151
Same Channel sequence (though it starts at different place), TX/RX IDs change pseudo randomly as expected. Protocol is much like the U816/8 V2, but using another RF channel to send out bind packets, and making real use of the very last byte of the payload now (its always 0x4A for data packets on U818 V2).
Last byte of payload of U839 is CRC of all bytes but the first (which indicates type of packet) but anded by 0x3f, thus limited to 0..3f *ouch*
(They must encode the data unary internally, and memory is limited. One and only conclusion I can come up with )
Nevertheless this should be an easy option to add once I have something up and running.
SPI Trace of another quad is highly welcome, and once I find out that its really using other channels, a trace with swapped transmitter should clarify who dicates the channels (if they ever change - I do not expect that from what I have seen with UDI protocols so far).
Please Log in or Create an account to join the conversation.
- SeByDocKy
- Offline
- Posts: 1016
btoschi wrote: Great, thanks for them.
SPI Trace of another quad is highly welcome, and once I find out that its really using other channels, a trace with swapped transmitter should clarify who dicates the channels (if they ever change - I do not expect that from what I have seen with UDI protocols so far).
Ok asap I will receive it,, I will trace also this second one. Anyway, if you have some to try.... you can build either for my Devo 7E or 10
Please Log in or Create an account to join the conversation.
- kr0sh1
- Offline
- Posts: 24
Did development of the UDI U818A protocol ever reach completion?
I've been doing my own research into how the drone communicates for my final university project and, being new to logic sniffing etc, gravitated to your existing work,
I posted my findings on Hackaday.io , on my project page, and there'll be schematics and source code for my design by the end of the month if anyone is interested in automated flight or machine vision,
But I could really do with some help/pointers if anyone has a moment - very very stuck! I can't get the drone to pair with it's original transceiver rigged up to an Arduino and you're the best crowd I've seen for this sort of thing.
Any help is greatly appreciated, many thanks
Please Log in or Create an account to join the conversation.
- PhracturedBlue
- Offline
- Posts: 4402
If you want help here, you need to ask specific questions. You mention a 'transceiver' but in RC, we have a transmitter (the thing with the sticks) and a receiver (the thing in the vehicle) regardless of whether there is bi-di communication. I don't know what issues you are having, so I have no idea what pointers you need. I can tell you that I am unlikely to try to debug someone else's code on Arduino, given that I primarily work on ARM, so if you are looking for a set of eyes, they probably won't be mine. But if you need help on methods, or spi parsing, then I can try to help.
Please Log in or Create an account to join the conversation.
- kr0sh1
- Offline
- Posts: 24
I'm interfacing to the BK2421 on the TX of the UDI U818A, and attempting to sniff the logic coming from it's SPI interface, using a Bus Pirate (logic sniffer) and a simple script,
First off, is wiring straight into the SPI pins of the TX the first thing you'd do to discover it's protocol?
In your opinion, is reverse engineering one of these protocols an enormous amount of work and should I just be using a more supported drone, or could this be achieved in a couple of days?
Please Log in or Create an account to join the conversation.
- PhracturedBlue
- Offline
- Posts: 4402
That said, technically, yes hooking up an SPI sniffer to the Tx is the best 1st step. You need to determine the initialization sequence of the Tx, and the timing and composition of the packets. Generally these are reasonably easy to do. The initialization sequence can just be replayed. The packets are usually 16 bytes unencrypted with 1 or 2 bytes per channel. With an NRF based protocol, you need to worry about whether there is a bi-directional binding scheme, and whether any data from the Rx is used in the channel hopping sequence. Usually the channel-hopping algorithm is the most challenging to figure out. it may be a hard-coded set of channels (which may or may not be transmitted to the Rx ahead of time), or it may be computed based on the Tx and/or Rx ID. Often it is not too difficult to emulate a specific Rx/Tx pair (y replaying the Tx channel hopping scheme(, but then you can't fly multiple vehicles in the same airspace because you need to know the parameters that determine the hopping.
Again, given your goals as I understand them, I think you'd be better off with a different quad as the basis, but if you really want to go forward with this, then read this thread carefully, look at btoschi's existing work, scan the SPI bus and see how your data compares to his. And post here any questions since we will certainly want to incorporate any of your findings into an eventual Deviation protocol.
Please Log in or Create an account to join the conversation.
- victzh
- Offline
- Posts: 1386
Banggood for the request "quadcopter with camera" gives 41 result, ranging from $37 to $880. If you can afford a model from supported list, I'd suggest you to buy a new one.
If you choose to reverse engineer your existing UDI 818, solder to it and publish the SPI traces, we'll definitely help you.
You mentioned Arduino, how exactly did you connect your TX to it? Do you have any other RF modules - nRF24L01+ or Beken (Inhaos) for example?
Please Log in or Create an account to join the conversation.
- Home
- Forum
- Development
- Protocol Development
- UDI R/C U816 / U818 Protocol