djmp69

So here's one for you. I have a plane that had a Smart-Fly board go out, and the receiver was an AR9350. I figured, I got a new radio (IX12) and some newer receivers, so why not take advantage of that and swap out. No problem. I put in the receiver (AR10360T) from a sailplane I no longer flew. Mind you, this sailplane has never been crashed, no kind of rough housing. Piece of cake. Turned on the IX12, but forgot to switch to a new model, so I had an existing model active. However, when I turned on the newly installed AR10360T, the IX12 somehow was already bound, even though I hadn't put it in bind mode. Of course, this was even before the Airware booted up. Really cool feature that you have control even before the software boots up. So I shut off power to that receiver, and just to check, turned on the plane to which the profile on the IX12 matched. Guess what? Full control.

The kicker? THAT plane has an AR10100T, totally different receiver. The thing is, I hadn't rebinded to the 360T yet, and for all it knew, it was still in the sailplane, which had nothing to do with the model profile that was active in the ix12. So at that point I had total control of two different receivers, one of which I hadn't even binded to yet.

Kinda scary hunh? Imagine I'm flying BTW down on the deck and someone turns on. Reminds me of days of old 72mh systems...

Any ideas?

djmp69

Just to make sure I am making sense:



Plane A – AR9350, binded and flown, no problems

Blane B – AR10360T, Binded and flown, no problems

Plane C – AR10100T, binded and flown no problems



Removed AR9350 from plane A

Removed AR10360T from plane B and put into plane A



Before I binded the 10360T to Plane A’s model profile, I was still able to control plane A with Plane C’s model profile. I was also able to control Plane C with Plane C’s profile.


Once I binded Plane A’s profile to the 10360, everything was as normal, neither plane would respond to the other’s profile.

AndyKunz

Your transmitter has a unique ID and a model ID that it sends with each packet of data so all the receivers listening will know if it belongs to them or not. The receiver doesn't know if you've put it into a new model or not. It it hears your transmitter talking to the model that it was last bound to (250 possibilities), then it will respond. That's why it was already bound - the "new" receiver had already been configured to listen to your IX12 talking to model number X.

That's good, it's working as designed. Your IX12 has two computer chips in it (actually more, but two to talk about here). One chip runs Android and shows you pretty pictures. The other chip takes the controls and does some math and sends the results out to the RF. This second one boots up instantly (a fraction of a second). So it starts talking. It doesn't know, nor does it even care, if the display is working. It has a job to do, and it does it. Just in case the Android ever goes kaflooey, you will still have perfect control of the model. That's what you want.

Oh, you bound to that receiver, you just didn't know it. The remote receivers are actually independent receivers, too, so if you mixed and matched receivers bound to different models, they would be reporting control signals to the base, and the base would work with them because it can keep working even if it's internal RF isn't getting any signal. It's working exactly as intended for this also.

As one of the guys on the transmitter development team, I'd be really upset if the hardware wasn't working exactly as you stated! If you bind your model and all its receivers to your transmitter/model, you'll be golden until you bind them to another model. But it has no way of knowing if you're doing things right or, as in this case, not quite right. So it keeps working as it was designed - it hears a signal from your transmitter to the model number it was last bound to, it takes that data and forwards it to the rest of the system. It's working perfectly.

Andy

djmp69

That makes sense, thanks for that VERY informative explanation. The only thing I dont get though, isif the identifiers are unique, how was i able to control two different planes from the same model profile? That kinda defeats the whole purpose of uniqueness. I tried this with my other models, and none of them respond unless the correct model profile is active in the TX, even before airware boots up. And there was no mixing matching.

I could see if I was on the sailplane profile, which is where the rx came out of. But I was on an Extra 300 profile active in the TX bound to a 10100t, not a 10360 with a total different set of remotes. From what you explained Andy, it shouldnt have connected.

Unless I read that wrong?

djmp69

If that's the case, evertime I turned on my TX, what you're saying is that I would have control of any plane I've ever bound with that radii, no matter what profile I was on, and that, as dangerous as it is is not the case. It only happened with that one situation...


Update, Andy, I read what you wrote again, and must say again. You are correct, I did bind the receiver before. The problem is that when I put the receiver from the sailplane (10360t) into a different plane, we'll call it the xplane, the receiver was still bound as if it were still in the sailplane. When i booted up the ix12, the ix12 had the profile for my extra 330 active with the 10100t. I will add that I moved the entire setup from the sailpane to the X-Plane so no mix/match remotes/main or anything. So what happened is not that I had the sailplane profile active, it was for a totally different receiver and model setup. If that was already bound to an AR100T, how could it control an AR10360T. AND AR10100T at the same time?

AndyKunz

At some time, your receiver was bound to this transmitter and this model number. As you add and delete models, the model number portion of the ID changes, but it DOES get re-used. And that's exactly what happened here.

The receiver has no idea what type of model it is in. It just gets commands for positioning each channel, and it obeys them. But it only does that if the same transmitter & model number are being used.

Because your had used this same receiver with this same model number (which is invisible to you), the receiver was able to listen and obey.

It might help your understanding some if you go to the Frame Rate screen and study the Model Match Override capability.

Andy

AndyKunz

ONLY because the transmitter+model number ID is the same. It does not connect to all your planes, it only talks to those with the same transmitter+model number ID.
It sounds like you're almost getting it now.

The transmitter doesn't know what kind of receivers it's talking to. It talks the same language (with a few minor dialect differences over the years) to everybody. The message packet is literally this:

FROM TRANSMITTER X MODEL Y: Put channel 1 to X, channel 2 to Y, ... channel 7 to Z.

Then it says nothing for 11ms.

FROM TRANSMITTER X MODEL Y: Put channel 8 to A, channel 9 to B, ... channel 20 to C.

Then it says nothing for 11ms.

And so on.

The receiver only listens for that particular transmitter & model, so it if hears a command to that, it does it.

The DSM protocol is not a 1:1 thing. It is a Broadcast. It is one to many. As many receivers that have been bound to that transmitter + model will listen and obey. Whether they are integrated receivers (servo output + RF module) or just RF modules (Remote Receivers). In fact, that's NECESSARY for the whole concept of remote receivers to work!

Andy

rgburrill

Andy, are you relating "channel" to "aileron", "elevator", etc? Or does a "channel" have all the transmitter channels for a particular model mapping?

AndyKunz

A "channel" is a servo port. This is the standard name we've used for decades. The transmitter tells servo ports what pulse to output, in the traditional sense.

"Aileron" and "elevator" are functions that their outputs get mapped to servo ports (channels).

Andy

rgburrill

Confusing. I thought that the model mapping affected only the transmitter. When you select a model number you are setting up the transmitter for a specific functionality. Some, not all, transmitters tie that functionality to a specifically bound receiver. Changing the receiver to a different plane moves the functionality to the new plane BUT STILL KEEPS THE SAME MODEL NUMBER IN THE TRANSMITTER.

I must be missing something from the OPs posts because I thought Plane A, Plane B and Plane C all had differently functionality.

AndyKunz

Actually, it's super straight-forward. Nothing has changed about this since I was a kid in the 70s. The only thing is that Spektrum Model Match feature ties a receiver so it listens only to a specific model number from a specific receiver, getting rid of the use of frequency pins.

When you move a receiver from one plane to another, which means it should be configured to talk to a different model in your transmitter, the absolute very first thing you need to do is bind the receiver to that model in the transmitter. Skipping that step (what he did here) is why there is confusion. UNTIL RE-BOUND, the receiver will continue to listen to the model number that it was last bound to. That's why you absolutely MUST re-bind right away.

Functionality (what servo is plugged into what port) is determined by the transmitter, and is specific for each model. The transmitter tells, via the receiver, each servo port what the receiver should be sending out to the servo plugged into each port (each port = each channel). The receiver (unless it's stabilized, which I'm not getting into here) doesn't know anything about what functionality is conceptually attached to each port/channel. It takes the command from the transmitter and delivers it to the servo. If you tell it to listen to a different model than what you think it should be listening to (which is what he did by NOT re-binding it) then it will continue to obey that.

Andy

AndyKunz

A 6-channel transmitter controls 6 servo ports. That is the way that channel is being used here.

Andy

djmp69

Ok, I get that, I really do. But please bear with me here. The receiver in question was purchased brand new for the sailplane. I set the model number up from scratch, I did not copy another model and simply change it. That receiver had never been bound to another model profile in the IX12. It had ONLY been bound to the model number corresponding to the sailplane setup. So no, I had NOT used that same receiver with the same model number. I keep meticulous records, a flight log if you will, of all my birds, detailing the smallest changes. Lol, The guys in my club give me both admiration and great ribbings for this.

I understand that the receiver is an inanimate thing, it just takes commands from a signal put out there. Kinda like a spider web just sitting out in the middle of nowhere, it doesn't choose what it catches, just whatever blows into it. But again, I have tried what you are talking about, and have turned on other planes, then turned on the TX. If the model profile is not currently matching the plane I turned on, there is no response. If the model matches the plane, I get response, as you described, even before Airware booted up, as expected. As you said before, the TX has a unique ID and sends a unique model number to the RX.

I get how modelmatch works, and that's what's confusing, I get what you're saying, and it makes total sense, IF that's what had happened. But again, the receiver had only been bound one time, to a fresh "new model", yet was receiving and obeying commands from a model profile matched to a different receiver WHILE the correct receiver simultaneously did the same. I know you think I'd bound to that model in the TX before but that is not the case. You said before, "The receiver only listens for that particular transmitter & model, so it if hears a command to that, it does it."
So how can two receivers binded to two different model profiles be controlled at the same time from one profile in one transmitter? This is what I don't think you understand that has happened.

I know you're WAY more versed on this stuff than I am, I think maybe I just haven't been describing the issue clearly. As everything seems to be ok now after I rebinded the receiver to the "correct" profile, all my planes are responding only to the model in the TX to which they were bound, the anomaly has not occurred again yet, knock knock. As Spektrum has never let me down, I'll just chalk this up to a rogue wave, and press on. With the kind of problem it was, I'll know somethings wrong if it happens again before I get in the air, or even start the plane. Hopefully it doesn't.

Andy again, thank you for your continued patience and help!

AndyKunz

The answer is very simple. The "new model" has the same ID that the plane had been bound to.

When you delete a model, that ID becomes available again.

If you create a new model, it will re-use an old ID.

If you have a receiver that was bound to the old model with that ID, it will now be bound to the new model you just created that has the same (re-used) ID.

Andy

djmp69

See, you get it. You didn't miss anything. You are correct, when I moved the receiver to the new plane, it was still bound to the sailplane model in the transmitter, so it should have tried to make the "new" plane respond to the the sailplane commands from the transmitter. However, it was responding to commands from an Extra 330L model in the transmitter that was bound to a totally different receiver. I hadn't yet rebinded the receiver (I accidentally turned on the receiver before I realized I hadn't switched models in the TX). Andy thinks that I had binded the receiver before, but what he's not getting is that

1) The RX in question had only been binded one time to the sail plane.
2) The RX in question was receiving and obeying commands from a model profile that it had never been binded to
3) Two different receivers were simultaneously receiving and obeying the same commands from a single model profile

AndyKunz

Also, when you import a model, it gets assigned a new or re-used ID. So if you delete models, then import, you might find that your newly-imported models are bound to receivers that are in other models. And if you imported a model into your transmitter that you had previously deleted, chances are it will get a different ID than the last time so you'll need to re-bind it.

This emphasizes the importance of the very first thing you do with a model when setting it up is to bind it to the receiver. And have your other models off. Transmitter on, model on. Fly. Model off, transmitter off.

Andy

AndyKunz

But that model ID (not visible) was the same in both cases.

It doesn't bind to a model profile. It binds to an invisible number that gets re-used.

That is the principle behind Remote Receivers. It's how the system works.

Andy

djmp69

I never deleted any models. Haven't had to yet. This is a relatively new IX12. I say relatively, because I've had it for almost a year now, but haven't had to delete any models because I'm still transitioning from my DX9.

Also, I didn't create a new model, I simply was going to rebind the 10360 to the SAME model that was binded to the 9350. However, I didn't yet get the chance because the problem arose while the transmitter was set to a model binded to the 10100
So as you see, there was nothing being reused yet. No models were deleted from the TX. I hadn't gone thru the rebind process yet.

djmp69

So its designed that I can control two different airplanes at the same time from one radio? Because that's what was happening.

AndyKunz

Yes, you can force it to allow you to do that by playing with the Model Match ID on the Frame Rate screen. By default, no. You have to do something (whether remembered or not) to cause it to happen otherwise. That's because of how the spread spectrum encoding works. A transmitter talking to a different model sounds like a white noise hiss to a receiver bound to another model on the same transmitter, the same as a different transmitter. The sending of the ID information is almost redundant - it's done in case by some chance there are two radios using the same encryption at the same time (about 1 in 4 billion).

Andy

djmp69

I didnt do any of that. Enough gobbledegook. Bottom line, there is an unforseen issue where, in this case, things are not working as designed. It happens. Bottom line, a line of communication between a receiver and transmitter is flawed, be it a fluke or a common issue. I have not gone into the frame rate screen because I have had no need to. My memory is not the issue. Whether you want to admit it or not, the fact is, something is not working the way it was intended. There is no way a receiver still binded to one model number is supposed to respond to a different model number, as you have repeatedly stated. Even further, there is no way, according to the overtures of modelmatch, that one transmitter is supposed to control two diffferent receivers unless purposely done through quite a few steps, as you said above. I have used Spektrum systems for a very long time now, and am very well versed. No expert for sure, but enough experience to know this is not normal and is an issue, isolated or not.

The facts again. The receiver should have reacted to the commands from the TX of the plane it was previously in. It did not. It reacted to a model profile in the TX that was never associated with it EVER. Simultaneously with another receiver. This was not purposely set up by me. I simply physically removed a receiver (with the remotes) from one plane and put it into another and turned on power. That is all. There is no way a model number could have been re-used as you said because I never deleted any models from the radio and hadnt yet entered the bind process.

I am without a doubt the biggest Spektrum flagman in my club, probably the whole area. But even I can admit there may be an issue, which is more probable than not, given we are talking about two new systems (IX series transmitter and newer AR series receivers). I did not imagine this, this actually happened. Somehow, the TX was controlling something it should not have been able to control. The only other thing that could have happen is maybe the software in the TX got corrupted somehow and something changed without my knowledge. Imagine, that happening to a computer? What? That's madness...

AndyKunz

There is no way a receiver is going to hear (due to spread spectrum spreading code), let alone act on, commands given by a transmitter bound to a different model ID than the one to which it is bound. Therefore both receivers were bound to this transmitter & model ID previously, not only previously, but most recently because the receivers have only a single bind memory available, by design.

All receivers turned on and bound to a transmitter & model ID will hear and act on any transmissions made by that transmitter while it is transmitting on that model ID. That is how the remote receiver system works, whether the receivers are remote receivers or integrated receivers.

Any database-level changes to the models listed in database can cause re-assignment of IDs (this is in contrast to data-level changes in the models). If a model was imported, that will affect its model ID. If a model is moved from another transmitter (or from a backup copy of THIS transmitter, if an IX radio) the ID can be changed. Resetting a model (which is a data change, but also affects the db level) can change the ID. If a model was recovered automatically by the transmitter due to a corruption, the ID could be affected. I can go on...

Both receivers were bound to this same transmitter/ID. It is possible to do, it is often done intentionally whether the user understands what they are doing or not.

What's important to capture is that there is no key that says "this is my Extra" vs. "this is my glider" to the receiver. The model ID is the sole connection. The model ID can be changed without realizing it. I strongly suspect that is what happened here. In large part because the receiver will not even hear a non-bound transmitter. It's just white noise.

Andy

djmp69

OK, like I said, I'll just chalk this one up to RC spirits. I know for FACT the receiver was not bound more than once. I am not a newbie, screwing around with programming and what not without knowing what I'm doing. What you fail to understand is that what you're describing isn't possible because I hadn't gotten to that point yet. There is NO WAY that the 360T was bound to the TX in a slot that was bound to 100T. Especially since the ONLY time the 360T was bound was when I first bought it, and that was for the sailplane. I know the receiver doesn't know what kind of plane it's in, stop talking like I'm an idiot. The model that held the 100T, I'd flown that plane perfectly fine, and that one as well has only been bound one time. There was no need to remind or delete the model or any other garbage you're asserting I did. And in order for me to make it so two different receivers would respond to the same model id, I would have to have gone in and really done some work that I would know about. Which did NOT happen.

To everyone out there, just be aware that this CAN happen, no matter what the oval office tells you. It happened to me. I made a mistake in the order in which I turned on the RX and TX, which made the problem manifest. You just have to pay attention. They may know the answer, and will secretly roll out a fix because they don't want you to know about the weak point in the armor. But it did happen as I said.

Andy, you are usually spot on with your support and advice, but this time, in THIS case, the situation eludes you. Thanks again for your patience and knowledge!

AndyKunz

I know exactly how it works, and why it works, at a far more detailed level than what you apparently get.

If you read my previous post, you will see that deleting is not necessary.

Andy

djmp69

I DID read your post, all of them, and on more than one occasion yo make mention of deleting a model would open that model id up to again being available. I know how the system is SUPPOSED to work, but, in this case it didn't work like that. I am well acquainted with how it's SUPPOSED to work, which is why I noticed there was a problem. 99% of the time, it works exactly as you describe in your posts. This 1% time it did not. That's why I reached out. I could see if I went in messing with menus, programming, etc, but I did none of that. I simply did the act of taking a receiver out of a plane and placing it into another. Thay receiver was only bound ONCE to the IX 12. Yet it responded to another model id simultaneously with the correct receiver responding. This is not fiction. This actually happened. And i did not do any deleting, programming, etc to make it happen. I simply mafe the mistake of powering on the reciever before the TX. There was no bind plug. I did not push and hold the bind button while powering up. End of story. This is simply an anomaly. No system is absolutely perfect to where problems cannot arise.