Did XJT protocol change?

[JimDrew]

I have had one person report that v2.2.0 and later firmware does not work with the XPS XtremeLink module in XJT D-16 mode. V2.1.x and earlier works fine. So, did something change in the XJT protocol between with the release of v2.2.0?

Thanks!

[Kilrah]

I think I remember it was found that a couple of bits were sent wrong.

[JimDrew]

Is there some kind of documentation or release note about this? I would like to get it fixed if there is actually a problem. So, far only one person has had this issue. I don't have it with the new X10S that I received (stock Horus firmware).

Thanks!

[Kilrah]

Well I guess your best bet besides officially requesting the protocol spec from FrSky which you probably should have done is to browse through the commit history in OpenTX.

[JimDrew]

I looked at the OpenTx PXX support and there doesn't appear to be much difference between 2.1 and 2.2, but 2.1 works and 2.2 doesn't. However, it seems to be much worse of a problem than I thought.

I have a brand new X10S. It came with 1.1.02 firmware. I put our JR module into the external port and changed its mode to XJT. That worked perfectly. I then went to the FrSky website and downloaded the X10S 1.1.03 and 1.1.04 firmware upgrades. I backed up the 1.1.02 files (via USB), and then installed the 1.1.04 firmware into the FIRMWARE folder, ejected the virtual device, and powered off. I powered up with ENTER held down updated the firmware, and confirmed in the INFO menu that it was in fact 1.1.04. The files in the FLASH directory were then copied to the internal flash folders. Rebooted and now our module doesn't work. I tried 1.1.03 with the same result. The odd thing is that I re-installed the 1.1.02 files and it still does not work. PPM + or - works (our module auto-detects polarity), but XJT does not. So, I got out the logic analyzer and captured the XJT output - and what do you know - it's not a XJT signal. It's a square wave that goes forever, not a typical series of bytes every 18ms as you would expect.

So, its apparent that something has dramatically changed. Is FrSky now doing something to prohibit 3rd party modules from working with XJT D16?

proper XJT protoocol

after upgrading firmware

[Kilrah]

Umm are you sure you're looking at the right thing? The first capture isn't anything close to a PXX signal either.

The change is minor, if I remember well something like just the very last transition was missing or was in excess at the end of a frame.

[JimDrew]

Yes, the first capture is 100% correct. It is from my Taranis set to output the XJT D16 protocol. The header byte is 0x7E and the frame also ends with 0x7E, but there is data after that (presumably for telemetry, which I ignore). This has been working perfectly this way for years now. With the firmware update to the X10S, the signal being output is a square wave now, not a signal with a changing pattern.

I was told by a customer that rolling back the OpenTx firmware to v2.1.x makes the Taranis (and X10S) work. Starting with v2.2.0, it no longer works.

I have not tried OpenTx since putting on the Taranis years ago. It's a bit of a hassle to install on the X10S, and I would like to keep this X10S with the stock firmware. I guess I will have to get the Taranis out and update it to see if it also outputs a square wave, or the normal XJT D16 data. I am guessing at this point that perhaps FrSky checks the external module to make sure it is their's before outputting the XJT protocol. I ordered an external XJT module and some receivers to test this theory.

Looking at the OpenTx source code, my reverse engineering of the protocol seems to be correct. From my PIC assembly source code:

Code: Select all

;**********************************************************************
; XJT D16 protocol - determine from DSO/logic analyzer timings
; XPS XtremeLink module
;
; This routine captures a stream of bits from a FrSky module output
; pin that is using the XJT D16 protocol.
;
; A packet of 20 bytes + a 4 bit preamble are sent.  There could be more
; that 164 bits of data sent due to bitstuffing (not allowing more than
; five 1 bits in a row).  The data is not serial in nature, instead the
; bits are represented by a time value equal to each bit.  A 1 bit is
; 6us long, and a 0 bit is 14us long.  There is always a 10us space
; between bits.
;
; NOTE!  Signal we get is inverted from original due to the level converter!!
;
; 0 bit = 6us low/10us high
; 1 bit = 14us low/10us high
;
;
; --------+       +----------+                 +----------+
;         |       |          |                 |          |
;         |   0   |          |        1        |          |
;         |       |          |                 |          |
;         |       |          |                 |          |
;         +-------+          +-----------------+          +---------
;
;         |  6us      10us   |       14us          10us   |
;         |-------|----------|-----------------|----------|--------
;         |       16us       |            24us            |
;
;
; Bitstuffing - when more than five 1 bits are in a row, a zero bit is
; inserted afterwards.  This zero bit must be ignored during the decoding
; of the data.
;
; Packet format:
;
; Preamble - four 1 bits in a row to start the frame
;
; 0x00 - Sync, 0x7E (sync header ID)
; 0x01 - Rx ID, 0x?? (receiver ID number, 0x00-0x??)
; 0x02 - Flags 1, 0x?? (used for failsafe and binding)
; 0x03 - Flags 2, 0x00 (reserved)
; 0x04-0x06, Channels 1/9 and 2/10
; 0x07-0x09, Channels 3/11 and 4/12
; 0x0A-0x0C, Channels 5/13 and 6/14
; 0x0D-0x0F, Channels 7/15 and 8/16
; 0x10 - 0x00, always zero
; 0x11 - CRC-16 High
; 0x12 - CRC-16 Low
; 0x13 - Tail, 0x7E (tail ID)
;
; Channels are encoded as 3 bytes = 2 channels, each with
; 12 bits of data.  The upper bit (bit 11) determines if the
; channel data belongs to channels 1-8 (clear) or channels
; 9-16 (set).
;
; Each set of 3 bytes (for 2 channels) is encoded as:
;
; Byte 0.H    Byte 0.L    Byte 1.H    Byte 1.L    Byte 2.H    Byte 2.L
;----------------------------------------------------------------------
; CH1:b7-b4   CH1:b3-b0   CH2:b3-b0   CH1:b11-b8  CH2:b11-b8  CH2:b7-b4
;
;
; The channel data is 12 bits decoded as:
;
; Bit11 = 0 for channels 1-8, 1 for channels 9-16 **NOTE*** always clear
; this bit before decoding!
;
; Temp = D16 value - 1024 (subtract 10 bit center)
; Temp = Temp * .666667
; PWM = Temp + 1500 (add PWM center offset)
;
;
; The CRC16 is poly 0x1189 (X^16+X^12+X^8+X^7+X^3+1), and is calculated
; using bytes 0x01 to 0x10 (inclusive).

[Kilrah]

What you say makes no sense.

Your capture shows standard async serial. PXX as it is fed to an external module on both Taranis and Horus on any version is (and which you confirm in your code) not that at all, it's a different encoding where 0s and 1s are just pulses with different durations.

The only place where PXX is transported over async serial is between a Horus and its internal module, which there's no reason you should be looking at.

In any case be clear about what you're referring to, what radio, what firmware, what version, what exact settings, and what pins/signals you're looking at.

[JimDrew]

Ignore what the caption of the analyzer says (async serial). The decoding shown is a custom plug-in I made just to decode the XJT's bitstuffed datastream. We have sold hundreds (maybe as many as a thousand by now) JR transmitter modules specifically for the Taranis (and now X10/X12) owners. This has worked for *years*, and now with the release of the OpenTx 2.2.x firmware, it doesn't. So, the question is: what changed?

You can see from your capture that there are in fact varying times representing the different 0's and 1's that are encoded. You can see from my Horus capture that it is a perfect 50/50 duty cycle square wave that is continuously output (no breaks for frames). The issue with the Horus is likely a different issue (coincidence?). I am guessing that they might be doing something that ID's the module and that's why it doesn't work. I will know as soon as my FrSky XJT external module arrives.

In the mean time, if there is something that has specifically changed in the XJT D16 protocol between v2.1.x and v2.2.0, I would really like to know.

[Kilrah]

Last comment, I don't know why I'm wasting my time.

I already told what changed AFAIK, one or 2 transitions at the end of the frame and nothing else.
The waveform your "custom plugin" is shown supposedly working on has more than 2 pulse widths and is thus not PXX as we know it (the capture I posted), period. It DOES look like async serial though.

There is no bidirectional communication or detection, PXX is sent out when external module is set to XJT/Dx regardless of what module is connected (if any, works same with none) on all versions of FrOS and OpenTX.

This is just captured from an X10 with FrOS 1.1.04 on the PPM pin of the external module connection.

So either you're doing something wrong or your hardware is somehow faulty, with more bets on the former given the rest of your report still makes no sense, and since you won't clarify the whole discussion is pointless.
Also FrOS puts out PXX in a continuous stream with no break between frames so neither of your captures can come from FrOS.

[MikeB]

Looking at the waveform in your first capture, it does look exactly like async serial at 250kbps to me.

Mike.

[JimDrew]

Perhaps this will help you. Look at the pictures I just took of my Taranis that was used for the capture shown above.

So, this data is coming out of the external module port on the PPM pin, and our module decodes this just fine.

I suppose this could actually be the data sent to the internal module, not the external module. I did this over 3 years ago. I will have to re-capture the output from the external module port to be certain, but I agree that does not look like 4 preamble bits and the 16us/24us bit times.

What I don't understand is why the 1.1.02 Horus firmware that came with my X10S worked with our module perfectly until it was updated to 1.1.04, and even going back to 1.1.02 no longer works. If the Horus is always outputting a continuous data stream like you say, then our module would definitely not work. it is expecting a break of at least 1ms to determine the start/end of the frame.

[Kilrah]

I suppose this could actually be the data sent to the internal module, not the external module. I did this over 3 years ago.

PXX over UART to internal module only started with X12S, so didn't exist 3 years ago.

What I don't understand is why the 1.1.02 Horus firmware that came with my X10S worked with our module perfectly until it was updated to 1.1.04, and even going back to 1.1.02 no longer works.

Makes no sense indeed, gotta be a measurement error or faulty hardware.

[JimDrew]

I suppose this could actually be the data sent to the internal module, not the external module. I did this over 3 years ago.

PXX over UART to internal module only started with X12S, so didn't exist 3 years ago.

Hmmm.. well that capture was done on May 5th, 2014 according to the time stamps on the logic file.

What I don't understand is why the 1.1.02 Horus firmware that came with my X10S worked with our module perfectly until it was updated to 1.1.04, and even going back to 1.1.02 no longer works.

Makes no sense indeed, gotta be a measurement error or faulty hardware.

Faulty hardware? My X10S works in PPM + or - modes just fine with my module. The same module works fine in the Taranis with OpenTx 2.0.x in XJT D-16 mode. It just doesn't work with the X10S and any version of the Horus firmware with XJT D-16 mode. BUT, the X10S definitely worked with our module in XJT-D16 mode before I changed the firmware. So, I guess updating it (even with the same firmware version) changed something.

Any idea why the XJT output with the Horus firmware would send the protocol over and over without a break between frames? This seems like an incredible waste of CPU time (unless it's done via DMA).

A change to the XJT protocol occurred between OpenTx v2.1.x to v2.2.0. You mentioned that it was something new added to the end of the packet. Is this change backwards compatible with existing FrSky XJT modules, or is a firmware upgrade to the module required to support the change to the protocol?

Thanks for help with this. This is rather annoying!

[bob195558]

Suggestion: maybe try re-flashing the problem newest firmware, maybe something failed during it's flashing ?

[Kilrah]

Any idea why the XJT output with the Horus firmware would send the protocol over and over without a break between frames? This seems like an incredible waste of CPU time (unless it's done via DMA).

I think it's their take at trying to reduce latency without doing it right by synchronisation. Best would be for the module to request a frame at the right moment and the radio sending it then, but I guess spamming the module continuously also means it always has somewhat more recent information when it needs it...
It's certainly done via DMA.

A change to the XJT protocol occurred between OpenTx v2.1.x to v2.2.0. You mentioned that it was something new added to the end of the packet. Is this change backwards compatible with existing FrSky XJT modules

Yes. Signal is now to spec, before 2.2 it wasn't but the modules weren't fussy about it and accepted it anyway.

[JimDrew]

So, if the Horus firmware beats on the module output continuously, how is the actual frame rate established? With the receiver itself?

My FrSky XJT module arrives today, so I should be able to resolve this mystery. I did reflash the firmware on the X10S numerous times, tried various SYSTEM folders (from different versions), etc. All with the same results.

[Kilrah]

So, if the Horus firmware beats on the module output continuously, how is the actual frame rate established? With the receiver itself?

No by the module. It sends at 9ms interval, and sends the last full dataset it received from the radio.

I did reflash the firmware on the X10S numerous times, tried various SYSTEM folders (from different versions), etc. All with the same results.

And tried to install OpenTX for comparison?