PXX work

er9x is the best known firmware. It has a superb range of features and is well supported by the community. Well worth trying out.
Post Reply
bertrand35
9x Developer
Posts: 2764
Joined: Fri Dec 30, 2011 11:11 pm
Country: -

PXX work

Post by bertrand35 » Mon Jan 02, 2012 9:35 am

Hi all,
Anybody has some info on the PXX protocol? I am ok to help to introduce it in er9x / gruvin9x, but I don't know anything except the struct used which looks promising (model match feature?)
Thanks,
Bertrand.


Addition by MOD:
The Tx FW can be downloaded here: http://code.google.com/p/er9x/downloads ... me=PXX.zip


User avatar
erazz
9x Developer
Posts: 682
Joined: Tue Dec 27, 2011 6:25 pm
Country: -
Location: NJ-USA
Contact:

Re: PXX work

Post by erazz » Mon Jan 02, 2012 1:39 pm

Excellent!

I think it's a great idea to work on it. I'm attaching the protocol documentation.

.... Or I will once Rob allows the .doc and .pdf extensions....
Z

BEWARE - WE ARE IN THE AIR!!!
What goes up... Should be controlled by a 9X!

User avatar
MikeB
9x Developer
Posts: 16622
Joined: Tue Dec 27, 2011 1:24 pm
Country: -
Location: Poole, Dorset, UK

Re: PXX work

Post by MikeB » Mon Jan 02, 2012 3:50 pm

bertrand35 wrote:Hi all,
Anybody has some info on the PXX protocol? I am ok to help to introduce it in er9x / gruvin9x, but I don't know anything except the struct used which looks promising (model match feature?)
Thanks,
Bertrand.
I have some code already written to produce the pulse sequence with CRC. I have also been looking into freeing off the second serial port to allow that to be used in synchronous mode to output the pulse stream. However, in the light of DSM2 developments where a second, faster, interrupt is now avalable for sending the actual pulses, it may be useful to look into using that mechanism to deliver the pulses, as long as we can make the pulses array large enough. Have a look at the DSM2 code posted in the DSM2 thread, I have a union on the pulses array so that for a lot of short pulses we use it as bytes not words.

Mike.
pcm.zip
(2.09 KiB) Downloaded 483 times
erskyTx/er9x developer
The difficult we do immediately,
The impossible takes a little longer!

User avatar
Rob Thomson
Site Admin
Posts: 4542
Joined: Tue Dec 27, 2011 11:34 am
Country: United Kingdom
Location: Albury, Guildford
Contact:

PXX work

Post by Rob Thomson » Mon Jan 02, 2012 5:46 pm

erazz wrote:Excellent!

I think it's a great idea to work on it. I'm attaching the protocol documentation.

.... Or I will once Rob allows the .doc and .pdf extensions....
You should be ok now to upload :)


Sent from my iPhone using Tapatalk
Slope Soaring, FPV, and pretty much anything 'high tech'
...........if you think it should be in the wiki.. ask me for wiki access, then go add it!

User avatar
erazz
9x Developer
Posts: 682
Joined: Tue Dec 27, 2011 6:25 pm
Country: -
Location: NJ-USA
Contact:

Re: PXX work

Post by erazz » 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.
Attachments
protocol.pdf
(140.64 KiB) Downloaded 2876 times
Z

BEWARE - WE ARE IN THE AIR!!!
What goes up... Should be controlled by a 9X!


bertrand35
9x Developer
Posts: 2764
Joined: Fri Dec 30, 2011 11:11 pm
Country: -

Re: PXX work

Post by bertrand35 » Tue Jan 03, 2012 9:22 pm

erazz wrote:OK,

Here's the protocol. This is based on FrSky's suggestions. I have a version of their FW that supports this.
Wow! Very interesting. I think I will give priority to this work.
Is it possible you send me this firmware?
Bertrand.

User avatar
Rob Thomson
Site Admin
Posts: 4542
Joined: Tue Dec 27, 2011 11:34 am
Country: United Kingdom
Location: Albury, Guildford
Contact:

PXX work

Post by Rob Thomson » Tue Jan 03, 2012 9:41 pm

Any idea roughly when this protocol option will be 'official' and working?


Sent from my iPhone using Tapatalk
Slope Soaring, FPV, and pretty much anything 'high tech'
...........if you think it should be in the wiki.. ask me for wiki access, then go add it!

User avatar
MikeB
9x Developer
Posts: 16622
Joined: Tue Dec 27, 2011 1:24 pm
Country: -
Location: Poole, Dorset, UK

Re: PXX work

Post by MikeB » Tue Jan 03, 2012 10:40 pm

We have 19 bytes (plus bit stuffing) to send. This is a minmum of 152 bits, each of which requires two state changes (low and high) a total of 304 states minimum. We have to output these on an interrupt at 8uS or 16uS intervals. I've done some work towards the DSM2 protocol, creating an alternative set of interrupt routines to generate the 125k baud serial data stream by bit banging. This is similar so we may be able to combine the twom, but need to keep the interrupt routine as short as possible. I've attached a zip of the two files I have, the pcm.cpp file is slightly different to the previous one as the bit protocol changed at some point after I originally wrote the code. The pulses.cpp file generates the DSM2 bits. Pat Mackenzie has been changing this further so there may be some merging of changes to do.

I'm not sure we can afford to have a 300+ byte array storing the complete data sequence for bit banging. We also don't know whether the FrSky module needs to see all the bits packed end to end, or if we could have a gap in the middle. If we are allowed a gap we could try something like:

Create the output stream for the first 6 bytes, extending the last '1' output beyond 8uS to (say) 40uS. Follow this with the output stream for the next 6 bytes again with the last '1' output beyond 8uS to (say) 40uS. Let the CAPT interrupt run sending the first 6 bytes worth of data. Have the OCRB set to interrupt (NOBLOCK) at 35uS. when the first 6 bytes have been sent, the CAPT interrupt will carry on with the next 6 bytes of data. The OCRB interrupt now builds the next 4 bytes of data at the beginning of the buffer, again with a long '1' at the end. When the OCRB interrupt occurs again, move the pointer for the CAPT interrupt back to the beginning so it will carry on with the next 4 bytes, meanwhile the OCRB interrupt builds the rest of the output stream with a last '1' of (say) 100 uS. The CAPT interrupt will get to the end of the data stream, waiting for the 100uS to have passed. The OCRB interrupt will pick up on this last long gap, and change the CAPT time to 20mS, before the 100uS has passed.
The OCRB interrupt could now set OCRB to interrupt after (say) 16mS, when it starts preparing the next data packet ready for the CAPT interrupt to send.
This should be able to use the CAPT interrupt exactly as I have written it for the DSM2 protocol, only the OCRB interrupt would need to change. This interrupt is not as time critical, so should have time to see which protocol is running, and where it is in the processing of the protocol.

With the DSM2 protocol, the standard OCRA interrupt actuall took too long to respond to 2 consecutive interrupt, 8uS apart sometimes. Pat had to remove the jitter monitoring code to make it work before I added the CAPT and OCRB interrupts. This means keeping the CAPT interrupt as short as possible is really important, otherwise, when it is running, there won't be much processor time left for anything else. If necessary it may need to be hand crafted in assembler.

That's my thoughts so far.

Mike.
pcm1.zip
(5.31 KiB) Downloaded 377 times
erskyTx/er9x developer
The difficult we do immediately,
The impossible takes a little longer!

User avatar
MikeB
9x Developer
Posts: 16622
Joined: Tue Dec 27, 2011 1:24 pm
Country: -
Location: Poole, Dorset, UK

Re: PXX work

Post by MikeB » Sat Jan 14, 2012 5:34 pm

OK, as I have been looking at the DSM2 stuff, and PPM16, I pulled this in with it. I reckon I now have a working set of interrupts that drive out the PXX data stream. The input is two bits for each output bit. If the input is 10, it sends 16uS of 0 and 8uS 0f 1, if the input is 11 it sends 8uS of 0 and 8uS of 1. The two bits are needed to keep the interrupt routine short. Pack the bits together in a byte, lsb first and away we go. Max packet size is around 25 bytes of data, so this only takes up 50 bytes, so we have enough space to do it all.

Just need to pull all this together now.

Mike.
erskyTx/er9x developer
The difficult we do immediately,
The impossible takes a little longer!

User avatar
erazz
9x Developer
Posts: 682
Joined: Tue Dec 27, 2011 6:25 pm
Country: -
Location: NJ-USA
Contact:

Re: PXX work

Post by erazz » Sat Jan 14, 2012 7:09 pm

Great,

You know what. I think it'd be productive if you keep on this track (e.i bit-banging). I wan to explore using the built in functions to drive this - possibly requiring a HW change.
Sounds like a plan!

I think this protocol should now be our top priority as it's a huge advancement and would further the capabilities of the FW.
Let's make it happen!
Z

BEWARE - WE ARE IN THE AIR!!!
What goes up... Should be controlled by a 9X!

User avatar
MikeB
9x Developer
Posts: 16622
Joined: Tue Dec 27, 2011 1:24 pm
Country: -
Location: Poole, Dorset, UK

Re: PXX work

Post by MikeB » Sat Jan 14, 2012 8:44 pm

Ok, folks, try this for size.
I haven't tried to keep the code small (yet), just get it working.
TWO new protocols added PXX and PPM16. Also, slight changes to DSM2 interrupt routines, I needed TIMER 1 compare B for PXX, changed DSM2 to use compare C. (B has faster access to the OCR register)
The changed sources, and the standard and FRSKY hex files attachec in a zip.
With the PXX, I bit stuff if there are 5 1s in a row, as specified. It is possible the flag byte (0x7E) should NOT be bit stuffed, they are flags because the do have 6 1s in a row.
So in PPM16 mode, 8 extra channels are output on the trainer socket. Set the PPM number of channels to the number required to go to the normal tx module, the next 8 go to the trainer socket. I haven't fully checked this yet, if you set 10 to go to the normal module, you may get funnies on the extra.
NB, this is very much a test version, please don't fly with it unless you are confident it is OK.

Mike.
er9xPxxPpm16.zip
(168.8 KiB) Downloaded 414 times
erskyTx/er9x developer
The difficult we do immediately,
The impossible takes a little longer!

User avatar
wheelspinner20
Posts: 175
Joined: Tue Dec 27, 2011 6:22 pm
Country: -
Location: Michigan, U.S.

Re: PXX work

Post by wheelspinner20 » Sat Jan 14, 2012 8:53 pm

Guys, great work, I think. First, sorry to bother you, but could you describe, in laymans terms please, what one might do with the extra channels.? Is this only for the big fullhouse sailplane guys? or I guess what I mean is, whats the real world simple term application for this particular "expansion of our possibilities"...
Thats correct, I have no imagination. Help me out here.

Pat
no more quippy little latin phrases.! Its old

User avatar
Rob Thomson
Site Admin
Posts: 4542
Joined: Tue Dec 27, 2011 11:34 am
Country: United Kingdom
Location: Albury, Guildford
Contact:

PXX work

Post by Rob Thomson » Sat Jan 14, 2012 10:05 pm

Imagine a big scale model.

Retracts.
Bomb door
Flaps
Lights
Sound effects


Very quickly use more than 8 channels :)




Sent from my iPhone using Tapatalk
Slope Soaring, FPV, and pretty much anything 'high tech'
...........if you think it should be in the wiki.. ask me for wiki access, then go add it!

User avatar
wheelspinner20
Posts: 175
Joined: Tue Dec 27, 2011 6:22 pm
Country: -
Location: Michigan, U.S.

Re: PXX work

Post by wheelspinner20 » Sat Jan 14, 2012 10:12 pm

OK, thanks, would one then need a 2nd 6 or 8 ch receiver in the model? + power to it I assume. What about the 2nd radio? Could you hack power and ppm signal to a seperate module and just mount it to the main radio, or would the close proximity of the antennas be an issue?
no more quippy little latin phrases.! Its old

User avatar
Rob Thomson
Site Admin
Posts: 4542
Joined: Tue Dec 27, 2011 11:34 am
Country: United Kingdom
Location: Albury, Guildford
Contact:

Re: PXX work

Post by Rob Thomson » Sat Jan 14, 2012 10:20 pm

The way I would do it is:

1 x FRSKY MODULE in the normal module slot.
1 x FRSKY DIY MODULE inside the tx, using the top antenna. (wired to the ppm on the trainer jack internally)

So.. two transmitters running off one box.

Channel 1-8 goes via rear module
Channel 8-16 goes via internal module.

Note! This would only apply to the PPM16 option. The FRSky PXX would be a somewhat different config
Slope Soaring, FPV, and pretty much anything 'high tech'
...........if you think it should be in the wiki.. ask me for wiki access, then go add it!

User avatar
cre8tiveleo
Posts: 1434
Joined: Tue Dec 27, 2011 6:13 pm
Country: -
Location: Ontario,(GTA North)
Contact:

PXX work

Post by cre8tiveleo » Sun Jan 15, 2012 2:25 am

rob.thomson wrote:...

Channel 1-8 goes via rear module
Channel 9-16 goes via internal module.
fixed... :D

User avatar
GrootWitbaas
Posts: 358
Joined: Tue Dec 27, 2011 8:57 pm
Country: -
Location: Germany

PXX work

Post by GrootWitbaas » Sun Jan 15, 2012 6:28 am

rob.thomson wrote:
Channel 9-16 goes via rear module
Channel 1-8 goes via internal module.
Fixed again



Sent from my iPhone using Tapatalk
General trouble maker and wannabee Dev

User avatar
jhsa
Posts: 19038
Joined: Tue Dec 27, 2011 5:13 pm
Country: Germany

Re: PXX work

Post by jhsa » Sun Jan 15, 2012 8:40 am

some people already have the telemetry hardwired from the rear module.. Do you expect them to go and mess about with it again?? Just a thought ;)
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

User avatar
MikeB
9x Developer
Posts: 16622
Joined: Tue Dec 27, 2011 1:24 pm
Country: -
Location: Poole, Dorset, UK

Re: PXX work

Post by MikeB » Sun Jan 15, 2012 9:10 am

My intention was for PPM16 to be veru easy for the user. Send the 'extra' 8 channels out the trainer socket, plug another 9x into that, and set it uo as though it is a master, but using a permanent switch instead of the trainer switch to keep it always sending the 8 channels it gets on its trainer socket. No special wiring, and only plug it up when you need the extra channels.

PXX is totally different. It needs an updated FrSKY tx module (new firmware) and supports 16 channels directly.

Mike.
erskyTx/er9x developer
The difficult we do immediately,
The impossible takes a little longer!

User avatar
jhsa
Posts: 19038
Joined: Tue Dec 27, 2011 5:13 pm
Country: Germany

Re: PXX work

Post by jhsa » Sun Jan 15, 2012 10:39 am

Hi Mike PXX is the way to go then, so would it be possible to update our existing modules??.. That would be wonderful..
And how would we get the 16 channels at the other end??
Thanks
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

pmackenzie
Posts: 236
Joined: Tue Dec 27, 2011 11:19 pm
Country: -
Location: Don Mills, Ontario

Re: PXX work

Post by pmackenzie » Thu Jan 19, 2012 5:48 am

Does anyone know if PXX will work in both modes (one-way and two way)?
Most of my FrSky models use the one-way V-series receivers.

What frame rate are they going to support? Will this actually make the high speed mode they have in the receivers be of some use?

Thanks,

Pat MacKenzie

User avatar
Rob Thomson
Site Admin
Posts: 4542
Joined: Tue Dec 27, 2011 11:34 am
Country: United Kingdom
Location: Albury, Guildford
Contact:

Re: PXX work

Post by Rob Thomson » Thu Jan 19, 2012 6:39 am

I would have thought that was a function of the module - not the protocol. But may be wrong :D
Slope Soaring, FPV, and pretty much anything 'high tech'
...........if you think it should be in the wiki.. ask me for wiki access, then go add it!

pmackenzie
Posts: 236
Joined: Tue Dec 27, 2011 11:19 pm
Country: -
Location: Don Mills, Ontario

Re: PXX work

Post by pmackenzie » Thu Jan 19, 2012 11:23 am

The present receivers have a "high speed" mode that simply outputs the same info twice every frame - totally useless feature.
Analog servos can't use it and it does nothing to improve the performance of digital servos.

The system also uses a fixed frame rate which adds on average a 1/2 frame delay to system latency.
(Since the outgoing signal is not in sync with the incoming one most of the time the data going out will be from the previous frame)
As we have seen from the DSM2 work the Spektrum RF module getting serial data matched the RF frame rate to the incoming serial data. Then it is down to the receiver to cope with it.

One of the goals of PXX should be to fix both, otherwise its only useful feature will be to add model match - not worth the effort IMO.

From an RF point of view the FrSky stuff is great, but when viewed from a performance/latency perspective it is actually quite poor.

Pat MacKenzie

MGeo
Posts: 21
Joined: Fri Feb 03, 2012 4:43 pm
Country: -

Re: PXX work

Post by MGeo » Fri Feb 03, 2012 10:15 pm

Are the FrSky PXX Tx/Rx module loads available to the general public or limited distribution at this point?

Thanks,
George

User avatar
erazz
9x Developer
Posts: 682
Joined: Tue Dec 27, 2011 6:25 pm
Country: -
Location: NJ-USA
Contact:

Re: PXX work

Post by erazz » Sun Feb 05, 2012 2:42 am

It's a work in progress.
We're constantly improving and now waiting for FrSky to recover from the new year so we'll get some answers.

It's not even beta at this stage so if you're not a hard core hacker I'd advise you to stay away. It's not flightworthey at the moment as far as I'm concerned.
Z

BEWARE - WE ARE IN THE AIR!!!
What goes up... Should be controlled by a 9X!

MGeo
Posts: 21
Joined: Fri Feb 03, 2012 4:43 pm
Country: -

Re: PXX work

Post by MGeo » Sun Feb 05, 2012 10:47 am

Warning accepted.

I am still a bit confused. Is the PXX module code (the binaries loaded in the FrSky Tx and Rx modules, as opposed to the ATMega code for the 9X transmitter board) unique? I am a assuming it is in order to accept bitstream input in place of PPM.

Is it an FrSky product, or did the group on this board develop it? If it is FrSky, is it publically available or closed?

Thanks,
George

User avatar
MikeB
9x Developer
Posts: 16622
Joined: Tue Dec 27, 2011 1:24 pm
Country: -
Location: Poole, Dorset, UK

Re: PXX work

Post by MikeB » Sun Feb 05, 2012 8:32 pm

The code for the modules is from FrSky I believe. I assume when it is all tested they will make it publically available.

Mike.
erskyTx/er9x developer
The difficult we do immediately,
The impossible takes a little longer!

User avatar
erazz
9x Developer
Posts: 682
Joined: Tue Dec 27, 2011 6:25 pm
Country: -
Location: NJ-USA
Contact:

Re: PXX work

Post by erazz » Sat Feb 11, 2012 3:33 pm

New version up today. I fixed some things as per FrSky's instructions (not stuffing the head or tail)
I'm uploading this so they can test it. I still don't have it working.

Please test guys, maybe something's wrong with my setup.
Z

BEWARE - WE ARE IN THE AIR!!!
What goes up... Should be controlled by a 9X!

User avatar
Rob Thomson
Site Admin
Posts: 4542
Joined: Tue Dec 27, 2011 11:34 am
Country: United Kingdom
Location: Albury, Guildford
Contact:

PXX work

Post by Rob Thomson » Sat Feb 11, 2012 3:46 pm

Do we need to do any wiring for Pxx to work?

Or just flash the tx & rx with alternative firmwares?


Sent from my iPhone using Tapatalk
Slope Soaring, FPV, and pretty much anything 'high tech'
...........if you think it should be in the wiki.. ask me for wiki access, then go add it!

User avatar
erazz
9x Developer
Posts: 682
Joined: Tue Dec 27, 2011 6:25 pm
Country: -
Location: NJ-USA
Contact:

Re: PXX work

Post by erazz » Sat Feb 11, 2012 4:07 pm

Just flash the module and rx.
Z

BEWARE - WE ARE IN THE AIR!!!
What goes up... Should be controlled by a 9X!


Post Reply

Return to “er9x”