Fehlerhafte falsche ID bei T6ex und T7C 2.4gHz

[Flyfrog]

Hier noch mehr dazu:

http://www.rc-network.de/forum/showthread.php?t=90961

Mir ist das Thema durchaus bekannt, ich lese (und schreibe) auch viel in anderen Foren .

[Flyfrog]

Ohne jetzt weiterhin die Pferde verrückt machen zu wollen, mein
"IDverlierTest" ist fast abgeschlossen.

Ich habe den Sender über Nacht angelassen, heute morgen machte er
keinen Mucks mehr. Also den guten Eneloop rein und der Bindungstest
konnte beginnen. Kurz und knapp: Der Sender scheint seine "alte ID"
vergessen zu haben. Der vorher gebundene F617FS kann nicht mehr
angesteuert werden. Leider habe ich z.Zt. keine ungebundenen Empfänger
mehr hier. Der Test mit bisher ungebundenen Empfängern muss also bis
heute Nachmittag/-abend warten.

Mein Sender T7C (Serial No. 071107015 Robbe/Futaba Service-No.
T257641) zeigt das oben geschilderte Verhalten.

Eine Bewertung dessen, überlasse ich den Fachleuten.

Eine Anmerkung noch, der hier im Forum aufgetauchte Sender, der das
gleiche Verhalten zeigte, ist nicht weit von meinem entfernt (Serial
No. 071106956 Robbe/Futaba Service-No. T257736) somit nehme ich
meine Aussage zurück, dass ich eddy039 nicht ganz glaube, was er
getestet hat.

[FPK]

Daraus kann man also einige Schlüsse ziehen:
1) Man sollte den Sender nie tiefentladen.
2) Wenn man den Sender tiefentladen hat, sollte man sich Gedanken machen, wenn man danach die Emfänger neu binden muss.
3) Wenn man einen neuen Empfänger hat, kann man testen, ob man sich nicht früher die ZGUID eingehandelt hat.

Nicht schön aber handhabbar.

Immerhin haben die Recherchen gestern einiges mehr ergeben, die FF-7 verwendet als Transmitter/Modulator einen ML2724 (http://pdf1.alldatasheet.com/datasheet- ... L2724.html).
Damit ist immerhin die Rohdatenrate von 1,5 MBit/s bekannt. Da die FF-7 meines Wissens 8 Kanäle mit 16 Bit Genauigkeit (160 Bit) in 2 ms (3072 Bit verfügbar) sendet, sieht es immerhin so aus, als würde Futaba auch DSSS machen, allerdings reicht das Rohdaten/Nutzdatenverhältnis nicht aus, um jeder GUID (~130 Mio waren es, oder?) einen eigenen (orthogonalen) Spreizcode zuzuweisen ... da muss wohl noch FHSS mithelfen ...

[actron]

hier steht, dass es bald eine Stellungnahme geben wird.

http://www.rc-network.de/forum/showpost ... tcount=137

Gruß Mike

[tracer]

1) Man sollte den Sender nie tiefentladen.

Klar, aber es kann passieren, und darf maximal den Akku schädigen.

[worldofmaya]

Also für mich wäre interessant ob davon nur die FF6/FF7 oder auch die Module betroffen sind. Zur Zeit kann man ja nur spekulieren... nach dem sich aber scheinbar der Fehler reproduzierbar ist wird's wohl ein größeres Problem sein.
Über kurz oder lang wird wahrscheinlich kein Weg daran vorbeiführen entsprechende Technik einzusetzten um die IDs zu überprüfen. Aus Versicherungsgründen auf einem Vereinsplatz wird daran wohl kein Weg vorbeiführen. Ob das dann wirklich so ein großer Erfolg gegenüber dem Kanal-"Problem" bei 35MHz ist würde ich jetzt mal sehr bezweifeln...
-Klaus

[FPK]

1) Man sollte den Sender nie tiefentladen.

Klar, aber es kann passieren, und darf maximal den Akku schädigen.

Ja, aber immerhin scheint es nicht so zu sein, dass man einfach einen Sender mit ZGUID bekommen kann, sondern es selber merken kann. Klar ist es blöd, aber es gibt schlimmeres als Schaden am Sender beim Tiefentladen

[tracer]

Klar ist es blöd, aber es gibt schlimmeres als Schaden am Sender beim Tiefentladen

Jain.
Ok, wenn es so ist, das man durch tiefentladen die GUID auf eine ZGUID verändert, und weiss das dann auch, kann man den Sender einschicken.
Wenn jemand nun nicht die hunderte Seiten in diversen Foren verfolgt, sondern einfach neu bindet, und fliegt, haben wir schnell viele, viele Sender mit der ZGUID im Umlauf, oder?

[glaus]

als nächstes könnt ihr probieren jetzt sender und empfänger aneinander zu binden, und dann tiefentladen, und schuan ob die bindung wieder weg ist.
möglich äre, dass nur die bindung vergessen wird, und die id gleich bleibt (ne flüchtige tabelle mit den bindungen).
Wenn die id auf einen bestimmmten wert gesetzt wird (z.B.0), dann ist sie nach dem 2. mal entladen immer noch bei 0. Dann müsste ja die Bindung immernoch bestehen. (wenn sie das tut, hat man ein problem, dann müsste man mal mit nem 2. sender zusätzlich versuche machen um noch mehr herauszubekommen, den leer werden lassen, und schaun, ob der jetzt an den empfänger gebunden ist)

[actron]

sondern einfach neu bindet, und fliegt, haben wir schnell viele, viele Sender mit der ZGUID im Umlauf

Genau so wird es kommen. Und wer sagt denn, dass es nicht schon beim Ausschalten passieren kann ? Könnte ja der Ein/Aus Schalter prellen und
schon vergisst das HF Modul seine GUID.

Es ist also höchste Vorsicht geboten, sobald man seine Empfänger neu binden muss.

Und wer legt sich schon einen extra neuen Empfänger einfach so in den Keller, nur um zu testen, dass die Anlage keine ZGUID hat ???

Ich will fliegen und 100% sicher sein dass ich mit einer Wahrscheinlichkeit von 1:130000 (oder so ähnlich ) keine doppelte GUID haben kann.

Wenn schon das Modul aus irgendeinem Grund mal seine GUID auf Default
setzt, bzw. schon hat, dann möchte ich das gerne wissen, oder die Anlage sendet einfach nicht.

Mir stinkt das gewaltig, da kauft man sich eine neue Anlage und dann sowas, also echt.


Gruß Mike

[tracer]

möglich äre, dass nur die bindung vergessen wird, und die id gleich bleibt (ne flüchtige tabelle mit den bindungen).

Das passt aber nicht dazu, dass mehrere Sender den selben rx bedienen konnten.

[actron]

Entweder schreibt der Controller im Modul bei Unterspannung ein Haufen Schrott rein in seinen nichtflüchtigen Speicher (Erzeugt dann Checksummenfehler) oder er kann dann seinen Speicher nicht mehr korrekt lesen (auch Checksummenfehler) und initialisiert sich auf eine Default ID.

Gruß Mike

[worldofmaya]

initialisiert sich auf eine Default ID.

Das wäre aber schon ein schwerwiegender Fehler im System. Zumindest müsste eine Fehlermeldung ausgegeben werden.
-klaus

[eddy039]

Moin!

Also, ich hatte eben einen Rückruf von Robbe erhalten und mir
wurde das Problem ganz klar bestätigt. Bisher war ihnen nur das Thema bekannt, das einige wenige Sender mit einer leeren ID geliefert wurden.
Seit einigen Tagen bestätigen sich einige Fälle wie meiner, das die ID
durch Tiefentladung verloren ging. Ebenso soll es durch extrem unglückliches, sehr schnelles ein und ausschalten schon dazu gekommen
sein.
Derzeit ist man wohl mit Futaba in eifriger Verbindung und es wird in den
nächsten 1-3 Tagen eine Meldung auf der Robbe-Seite geben, wie das
nun gehandhabt wird. Es wird wohl eine weltweite Rückrufaktion aller
Produkte geben.
Er bedauerte es sehr und sieht auch ein bisher ungeklärtes Problem
mit der Ersatz-Lieferung, da man ja wohl erstmal produzieren müsse...
Futaba redet wohl von Februar, aber er weiß es nicht...

Gruß, ed

[actron]

Zumindest müsste eine Fehlermeldung ausgegeben werden

Genauso sehe ich das auch.
Aber es wird eine Fehlermeldung ausgegeben in der Form, dass die
Empfänger nicht mehr gehen und neu gebunden werden müssen.

Aber wenn die bisherigen Empfänger schon DefaultID hatten siehts schlecht aus.

Irgendwie wurde das nicht zu Ende gedacht bei Futaba.

Gruß Mike