PXX work
- MikeB
- 9x Developer
- Posts: 17990
- Joined: Tue Dec 27, 2011 1:24 pm
- Country: -
- Location: Poole, Dorset, UK
Re: PXX work
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.
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.
erskyTx/er9x developer
The difficult we do immediately,
The impossible takes a little longer!
The difficult we do immediately,
The impossible takes a little longer!
Re: PXX work
I wasn't objecting to your correction - simply elaborating on the difference for the sake of anyone that needed elaboration.Kilrah wrote:which is why I corrected
Re: PXX work
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?
- MikeB
- 9x Developer
- Posts: 17990
- Joined: Tue Dec 27, 2011 1:24 pm
- Country: -
- Location: Poole, Dorset, UK
Re: PXX work
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.
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.
erskyTx/er9x developer
The difficult we do immediately,
The impossible takes a little longer!
The difficult we do immediately,
The impossible takes a little longer!
Re: PXX work
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.
- MikeB
- 9x Developer
- Posts: 17990
- Joined: Tue Dec 27, 2011 1:24 pm
- Country: -
- Location: Poole, Dorset, UK
Re: PXX work
The code for both openTx and er9x/ersky9x is open source so your best bet is to look at that.
Mike.
Mike.
erskyTx/er9x developer
The difficult we do immediately,
The impossible takes a little longer!
The difficult we do immediately,
The impossible takes a little longer!
Re: PXX work
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 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.
Re: PXX work
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?
Re: PXX work
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.
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.
Re: PXX work
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.
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.
Re: PXX work
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.
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.
Re: PXX work
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
"..... 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
Re: PXX work
All for both internal and external, but it was ONLY 2.0.10. 2.0.11 was released a day later and fixed it.
Re: PXX work
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.
Re: PXX work
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.
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
Code: Select all
channels set to 0%- 1500
0x0C 0x04 0x0C 0x04
0xC0 0x40 0xC0 0x40
0x00 0x00 0x00 0x00
0x0C 0x04 0x0C 0x04
0xC0 0x40 0xC0 0x40
0x00 0x00 0x00 0x00
0x0C 0x04 0x0C 0x04
0xC0 0x40 0xC0 0x40
0x00 0x00 0x00 0x00
0x0C 0x04 0x0C 0x04
0xC0 0x40 0xC0 0x40
0x08 0x08 0x08 0x08
channels set max +100%
0x07 0x0F 0x07 0x0F
0x70 0xF0 0x70 0xF0
0x00 0x00 0x00 0x00
0x07 0x0F 0x07 0x0F
0x70 0xF0 0x70 0xF0
0x00 0x00 0x00 0x00
0x07 0x0F 0x07 0x0F
0x70 0xF0 0x70 0xF0
0x00 0x00 0x00 0x00
0x07 0x0F 0x07 0x0F
0x70 0xF0 0x70 0xF0
0x08 0x08 0x08 0x08
Re: PXX work
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 ?
Re: PXX work
The PXX doc isn't public.
Re: PXX work
Hint, the openTX and Ersky9x code is open source..
João
Sent from my BLN-L21 using Tapatalk
João
Sent from my BLN-L21 using Tapatalk
My er9x/Ersky9x/eepskye Video Tutorials
https://www.youtube.com/playlist?list=PL5uJhoD7sAKidZmkhMpYpp_qcuIqJXhb9
Donate to Er9x/Ersky9x:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=YHX43JR3J7XGW
https://www.youtube.com/playlist?list=PL5uJhoD7sAKidZmkhMpYpp_qcuIqJXhb9
Donate to Er9x/Ersky9x:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=YHX43JR3J7XGW
Re: PXX work
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)
(I want to control a R9M lite Tx and use an ESP32 cause it is quite fast)