Model Match

[Dave Hopkin]

Posted by kc on 27/05/2015 15:58:19:

Not quite sure what you are saying there Dave. Are you saying that each memory gives a different Global Unique Identity? That is to say a 10 memory Tx would be able to transmit any of 10 different GUID and a 250 memory would give 250 different GUID?

Both the TX and RX will have a GUID, when the RX is bound to the TX the RX stores the GUID of the TX and the RX stores the GUID of the RX in the model memory (we call the RX's but in reality they are transceivers)

So when bound the RX stores one and one only GUID - the TX to which it is bound to, to prevent it being picked up by a different TX, the RX stores the GUID in its model memory area associated with the model number

As for the disabling model match that mike mentioned, he says he did in in OpenTX so he cant have altered the physical binding process itself - so the GUIDs will be exchanged, what I assume he has done is removed the check in the coding that has a decision point "Selected Model GUID = Recieved RX GUID" if that decision point exists in the code a negative answer would take the program to display a wrong model selected message and do what ever inhibits are coded, a positive answer would allow the code to move forwards into whatever was next in the program flow

[Mike Blandford]

My changes are to ersky9x, not openTx. OpenTx doesn't have support for these potential modules yet.

The Tx firmware doesn't see the Tx or Rx GUIDs. All it does is keep sending an additional value, a "model match" number. The receiver stores this value when it is bound, and only responds to control data if this is the same number it is receiving in normal operation. I simply always send the number 1.

Mike.

[kc]

So how can just sending a number be patented?

[Bob Cotsford]

I guess the concept of adding an ID tag to the datastream in order to identify a correctly matched model could be intellectual property and subject to patent rights. Sending a number or stream of numbers is what digital technology is all about, but how those numbers are interpreted and used is another matter!

[Dave Hopkin]

I would rather think Microsoft, Hewlett Packard, Intel, Texas Instruments and a whole heap of other corporates would stamp on Spektrums claims to have a patent on GUIDs in fairly short order!

Mike - I don't know the code in the ersky9x at all, but I can see what you mean, if you mean your effectively using a pre-existing model number in places of the firmware GUID - But the comment "I always send the number 1" confuses me as that would imply that regardless of the Model Selected the common data ID will be 1 - in that case it wont matter which model is selected the RX will respond to the controls....

[Simon P]

A quick experiment with my JR XG8 which works on JR's new DMSS system indicates that the transmitter does not check which RX it is communicating with. I bound two different RXs to the same transmitter on the same model memory. Turning each RX on in turn (and turning the transmitter off between switch overs) I was able to control servos via both RX's without having to rebind either. I did not try to turn both RXs on simultaneouly since they both will attempt to send battery voltage telemetry to the transmitter and I didn't want to add that complication to the experiment - would be interesting though and I seem to recall reading a few years back about someone who controlled two Blade micro helis simultaneously on the Spektrum system in the very same way. Back to the DMSS system for concludion: This is interesting on a few levels not least of which is that telemetry is built into the RXs on the DMSS system so all DMSS RXs are perfectly capable of sending some kind of Identifier to the TX but they clearly don't or, if they do, it is ignored.

[Bob Cotsford]

That sounds correct Simon, the transmitter sends the model ID which the receiver stores, once binding is complete the receiver will only respond to a command stream with the correct model ID. In that way you can bind as many receivers as you like to a particular model memory, they will all link and all will respond to that model ID. What will confuse matters is if they all send telemetry data back!

With FrSky this is used to provide all 16 channels using two receivers without resorting to S-Bus, one outputting ch 1-8, the other ch 9-16. The catch is that only one receiver can be bound in telemetry mode.

 

Edited By Bob Cotsford on 27/05/2015 21:30:46

[Mike Blandford]

Dave: We have two different things here.

1. The Tx module and the receiver deal with the GUID(s). These guarantee that only receivers bound to this Tx module can possibly be controlled by that module, not by any other module.

2. The transmitter firmware additionally sends a "model number" to the receiver, via the Tx module. This is the "model match" function and is completely separate from the GUID use.

It is this "model number" I force to be always 1, I have no control over the GUID used by the Tx module.

Mike.

[Simon Chaddock]

I fly two separate planes using the same Spectrum model memory, indeed the Tx will work them simultaneously if both are powered up at the same time.

This does seem to suggest that the Tx can store more than one unique Rx identifier against a model memory.

Obviously to be practical both planes have to have identical servo directions and the same basic trim levels.

[Mike Blandford]

I'm fairly certain the Tx doesn't store anything about the receiver. Instead, it is the receiver that stores the GUID from the transmitter, as well as the "model number", and only responds to those set during binding.

Mike.

[Former Member]

[This posting has been removed]

[Bob Cotsford]

This looks to be the way of the future, with the ability to backup and restore individual models comes the ability to download pre-defined model setups to your transmitter. There are already web sites where users can swap setups for particular model/transmitter combinations.

[Former Member]

[This posting has been removed]

[Chris Bott - Moderator]

In OpenTx, certainly for Taranis, this idea is implemented by assigning a Receiver number during setup. (D16 mode)

If you set up a brand new model, then the model memory number seems to be used. As a consequence, the Rx number in this case is unique.

However if you copy an existing model to a new model memory, which is a very common technique when setting up a model that's similar to an existing one, then the Rx number is also copied.

So I think it's a fair bet to say that many of us Taranis users, believe that we have full model match type protection, when actually we may not.

Rx number is manually configurable (then needs a rebind), so it can be checked and altered for every model. All part of the incredible flexibility, which in turn brings it's own confusions.

[Bob Cotsford]

Chris, if you copy a memory that uses D16 mode then when you bind it will warn you that you have already bound a receiver to that model number. This is your prompt to change the model number.

[Chris Bott - Moderator]

Indeed it does Bob, but I'm probably not the only one that on occasion has just accepted that, with the full intention of going back to change it later?

[kc]

If that is the way Binding and Modelmatch are achieved, then why could something similar not be done with 35Mhz? The Rx dont send info back to the Tx but we could have a cable to plug into the RX whilst linking the two together. So whats stopping (in theory) having 35Mhz that is bound to one particular Rx with a GUID? ( I asked the same question years ago before 2.4 was used and got negative comments then! )

I ask this question because if 2.4 gets overcrowded with lots of non RC stuff we might need to go back to 35mhz. And of course if we dont use 35mhz then we will lose it eventually.

[Dave Hopkin]

Binding using a GUID could be achieved on any frequency TX/RX combo - however, I would suspect that the chip sets used in 35Mhz kit are quite an elderly design and probably dont have a GUID burnt into them - but if they, then with a major redesign of the RX and TX plus the associated microcode changes it could be done - but what manufacturer is going to invest in 35Mhz development

It will take a huge amount of equipment using 2.4 to make it too crowded dont forget 2.4 is used by low power output devices so you would only find very local devices plus the bandwidth of the channels on 2.4 if far narrower so coupled with modern radio frequency agility I dont see it being an major issue any time soon

[kc]

I think you are right about investment. But if it is ( was) possible why didn't anyone produce a 35Mhz system that couldn't be 'shot down' when 35 was popular?

I fear we will lose 35mhz because so few use it now and new equipment is no longer sold.

[Chris Bott - Moderator]

KC it's because it's not just the GUID that saves you from being shot down. The bandwidth available at 2.4Ghz allows robust modulation techniques (e.g. Spread Spektrum) that will continue working even when interference is hitting some of the signal.

An analogy that I heard recently was that it's like the difference between an open ended pipe and a shower head. You can block a pipe with one finger (the interference) but put one finger on a shower head, and you hardly make any difference.

[Bob Cotsford]

Mainly because most 35MHz uses a simple stream of variable width pulses with no digital content that could hold an encoded ID? I don't know about PCM systems, they may have been suitable but not common or garden PPM systems.

Seeing as the core method of encoding servo positions remained the same since the '60s 27MHz AM systems I guess it was the case that it worked well enough for the majority of users, why change it?

 

edit - though Chris has a valid point re bandwidth!

Edited By Bob Cotsford on 31/05/2015 17:22:31

[Dave Hopkin]

Also the "digital revolution" hadn't happened, wireless devices were not around and most radio signal transmitters either licenced or subject to very restricted power (or both!) - if memory serves it was CB Radio that was the first real "Threat" to RC on 27Mgz (or is that showing my age?)

[Erfolg]

It all sounds like a very basic "Check Sum" algorithm as used extensively in computing and control systems, where there are many forms.

If a patent has been obtained, in my opinion emphasises how what once was a facility that made research and development worthwhile, becomes one where stretching the limit where prior art can be distorted into becoming new and novel, by arguing that the specific application is in itself unique.

I find it bizarre that copyright can be applied to shoes with red soles.

At one time trivial and self evident ideas could not be patented, things seem to have changed in recent times.

 

Edited By Erfolg on 31/05/2015 17:37:09

[Former Member]

[This posting has been removed]

[kc]

About 17 years ago a group of us RC fliers had normal flying session where we ensured strict 35 Mhz peg board control then walked back to our cars in a group, each of us pressed the car alarm 'fob' to unlock our car. Nobodys remote unlocked the wrong car as you would expect. So the thought occured to me then why do the cars not interfere yet planes do? Nobody could say why a similar system had not been used on planes.

To check with other equipment I drove down the road pressing my garage door remote - nobody else's garage seemed to open but mine! So obviously there were several systems of indivdual control available then - predating Spektrum's production anyway. So how come they have a patent? Do they have a patent on Model Match or just trademarked the name?

Edited By kc on 31/05/2015 18:47:31