Protocol Stacks

In case you are wondering, I haven't been idle the past few days. I'm currently working on understanding the Flysky protocol. This is an easy protocol which I can connect to via SPI reasonably easily. I understand most of it now, so i can theoretically finish the implementation. I'm not sure yet what the easiest way to test it is. I may wait until I have my RaspberryPi, since it should be able to act as a hybrid Tx, allowing interactive programming/debugging, but also be able to talk to the Radio modules.

I'm also waiting of a couple of Receivers to come in from China so I can verify all channels.

My plan is to start with the Flysky using an A7105 board, since it seems simple to program for, and I have both the transmitter module and helis which use it.

Next I'll move onto DSM2 (using a DSM2 module), since the protocol is documented. I don't have any receivers for this yet, so I won't make much progress until they arrive

After that we'll see if I start work on the Walkera protocol or the DSM protocol using the native Walkera module.

I'd be surprised if I have any of the above actually working before the end of June though.

If I understand right, you will use a different transmitter rf module for the Flysky protocol, will you?
And what about the DSM2 protocol? Do you plan to use an other transmitter rf module for it, or use the built in CYRF?

Until we know the Walkera protocol in details, could we use the binaries from the disassembled firmware?

Yes, the Flysky uses a different module (that I bought from China for $3)

Initially the DSM will also use a separate module. this is because the DMS module interface is documented, but the actual DSM protocol is only known by a couple folks (like hammer22) who don't want to document it fully.

We can't use the walkera protocol directly from the binary. It is all interrupt driven and has too many dependencies on specific memory locations and whatnot.

However, as it turns out, rch4x0r did a lot of work on the protocol before he disappeared. With his existing work plus the logic-analyzer traces I've taken, I think I can decipher the DEVO protocol as well.

I'm still working out exactly what is being sent when, and I probably need to wait until I get my RX1202, but I've already made significant progress (again mostly due to rch4x0r's work) in understanding it.

OK.

PhracturedBlue wrote: However, as it turns out, rch4x0r did a lot of work on the protocol before he disappeared.

I haven't seen it. Is it in the code already?

PhracturedBlue wrote: I probably need to wait until I get my RX1202

Wow, straight to 12 channel!

I have converted his analysis into code verbatim, but it is only part of the puzzle, and I haven't checked in the code yet since it isn't compilable as it is.

I figured if I was going to buy a receiver, I might as well get the 'big' one, as the price difference wasn't too high.

PhracturedBlue wrote: I have converted his analysis into code verbatim, but it is only part of the puzzle, and I haven't checked in the code yet since it isn't compilable as it is.

I see, but I was not aware of his analysis. Where is it?
That one on his (now not working) page was about the old 4 channel Walkera protocol, at least when I saw it last time.

PhracturedBlue wrote: I figured if I was going to buy a receiver, I might as well get the 'big' one, as the price difference wasn't too high.

I agree, but yet it is a brave move, because I'm not sure if the DEVO 8 can bind to it with the original firmware, which would make it difficult to study the protocol...

I've made good progress on analyzing the protocol, though I am nowhere near finished.
Channel data is sent differnetly than any other protocol I've looked at so far. the value is signed, with '0' corresponding to the stick being centered and 0x640 corresponding to the stick being at full throw (in either direction). There is a bit in a different byte that indicates which direction the stick moved in. Basically data is stored in a 'signed' word, but the sign bit is not the MSB.

If there is no FixedID set, then the 1st 10 seconds are spent sending binding packets, before switching to data packets. If the FixedID is set, the radio immediately starts sending data packets as it boots up. I haven't spent much time looking at binding or how fixed-id works.

Data packets are sent every 2.4msec, each packet containing either the 1st 4 channels or the 2nd 4 channels.

Every 10 data packets an alternate packet is sent whose contents I do not know.

There are also 5.5 bytes in each data packet whose contents I have not yet analyzed.

1.2msec after the packet is sent, the radio module is queried to see if the receiver acknowledged the transfer. I'm not sure what the Tx does with this info, as it doesn't seem to matter whether it was accepted or not.

If enabled, Telemetry is queried continuously between data packets. I haven't done much analysis of the telemetry side yet.

I've documented most of my progress so far in docs/Devo.txt

I've just about completed the transmit packet documentation. I haven't tried to analyze the fixed-id-setting process (when the fixed-id is saved to the Rx) but otherwise I should be able to build packets with and without fixed-id now. I don't know the channel assignments for channels 5-8, and don't know the syntax of the Telemetry packets either.

Still, I think I have enough to be able to fly by Ladybird with custom firmware. So Ijust need to hook it all together...

Good progress!
I assume you are talking about the devo protocol...

PhracturedBlue wrote: the value is signed, with '0' corresponding to the stick being centered and 0x640 corresponding to the stick being at full throw (in either direction). There is a bit in a different byte that indicates which direction the stick moved in. Basically data is stored in a 'signed' word, but the sign bit is not the MSB.

It's a good resolution then, about 11.5 bit...

PhracturedBlue wrote: Data packets are sent every 2.4msec, each packet containing either the 1st 4 channels or the 2nd 4 channels.

That might change in the DEVO 1: I don't think they use 5ms to send a whole package, so they might double the rate...

PhracturedBlue wrote: Every 10 data packets an alternate packet is sent whose contents I do not know.

That might be some resynchronizing packet, I guess...

PhracturedBlue wrote: 1.2msec after the packet is sent, the radio module is queried to see if the receiver acknowledged the transfer. I'm not sure what the Tx does with this info, as it doesn't seem to matter whether it was accepted or not.

Is it only if telemetry is enabled, or always? In the telemetry settings you can set the alarm "No Signal Warning", it may be related, however it could use the actual received telemetry data for that...

PhracturedBlue wrote: If enabled, Telemetry is queried continuously between data packets. I haven't done much analysis of the telemetry side yet.

You mean the Tx ask for the telemetry data and the receiver answers it? Then probably my previous assumption is false...

I assume you have seen this:
bulldozers' spi log

PhracturedBlue wrote: I've just about completed the transmit packet documentation. I haven't tried to analyze the fixed-id-setting process (when the fixed-id is saved to the Rx) but otherwise I should be able to build packets with and without fixed-id now. I don't know the channel assignments for channels 5-8, and don't know the syntax of the Telemetry packets either.

Still, I think I have enough to be able to fly by Ladybird with custom firmware. So Ijust need to hook it all together...

Cool!

I started to answer your previous post before this one, and see: it took me an hour to post it...

So I went throw the devo.txt and have a few questions:
1. Is the channel max value (=0x640) with 100% or 150% travel adjust?
2. I see that more 4ch packages can follow (for example with first 0x8d, 0x8e, etc), but it would longhten the communication from 4.8ms to 9.6ms, which on all the three frequencies already takes 28.8ms. Isn't that too much in your opinion? The fact that frequency changes every 4 packet hints, that 4x4=16 channel data is the maximum.
3. According to rcH4x0r's work, in the old Walkera protocol they sent trim values with the data bytes, which is indeed unnecessary, but I miss the fail save values to be transmitted at least in the binding packages. Because the receiver should remember that values to apply them when the transmitter signal is lost.

I assume the Devo10 and Devo12 use the same packet size (there are 4 channels per packet). So they should use 7.2msec to send all 12 channels. I don't think that is too much honestly. Once I have the Rx1202 I will try sending the 3rd data packet and verify the frame rate

You are correct that channels 9-12 are on the 0x8d packet (actually it will be either 0xad or 0xcd since the upper nibble is the number of channels being sent)

It is possible that the '0x87' packet contains trim or failsafe codes. I didn't have them enabled when I was capturing from SPI. I will verify though

The 0x640 represents 100%. I assume it is larger if the limit is 150%. Again, I'll verify it.

Frequency change actually has nothing to do with the number of channels. frequency already can change at any point since the 0x87' packets are part of the rotation.

The query message 1.2msec after sending the data packet is present on both the 8 and 8s firmware (though in the 8s there are actually 4 queries back-to-back even if telemetry is off).

I believe the receiver is always transmitting telemetry data, and that the transmitter just checks to see if any data is available when telemetry is enabled. I need to spend some more time looking at the packets to figure it all out. The cyrf6936 seems to queue received data, so the firmware appears to be checking if there is anything in the queue and reading it if there is (but only when telemetry is on).

FYI, I'm using the same equipment as bulldozer (a Salea logic analyzer) to do the analysis. The big difference is that I had rcH4x0r's initial work on the Devo8 protocol to help get things to make more sense. Sorry if I'm a bit vague on that; he didn't post it publicly and I'd rather he make the decisions on who sees it....In any case, it is no longer very relevant since I've documented everything he gave me plus everything I've found already.

PhracturedBlue wrote: I assume the Devo10 and Devo12 use the same packet size (there are 4 channels per packet). So they should use 7.2msec to send all 12 channels. I don't think that is too much honestly. Once I have the Rx1202 I will try sending the 3rd data packet and verify the frame rate

OK, I have doubled the package only by assuming that the whole package shoul fit in one frequency hop, so it can be max 4x4ch package.

PhracturedBlue wrote: I believe the receiver is always transmitting telemetry data, and that the transmitter just checks to see if any data is available when telemetry is enabled. I need to spend some more time looking at the packets to figure it all out. The cyrf6936 seems to queue received data, so the firmware appears to be checking if there is anything in the queue and reading it if there is (but only when telemetry is on).

I hope that you are aware of the telemetry bug in the Walkera firmware, (which they corrected with the latest fw upgrade) and use the latest v0.8 fw.

PhracturedBlue wrote: The big difference is that I had rcH4x0r's initial work on the Devo8 protocol to help get things to make more sense. Sorry if I'm a bit vague on that; he didn't post it publicly and I'd rather he make the decisions on who sees it....

I see, it's OK!
It was just weird, that everybody was referring his findings on his page, which I was not aware of...
Actually I have the contents of his page, but it is about the old 4ch Walkera protocol, which has nothing to do with the DEVO protocol.
Unfortunately I saved them in .mht format, which was not a good idea, but I can reformat it if you would like.

I think it would be useful to capture what he documented in the deviation/docs directory. If you want to send me his docs, I can format them appropriately for text. I can handle mht just fine.

I looked over the 2405 documentation rcH4x0r did, but unfortunately the key piece of this is missing (maybe he never posted it) which is the contents of the 16 byte packet. From what I see, it looks remarkably like the Devo protocol actually, but the core of it is the formatting of the channel data, and that is missing.

Weird. I think I do remember it, but I don't see any missing link to it...

Well, after many hours trying to get the firmware (which runs fine on the PC) to run on my Devo8, I finally discovered a subtle issue that seems to be responsible for my issues. gcc was transparently replacing printf() with puts() when printf had only one argument. I don't know where the puts implementation came from, but it was hanging the STM32 processor. So with the proper switch in place, it is no longer doing that, and the firmware is now running on the Devo8 again.

It was a very trying afternoon to figure this out, so I'm calling it a night. Hopefully starting tomorrow, I can start experimenting with connecting the radio module to my Devo protocol and actually be able to control my ladybird with my custom firmware sometime this week.

I feel for you! It's not too reassuring, that the compiler may introduce bugs...

Some notes/questions about the new devo.txt:
1. In line 8: 2402D is a 4 channel transmitter...
2. If the upper nibble of the first byte is the number of channels, do you think it means we are limited to 15 channels?
3. In the binding and data packets when auto binding is used, there is a generated ID instead the fixed one, isn't it?
4. The GUI allows failsafe values in the -125..+125 range...

Thanks. I fixed the failsafe and 2402 stuff. that was just typos. Due to how it is sent, it isn't possible to every have failsafe go to 150%. A signed 8bit value can only contain -128 to +127, so for failsafe we are limited to this range.

As for the upper nibble, they don't make anything bigger than a devo12 today, so we are actually limited to 12channels. There is no reason that the 1st nibble has to correspond to the number of channels, so they could send 'oxf0' and translate it as 18ch if they wanted to.

My limited analysis seems to indicate that the Devo uses the last fixed id when in auto-binding mode (i.e. the id does not change on subsequent power-ons). It it doesn't really matter what it uses though since the bind packets contain everything that is needed. I do need to look at some more logs to confirm this behavior though.

One more small typo: it is "2402D"! It might be confusing, because there was a 2402, but it is not devo compatible. (I have one...)