Jeti Duplex Lockoutproblem

Brownout-Funktion eines Reset-ICs ist nicht stoppen sondern ein x-ms anliegendes Reset Signal für den uC.

Es gibt 100% zuverlässige externe-Watchdog ICs (genau wie Brownout-Reset-Wächter).

Diesen kleinen Teilchen darf man dann im x-ms Takt einen Flankenwechsel eingeben. Tut man das für eine gewisse Zeit nicht, gibts auch ein x-ms anliegendes Reset Signal für den uC.

Den Flankenwechsel erzeugt man an einer Stelle im uC-Code, welche schon bei kleinen Problemen im Ablauf nicht mehr angesprungen wird.

Man braucht die externen Watchdog und Brownout-Wächter eigentlich nicht, wenn der uC sowas schon mitbringt, aber die uC-Teile sind leider oft nicht sauber implementiert.

Ein SC70-6 hat wohl noch auf jeder Platine platz.
 

sidigonzales

User gesperrt
Prof. Dr. YoMan schrieb:
Brownout-Funktion eines Reset-ICs ist nicht stoppen sondern ein x-ms anliegendes Reset Signal für den uC.
Nur damit wir über die selbe Funktion reden.
Brown out ist wenn die Betriebsspannung sich langsam dem unsicheren Bereich nähert und um sicher zu gehen das der Prozessor keine ungewollten weil fehlinterpretierten Aktionen ausführt hält man ihn so lange an wie die Spannung den sicheren Betriebsbereich nicht wieder erreicht hat und das meist mit einstellbarer Dauer für die Erholzeit.
Nur einen Int auslösen der den Proz neu startet löst das Problem der zu niedrigen BS nicht. Einen Int auslösen um ihn gezielt in den Tiefschlaf zu schicken ist sicher möglich genau wie den Proz einzufrieren aber das hängt ein wenig von der Technologie ab.

sanfte Grüße
 

Julez

User
Hi!

Bezüglich meiner erneuten Nachfrage erhielt ich diese Antwort:

###########
Dear Julian,

The Servos interference partially damaged the contents of processor RAM.
You can see this problem on the JETIBOX.
The program was running in the processor and it is the reason why the
watchdog did not react.

Best Regards
#############

Für mich als normalem Endverbraucher ist das Thema damit abgeschlossen.

Die Empfänger R4/R5 die durch rc-easy bezogen waren können bei rc-easy
kostenlos gegen Störungsresistente R4/R5 getauscht werden.

100% Zufriedenheit bringt Jans vorbildliche Umtauschaktion für mich.
Da kann ich nur sagen, Daumen hoch, sowas schafft Vertrauen.

Super!

Ciao,

Julian
 
sidigonzales schrieb:
Nur damit wir über die selbe Funktion reden.
Brown out ist wenn die Betriebsspannung sich langsam dem unsicheren Bereich nähert und um sicher zu gehen das der Prozessor keine ungewollten weil fehlinterpretierten Aktionen ausführt hält man ihn so lange an wie die Spannung den sicheren Betriebsbereich nicht wieder erreicht hat und das meist mit einstellbarer Dauer für die Erholzeit.
Nur einen Int auslösen der den Proz neu startet löst das Problem der zu niedrigen BS nicht. Einen Int auslösen um ihn gezielt in den Tiefschlaf zu schicken ist sicher möglich genau wie den Proz einzufrieren aber das hängt ein wenig von der Technologie ab.
sanfte Grüße
Ja, wir reden vom gleichen. Und das was du "Anhalten des Prozessors" nennst, nenne ich Reset Signal an den uC anlegen. Und das sobald die Spannung aus dem zulässigen Bereich nach unten heraus geht. Sobald die Spannung dann wieder ansteigt muss sie erst eine definierte Zeit im zulässigen Bereich sein, bevor das Reset Signal wieder den Pegel wechselt und der uC wieder laufen darf.
 
Moin,

in unserem Fall wär es natürlich cleverer wenn der µC bei einer BrownOut - Gefahr per Interrupt genötigt würde die Failsafe - Einstellung zu aktivieren und per Telemetrie seine Befindlichkeit durchzumelden. Danach erst schlafen legen :)

Aber insgesamt freue ich mich über den derzeitigen Stand der Erkenntnisse und die Reaktion von Jeti.

Julian, das haste gut gemacht.

Gruß

gecko
 

Julez

User
Danke, ich freu mich auch :)

Ist doch schön, wenn alles so schnell geht!
Mit dieser vorbildlichen Aktion sollte Jeti eine Menge neuer Kunden gewonnen haben.
Gerade bei 2,4GHz Systemen ist ein schnell und richtig handelnder Hersteller ein schlagendes Argument.
 

sidigonzales

User gesperrt
Prof. Dr. YoMan schrieb:
Ja, wir reden vom gleichen. Und das was du "Anhalten des Prozessors" nennst, nenne ich Reset Signal an den uC anlegen. Und das sobald die Spannung aus dem zulässigen Bereich nach unten heraus geht. Sobald die Spannung dann wieder ansteigt muss sie erst eine definierte Zeit im zulässigen Bereich sein, bevor das Reset Signal wieder den Pegel wechselt und der uC wieder laufen darf.

Ok, das löst aber keines unserer Probleme. Wenn der Brownoutdetektor zuschlägt ist es für einen geordneten Rückzug in eine Failsafeposition zu spät.
Jeti hat uns aber die wundervolle Möglichkeit der Spannungslevelunterschreitungsrückmeldung ;) gegeben. Die, meines Wissens, einzige Möglichkeit eine unnormal schnelle Verringerung der Batteriespannung frühzeitig zu erkennen und damit möglicherweise noch rechtzeitig zu reagieren.

sanfte Grüße
 
Öhm. Wir reden hier von einem Lockout wegen stehendem Prozessor ausgelöst durch ein madiges Servo. Auf jeden Fall sollte der Prozessor wieder auf die Füße fallen. Egal ob die Verbindung dann 1s weg ist. Schön wenn man es dann noch signalisiert bekommt, aber so wie es beschrieben war, "hängt" sich das System in einen nicht funktionsfähigen Zustand.
 

MalteS

User
Der Prozessor steht nicht wirklich total. In dem Video sieht man doch deutlich wie der Empfänger zwar keine Servosignale mehr zum Servo schickt, aber durch die Jetibox ausgelesen und gesteuert werden kann. Die Dinge die die Jetibox darstellt kommen vom Empfänger, das ist quasi eine Art Terminal.

http://de.youtube.com/watch?v=iOqQ_Nynr58

Auf die Spannungsversogung bzw. irgenwas in Richtung Brown-Out zu tippen halte ich für ne falsche Fährte.

RAM wie Jeti schreibt könnte sein, dann sollte aber der Watchdog zünden. Könnte mir aber auch gut vorstellen das es auf der Strecke von dem Empfänger IC zum Applikationsprozessor zu Fehlern kommen könnte. (Vorrausgesetzt sie verwenden überhaupt so eine Struktur). Das führt zu spezifischeren Fehlern im Ram.

Andererseits jetzt hier für Jeti die Entwicklung zu machen ist auch quatsch. Wenn man das wollte kann man ja auch in das Selbstbau RC Projekt einsteigen.
 

sidigonzales

User gesperrt
Prof. Dr. YoMan schrieb:
Öhm. Wir reden hier von einem Lockout wegen stehendem Prozessor ausgelöst durch ein madiges Servo. Auf jeden Fall sollte der Prozessor wieder auf die Füße fallen. Egal ob die Verbindung dann 1s weg ist. Schön wenn man es dann noch signalisiert bekommt, aber so wie es beschrieben war, "hängt" sich das System in einen nicht funktionsfähigen Zustand.
Holger, das der Prozessor hängt in der Form das er gar nix macht ist eine Annahme von dir und so nicht bestätigt.
Es ist ja genau das Problem das man in einem komplexen von verschiedenen Timings abhängigen Prozess nicht einfach irgendwo den Watchdog zurücksetzen kann. Eigentlich, und ich weiss das das nahezu unmöglich ist, muss man alle Prozesse sinnvoll überwachen. Das geht aber weit über eine simple Implementation hinaus.

sanfte Grüße
 
Korrekt und es wurde ja schon gesagt das wir hier nicht die Entwicklung für Jeti machen.

Aber das Problem einer eindeutigen Erkennung ob ein System noch sauber läuft oder nicht kann man lösen. Auch nicht sonderlich komplex, aber mit etwas Aufwand verbunden. Man kann jedes System in kleinere Teilsysteme unterteilen und jedes für sich kann einen Status signalisieren.

Aber wie auch immer. Ich hoffe Jeti löst es zuverlässig.

Wird dann wohl auch meine Wahl sein, außer MPX bringt etwas ebenbürtiges.
 

Space

User
MalteS schrieb:
Der Prozessor steht nicht wirklich total. In dem Video sieht man doch deutlich wie der Empfänger zwar keine Servosignale mehr zum Servo schickt, aber durch die Jetibox ausgelesen und gesteuert werden kann. Die Dinge die die Jetibox darstellt kommen vom Empfänger, das ist quasi eine Art Terminal.

http://de.youtube.com/watch?v=iOqQ_Nynr58

Auf die Spannungsversogung bzw. irgenwas in Richtung Brown-Out zu tippen halte ich für ne falsche Fährte.

RAM wie Jeti schreibt könnte sein, dann sollte aber der Watchdog zünden. Könnte mir aber auch gut vorstellen das es auf der Strecke von dem Empfänger IC zum Applikationsprozessor zu Fehlern kommen könnte. (Vorrausgesetzt sie verwenden überhaupt so eine Struktur). Das führt zu spezifischeren Fehlern im Ram.
Dem Beitrag von Malte kann ich voll zustimmen.
Die zerschossenen Werte im RAM sollte die Watchdog Resetroutine erkennen -> Plausiblitätsprüfung von Variablenwerten

Fehlerhafte Brownout Detection wird nicht die Ursache sein, da moderne Prozessoren normalerweise bis zu 1,8V noch sicher arbeiten. Da sind wir bei dem Testaufbau von Julian und der dort verwendeten Spannungsversorgung, weit von entfernt.

Wird der Watchdogtimer ohne eine Prüfroutine im Programmablauf "pauschal" zurückgesetzt, so ist zwar vorhanden, aber falsch eingesetzt !

Warum die Erklärung von Jeti über die zerschossenen RAM Inhalte euch hier genügt, kann ich wiederum nicht nachvollziehen.
Warum werden diese nicht erkannt...?

Ich möchte ein ausgewachsenen Betriebssystem nicht mit einem Empfänger vergliech, aber trotzdem kann man hier von lernen (von anderen OS natürlich auch)
Microsoft hat in Windows Schutmechanismen (z.B. Dr Watson) etabliert, um bei aus dem Ruder gelaufenen Prozessen ein Speicherabbild zu schreiben (Bluescreen) und den Rechner ggf. zu resetten. Genauso können einzelne Prozesse überwacht werden und im Fehlerfall Aktionen ausgelöst werden.

Andererseits jetzt hier für Jeti die Entwicklung zu machen ist auch quatsch. Wenn man das wollte kann man ja auch in das Selbstbau RC Projekt einsteigen.
Selbstbau mit 2 XBee's in redundanten Diversity Konstellation fliege ich seit der vergangenen Saison ohne Probleme. Allerdings wünsche ich mir trotzdem ein Kaufprodukt, welches meinen Ansprüchen abdeckt.
Jeti ist da mein Favorit, da es den Rückkanal bietet und preislich realistisch plaziert ist. Allerdings hat der Test von Julian bewiesen, dass im Bereich Fehlerhändling in der Software der Empfänger noch nicht alles optimal gehändelt wird. Solange bohre ich hier weiter nach. Das sollte positiv von Jeti aufgenommen werden, weil ich den Jeti Leuten zutraue, dass sie das Problem ernst nehmen und wirklich zeitnah nachbessern. Bei anderen Herstellern hätte ich da weniger Hoffung...
 
Moin,

ich wundere mich zZt darüber, das auf den Seiten von rc-easy und Hepf nichts zu dem Problem und dem Austausch der Empfänger steht ...

Aber wahrscheinlich ist alles Gut und die Käufer wurden direkt informiert.

Gruß

gecko
 

Julez

User
Hi!

Soeben habe ich die Lieferung von Jeti wiederbekommen.
Dabei waren ein R4 der neuen Serie, ein 30A Sensor als Ersatz :) für das Servo, was bei deren Tests schwer gelitten hat und nun praktisch hinüber ist, sowie ein Temperatursensor und ein Telemetrieexpander als Dankeschön für den Aufwand.
Sehr ordentlich, ich bin sehr zufrieden.

Ich hab den Servomotor auseinandergenommen und soweit wieder hingebastelt, dass das Servo gerade irgendwie noch läuft, um weiter testen zu können.
Ein Versuch mit einem alten R5 ergab das übliche, starkes Zittern an benachbarten Kontrollservo, wenn das Störservo bewegt wurde, und Lockout nach kurzer Zeit.
Als die identische Peripherie an den neuen R4 angeschlossen wurde, verhielt sich das Kontrollservo völlig ruhig, und es gab auch keine Lockouts.
Sehr gut! Die Filter scheinen ordentlich zu wirken.

In sofern kann ich nur sagen, Daumen hoch und weiter so.

Ciao,

Julez

PS: Video ist gemacht und kommt, nachdem ich meine Festplatten ausgetauscht habe. :D ;)
 

Anhänge

  • neuer Empfänger 003.jpg
    neuer Empfänger 003.jpg
    144,1 KB · Aufrufe: 56

koner

User
Das darf doch nicht wahr sein .!!! Er bekommt von Jeti so viel um SONNST und das für seine Papierflieger .!!!!:rolleyes:
Ich werde Narrisch , Morgen Schreibe ich einen Brief an Jeti und Jan .:cry:
:D
Gruß Paul
 

udogigahertz

User gesperrt
freudi schrieb:
Hallo,
heist das jetzt, dass alle neuen Empfänger auf dieses Problem geprüft werden?

Freudi
Also, ich kann mir jetzt beim besten Willen nicht vorstellen, dass Jeti immer noch "alte" Empfänger, die mit diesem Problem behaftet sind, ausliefern sollte. Das würde doch absolut keinen Sinn machen, oder?

Grüße
Udo
 
Ansicht hell / dunkel umschalten
Oben Unten