DX8: Akte X Season 2 oder zwei Modelle gleichzeitig binden

[miszczuk]

Hallo liebe Forumkollegen,

letztens habe ich von den Problemen meiner DX8 berichtet ein paar ältere BNF Modelle zu binden. Diese hatte ich schon mal gebunden und ich konnte mir das ganze nicht erklären.

Heute möchte ich vom genauen Gegenteil berichten. Ich kann die zwei mCPX V2 die ich mein Eigen nenne gleichzeitig binden.

Danke Spektrum für diese Innovation. Ihr habt wirklich die fortschrittlichste Funke der Welt gebaut! Die DX8 ist damit optimal für den Synchronflug geeignet.

Für den, der es nicht glauben kann, so zum Beispiel ich selbst, ein kleines Video:

http://www.youtube.com/watch?feature=player_detailpage&v=Baf-1sBCzug

Bevor ich mich mit HH in Verbindung setze schlafe ich erst eine Nacht drüber. Ich will nicht unhöflich auftreten.


Viel Glück den Leuten, die eine DX8 Funke besitzen wünscht

Bernhard

[Dennis_HB]

AW: DX8: Akte X Season 2 oder zwei Modelle gleichzeitig binden

Wow, ich konnte es nicht glauben und habe es gerade mit meinen beiden mCP x getestet. Einer V1 der andere V2. Auch diese kann ich beide an einen Modellspeicher binden.

Schönen Gruß an HH auch von meine Seite

Dennis

[joeggi]

AW: DX8: Akte X Season 2 oder zwei Modelle gleichzeitig binden

Hallo Bernhard

Ich denke, Du hast in Deinem Video die Helis eingeschaltet aber nicht gebunden.

Das Binden ist der Vorgang, bei dem Sender und Empfänger sich auf einen gemeinsamen Code einigen. Das Binden leitet man beim mCPx dadurch ein, dass man den Heli vor dem Sender einschaltet. Danach muss man die DX8 mit gedruecktem Bind Knopf einschalten und abwarten bis die Heli LED konstant leuchtet.

Nach meinem Verständnis ist es durchaus normal, dass 2 Empfänger auf den gleichen Modellspeicher gebunden werden können. Es ist dann also die Verantwortung des Anwenders sicher zu stellen, dass jeweils immer nur eine Empfänger eingeschaltet ist.

Anders ausgedrückt : pro Kanal wird ein Globally Unique Identifier (zufällig) verwendet, der von keinem anderen Spektrum Sender/Kanal weltweit eingesetzt wird. Damit kann - solange man die Empfänger/Sender nicht auf einander bindet - kein fremdes Modell auf Deinen Sender reagieren oder umgekehrt. Mehr ist nicht, weniger aber auch nicht.

Gruss
Joerg

[Hero67]

AW: DX8: Akte X Season 2 oder zwei Modelle gleichzeitig binden

Bernhard hat recht, man kann mit Spektrum durchaus mehrere Modelle auf einen Modellspeicherplatz binden. Hat aber nichts mit der DX8 speziell zu tun.

Ist aber nichts Neues:
RC-Heli Community - Einzelnen Beitrag anzeigen - Spektrum Binding und das Feature Modelmatch

Das angepriesene Modelmatch ist auf selten däml.... Weise von Spektrum implementiert worden. Der Empfänger speichert eine GUID, die aus der UID des Senders und ganz stumpf aus der Nummer des Modellspeichers generiert wird. Dadurch kann man mehrere Modelle/Empfänger an einen Modellspeicherplatz binden, was aber leider nicht geht ist, mehrere Modellspeicherplätze(Setups) für einen Empfänger zu verwenden.

Ich habe mich in den obigen Thread schon lang darüber ausgelassen, vom Spektrum Entwickler bislang nur eine ausweichende Antwort erhalten und mich mit Leuten im Forum schon über den Unterschied ßquivalenz/gerichtete Realtion gestritten.

Würde Spektrum nicht stumpf die Nummer des Speicherplatzes für die GUID verwursten, sondern z.B. mit einer Hashmap arbeiten, dann könnte obiges nicht passieren, man könnte durch die indirekte Indizierung mehrere Setups für einen Empfänger verwenden und wäre trotzdem auf dem sicheren Seite bzgl. Modelmatch. Zudem wäre eine solche Implementierung nur durch ßnderung der Funkenfirmware machbar und wäre kompatibel zu allen existierenden Empfängern.

[piotre22]

AW: DX8: Akte X Season 2 oder zwei Modelle gleichzeitig binden

Das ist ja krass!


Ich habe das gleiche schon mal mit meinem Jeti Duplex ausprobiert, also einfach zwei gebundene Empfänger einschalten (bei Jeti gibts kein Modelmatch), doch der Empfänger der später eingeschaltet wird bleibt dann einfach tot.

Liegt das vielleicht an dem nicht vorhandenem Rückkanal bei Spektrum? Denn ohne Rückkanal weiß der Sender ja gar nicht ob und wie viele Empfänger da bzw. eingeschaltet sind, oder? Der Empfänger empfängt dann einfach nur die Daten die vom Sender kommen und führt die Befehle aus. Bei 35Mhz konnte man ja auch einfach mehrere Empfänger einschalten und alle eingeschalteten Empfänger auf dem gleichen Kanal haben dann brav das gleiche gemacht.



Aber abgesehen davon:
Ich würde das Synchronfliegen mit den beiden mCP X mal machen!
Einfach mal auf ne große Wiese gehen und dann mal versuchen + Video davon machen...ist bestimmt lustig

[Hero67]

AW: DX8: Akte X Season 2 oder zwei Modelle gleichzeitig binden

Liegt das vielleicht an dem nicht vorhandenem Rückkanal bei Spektrum? Denn ohne Rückkanal weiß der Sender ja gar nicht ob und wie viele Empfänger da bzw. eingeschaltet sind, oder? Der Empfänger empfängt dann einfach nur die Daten die vom Sender kommen und führt die Befehle aus.

Im Prinzip ja. Aber damit das "richtig" funktioniert, ist kein Rückkanal erforderlich.

Die Programmierer haben einen logischen Fehler gemacht. Die Forderung an eine funktionierendes Modelmatch muß lauten:

Es gibt genau einen Empfänger der mit einem bestimmten Modellspeicherplatz einer Funke funktioniert.

Die Aussage:
Es gibt genau einen Modellspeicherplatz einer Funke, der mit einem bestimmten Empfänger funktioniert
ist NICHT identisch zu der obigen Forderung, erlaubt das Binden von mehreren Empfängern an einen Modellspeicherplatz und ist leider genau das, was Spektrum implementiert hat.

Was passiert beim Binden ? Aus einer einder eindeutigen Identifikationsnummer der Funke (z.B. Seriennummer) und dem Index des Modellspeicherplatzes wird eine GUID generiert (mit welchem Algorythmus ist nebensächlich, solange die erzeugte GUID global eindeutig ist). Also simpel gesagt aus Seriennummer ABC und Modellspeicherplatz 4 wird eine GUID ABC4. Diese wird beim Binden an den Empfänger übertragen und dieser speichert sie während des Bindevorgangs. Im Normalbetrieb der Funke wird mit jedem Datenpaket die GUID ABC4 mitgeschickt, der Empfänger vergleicht diese mit der gespeicherten GUID und kann daran erkennen, ob das Datenpaket für ihn bestimmt ist.

Diese statische Zuordnung der GUIDs zu den Modellspeicherplätzen hat zwei Entscheidende Nachteile:
1. Beim Binden kann ein und die selbe GUID an mehrere Empfänger übertragen und gespeichert werden, das führt zu dem Verhalten mit den 2 mCPx
2. Beim kopieren eines Modellspeicherplatzes auf einen anderen geht die Bindung zum Empfänger verloren, da jedem Modellspeicherplatz eine statische GUID zugeordnet ist. Es ist also nicht möglich, sich mehrere funktionierende Setups für den selben Empfänger anzulegen. Z.B. ein Setup für viel Wind, eins für meinen Sohn, eins für Lehrer-Schüler Betrieb etc.

Vergleichbar ist das mit einem Autoschlüssel: Es gibt genau ein Auto, welches ich mit dem Schlüssel fahren kann. Was aber nicht heißt, das es für das Auto nur einen Schlüssel gibt, das ist nämlich nur dann so, wenn man seinen Zweitschlüssel verloren hat

Ich skizziere mal einen Ausweg aus dem Dilemma:

Statt jedem Modellspeicherplatz eine statische GUID zuzuordnen, benutzt man eine dynamisch generierte GUID. Für solche Probleme gibt es nette Algorithmen, aber bei nur 30 Einträgen geht es auch ganz simpel.

Dazu erweitert man die im Flashspeicher der Funke abgelegte Datenbank um ein Feld "Model-ID" für jeden der z.B. 30 Datensätze einer DX8. Zusätzlich führt man einen globalen Model-ID Zähler ein, der ebenfalls im Flashspeicher abgelegt wird.
Keine Ahnung wie groß der Flashspeicher ist, aber nehmen wir mal für einen 16Bit Wert für das zusätzliche Datenbankfeld und 16Bit für den Zähler, dann haben wir lediglich 62 Byte zusätzlichen Speicherbedarf.

Und so funktioniert es:
1. Beim jedem neuen Binden wird nun nicht einfach aus dem Index des Modellspeichers die GUID ermittelt, sondern nach folgendem Algorithmus: Für den Model-ID-Zähler z finde die kleinste Zahl x, für die gilt x > z und x > als alle verwendeten Model-IDs die in den 30 Datensätzen abgelegt sind. Nehme als nächstes z nun die Zahl x und speichere sie im Feld "Model-ID" des aktuell gewählten Modellspeichrplatzes ab:

for ( i = 1; i <= 30; i = i +1 )
{
if ( Model_ID[i] = z )
z = Model_ID[i] + 1;
}
Model_ID[akuteller Speicherplatz] = z;

Die GUID wird nun aus der Seriennummer und dem im Feld Model-ID abgelegten Zähler z erzeugt und bei jedem Bindevorgang als ABCz an den Empfänger übertragen und der speichert die GUID ab.
Im Normalbetrieb wird die unter dem Modellspeicherplatz abgelegte GUID mit jedem Datenpaket mitgeschickt.
In der Firmware des Empfängers muß nichts geändert werden, er bekommt eine GUID, die er beim Binden abspeichert und später vergleicht, daran hat sich nichts geändert.

Dadurch, dass nun bei jedem Bindevorgang eine neue GUID generiert wird, vermeidet man das Abgspeichern von identischen GUIDs in mehreren Empfängern. Natürlich hat ein 16Bit Zähler einen ßberlauf, man fängt also irgendwann wieder bei 1 an, aber das bedeutet nur, dass man nach über 65000 Bindevorgängen frühestens einmal in das Dilemma laufen kann, was man aktuell immer hat.

2. Beim Kopieren eines Modellspeicherplatzes wird das Feld "Model-ID" mitkopiert. Dieser neue Speicherplatz funktioniert also auch mit dem zugeordneten Empfänger, der Zweitschlüssel also.

Ist das ein Widerspruch zu der Forderung, nicht ausversehen mit einem nicht passenden Modellspeicherplatz ein falsches Modell zu steuern ? NEIN
Denn der Empfänger eines anderen Modells wird mit der GUID nichts anfangen können, sie ist ja immer noch eindeutig.

Will man den kopierten Modellspeicherplatz nur als Vorlage für ein neues Modell mit einem neuen Empfänger benutzen, so ist das auch kein Problem, es wird ja beim Binden eine neue GUID für den Modellspeicherplatz generiert.

Der Algorithmus ist simpel, sicherer als der aktuell existierende und zudem durch die Möglichkeit mehrerer Setups auch noch flexibeler und erfüllt zu 100% die Forderung:

Es gibt genau einen Empfänger, der mit dem aktuellen Modellspeicherplatz funktioniert.

Warum Spektrum das nicht so gemacht hat, ist mir ein Rätsel. Statt dem simplen obigen Algorithmus zum Ermitteln der Model-ID einfach zu sagen Model-ID = Modellspeicherplatz ist natürlich noch simpler

[coerni]

AW: DX8: Akte X Season 2 oder zwei Modelle gleichzeitig binden

Walkera macht es noch einfacher... .

Hier kann der User einen 6stelligen Code manuell eingeben. Nur Empfänger mit passenden Code werden gebunden... .

[Jee]

AW: DX8: Akte X Season 2 oder zwei Modelle gleichzeitig binden

Normalerweise sollte das nur gehen, wenn du die beiden Helis gleichzeitig bindest.

Das kann sinnvoll sein - so wurde mir zum Beispiel erklärt: Wenn man in einem Großmodell so starke Servos drin hat, dass ein Empfänger überlastet wäre von den Strömen her.. dann bindet man eben zwei Empfänger und verteilt die Servos.

Gruß,
JP

[coerni]

AW: DX8: Akte X Season 2 oder zwei Modelle gleichzeitig binden

dann nimmt man doch eher ein BEC mit Servoausgängen... .

Bei Grossmodellen mit starken Servos versorgt man diese normalerweise nicht über den Empfänger... .

[Mikewoofer]

AW: DX8: Akte X Season 2 oder zwei Modelle gleichzeitig binden

Das weis ich schon seit über einem Jahr

Das geht auch mit einer DX7 !!!

Ich weis nur nicht was daran schlimm sein soll *

Meine Funke + Meine Modelle .

Wer schaltet den schon 2 Modelle gleichzeitig ein ??

[Darko]

AW: DX8: Akte X Season 2 oder zwei Modelle gleichzeitig binden

Wer schaltet den schon 2 Modelle gleichzeitig ein ??

seh ich genauso...
Ist doch völlig wurscht.. andere Hersteller haben nichtmal ein ModelMatch.

Vorallem kann man so einen Speicherplatz für mehrere MCPx nutzen.. ist doch auch nicht schlecht... und wenn man es nicht möchte, bindet man den 2. MCPx einfach auf nen anderen Speicherplatz und schon funktioniert das hier gezeigte nicht mehr.

Also ich versteh grad das Problem nicht

[ArguZ]

AW: DX8: Akte X Season 2 oder zwei Modelle gleichzeitig binden

Ich find das super, meine beiden mCP X freuen sich dass ich nicht umschalten muss.
Geiles Feature, hat Fubar nicht

[Razputin]

AW: DX8: Akte X Season 2 oder zwei Modelle gleichzeitig binden

Ich kann auch nicht nachvollziehen, warum das ein Problem ist. Das "zufällig" der zweite mCPx auch angeschaltet rumsteht und mit abhebt, weil man die Empfänger "aus Versehen" genau so gebunden hat?

Modelmatch verhindert, das man Empfänger mit falschen Einstellungen ansteuert. Das du zwei Modelle mit den gleichen Sendereinstellungen betreiben kannst, ist doch prima.

[higginsd]

AW: DX8: Akte X Season 2 oder zwei Modelle gleichzeitig binden

Langer Rede kurzer Sinn: ich will sehen, wie die beiden mCPxe abheben! Video, Video!

Gruß
Dirk

[Hero67]

AW: DX8: Akte X Season 2 oder zwei Modelle gleichzeitig binden

Normalerweise sollte das nur gehen, wenn du die beiden Helis gleichzeitig bindest

Das geht auch bei der dynamischen Generierung von Modell-IDs beim Binden. Aktuell kann man bei Spektrum aber auch schön einzeln nacheinander mehrere Modelle an den gleichen Modellspeicher binden.

Ist doch völlig wurscht.. andere Hersteller haben nichtmal ein ModelMatch.

Nein, haben andere auch, nennt sich nur nicht Modelmatch. KDS hat es z.B. und da funktioniert es ohne solche Nebeneffekte.

Vorallem kann man so einen Speicherplatz für mehrere MCPx nutzen.. ist doch auch nicht schlecht... und wenn man es nicht möchte, bindet man den 2. MCPx einfach auf nen anderen Speicherplatz und schon funktioniert das hier gezeigte nicht mehr.

Und die beiden mCPX oder sonstigen gleichen Modelle haben auch genau gleiche Gestängelängen und den gleichen nötigen Subtrim etc. ? Nö, Nö, das braucht niemand.

BTW: Es war ja schon ein bißchen spät. Der Algorithmus muss natürlich lauten:

Man finde eine neue Modell-ID x für die mit einem aktuellen Modell-ID-Zähler z gilt: x > z und x wurde noch nicht von einem anderen Modellspeicher als ID verwendet.

do
{
z = z +1;
used = false;
for ( i = 1; used != true && i <= 30; i = i + 1 )
{
if ( Model_ID[i] == z )
{
used = true;
}
}
} while ( used );
Model_ID[akuteller_Speicherplatz] = z;

Tut aber nicht was grundsätzliche zur Sache, wichtig ist nur, jeweils beim Binden eine neue noch unbenutzte Modell-ID zu generieren.