2.4 Module Questions

[Racer38]

I have a question cencerning multiple models using either Specktrum or XPS Modules.

Do you have to reset / link or whatever every time you want to use another model ??

I dont see where the radio will store that data, and the instruction sheets I have read talks about binding to the rx ??

Just curious maybe I am missing something here ??

Thanks

Craig

[Danal Estes]

The module is bound to the RX. The module has no knowledge of which model memory is selected in the TX. No need to rebind.

Also no "model match" protection... this is the Spektrum brand term for binding an RX to a specific model memory... if you select the wrong one, no link, so no takeoff. Extra protection.

Anyway, back to your question: Bind is a one-time thing, for each RX.

[Racer38]

Ok so how does the TX module know which model you want to fly ? Is it nothing more than pushing a button on the TX module to tell it which RX you are flying ??

[Tom Fiddler]

You bind a reciever to the module. It does not matter what heli it is in.
If you bound 3 RX's and put them in different heli's it would make no difference.

What you are doing is "marring" the RX's you have to the module...so your buddies RX's don't listen to your module.

This is only done the first time you use the system, or add another RX
Then it is just up to you to be sure your TX is set to control the right model. Same as always.

[Danal Estes]

Ok so how does the TX module know which model you want to fly ? Is it nothing more than pushing a button on the TX module to tell it which RX you are flying ??

A module based transmitter does not know. Only a DX7 or x9303 style transmitter (internal digital integration, not module) can "know" and implement "model match".

In a module based setup, the RX binds to the module. You can change model memories, or even move the TX module to another transmitter, all without rebinding. This means you get no "model match" effect. If you own several aircraft, the RX in each was bound (one time only) to the module. The RX that's powered up is the one that responds. If you have two RX/Aircraft powered up, both will respond when you wiggle the sticks. Other people's 2.4G stuff won't respond to your TX(module) because they're not bound.


In an "all digital" setup (DX7 today, x9303 soon), the RX binds to a model memory. This is an advantage in that it prevents accidental use of a given memory with the wrong RX/model. It is a disadvantage if you move the RX betwen physical aircraft on a regular basis. Small disadvantage if you think about all the plugging and moving and Etc... re-binding only adds a few seconds to all of that... back to the more common case of owning several aircraft, each with its own RX. Power up the one bound to Model#1 and it responds... power up another of yours and it won't respond, it's not bound to #1. Either switch to the correct model memory or power up the right model. This is "model match".

[Ciprian]

Danal,

I don't know how other modules work, but with XPS you cannot have 2 receivers at the same time 'listening' or 'responding' to one module, since XPS is bi-directional (module also listens to the rx for some information). Somebody asked this question on RCGroups (wanted to use 2 receivers in a plane for redundancy) and Jim Drew himself responded that this is not possible. Maybe spektrum works like this since it is uni-directional like on 72 MHz.

[stevehonn]

Danal,

I don't know how other modules work, but with XPS you cannot have 2 receivers at the same time 'listening' or 'responding' to one module, since XPS is bi-directional (module also listens to the rx for some information). Somebody asked this question on RCGroups (wanted to use 2 receivers in a plane for redundancy) and Jim Drew himself responded that this is not possible. Maybe spektrum works like this since it is uni-directional like on 72 MHz.

The problem with the built in modules is that 'model match' can't work, as Danal says, because it needs a native 2.4ghz radio, not a plug in module. Using a module any model memory will work with any receiver than has been bound to the module, the receivers are bound to the module, not the memory. The Spektrum system is also bi-directional, the module & receiver swap GUID codes so the module will only work with receivers bound to it and the receivers will only work with the module, it's just not able to tell which receiver of those bound to it is in contact with it.

[Ciprian]

Steve, you missed the point completely of what I was telling Danal. I am not talking about model match here. I am talking about XPS not being able to have 2 receivers on at the same time responding to stick inputs. Maybe spektrum can do that.

This is the part in Danal's message that I was refering to.

If you have two RX/Aircraft powered up, both will respond when you wiggle the sticks.


And, if you think that spektrum is bidirectional, you are mistaken. Spektrum after the bootup chooses 2 free channels and transmits on those 2 and that is it. No feedback from the receiver at all. With XPS, the module and the receiver are communicating back and forth all the time. At bootup, they choose one channel and then the receiver all the time transmits back to the module how good the link is, also telemetry info, etc. When they find interference on that channel, they agree on which channel to move and they start using that channel until something else happens. This is what I mean by bidirectional communication. Both module and receiver are in constant communication with each other.

BTW, I am not trying to say here which one is better than the other. I am just saying that XPS can only communicate with one and only one receiver at the same time.

[Danal Estes]

Spektrum definately can run two (or more) receivers on the same bind (to a module or a model memory, as per the TX type). This can be used for redundancy. The RXs can be bound at the same time, or at separate times (e.g. sequentially).

Spektrum is not bidirectional in flight.

Agree with Ciprian's statement regarding XPS. Only one RX active at a given time. Interesting limitation.

[Pinecone]

XPS can use multiple Rxs, but the extra Rxs only send data to the main Rx, not directly to servos. Some guys are using mulitple 72MHz Rxs and putting say one elevator servo on one Rx, the other elevator servo on the other. XPS doesn't allow this. But it does allow slave Rxs, similar to the AR7000 model.

XPS can hook up to 256 Rxs around an aircraft.

[stevehonn]

Steve, you missed the point completely of what I was telling Danal. I am not talking about model match here. I am talking about XPS not being able to have 2 receivers on at the same time responding to stick inputs. Maybe spektrum can do that.



Given the sytem and the way it works I'd say it shouldn't be a problem, as long as they are both bound to the same module. I do have to ask though, why would you want to as when the 9 channel receiver arrives it has two receivers built in and can accept another 2 satellite receivers. I suppose it would be possible to run two completely seperate receivers with seperate power supplies and servos for a high level of inbuilt redundancy.

[Danal Estes]

There seems to be confusion regarding Spektrum v XPS and multiple receivers.

Spektrum can bind any number of receivers to a given module, TX or TX memory (in the case of model match). They must be all of the same type DSM1 or DSM2. So, you can bind several AR7000s to the same TX. Just to clarify the description, note the AR7000 is already multi receiver, "base" and "satellite". As pointed out the the AR9000 can be 2-4 in one RX. I'm talking about binding several AR7000s or 9000s or whatever... Example: Giant scale. Two battery packs, two AR7000s (each with base and sat), each Batt/RX drives 1/2 the airplane. Full redundancy.

Several people have used the words "...maybe..." or "...shouldn't be a problem..." with reference to this multi-bind, multi-RX setup. Just so you know, this has been physically verfied; there are people flying this way. It has also been verbally verified by Paul Beard (chief engineer at Spektrum) as a valid setup.

XPS cannot do this fully redundant configuration. Because it is a bidirectional link, only one RX may link to the TX at any time. As pointed out above. XPS can be configured as a pair that behave like a SINGLE Spektrum AR7/9 receiver. That is, a "base" which drives the servos, and one or more "satellite" that receive and pass info to the "base". From what I can see, there is no way to have the "two pack/two RX, totally separate, each drives 1/2 the airplane" style setup with XPS.


As ciprian says, not sure which one is better or worse. Just being clear about the differences.

[spork]

Danal, I'm sure you're right about the Spektrum, and you're almost certainly right about the XPS; but it doesn't have to be designed that way. There are several ways two RX's could both communicate effectively back to the TX. I suspect they didn't implement any such system, but do you know if anyone's tried it?

[Danal Estes]

Agreed! If nothing else, as simple as one RX operating normally and the other "receive only". There are more elagant possible solutions... we know that "one normal, one receive only" would work and we know JD/XPS has the code for "receive only" as that is how their parkflyer receiver works when beyond bi-directional range, according to JD about 300 feet.

So, nothing to stop XPS from offering true "redundant" dual RX capability in the future. If they're interested. :)

[spork]

I would think the most likely solution would be either

- time slotting (each RX takes it's turn after packet is recieved)
- each RX uses it's own spreading code (makes it hard on the "transmitter" though).

When we developed a system for tracking all 43 vehicles in a NASCAR race we opted to use a time slotting approach, each base station and each car gets a slot. Take your turn and everyone gets to speak.

[Pinecone]

Bottom line is, if you need this capability, email Jim Drew and it will happen.

So far, just about everything someone has asked for, with a reason, he has managed to do, from the satellte Rxs to the Park Rx, to other things. Heck the whole R/C thing came about due to someone saying, why don't you??? to his original telemtery only concept. :)

And actually you can probably do it when the universal module comes you buy having TOTAL redundancy. One Tx in teh module slot and one Tx through the trainer port. No other systems offers Tx redudancy. :)

[DavidH]

One Tx in teh module slot and one Tx through the trainer port. No other systems offers Tx redudancy.


That will probably not work , unless there is a change made to how the transmitter operates. The port that the trainer cable plugs into is not active all the time. Only when the trainer switch is activated.

David

[spork]

The port that the trainer cable plugs into is not active all the time. Only when the trainer switch is activated.

I may be misunderstanding your point, but I'm pretty sure the trainer port on the back of the TX is always providing the PPM signal. Afterall, the switch on the student's TX is never activated, and it's the one putting out the signal that goes through the instructors RF stage. Also, I think the XPS module is intended to run from trainer output on non-module radios.

[DavidH]

Spork,
You may be correct. Hadn't thought of it that way. I just don't think 2 TX modules operating off the same tranny will work as mentioned above. All it takes is a millsecond difference in the signal being sent and the RX will not know which one to interpet.

David

[spork]

I just don't think 2 TX modules operating off the same tranny will work as mentioned above.

I'd bet you're right about that.

[Danal Estes]

The port that the trainer cable plugs into is not active all the time. Only when the trainer switch is activated.

I may be misunderstanding your point, but I'm pretty sure the trainer port on the back of the TX is always providing the PPM signal. Afterall, the switch on the student's TX is never activated, and it's the one putting out the signal that goes through the instructors RF stage. Also, I think the XPS module is intended to run from trainer output on non-module radios.

Not true for JR. On a JR, plugging in the cable while main power switch remains off causes the TX to power up and output PPM on the port, while leaving the module bay powered off (no RF emitted). Plugging in the cable with main power switch on causes the TX to power up (including the module bay) and input PPM on the trainer port.

However... you could certainly just use a Y cable from the trainer port (or from the bay for that matter) if you want redunant modules. Seems somewhat pointless since there are still a bunch of SPOF (single point of failure) in the TX itself. Having said that, this would be a way to have true redunant RX in XPS as it is configured today:

One TX > Y cable > TX Module A & TX Module B

In airplane, on RX bound to A and one RX bound to B. Should work a charm. Also seems a bit overkill as opposed to some of the other SS 2.4.G solutions.

[spork]

Not true for JR. On a JR, plugging in the cable while main power switch remains off causes the TX to power up ....

Interesting. I've never played with the JR's. That approach makes sense, but it still sounds like it's not dependent on the trainer switch being on or off. It's just a matter of the configuration at power up if I'm understanding correctly.

[Danal Estes]

Not true for JR. On a JR, plugging in the cable while main power switch remains off causes the TX to power up ....

Interesting. I've never played with the JR's. That approach makes sense, but it still sounds like it's not dependent on the trainer switch being on or off. It's just a matter of the configuration at power up if I'm understanding correctly.

That statement is 99% true and I see where my phrasing caused the 1% miss. That last 1% is: it's not just at power up. It depends on the configuration of the power switch AND the trainer cable at any moment. Examples:

TX with switch off and no cable, nothing.

Plug in cable (switch still off), now it is a "Slave", powered up, no RF, outputting PCM on trainer cable. Use this for Flight Sim & etc.

Don't move the cable... and turn on the power switch. Now it is a "master", fully powered up and emitting RF, and (sort of) reading the trainer port. "Sort of" because the RF signals being output are from master sticks.

Now, pull the trainer switch; RF signals emitted from master are now from the slave sticks. There is a menu setting that determines whether the master's mixers are applied to those slave inputs. With this set, you can fly a CCPM heli with a 4-chan slave. Wonderful feature, this.


To summarize: Cable in & switch off= slave. Cable in & switch on= master. Spring loaded trainer switch effective only on master.

[spork]

To summarize: Cable in & switch off= slave. Cable in & switch on= master. Spring loaded trainer switch effective only on master.

Makes perfect sense.