PXX work
-
- 9x Developer
- Posts: 2764
- Joined: Fri Dec 30, 2011 11:11 pm
- Country: -
PXX work
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
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
Re: PXX work
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....
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!
BEWARE - WE ARE IN THE AIR!!!
What goes up... Should be controlled by a 9X!
- MikeB
- 9x Developer
- Posts: 17993
- Joined: Tue Dec 27, 2011 1:24 pm
- Country: -
- Location: Poole, Dorset, UK
Re: PXX work
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.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.
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!
- Rob Thomson
- Site Admin
- Posts: 4543
- Joined: Tue Dec 27, 2011 11:34 am
- Country: United Kingdom
- Location: Albury, Guildford
- Contact:
PXX work
You should be ok now to uploaderazz 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....
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!
...........if you think it should be in the wiki.. ask me for wiki access, then go add it!
Re: PXX work
OK,
Here's the protocol. This is based on FrSky's suggestions. I have a version of their FW that supports this.
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 3582 times
Z
BEWARE - WE ARE IN THE AIR!!!
What goes up... Should be controlled by a 9X!
BEWARE - WE ARE IN THE AIR!!!
What goes up... Should be controlled by a 9X!
-
- 9x Developer
- Posts: 2764
- Joined: Fri Dec 30, 2011 11:11 pm
- Country: -
Re: PXX work
Wow! Very interesting. I think I will give priority to this work.erazz wrote:OK,
Here's the protocol. This is based on FrSky's suggestions. I have a version of their FW that supports this.
Is it possible you send me this firmware?
Bertrand.
- Rob Thomson
- Site Admin
- Posts: 4543
- Joined: Tue Dec 27, 2011 11:34 am
- Country: United Kingdom
- Location: Albury, Guildford
- Contact:
PXX work
Any idea roughly when this protocol option will be 'official' and working?
Sent from my iPhone using Tapatalk
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!
...........if you think it should be in the wiki.. ask me for wiki access, then go add it!
- MikeB
- 9x Developer
- Posts: 17993
- Joined: Tue Dec 27, 2011 1:24 pm
- Country: -
- Location: Poole, Dorset, UK
Re: PXX work
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.
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.
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!
- MikeB
- 9x Developer
- Posts: 17993
- Joined: Tue Dec 27, 2011 1:24 pm
- Country: -
- Location: Poole, Dorset, UK
Re: PXX work
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.
Just need to pull all this together now.
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
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!
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!
BEWARE - WE ARE IN THE AIR!!!
What goes up... Should be controlled by a 9X!
- MikeB
- 9x Developer
- Posts: 17993
- Joined: Tue Dec 27, 2011 1:24 pm
- Country: -
- Location: Poole, Dorset, UK
Re: PXX work
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.
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.
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!
- wheelspinner20
- Posts: 175
- Joined: Tue Dec 27, 2011 6:22 pm
- Country: -
- Location: Michigan, U.S.
Re: PXX work
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
Thats correct, I have no imagination. Help me out here.
Pat
no more quippy little latin phrases.! Its old
- Rob Thomson
- Site Admin
- Posts: 4543
- Joined: Tue Dec 27, 2011 11:34 am
- Country: United Kingdom
- Location: Albury, Guildford
- Contact:
PXX work
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
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!
...........if you think it should be in the wiki.. ask me for wiki access, then go add it!
- wheelspinner20
- Posts: 175
- Joined: Tue Dec 27, 2011 6:22 pm
- Country: -
- Location: Michigan, U.S.
Re: PXX work
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
- Rob Thomson
- Site Admin
- Posts: 4543
- Joined: Tue Dec 27, 2011 11:34 am
- Country: United Kingdom
- Location: Albury, Guildford
- Contact:
Re: PXX work
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
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!
...........if you think it should be in the wiki.. ask me for wiki access, then go add it!
- cre8tiveleo
- Posts: 1434
- Joined: Tue Dec 27, 2011 6:13 pm
- Country: -
- Location: Ontario,(GTA North)
- Contact:
PXX work
fixed...rob.thomson wrote:...
Channel 1-8 goes via rear module
Channel 9-16 goes via internal module.
- GrootWitbaas
- Posts: 358
- Joined: Tue Dec 27, 2011 8:57 pm
- Country: -
- Location: Germany
PXX work
Fixed againrob.thomson wrote:
Channel 9-16 goes via rear module
Channel 1-8 goes via internal module.
Sent from my iPhone using Tapatalk
General trouble maker and wannabee Dev
Re: PXX work
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
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
- MikeB
- 9x Developer
- Posts: 17993
- Joined: Tue Dec 27, 2011 1:24 pm
- Country: -
- Location: Poole, Dorset, UK
Re: PXX work
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.
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!
The difficult we do immediately,
The impossible takes a little longer!
Re: PXX work
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
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
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
-
- Posts: 236
- Joined: Tue Dec 27, 2011 11:19 pm
- Country: -
- Location: Don Mills, Ontario
Re: PXX work
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
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
- Rob Thomson
- Site Admin
- Posts: 4543
- Joined: Tue Dec 27, 2011 11:34 am
- Country: United Kingdom
- Location: Albury, Guildford
- Contact:
Re: PXX work
I would have thought that was a function of the module - not the protocol. But may be wrong
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!
...........if you think it should be in the wiki.. ask me for wiki access, then go add it!
-
- Posts: 236
- Joined: Tue Dec 27, 2011 11:19 pm
- Country: -
- Location: Don Mills, Ontario
Re: PXX work
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
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
Re: PXX work
Are the FrSky PXX Tx/Rx module loads available to the general public or limited distribution at this point?
Thanks,
George
Thanks,
George
Re: PXX work
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.
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!
BEWARE - WE ARE IN THE AIR!!!
What goes up... Should be controlled by a 9X!
Re: PXX work
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
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
- MikeB
- 9x Developer
- Posts: 17993
- Joined: Tue Dec 27, 2011 1:24 pm
- Country: -
- Location: Poole, Dorset, UK
Re: PXX work
The code for the modules is from FrSky I believe. I assume when it is all tested they will make it publically available.
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
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.
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!
BEWARE - WE ARE IN THE AIR!!!
What goes up... Should be controlled by a 9X!
- Rob Thomson
- Site Admin
- Posts: 4543
- Joined: Tue Dec 27, 2011 11:34 am
- Country: United Kingdom
- Location: Albury, Guildford
- Contact:
PXX work
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
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!
...........if you think it should be in the wiki.. ask me for wiki access, then go add it!
Re: PXX work
Just flash the module and rx.
Z
BEWARE - WE ARE IN THE AIR!!!
What goes up... Should be controlled by a 9X!
BEWARE - WE ARE IN THE AIR!!!
What goes up... Should be controlled by a 9X!