openrcforums

Have a look at: http://www.rcgroups.com/forums/showpost ... ount=13558, for some timings idea.
A lot of the latency is in the RF link and the pulse output delay. The Rx sends a servo pulse every 18mS, so if an updated position arrives between pulses, you have to wait until the next pulse time, hence some of the variability. er9x won't be a lot different. Unless someone does some specific timings I can't give anything more accurate.

Mike.

Kilrah wrote:which is why I corrected

I wasn't objecting to your correction - simply elaborating on the difference for the sake of anyone that needed elaboration.

Is there a current document for the PXX/DJT D16 protocol? The document shown early in this thread talks about maybe extending the protocol to 16 channels. I would like to add this protocol to our existing module. I see from the logic analyzer capture that the frames are 9ms. Is 100% of the 16 channels worth of data transmitted every 9ms or is it broken up between two transmissions?

It has been extended to 16 channels, 8 channels are sent every 9 mS. Which module is this you want to add it to?

There is a document, but FrSky have asked for it to be restricted. It may be worth you asking them directly, with a reason why you want it. They have said they will supply the SPort documentation under the same concept.

Mike.

This is our XtremeLink module, which is competition to FrSky. Since the individuals that were going to add the Xtreme protocol to Taranis have decided there is a conflict of interest, they won't be doing it. So, I have opted to support the DJT D16 protocol directly. I just need to know the actual protocol. The data I have captured does not match the original datasheet. It appears that no bit stuffing is done because there are numerous cases of more than 5 consecutive identical bits (both polarities). It appears that only the channel data is actually bitstuffed, the ID byte (0x7E), receiver #, etc. are not included.

The code for both openTx and er9x/ersky9x is open source so your best bet is to look at that.

Mike.

I have decoded the stream. I see a packet every 9ms that is 20 bytes long. I set the Taranis for external module using XJT D16, CH1-16. I have channel 1 set to 125% (2140us) and channels 2-16 set to 100% (1500us).

I see this data stream:

Packet 1:

0x7E, 0x00,0x00,0x00 - this is Sync, Rx ID, Flags1, Flags2 (this seems correct)
0xC0,0x07,0x40,0x00,0x04,0x40,0x00,0x04,0x40,0x00,0x04,0x40,0x00
0xD1,0x00,0x7E (CRC16 + Sync)

Packet 2:

0x7E, 0x00,0x00,0x00 - this is Sync, Rx ID, Flags1, Flags2
0x00,0x0C,0xC0,0x00,0x0C,0xC0,0x00,0x0C,0xC0,0x00,0x0C,0xC0,0x00
0x6A,0x3A,0x7E


So, now I just need to figure out the bit packing that is used for the channels. I will set different channel values until I figure it out.

I have had reports by several people that v2.0.8 was the last version of the firmware that works with the Taranis and the XJT D16 emulation of our module. Any idea what changed?

Any more details than "does not work"?

Nothing's supposed to have changed, except maybe a detail about allowing SWR display in telemetry data or not. Not even sure it was merged yet, but shouldn't affect control anyway.

The only details I have are the module no longer sees a valid XJT D16 signal - the LED on our module stays solid red like there is no data. Normally, the LED will toggle on every valid incoming packet. Going back to v2.0.8 or earlier results in everything working correctly.

I am still using the original firmware that came with the Taranis, so I will upgrade it and see if I can see something different in the data stream.

Yep, good idea, check with the current version of course. Can't see anything obvious changed in PXX code since 2.0.3.
2.0.10 however had all protocols broken due to a compiler issue. If your guys all upgraded to 2.0.10, noticed it didn't work, went back to 2.0.8 and never updated again it might well be OK with further versions.

Hy Kilrah,
"..... 2.0.10 however had all protocols broken due to a compiler issue..."

All Protokolls at the external modul socket ?

PPM too?

Because I have at Taranis Plus and V2.013 lots of problems with div Moduls at external moduls socket
Orange, Multiprotokoll Modul
all with PPM


But only with Taranis Plus and not with Taranis A or B

Helle

All for both internal and external, but it was ONLY 2.0.10. 2.0.11 was released a day later and fixed it.

Thanks for the info! I just updated to v2.0.13 and I will do some testing. I have had a few people report that v2.0.13 works fine, so perhaps people were trying to use v2.0.10 and that is the cause.

I see something interesting here,
I started cracking Frsky X protocol from using spi dump file from XJT and X4.
I identified most of the X protocol bytes.It remain to identify data,I t seems that 16 channelsl are encoded in 4 frames.
see below only relevant data It looks like PXX frame bytes.

erazz wrote: ↑Tue Jan 03, 2012 4:33 pm OK,

Here's the protocol. This is based on FrSky's suggestions. I have a version of their FW that supports this.

Hi
I'm looking for the latest documentation of the PXX protocol. I've only found the doc above from 2012 (1st side of this thread).
Is there a newer (and complete) one available ?

The PXX doc isn't public.

Kilrah wrote: ↑Mon Apr 01, 2019 3:09 pm The PXX doc isn't public.

Hi Kilrah
thanks for information - but not the information I like.....

Hint, the openTX and Ersky9x code is open source..

João

Sent from my BLN-L21 using Tapatalk

Hello, I'm trying to output PXX out of an ESP32 but i'm quite new to outputting such data. Can anyone help me please?
(I want to control a R9M lite Tx and use an ESP32 cause it is quite fast)