Analyzing Jeti EX-bus and Spirit FBL

Foreword

Well, this was a hard nut to crack, that’s for sure. Not only was I forced to read some protocol-specs but also this article required quite extensive background-work and a whole lot measurements and logging to be done.

Please do note a few things!

• I’m just an RC-hobbyist as anyone else.
• I’m in no way professional software- or protocol-engineer in any way.
• All opinions and conclusions are my own unless otherwise stated.
• This is WorldWideWait, always use source-criticism.

Well, not when that’s out of the way, here we go!

What’s this all about?

The recent UDI-issues with REX-receivers firmware 1.00 together with one incident with a strange behavior and crash made it apparent that the EX-bus should be examined a bit also. And on some perverted way this is fun :)

Equipment used in this article

• Jeti DS-16 fw 4.00
• REX6 fw 1.00 and 1.01e
• Spirit FBL fw 1.3.2
• Spirit.bin from Jetimodel and Spirit-System. (Explained later)
• Rigol DS1104Z Oscilloscope
• A lot of coffee!

Failsafe on and off, transmitter on 100Hz.

I used two different versions of Spirit.bin-file in transmitters “Devices”-folder. It has come to my attention that Jetimodel is shipping old version of the file. (Thanks to jmackey @Helifreak for pointing this out!) Confirmed by Spirit-Systems developer here, so grab the correct file here and replace the old file in your transmitter. (Reboot to make changes take effect.)

Initial findings

It certainly is not easy for manufacturers of different devices to keep up with different revisions of other’s firmware’s and other changes in systems. Thankfully there are specifications to follow so we can read up on these things.

EX-bus protocol-specs are available on Jetimodel page but there is a catch. Part of the protocol is proprietary ie. not public. So, this means we are not allowed to “get inside” the whole traffic between Spirit and REX, unfortunately. But, we can find something, let’s have a look.

Protocol specifications we need to know

We need to read on some things before we start, here’s the essentials:

• Receiver is Master, Spirit is Slave
• Master always initiates communication
• Serial speed is 125kBaud 8-N-1 or 250kBaud 8-N-1
• Upon init Slave confirms the communication-speed, after that the speed is not changed dynamically by Master

Also for packet data there is one important thing to note, master (receiver) send two types of packets to slave (Spirit):

• A packet with 4ms break after it so slave can respond (Header second byte 0x01)
• A packet without the 4ms break, no answer from slave expected (Header second byte 0x03)

And further:

• Masters packet with header 0x3E (first byte) is a packet containing channel data
• Masters packet with header 0x3D (first byte) is a packet requesting telemetry
• Packets sent by slave have a header first byte of 0x3B

Communication speed and relevant settings in transmitter

PPM and UDI take use of the transmitters setting “Device explorer” -> “REX6” -> “General Settings” -> “Output period”, EX-bus protocol does not. Regardless of the value of this setting EX-bus packets are timed in 10ms intervals. That means the only setting that affect this timing is transmitters frequency, and like it’s said many times, usually today it’s 100Hz. Looking at the scope this is confirmed, changing the value to 50Hz the EX-bus packets are 20ms apart.

This is quite wise in my opinion. Transmitter can send values in 10ms intervals at most, why would the receiver send values with double frequency? Also, there is plenty of time to keep the communication “clean” with no cluttered packets floating around.

Alright, we all like pictures, let’s take look.

EX-bus in the oscilloscope:

The size of EX-packet does vary a bit depending on the data it contains, but generally it seems to be around 3.3ms in length. You can see in the picture above a slightly longer packet on the left side. Also there are two things contributing to the “signal purity”, the packet is short and they are 10ms apart, that means the issue with REX firmware 1.00 and UDI is not possible.

I also confirmed this by doing the test’s with both 1.00 and 1.01e firmwares, I could not find any difference in signaling between them.

Looking at the actual packet and to identify what is from master (receiver) and what is from slave (Spirit) we need to read the actual data:

We know Spirit and REX talk to each other with 125kBaud speed, so setting that and looking for the header’s data 0x3E (Decimal is 62) we can trigger scope to that packet. We can confirm a few things here

• Packet interval is 10ms
• The data is what the protocol says it should be.

I was also curious what and how often Spirit is responding, so let’s search for that.

Setting the trigger to 0x3B (Decimal 59) finds the data. Once again, both units work as they should:

• Master (Receiver) asks for data giving slave (Spirit) time to respond
• Slave responds right-away as can clearly be seen in the picture above, response is right after the asked information.

We can also see in the picture that Spirit’s response is different in signal strength by approximately 0.3V which is insignificant in this application.

Findings of “anything strange”?

I put the receiver and gyro to a test-bench and had them on for about 45 minutes while shaking them more or less violently around, sometimes even hitting them a bit, all to provoke some true errors.

Came up with nothing basically, no lost communications, no lost signals, no nothing. Totally clean logs except for some obvious extreme vibration-mentions. I even connected my power-hungry Savox-servos from my 800 Xxtreme to Spirit to tease it even more, no errors even them.

So I was unable to re-produce the behavior jmackey had with his setup. Good for me of course but I really would have liked to find out the reason for that.

Who did what to what firmware?

After the jmackey’s incident and UDI-findings both Spirit and REX have got some updates. Let’s take a look at the relevant parts. (Not listing the whole changelog.)

Spirit mentions “Better EX Bus compatibility with REX receivers.” According the developer it is not related to this issue: “We have released the firmware update to fix different, minor problem related with the new transmission protocol and is absolutely not solution for this issue.” (Helifreak-post here.)

REX’s update mentions “Increased minimal gap between UDI and ExBus data packets.” Ok, they fixed the UDI-issue. But hang on a minute here. “And EXBus…” Uhh, what gap? Protocol states there’s the 4ms gap and packets are by design sent with 10ms apart? What am I missing here?

I could not get any packet’s to “jump around” to anywhere near how they did on UDI and firmware 1.00. So I am a bit interested in this. I’ll send a line to Jetimodel and ask for more information, they have been very forthcoming on these issues before so I’ll update this article after eventual response from them.

Where to from here?

Well. I’m going to get first-hand experience with Spirit and EX-bus quite soon. My build of a small fun-heli is almost done so we’ll see how it goes. I know that after doing the background-work to this article I’m confident to use EX-Bus and Spirit in my heli.

Other than that the general rule still applies, it there’s anything strange happening to your heli, investigate thoroughly. Always make sure that safety comes first, and nothing else.

Now, it was a long (and theoretically dry) article, go out and fly!