XPS module protocol

openTx has introduced a range of new features, ideas and bling. It is fast becoming the firmware of choice for many users. openTx will run on ALL current hardware platforms, including the gruvin9x and sky9x boards. Work has already started to support the new FrSky X9D radio!
JimDrew
Posts: 23
Joined: Tue Dec 10, 2013 4:59 pm
Country: -

XPS module protocol

Post by JimDrew » Wed Jan 22, 2014 7:58 pm

We have sold about 50 XPS JR modules for people wanting to use them with the Taranis, and I am getting questions from customers concerning the speed of using PPM vs. other protocols. Our module works fine in PPM mode (once you set the shift to be correct), and you can use up to 16 channels - but its pretty slow. We have our Xtreme protocol that is used for our receivers/X10+ units that could deliver data to the Tx module very fast, supporting sub-10ms frame rates for 16 channels of data. Is the Taranis' module output port pin fast enough to handle 250Kbps data? I am not sure if that output is serial or bit-banged and how much CPU time is available. If it can handle this speed, I can give you guys the protocol if you want to support it. I am not a C programmer, so I won't be of any help.. but the OpenAero2 project is using the Xtreme protocol, and that is written in C and is available to check out. Thanks!

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

Re: XPS module protocol

Post by MikeB » Wed Jan 22, 2014 8:50 pm

It should be possible, the PXX protocol to the XJT module basically has transisitions every 8uS (125kbps). It is driven from a hardware timer, but that is updated using DMA so very little processor overhead while sending the data.
I believe there is already code developed to simulate serial data using this in order to support custom DSM2/X modules (those taken from e.g. a dx4e). It should be possible to handle a new protocol at a different speed (I just looked at the receiving code, the protocol looks to be similar to existing ones).

The Turnigy 9XR-PRO will also be available soon. This also uses an ARM processor so there may be some more sales for you there. Probably even easier to add the protocol as that hardware has a serial port driving the module pin.

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

User avatar
Kilrah
Posts: 9602
Joined: Sat Feb 18, 2012 6:56 pm
Country: Switzerland

Re: XPS module protocol

Post by Kilrah » Wed Jan 22, 2014 9:03 pm

Hi,

The output is not a serial port so it would have to be bit-banged, but by hardware (timer/DMA) so I suppose it would be able to handle it. This approach is currently used for the DSM2 protocol for use with modules scavenged from low cost radios and works fine (although the bitrate is about half of yours in both cases).

The current volunteer team already has quite a lot on its plate (we have a major release that has been in the works for > 6 months already that still has a lot of open things), so it could be added to the list but without any guarantees regarding an ETA for implementation. If you found someone in your users who have coding skills and are interested in it (I imagine there would be some in the OA2 team if they implemented the decoding) we'd be happy to integrate their work.

JimDrew
Posts: 23
Joined: Tue Dec 10, 2013 4:59 pm
Country: -

Re: XPS module protocol

Post by JimDrew » Wed Jan 22, 2014 9:16 pm

I am not so much interested in sales of modules, I am more concerned about reducing the latency. Everything in our system runs at 250Kbps (over-air speed and local packets), so it can support frames as low as about 3ms with 7 channels. I know the standard frame rate with the DJT setup is suppose to be 18ms, which is WAY better than PPM skew that occurs when exceeding 8 channels. So, whatever I can do to help integrate support for the Xtreme protocol, just let me know. The protocol is:

Code: Select all

; Xtreme Tx packet protocol
;
; The packet varies in length based on the number of channels being sent,
; which is determined by the channel mask.  A set bit in the channel mask
; indicates the channel is present in the data stream.  Channels are sequential
; from lowest to highest (1 to 16).  An 8 bit checksum of the entire data packet
; is sent as the last byte.  Note, it is possible to output any number of channels
; (up to a max of 16) every frame.  Nothing is hard coded.  For more than 16
; channels, banks are used to select the channel bank.  See below.
;
; Serial protocol: 8N1 (8 data bits/no parity/1 stopbit, baudrate = 250,000 bit/s
;
;
; [Packet ID] [Flags] [MaskH][MaskL] [data1] [data2] .... [data16] [8 bit checksum]
;
; Packet ID = 0x58
;
; Flag bits 7/6/5 determine the actual channel definition as a 3 bit
; value * channel number as follows:
;
; 765 - bits for channel definition
; ---
; 000 = channels 1-16
; 001 = channels 17-32
; 010 = channels 33-48
; 011 = channels 49-64
; 100 = channels 65-80
; 101 = channels 81-96
; 110 = channels 97-112
; 111 = channels 113-128
;
; bit4-bit0 = reserved (used for telemetry and requests)
;
; Mask High/Low = 16 bit mask with LSB being the lowest channel number
;
; data1, data2, data3, etc. = channel1, channel2, etc. - 16 bits per channel, big endian, MSB first
; the value of the channel is in 1/4 microseconds (250ns), ie 1502.00us = 1502 *4 = 6008 (0x1778)
; 1502.75us = 6011 (0x177B).
;
; Chksum = all data bytes added together
;
; Example packet with 8 channels with a value of 1500us :
;
;  ID     Flgs    Mask H/L    < ch1 >     < ch2 >     < ch3 >     < ch4 >     < ch5 >     < ch6 >     < ch7 >     < ch8 >   ChkSum
; 0x58    0x00   0x00 0xFF   0x17 0x70   0x17 0x70   0x17 0x70   0x17 0x70   0x17 0x70   0x17 0x70   0x17 0x70   0x17 0x70   0x8F
;
; Example only updating 4 channels (1,2,3, and 7) with a value of 1500us:
;
;  ID     Flgs    Mask H/L    < ch1 >     < ch2 >     < ch3 >     < ch7 >    ChkSum
; 0x58    0x00   0x00 0x47   0x17 0x70   0x17 0x70   0x17 0x70   0x17 0x70    0xBB
;
; Example only updating 4 channels (1,2,3, and 9) with a value of 1500us:
;
;  ID     Flgs    Mask H/L    < ch1 >     < ch2 >     < ch3 >     < ch9 >    ChkSum
; 0x58    0x00   0x01 0x07   0x17 0x70   0x17 0x70   0x17 0x70   0x17 0x70    0x7C



Last edited by JimDrew on Sun Jan 26, 2014 4:12 pm, edited 1 time in total.

JimDrew
Posts: 23
Joined: Tue Dec 10, 2013 4:59 pm
Country: -

Re: XPS module protocol

Post by JimDrew » Sun Jan 26, 2014 4:07 pm

the PXX protocol to the XJT module basically has transisitions every 8uS (125kbps).
Is there detailed info on this format (other than what's in the C source code)? Like a simple chart or list of bytes and their functions? Supporting the DJT would be a start while waiting for someone to step up to the bounty being offered. Thanks.


User avatar
Kilrah
Posts: 9602
Joined: Sat Feb 18, 2012 6:56 pm
Country: Switzerland

Re: XPS module protocol

Post by Kilrah » Sun Jan 26, 2014 5:44 pm

What do you mean? Implement the protocol in your own modules so that they can be used with the XJT setting on the Taranis instead of doing it the other way?

AcBates
Posts: 40
Joined: Fri Jan 24, 2014 5:43 pm
Country: -

Re: XPS module protocol

Post by AcBates » Tue Jan 28, 2014 1:10 pm

Kilrah wrote:What do you mean? Implement the protocol in your own modules so that they can be used with the XJT setting on the Taranis instead of doing it the other way?
That has been the typical XPS way; reverse engineer the module protocol to make a module that is lower latency. e.g. Aurora 9, JR 11X.

Implementation of the Xtreme protocol is much more interesting though, the means to output 32 channels without the two module method. It is a shame that a 32 channel system is knocked down to 16 channels due to nothing more than module limitations. I walked the list of open issues in git hub, there are some interesting bugs and features to tackle, but in my opinion an improved module protocol would be a great draw card for OpenTx; a system more capable than JR's new 28X. I don't know what Jim is offering with his bounty, but I would also happily add a hundred or two to the pool myself, would be great to help it along.

User avatar
Bill
Posts: 195
Joined: Thu Jul 04, 2013 5:54 pm
Country: -

Re: XPS module protocol

Post by Bill » Tue Jan 28, 2014 2:47 pm

A word of caution here the 'bounty' may not amount to a bag of peanuts:
http://www.teamflyingcircus.com/forum/f ... back-4457/
Snake oil.jpg
Snake oil.jpg (13.72 KiB) Viewed 3726 times
“A good politician is quite as unthinkable as an honest banker”
They used to say "if you don’t want to work at McDonald’s, go to college." Now they say "if you want to work at McDonald’s, go to college.”

User avatar
ShowMaster
Posts: 4315
Joined: Thu Dec 29, 2011 3:44 am
Country: -
Location: Los Angeles, CA USA

Re: XPS module protocol

Post by ShowMaster » Tue Jan 28, 2014 3:40 pm

The few times I saw an xps system fly a plane it was a total disaster. One was in Henderson Nevada at a big RC air show. There was a xps demo booth as well as demo flying going on. The xps planes all crashed and one private owner that lost a true high $ 1/4 scale plane took the guys in the booth on yelling at all of them.
The next time was at a local field here several turbines went in with new xps systems. Sometime later the xps system was banned for turbine use there. I haven't seen one at all for several years now. I thought they had folded.
I don't believe I've seen an add for the system lately either.
They were cutting edge but I think the designer was a telemarketer first!
I had thought about buying one but after those events changed my mind. In glad I waited for the er9x/DJT and later the Taranis systems to come on board. I did pass through the dsm2 era and had my good and bad flying days.
So far all my flying days are good now.


Sent from my iPod touch using Tapatalk

AcBates
Posts: 40
Joined: Fri Jan 24, 2014 5:43 pm
Country: -

Re: XPS module protocol

Post by AcBates » Tue Jan 28, 2014 3:50 pm

Bill wrote:A word of caution here the 'bounty' may not amount to a bag of peanuts:
http://www.teamflyingcircus.com/forum/f ... back-4457/
I've played open source myself, it's largely thankless. So, take XPS aside, I personally would like to help sponsor a feature into existence I feel would be a solid boost to the OpenTx initiative: a protocol that allows the 32 channel system to output all 32 channels to a single point of transmission, rather than the split module compromise. This could be really epic. It is an open protocol, so any company can implement it and create a faster, better system. It is an ideal opportunity.
Last edited by AcBates on Tue Jan 28, 2014 5:17 pm, edited 1 time in total.

AcBates
Posts: 40
Joined: Fri Jan 24, 2014 5:43 pm
Country: -

Re: XPS module protocol

Post by AcBates » Tue Jan 28, 2014 4:00 pm

I think it is in error to get hung up on things like "what happened at the field this one time". this is only about having a better module protocol available. copy it, clone it, tweak it, expand it, improve on it. with a better performing module protocol baked into the system, everyone wins; which is the point of open source projects.

User avatar
Kilrah
Posts: 9602
Joined: Sat Feb 18, 2012 6:56 pm
Country: Switzerland

Re: XPS module protocol

Post by Kilrah » Tue Jan 28, 2014 8:34 pm

AcBates wrote:I don't know what Jim is offering with his bounty
Me either. The mention in his post is the only one I know of. You'd believe the dev team would have been informed...

I don't believe in generic protocols. Unless you put all manufacturers around a table with an intention of coming up with something common so that they really discuss their requirements and come with something that fits for everybody they're just doomed to failure. Everybody will want something that's not in the generic spec, so they'll just dump it and go with their own. Look at Adobe's DNG format for RAW photo, it's good, its been around for years, yet nobody could care less about it.
And that's not even taking into account the commercial reasons which usually take the last beating at not making it too easy for others to do as well as you.

The protocol XPS mentioned above has support for 128 channels, but who needs that, and on the other hand it doesn't have explicit support for useful stuff like module mode choice, bind control, range test, failsafe definition, etc...

I don't see a point in losing time designing a new protocol nobody supports. If someone comes with an intention of coming up with a 32CH module and want openTx to support it, then why not.
Current modules support 16 channels simply because it's enough for most uses, and transmitting more would only mean having to make compromises on more useful features like telemetry, range, refresh rate etc.

The current solution on the Taranis is enough for 98% of users, after all few models need that much, even less knowing the radio has a limited number of controls anyway. For the other 2%, they can add a $40 module and get 32.

AcBates
Posts: 40
Joined: Fri Jan 24, 2014 5:43 pm
Country: -

Re: XPS module protocol

Post by AcBates » Tue Jan 28, 2014 10:22 pm

"if someone comes with an intention of coming up with a 32CH module and want openTx to support it, then why not"

I don't see a problem with that attitude in general, and things can work/stay that way, but there is an opportunity to collaborate here. Jim appears to just want a protocol that meets technical objectives, doesn't particularly care what it is. the way XPS usually works is to reverse engineer the module protocol, and set up code specific for that system. In the absence of something that met the technical objectives, and the potential to improve the overall result, he put forth something that had docco and some code available; a starting point. why not ask if the packet can be added to so just maybe there can be a better collaboration/integration with OpenTx?

So there was a descriptor for module mode choice, bind control, range test, and failsafe definition. Is there anything else? what is the list? can a list be made? are there any changes to the protocol that would be easier for OpenTx to output? it can all be open. Open source spec implementations are cool, but open source collaboration is cooler by orders of magnitude.

How about pushing some changes that are simply the whims of OpenTx, maybe the start of the OpenTx-Module-Protocol. If the next manufacturer sees that it has a great integration with all the technical benefits they want, then they can implement it as-is. If it doesn't fit, maybe they can enter the conversation for future revisions to the protocol, or they simply hand OpenTx yet another spec to be implemented. there is no net difference to just implementing another spec, except that on this one there is a chance to collaborate on a better integration. It would be epic to see "openTx" as the module choice for both internal and external modules in the model config. Start off with the xtreme protocol, add the binding and a base level of collaboration coolness, name it version "0.1" and go from there. OpenTx can work on the protocol at their whim, see an opportunity and totally change it up as needed, XPS and other vendors can choose to implement it or not at their discretion. If the firmware has a dropdown list of options OTX0.1, OTX1.1, OTX2.1... drop old protocols if they're no longer relevant, whatever. This cannot be a future as bleak as simply implementing other people's protocols. It can build traction, would support OpenTx and what is ultimately possible from the system. Vendors can implement or not based on their discretion, as well as making a choice about joining the conversation about where it can head in the future.


Somewhere in the development of OpenTx it was decided that 32 channels was the cool number to implement. OpenTx is soup-to-nuts a 32 channel system, but it has a prostate problem when it goes to the toilet to transmit the stream because the modules cannot take all 32 channels. :o
Last edited by AcBates on Tue Jan 28, 2014 10:39 pm, edited 2 times in total.

AcBates
Posts: 40
Joined: Fri Jan 24, 2014 5:43 pm
Country: -

Re: XPS module protocol

Post by AcBates » Tue Jan 28, 2014 10:35 pm

OpenTx in its entirety is "we think transmitters can be better", why does it so willingly give up control at the hand-off point without even the option to have things implemented in a fashion most ideal for OpenTx? why have a system that has 32 channels baked all the way through it, but suddenly at hand-off it becomes "only 2% of users" arguments?

It feels so very inconsistent. to heck with vendors, make an output that is as cool as the rest of the system. Let the rest take care of itself.


Allow me to re-phrase what I am personally interested in: a true 32 channel module output protocol for OpenTx that is representative of what the system can do instead of having something lesser (both in performance or features). I feel the split module output is a workaround due to lacking module support that complicates things on both sides of the link and reduces options for the user (regardless if such users are in the lofty 2% or otherwise). If there was an OpenTx module protocol that showed the firmware to its true capability, the chances are that a company like XPS would step up to the plate and implement it. Not too many companies will want to open their soft underbelly of protocols to try and get theirs in, but it's another story if one already exists that is implemented with code available. Until such a protocol exists, OpenTx will be only awesome behind the curtain and continually cobbled by what is possible with available modules. I love open source, I want to see OpenTx stand straight up on its merits... a true 32 channel system that can totally take it to the likes of the JR28X.

If this is a possibility, then I would like to put my own hundreds of dollars towards this particular effort. If I cannot fund the whole thing, let me know what the price is, and I will go champion a fundraiser to help make it happen. When there is a worthy OpenTx-module-protocol implemented, I will then happily push vendors to get it implemented. If I were a C coder I would help code it, but alas my dev skills are elsewhere, so the best I can do is help fund it or find momentum.

It feels like the Xtreme protocol is a good starting point, but I will leave it at that. Yes, 128 channels is nutty, but 32 isn't. It is only coincidence that the Xtreme protocol gets to 128 by the same means it gets to 32.


As for open protocols, just treat this as the start. There is no need to gather companies ahead of time, let it form organically from those actively looking to integrate. If a company has a better way of doing a thing, they can step forward with their info, OpenTx can decide to update the protocol based on its merits.

Any company (or maybe just some part time hacker looking to toy with their own open source RF module/interface) looking to implement against OpenTx has the choice to implement the current or previous version of the opentx-module-protocol (older versions of protocols can be kept around or dropped as appropriate), collaborate in the meritocracy for improvement of the protocol, or simply ask/provide a proprietary protocol as a separate option. Given that at the moment all future integrations are looking at the "brand new separate implementation" option, there's no downside to setting up a protocol as a potential candidate as the "most deeply integrated protocol" or "official" protocol if that term helps people with the idea.

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

Re: XPS module protocol

Post by MikeB » Tue Jan 28, 2014 11:03 pm

One of the reasons the "extra" channels exist is for certain mixes these channels are used as "virtual channels", where certain inputs are mixed on one of these channels, then this "virtual" channel is used as the source of a "real" channel.
Over time, the capability of the mixer has improved such that less "virtual" channels may be needed.
Using the SLOW option however may well need a virtual channel as SLOW only applies to a single mix, if you have several mixes combined together, then want a SLOW output you need a "virtual" channel.

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

AcBates
Posts: 40
Joined: Fri Jan 24, 2014 5:43 pm
Country: -

Re: XPS module protocol

Post by AcBates » Tue Jan 28, 2014 11:24 pm

MikeB wrote:One of the reasons the "extra" channels exist is for certain mixes these channels are used as "virtual channels", where certain inputs are mixed on one of these channels, then this "virtual" channel is used as the source of a "real" channel.
Over time, the capability of the mixer has improved such that less "virtual" channels may be needed.
Using the SLOW option however may well need a virtual channel as SLOW only applies to a single mix, if you have several mixes combined together, then want a SLOW output you need a "virtual" channel.

Mike.
Yup, it is a cool thing and pretty powerful. However, OpenTx is actually able to send all 32 channels out the door... only that the door is defined by modules not as capable as OpenTx. The tail is wagging the dog.

For whatever reason, someone thought of the 2% enough to have OpenTx not simply truncate these channels and allow people to traffic-cop them through the two available modules. But rather than forcing the traffic cop operation, why not define a protocol that will allow modules to rise to the power of OpenTx instead of having OpenTx bend over to whatever the modules can or cannot do?

let the dog wag its tail :)

User avatar
Kilrah
Posts: 9602
Joined: Sat Feb 18, 2012 6:56 pm
Country: Switzerland

Re: XPS module protocol

Post by Kilrah » Tue Jan 28, 2014 11:41 pm

AcBates wrote:OpenTx in its entirety is "we think transmitters can be better", why does it so willingly give up control at the hand-off point without even the option to have things implemented in a fashion most ideal for OpenTx?
Because the dev team is just a few guys working on it for free, in their free time, next to their real-life jobs, who logically want to have fun and concentrate on what they feel is most useful/they have most fun doing. And they already have enough on their plate for probably a year at least with the currently open issues and what they want to do, so prioritization is required.

I never said we did not want to do it, I said the opposite. But now simply based on the (non-existence of) requests for such a thing, it's just somewhere deep down the TODO list. No point prioritizing something and spending months of development time on if it may not even serve when there are tons of more important things that are waiting and that people really asked for.
Now as said if someone like Jim shows a real interest, then in the right conditions it could be bumped up.
And of course it's all open, so anybody else could join the team and do that job if he's interested in it.
AcBates wrote:Allow me to re-phrase what I am personally interested in: a true 32 channel module output protocol for OpenTx that is representative of what the system can do instead of having something lesser (both in performance or features).
Can you give us some info on why you'd need this and how you would use it? What kind of models/functions?
Again there's no point prioritizing it if it's only so that "we're the best" or "we have as many channels as the not-yet-released JR radio" when there's no point in it. That's for the marketing and commercial guys, not for people who spend hundreds of hours without compensation ;)
Now if the marketing guys from a manufacturer want to hire the team to include openTx in their radio and have that as a feature, no problem.
AcBates wrote:OpenTx is soup-to-nuts a 32 channel system, but it has a prostate problem when it goes to the toilet to transmit the stream because the modules cannot take all 32 channels. :o
The higher number of channels is mostly there because of the need to use "virtual" channels for complex setups. On the Taranis we initially had chosen 24 because that was enough for that use, but... the decision to go with 32 in the end was as trivial and "stupid" as the channel monitor looking better with 2 full pages than with one with 16 and one with only 8!
It^s only after that that the possibility of using a 2nd module came up. We actually asked for a hardware change on the radio to support it when we found it was possible, otherwise 32CH operation wouldn't have been possible at all. FrSky wanted to sell a 16CH radio, we decided we coiuld just as well make it a 32CH one with what we had at hand. I think it's something already.
AcBates wrote:OpenTx can work on the protocol at their whim, see an opportunity and totally change it up as needed, XPS and other vendors can choose to implement it or not at their discretion. If the firmware has a dropdown list of options OTX0.1, OTX1.1, OTX2.1... drop old protocols if they're no longer relevant, whatever.
OK, come and help code and maintain that part then (or find someone else to do it) :)
As said, there's simply a serious lack of resources with the current dev team to consider that right now. We simply can't do everything.
AcBates wrote:This cannot be a future as bleak as simply implementing other people's protocols.
One year ago OpenTX could only run on a $50 radio with low end hardware that you had to take apart and solder in to install it on. The possibility to collaborate with FrSky was the opportunity we needed to make our work available to the general public, and not just tinkerers. It's relatively logical we implemented the FrSky protocol, which was already designed and "that's how it was" (although we did do some suggestions that were integrated).
This bunch of new users came up with tons of great suggestions to improve the firmware, which have sparked a major redesign of big parts of the firmware (see the upcoming openTx 2.0: https://github.com/opentx/opentx/issues/milestones). This has been 6+ months in the works for now. Supporting 32 channels on a single module or making our own module protocol wasn't part of them, so...

AcBates
Posts: 40
Joined: Fri Jan 24, 2014 5:43 pm
Country: -

Re: XPS module protocol

Post by AcBates » Wed Jan 29, 2014 1:33 am

Kilrah wrote:Because the dev team is just a few guys working on it for free, in their free time, next to their real-life jobs...
I think we agree more than we disagree. The bounty talk was only trying to make it clear that working on this feature doesn't need to be for free. It is just an artificial way to bump it up the list, of which it will succeed or not, which is fine. On the open source thing, I am more than on the same page, spent some years contributing to enterprise Java projects. I would code it myself, but I don't have the C... so I have to try and bounty my way to a coder (plus whatever Jim is offering, but I don't know what that is).

I get the tireless "dammit I have a day job too!" thing, been there, done it, still doing it... but from my own experience, coding an amusing thing for a pet project for a little flash money can be a little nicer than miscellaneous bug fix. I also understand that I need to trigger someone's enthusiasm against the measure of the bounty. I also don't know the level of effort required to get it done... which means I don't know whether a hundred or two in cash is an incentive or an insult. so, is it an incentive or an insult? :)

FrSky wanted to sell a 16CH radio, we decided we coiuld just as well make it a 32CH one with what we had at hand. I think it's something already.
...and that is awesome, and I concur that it's epic already. but in a similar "wouldn't it be nice?"... just define a protocol that's practical and performant and spit it all out of one module. Only seems to me to complete this process that you guys started.
Can you give us some info on why you'd need this and how you would use it? What kind of models/functions?
I usually invent to the limitations of my sandbox, but I am up against the limitations at the moment. One, I fly giant scale planes and it's easiest to gang servos by mixing them in the radio... but other things get tougher to explain... so here's some pics...

2012 effort...

Image


2013 effort...

Image


...I could fly with the 2012 wings, but cannot due to limitations of my system. In 2011, I also had a catchment/flag-release/payload deal on the plane that was also fun, but turned off for 2012/13. Add in that I desire to do even more than these two combined. I really am restricted by the system. I have intentions to do similar things to larger airframes (that can burn 13 channels even with a stock vanilla setup), but again, up against limitations. OpenTx can really help me out... my projects are like fish, they grow to the size of the tank.

The question was what would I myself use channels for, so this kind of stuff is what I get up to. And I don't expect piles of people to do what I'm doing, but it's a thing that removes limitations, so who knows what is possible. OpenTx and the general trend is making channels a commodity, removing them from being a limitation... 16 is almost the whole way there, 32 does that pretty profoundly.

OK, come and help code and maintain that part then (or find someone else to do it)
I'm pretty sure that the "finding someone" is exactly what I'm trying to do :)



Summary-ish would be that performance/latency of the system is also important to me simply due to the nature of these projects. Add in that if I can grow the size of the fish tank, I get to see what my fish will turn into... seeing how big the fish can grow is worth some money to me, happy to contribute that. Jim has said he'd contribute something, so this seems to at least come some way into what you mention as a radio manufacturer providing some funds for features. If there's a water mark of how much it would take to move things along, that would be handy to know.

There's no huge urgency, but I type my enthusiasm as I have it. Naturally, if none of this bounty or info or anything manages to motivate a coder to make it happen... then the feature request sinks down into the todo list where it would otherwise naturally sit, and life goes on until someone picks it up and starts to scratch it.


All of my spiel and verbiage only exists because I think OpenTx is very impressive... and I believe it is paving a bright future, it will continue to make waves in the industry. I thank you for your time and attention :)

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

Re: XPS module protocol

Post by jhsa » Wed Jan 29, 2014 2:54 am

AcBates wrote:
Yup, it is a cool thing and pretty powerful. However, OpenTx is actually able to send all 32 channels out the door... only that the door is defined by modules not as capable as OpenTx. The tail is wagging the dog.
According to what I've read in several places, XPS had more crashes due to lockups/loss of signal in one day than frsky in about 3 years.. I personally wouldn't trust that system to a park flyer.
Frsky is reliable and I think that is why the devs decided to support it
...I could fly with the 2012 wings, but cannot due to limitations of my system. In 2011, I also had a catchment/flag-release/payload deal on the plane that was also fun, but turned off for 2012/13. Add in that I desire to do even more than these two combined. I really am restricted by the system.
Sell your system whatever it is, and buy a Frsky Taranis if your system is that limited.
Buy an extra frsky module and get 32 channels. At least you know that you won't crash your big models like with XPS.
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

AcBates
Posts: 40
Joined: Fri Jan 24, 2014 5:43 pm
Country: -

Re: XPS module protocol

Post by AcBates » Wed Jan 29, 2014 3:17 am

jhsa wrote: Sell your system whatever it is, and buy a Frsky Taranis if your system is that limited.
Buy an extra frsky module and get 32 channels. At least you know that you won't crash your big models like with XPS.
Nothing of what you typed about XPS systems has reflected my personal experience, I trust the equipment implicitly... the extenuating circumstances I have seen it punch through are nothing short of astounding. Of the people I personally know, not a single reported issue. I choose to do more than just read stuff on the internet.

And two modules only a few inches apart, transmitting on the same band, is not exactly optimal... I wont be committing my airframes to that.

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

Re: XPS module protocol

Post by jhsa » Wed Jan 29, 2014 3:31 am

No, not optimal, but frsky link is very strong and can cope with that very well. I would trust a giant model to it. Not to XPS as it is reported to be even worse than the dsm2 stuff and the cheap flysky modules..
FRSKY is one of the most reliable systems on the market. Forget your system, go frsky and you can fly with confidence. You know that with FRSKY you won't crash your big models due to lockups.. ;)

Sent from my GT-I9195 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

AcBates
Posts: 40
Joined: Fri Jan 24, 2014 5:43 pm
Country: -

Re: XPS module protocol

Post by AcBates » Wed Jan 29, 2014 4:13 am

jhsa wrote:No, not optimal, but frsky link is very strong and can cope with that very well. I would trust a giant model to it. Not to XPS as it is reported to be even worse than the dsm2 stuff and the cheap flysky modules..
FRSKY is one of the most reliable systems on the market. Forget your system, go frsky and you can fly with confidence. You know that with FRSKY you won't crash your big models due to lockups.. ;)

Sent from my GT-I9195 using Tapatalk
ok, now you are just trolling.

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

Re: XPS module protocol

Post by jhsa » Wed Jan 29, 2014 8:23 am

No I'm not. I am free to say what I think. The same as you when you attack the excellent FRSKY system. :)

Sent from my GT-I9195 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

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

Re: XPS module protocol

Post by Rob Thomson » Wed Jan 29, 2014 8:24 am

Guys...

Don't let the technical discussion get side tracked.

You have differing opinions / objects.

Work through the options to see if something cohesive can be done. If not... Move on :)

Sent from my GT-I9300 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
Kilrah
Posts: 9602
Joined: Sat Feb 18, 2012 6:56 pm
Country: Switzerland

Re: XPS module protocol

Post by Kilrah » Wed Jan 29, 2014 8:31 am

jhsa wrote:No I'm not. I am free to say what I think. The same as you when you attack the excellent FRSKY system. :)
Nothing in this discussion has anything to do with RF performance or reliability of either of the systems. It's just about designing a more efficient way of transferring data from a radio to a module, whatever the radio and module are.

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

Re: XPS module protocol

Post by jhsa » Wed Jan 29, 2014 8:41 am

Yeah, but people can tell their ideas without attacking stuff that we all know it is good. I do apologise if I sounded too harsh, but there are other ways of selling your product without bashing other products.

Joao

Sent from my GT-I9195 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

User avatar
Kilrah
Posts: 9602
Joined: Sat Feb 18, 2012 6:56 pm
Country: Switzerland

Re: XPS module protocol

Post by Kilrah » Wed Jan 29, 2014 9:00 am

But as far as I can read nobody bashed FrSky. If anything the bashing was directed at openTx for not having its own protocol for talking to modules, that for example FrSky and others could have adopted. And yes it did spark a response that needed some moderation, it's always hard to respond nicely to that kind of "how come you haven't done that already???!?!?!" kind of posts.

But you're a bit overreactive...

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

Re: XPS module protocol

Post by jhsa » Wed Jan 29, 2014 9:38 am

Maybe, But shall I quote the parts where frsky was bashed?? Or shall I just stop and leave it like that?
I think maybe the second option is the best as I already said what I had to say about it. ;)

João
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
Rob Thomson
Site Admin
Posts: 4537
Joined: Tue Dec 27, 2011 11:34 am
Country: United Kingdom
Location: Albury, Guildford
Contact:

Re: XPS module protocol

Post by Rob Thomson » Wed Jan 29, 2014 10:00 am

Maybe.... Just move on and let's get topic back on track.

Beer time :)

Sent from my GT-I9300 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
jhsa
Posts: 18011
Joined: Tue Dec 27, 2011 5:13 pm
Country: Germany

Re: XPS module protocol

Post by jhsa » Wed Jan 29, 2014 10:23 am

Agree. Beer sounds good, even at this time in the morning. :mrgreen:
Sorry guys.

Joao

Sent from my GT-I9195 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

Post Reply

Return to “openTx”