Jeti Duplex Lockoutproblem

Julez

User
Hallo Leute,

Vielen Dank für eure sachlichen Beiträge!
So entwickelt sich der Thread so, wie ich es mir wünsche. :)

Microtino schrieb:
@ Juilan: Vielen Dank für deine hartnäckige und objektive Art solche Sachverhalte aufzuklären.
Drei Fragen könntest Du evtl. beantworten:
1. Wie kann ich einen Bodentest durchführen um ein evtl. Lockout-Problem zu identifizieren.
2. Hast Du mit dem R6 und R8 getestet - war da wirklich alles ok?
3. Ein Sender-Neustart (wäre ja im Flugbetrieb möglich) hilft nicht - oder?

Hi Martin,

1. Bis jetzt ist das Lockout Problem bei den Betroffenen immer recht schnell und reproduzierbar aufgetreten. Es reichte, das relevante Servo schnell hin und her zu bewegen. Ich würde dabei möglichst kurze Servokabel nehmen.
Ich habe zudem beobachtet, dass im Anfangsstadium, vor dem Lockout, kryptische Zeichen auf dem Jeti Box Display erschienen.
Sollte all dies nicht geschehen, sollte man vorerst sicher sein.
2: Ich habe nur mit dem R4 getestet. Bis jetzt liegen keine Berichte über Probleme mit dem R6 oder R8 vor. Der Mensch, der mit dem Dymond D150 Probleme hatte, konnte diese nicht bei dem R6 oder R8 reproduzieren.
3. Nein, hilft nicht. Jeti sagt ja auch, dass der Empfängerprozessor betroffen sei.

Ciao,

Julez
 

sidigonzales

User gesperrt
Hi Christian,

wie wäre es denn wenn du die betreffenden Personen mal ganz direkt und ohne Umschweife fragst warum sie den Tonfall nach deinem Erachten unangemessen verschärft haben.
Das ist zumindest besser als frei interpretierend tätig zu werden.
Alternativ kannst du auch gerne mal die Rechtsabteilung deiner Firma bemühen.

sanfte Grüße
 

HFK

User
Ich habe gerade noch mal nach gelesen: Jeti "vermutet" , das sich kein Kondensator am Motor befindet. Das kann man doch leicht prüfen indem man nachschaut. Beim gleichen Servotyp hat Julian einen gefunden.

Wann gilt ein Servo als defekt? Ich habe gerade 2 D 200 von Dymont in Reparatur: direkt am Motor ist kein Kondensator zu sehen. Zur Platine geht ein kurzes 3 cm Kabel. Ist dort einer? Reicht das bei dem Abstand? Müssen jetzt alle Betreiber des R4 erst ihre Servos aufschrauben?

Ein C 4041 arbeitet auch nicht FASST Empfängern zusammen - wie es auch mit einigen Hitec Servos stress gibt.

Schöne neue Giga Welt?
 

Julez

User
Gute Neuigkeiten!

Gute Neuigkeiten!

Hi!

Jeti hat mir eben die Erlaubnis erteilt, den Schriftverkehr zu veröffentlichen.

Also dann hier die erste eMail vom 09.01.:
##############

Dear Julian,

We measured Your servo and receiver you send us. As you can see, this servo Doesn´t have a filtration of DC motor commutator and electric discharge, which are on commutator and it generates extensive range of disturbing frequency. This signal is on servo cable (impuls) and passes directly to processor and influences function of its osccilator.
Receivers R6 and R8 have a greater input capacity and filtrate this disturbing signal.

DC motor of servo probably doesn´t have filtrations capacitors which are necessary for filtrattion a electric discharge of commutator. According to this fact, this servo hasn´t got CE certification. For CE is controled intensity and spectrum of disturbing signals.

Follows informations from our measurement.


Picture 1 . Scren021.jpg
Measurement: spectrum analyzer (Agilent N9320A, 9kHz – 3GHz)
You servo is not connected.
No. 1 and 2: GSM
No. 3: Duplex 2,4 GHz
------------------------
Picture 2 . Scren022.jpg
Measurement: spectrum analyzer (Agilent N9320A, 9kHz – 3GHz)
Your servo is connected.
No. 1 and 2: GSM
No. 5: Duplex 2,4 GHz
Another peaks: noise from servo commutator
-------------------------
Picture 3 . scope_1.bmp
Measurement: oscilloscope (Agilent DSO5014A, 100 MHz, 2GSa/s)
Servo is connected.
Green: power supply ( 4 x NiCd accu)
Yellow: servo impuls
------------------------
Picture 3 . scope_2.bmp
Measurement: oscilloscope (Agilent DSO5014A, 100 MHz, 2GSa/s)
Servo is connected.
Green: peak zoom - power supply ( 4 x NiCd accu)
Yellow: peak zoom - servo impuls
The measurement is not correct, because the maximum frequncy of oscilloscope is 100 MHz.
#######################
Bilder siehe Anhang.


Hier die eMail, die ich soeben erhalten habe:

###################

Dear Julian,

Regarding your questions:

>Does the processor have some kind of watchdog implemented, which could
restart it at the occurrence of a crashed processor?

In the processor is used watchdog with next safety component (brown-out
detector, etc.). Disturbing of this servo in range of hundreds MHz
probably influenced the osccilator function so that processor worked on
high frequency than is allowable. This may be reason for failure a
correct receiver function .



>Would it be possible to built future generations of those recievers with
lowpass filters between the processor contacts, and the servo plugs?

Actual production has protection for this event. We would like to
emphasize, that this trouble was only with using servos which don´t
follow EMC.



>Would it be possible, that noise is injected into long servo cables by
strong RF noise, thus leading to the same problem we discuss?

Not suitable conduction a long wires to these servos (which generates
strong disturbing) can occur to malfunction also other equipment.
Firstly, if wires make loop (coils) around these equipment.

We agree with publication these information, but with respect to trade
concern third parties, wouldn´t be presented name of servos
manufacturer. We would like to be informed about important things in
this matter.

We thank You for your work, which you helped to improve our new
products. According your finding, we have made decision to modify output
filter by R4 and R5 receivers so that it isn´t possibly to influence
function these receivers with using thus "wrong" servos.

Thank you for your understanding. We send your servo, modified R4 and
small (DUPLEX) present back.



With regards
######################

Na das freut mich doch zu hören. Die in der aktuellen Produktion befindlichen R4 und R5 Empfänger sind also mit einer Art Filter ausgestattet.
Ein Watchdog gegen Brownouts ist vorhanden. Die Störimpulse allerdings haben wohl zu einer Art unzulässig hoher Übertaktung geführt.
Wenn also Störimpulse durch neue Filter ferngehalten werden, und gegen normale Ausfälle Watchdogs vorhanden sind, sollten alle Sorgen ein Ende haben.

Den Servohersteller habe ich ja nun schon genannt, aber ich denke, dies ist auch richtig so, um maximale Informationstransparenz und Aufklärung sicherzustellen.

Ciao,

Julian

PS: Hat Jeti da gerade einen zeitlichen Rekord von "Problemmeldung" zu "Problembehebung" aufgestellt? ;)
 

Anhänge

  • SCREN021.JPG
    SCREN021.JPG
    124,9 KB · Aufrufe: 63
  • SCREN022.JPG
    SCREN022.JPG
    154,3 KB · Aufrufe: 67
  • scope_1.gif
    scope_1.gif
    42,5 KB · Aufrufe: 104
  • scope_2.gif
    scope_2.gif
    33 KB · Aufrufe: 73
Wie Jeti reagiert, finde ich vorbildlich. Allerdings habe ich an einem entscheidenden Punkt noch nicht richtig verstanden, was Sache ist: Brownout bedeutet absinkende Versorgungsspannung, was den Mikrocontroller natürlich auch abstürzen lassen kann. Ein Brownout-Detektor würde eventuell im letzten Moment Daten sichern und einen geordneten Wiedereintritt nach Wiederherstellen der Versorgungsspannung ermöglichen. Das hat aber nichts mit diesem Problem zu tun. Wenn nur für den Brownout vorgesorgt ist, reicht das nicht.

Hier geht es um den Absturz durch eine Störung auf der Signalleitung, keinen Brownout. Die Erklärung von Jeti reicht nicht hin, um zu begründen, warum das Servo den Empfänger dauerhaft zum Lockout bringen konnte. In diesem Stadium war der Empfänger tot, das Servo stand also still, weitere Störimpulse von Motor traten nicht auf. Nun hätte der Empfänger seine Arbeit wieder aufnehmen müssen. Wie weiter vorn beschrieben, wird dafür ein Watchdog benötigt, der nach Ablauf einer vorgegebenen Frist den Microcontroller zurücksetzt und damit wieder in einen definierten Zustand bringt. Wenn es den nicht gibt, ist das Problem nicht gelöst. Auch nicht mit Filtern, die lediglich die Signalleitung etwas besser vor Störungen schützen.

Willst du vielleicht noch einmal nachfragen, Julian?
 
Da sollte Sich der Herr Importeur Donocik rc-easy mal eine Scheibe von abschneiden. Sein Verhalten in der Sache habe ich für eine Frechheit gehalten.
Das Verhalten vom Hersteller ist mehr als vorbildlich.

Danke Julian!
 

Julez

User
Hi Christian!

Willst du vielleicht noch einmal nachfragen, Julian?

Jo, hab ich soeben gemacht.
Ich habe ja sogar das Problemservo während eines Tests komplett entfernt, hat aber nix geholfen.
Die Frage ist natürlich, inwieweit prozessorinterne Watchdogs es verkraften können, wenn der ganze Chip total Amok läuft.
Leider weiß ich nix über Prozessorarchitektur, aber wenn so ein Ding sagen wir mal im ganz unterne MHz Bereich läuft, und dann der Oszillator, angeregt durch die Störungen im dreistelligen MHz Bereich, in dieser Frequenz läuft, wird das schon einiges durcheinanderbomben, kann ich mir vorstellen.

Wie realistisch ist es, dass ein Prozessor derart gestört wird, wenn Störungen durch das Servo gefiltert werden?

Generell würde ich da erstmal den Teufel nicht an die Wand malen wollen, solange niemand von derartigen Problemen berichtet.

Aber Christian, du hast doch einige Experten in deinem Umfeld, was meinen die denn so?

Ciao,

Julez
 

sidigonzales

User gesperrt
Der Mail von Jeti ist eigentlich nichts hinzuzufügen. Die Interpretation dieser Mail ist allerdings wieder unterirdisch.
Das Englisch ist vielleicht nicht preisverdächtig aber gut zu verstehen.
Die Scopebilder sind eindeutig.
Die Schlussfolgerung von Jeti ist klar und verständlich.
Die schnelle und überlegte Reaktion von Jeti hat mehr als deutlich gezeigt das es sinnvoll ist Informationen dort einzuholen wo sie erhoben werden können.
Herrn Donocik zum Sündenbock machen zu wollen halte ich für kurzsichtig da er nicht der Händler und scheinbar auch nicht der Importeur war.
 
modellbobby schrieb:
Da sollte Sich der Herr Importeur Donocik rc-easy mal eine Scheibe von abschneiden. Sein Verhalten in der Sache habe ich für eine Frechheit gehalten.
Das Verhalten vom Hersteller ist mehr als vorbildlich.

Danke Julian!

Ich kenne keinen anderen Vertrieb / Importeur, der sich hier so engagiert.
In Verbindung mit dem Hersteller finde ich das eine sehr kundenfreundliche Kombination.
Deshalb finde ich die o.a. Äusserung unangebracht.
 
R4/R5 Empfänger

R4/R5 Empfänger

an User

die Probleme mit R4 Empfänger haben oder sich unsicher mit dem R4/R5 fühlen.

Wie schon hier geschrieben, hat Jeti die Störung des Empfängers durch stark störendes Servo analysiert und sofort den Design geändert. Aus der Produktion kommen seit Gestern dem 12.01.2009 nur die modifizierten R4/R5.

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

Für den Austauch für anderswo bezogene Empfänger bitte bei rc-easy zuerst anfragen.

Die neuen Störungsresistenten R4/R5 werde ich voraussichtlich ab dem 19.01.2009 auf Lager haben und ab dann auch aussenden können.

Ich hoffe das diese schnelle Massnahme im Sinne der Forumleser ist.
 

Space

User
Watchdog Problem bleibt

Watchdog Problem bleibt

Auf das Problem so schnell miteiner Hardwareänderung zu reagieren ist wirklich vorbildlich! :) Beim Thema Watchdog befriedigd micht die Antwort nicht.


Ein Watchdog ist ein Hardwaretimer im Prozessor, welcher bei Zuführung eines unsaubere Taktes zu schnell oder aber zu langsam zählt. "Aufhängen" kann der Watchdogtimer sich nicht! Denkbar ist aber das ein paar Takte zuviel oder zuwenig den Timer beeinflussen. Spätestens wenn das "Störservo" still steht, läuft der Watchdog aber sicher solange der Takt vorhanden ist. Also spätestens im Logout Fall muss er wieder tun .....


Was ich vermute ist, dass die Watchdog Resets in der Empfänger Software entweder im Programmablauf nicht optimal plaziert sind oder aber nicht sicher die Funktionsfähigkeit der Empfängers überprüft wird, aber trotzdem der Watchdogtimer resettet wird.


Kurze Erläuterung zum Watchdog Timer:
Der Timer im Prozessor ist komplett in Hardware abgebildet. Also gänzlich ohne Software Komponente. Timerlänge (Takteiler) sind über interen Chipregister beeinflussbar. Wenn dieser Timer abläuft, wird automatisch ein Reset des Prozessors durchgeführt.

Um diesen im Normalfall den nicht gewünschten Reset zu verhindern, muss im Programmablauf bei Normalfunktion der Timer zurückgesetzt werden (Watchdog reset). Wenn diese Watchdog resets im Programmablauf als Beispiel im Mainloop (Hauptschleife der Programmablaufs) plaziert werden, führt mit hoher Warscheinlichkeit eine Fehlfunktion des Prozessors nicht zum Watchdor reset obwohl der Empfänger nicht mehr funktionabel ist. Optimal ist eine Routine welche Werte auf Plausiblität überprüft und mit Hilfe von Flags den Ablauf von wichtigen Routinen sicherstellt.


Trotzder wiklich positiven Reaktion von Jeti, sehe ich das Hauptproblem noch nicht gelöst.
 
Space schrieb:
Trotzder wiklich positiven Reaktion von Jeti, sehe ich das Hauptproblem noch nicht gelöst.
Ja, so sehe ich das auch, aber ich habe gute Hoffnung das das auch noch wird.

Ein HW-Watchdog muss immer greifen, egal was passiert. Die Teile laufen wenn es so ist wie es sein sollte mit einem internen RC-Osci, also immer.

Brownout allerdings kann eine sehr tückische Sache sein. Der uC kommt bei absinkender Spannung in einen Zustand der Ihn Fehler machen lässt, leider sinkt die Spannung nicht weiter ab und das System fängt sich, macht aber Fehler bzw. agiert undeterministisch.

Deswegen ist es neben einem Watchdog bei Systemen mit instabiler Spannungsversorgung extrem wichtig eine Brownout Detection zu haben.

Wenn der uC das nicht bietet nimmt man klassischerweise einen entsprechenden extra-IC (klein und fein) der einfach unter einer Spannung (welche noch nicht ganz kritisch ist) den Reset des uC zieht.

Ich selber hatte zu verantworten das >100 entwickelte Geräte welche schon beim Kunden waren von uns nachgebessert werden mussten weil ich mich auf die Brownout-Detection eines uC verlassen hatte. Leider war diese fehlerhaft, wie der uC-Hersteller später selber in einem Errata zugegeben hat. Also ziert die Platine jetzt ein von Hand draufgepatchted Reset-IC und alle sind zufrieden.

Seither bei mir: Kein uC ohne Reset-IC wenn ich die Spannungsversorgung des Systems nicht selber in der Entwicklung im Auge habe.

Ich denke beim Brownout haperts bei Jeti (und ich vermute nach dem Schaltungsaufbau ebenso bei XPS/IFS).
 

Viktor

User
Wer den Beweis haben wollte, dass eine offene Diskussion sich letztendlich zum Vorteil und nicht zum Nachteil für den Hersteller auswirken kann, hier ist er. Voraussetzung ist, dass der Hersteller die Verantwortung für sein Produkt wahrnehmt.
Ich denke, die von Julian in Gang gesetzte und von Jeti aufgegriffene Aktion wird noch lange zitiert werden - nicht nur als ein Vorbild dafür wie Kundenfreundlichkeit aussieht, sondern wie moderne PR Arbeit aussehen kann. Die endet nämlich nicht beim aufsetzen von Ganzseitenanzeigen :-) Es führt in relativ schneller Zeit dazu ein System wirklich wasserdicht zu bekommen und schafft Vertrauen beim Kunden. Das ist in der wilden 2,4GHz Welt sehr viel wert.
 

sidigonzales

User gesperrt
Prof. Dr. YoMan schrieb:
Ja, so sehe ich das auch, aber ich habe gute Hoffnung das das auch noch wird.

Ein HW-Watchdog muss immer greifen, egal was passiert. Die Teile laufen wenn es so ist wie es sein sollte mit einem internen RC-Osci, also immer.

Watchdog ist eine komplexe Angelegenheit. Im Idealfall ist die Watchdogschaltung vom Prozessor unabhängig.
Wenn da nicht das resetten des Watchdogs wäre. Den Watchdogreset so zu plazieren das er immer aber auch immer genau so funktioniert das die grundlegenden Funktionen sichergestellt sind ist eine Kunst. Eigentlich müsste man eine komplexe Ereignisverwaltung mit Überwachung einbauen aber das geht weit über die Watchdogfunktion hinaus.

Das hat aber nix mit der Brownout-Funktion zu tun. Ich bin mir auch nicht wirklich sicher ob Brownout uns wirklich bei irgendwas helfen würde denn der Prozessor wird ja gestoppt um unsichere Funktion zu verhindern. Er gibt also auch kein Failsafe aus. :D

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