UDI R/C U816 / U818 Protocol

Just quickly posting my raw sniff captures, debating changing drone but I'm not entirely sure how much work this is going to be.

My key reason for mapping the protocol is I'm building a collective robotics platform that utilises machine vision as part of a 'payload', almost like an automated swarm of sensors. I'm trying to prove that drones can band together and intercommunicate to save power and navigate more efficiently.

I've already invested in three UDI U818As as part of my project, and it was my grave assumption that they had a similar/symmetrical protocol to this example , as it's based on the BK2421 and I started out connecting the TXs transmitter directly to my microcontroller via the SPI pins to eliminate possible hardware incompatibilities.

I'll post up my analysis of the sniff when I have something that differentiates from (toschi's?) work.

Hey victzh, thanks for the two-cents,

I'm using an Arduino Pro Mini, although purely for compatibility's sake - I'd normally use a Teensy ARM M4 - with the original BK2421 transceiver wired to the SPI pins,

I do have several nRF24L01 lying around however, and I did try one out earlier with a test sketch that printed a "BAD PREAMBLE" to the serial console, although it did say it detected a carrier, think I have a picture somewhere....

Would've gotten more (traces?) of the SPI exchange but I noticed something very odd - the logic sniffer was actually halting the MISO<->MOSI flow of commands and preventing the drone from pairing. Bizarre. Anyone else had that problem?

Because of that, I wasn't able to capture the exact moment the drone binds, only the moment before and after. I'll check Dangerous Prototypes for a workaround.

I will switch to OLS LogicSniffer in a second then - that will give full timing annotations.

I've annotated my initial findings of the TX in it's paired state and found two specifics:

1.) The TX transmits an ID packet, every 12th cycle, with a different header/start value
2.) Every 14th cycle the ID packet has another unique packet beforehand with different values enclosed

Were either of these things previously noted? I can't see any real pattern to the rest of the data packets however, their start packets almost seem to be randomly rotating between beginning with 0xE1, 0x25 and 0x27.

I'm not sure which of these things are significant, and which don't help but I'll keep running with it until I notice something big.

I've tried posting this three times and it's failed each time when I try to attach anything, is there an attachment limit on the forum? I keep getting booted back to the main page.

Attachments, heavily compressed...

I see. Unfortunately, your assumption about the protocol was wrong - it's a very popular chip and there are probably dozens of various protocols (if you count small, but sometimes incompatible variations).

Beken connected to Arduino will do. I have a TX implemented like this, you probably need to replace the code reading the stick positions with communication with PC.

I never dealt with OLS traces though I have one. I prefer Saleae. Some people here already traced this heli before, I'll try to look at their traces and compare with yours.

The square brackets in my trace text file dump denote the triggering on the SCN pin, just managed to crash my machine capturing via OLS so it's taken a little while but I've got them,

Thanks victzh, I've got some code from the earlier parts of this post I might try and adapt but it's a little complex for me - my background is mainly in C and not C++ with classes etc,

I'm going to give all this until the middle of tomorrow and if I can't turn it around I'll need to ask you guys for advice on an already supported, solid, drone model possibly on a different thread.

Now I've got the traces and all the data, but it's mainly in .ols format. I know it's a big ask, but if you guys could download Logic Sniffer OLS , it would allow you to see the entire trace, zoom in and out, and run SPI analysis with full control, and otherwise do what you couldn't with a text file. It's a Java app so completely self-contained and very small and safe. Once you've opened one of the ols files, just go to Tools > SPI Analyser and the application will do the rest for you.

I've ordered a 'proper' logic analyser, which will arrive on the 14th - I did some digging on the Bus Pirate and it has only 4k of sampling depth, making it useless for doing thousands of captures - the new one has 1GB. I'll be using Saleae for the next sniff also.

So I'll continue with my hardware design, and leave the TX as an empty slot, then check back in when I have some proper data for you.

That's a good question, and that's something I've done already in the past using a PWM signal and an RC filter with a Hubsan X4, but the device I'm building is a portable, drone-mounted, payload. There's quite a few occasions, at my lab, where they've hacked together base-stations using your suggestion, but I'm going for a self-contained product rather than a system as such.

I'll start another thread or PM you about which drone you'd suggest for the project in terms of existing support. I'm still going to post my findings next week, however.

What drone depends on payload. The platform you chose is a bit limited in several ways - the motors are weak, they're collector type motors so the lifetime is not very good, it has gear box - potential weak point as well. It can be airborne for a very limited time - 5-7 minutes. Also, UDI changed their protocol many times - they don't bother at all and consider it not as a line of models, but just as separate plastic cheap toys.

Good for a prototype, not so good for a product.

I've created this thread to discuss this further .

General UDI support in Deviation looks to be quite weak, I'm guessing the lack of a unified protocol is the cause.

Hubsan seem to be a solid make, but I'll leave those thoughts for the other thread.

I've got a capture of two states of the UDI U818A TX, is that enough to keep things moving?

Saleae is a much better program! I can see why people use it - twinned with a better logic analyser I've got traces for days

Is it possible I haven't exported them correctly, or have used the wrong sample rate or SPI 'clock rate'?

Also, for future reference, which is more helpful; the CSV file exports or the data and settings saves for Saleae? Or something else?

I took a look at the traces and compared with SeBy's U839 and concluded that UDI U818A and U839 use the same protocol.
May be I am missing something, but if you could upload some code into your Arduino connected to nRF24L01 or Beken we can check U818a binding.

Can you connect it as follows:
CE - Arduino pin 9
CSN - pin 10
MOSI - pin 11
MISO - pin 12
SCK - pin 13

I'll finish up Arduino code tomorrow, it's 4am here and I'm a bit sleepy