• Liebe RC-Network Benutzer: Bitte beachtet, dass im August 2020 alle Passwörter zurückgesetzt wurden. Mehr dazu in den News...

Jeti, andere Systeme - tolerierbare Hold-Impulse?

B. de Keyser

Vereinsmitglied
Hallo,

brauche mal Eure Erfahrung - auch mit anderen Systemen als Jeti, weil mir Vergleichswerte fehlen.

Fliege seit mehreren Jahren Jeti TU in einer MC3030 unauffällig, was die Fliegerei betrifft. Voriges Jahr fiel mir beim Unilog-Mitloggen der Servoimpulse auf, dass bei (nur) einem Flieger hin und wieder ein Impuls der Länge 0 auftrat, was wegen Hold und Fail-Save-Einstellungen aber überhaupt nicht auftreten dürfte.

Deshalb habe ich mich durch Arduino-Threads hier im Forum ab Winter darin eingearbeitet und eine Messschaltung mit Arduino und ein PC-Auswertprogramm geschrieben, welches mir die Impulse an einem Servo/Regler misst und logt.

Nun, endlich zumindest einsatzfähig, wenn auch noch nicht 100% fertig, konnte ich die ersten Messflüge damit machen und musste zu meinem Erstaunen, wie unten aufgelistet, eine Reihe von gestörten Servoimpulsen auslesen. Diese traten ähnlich auch mit einem anderen Modell auf.

Im fast 10 minütigem Beispiel sind 3 echte Hold-Impulse zu erkennen und 8 Beinahe-Holds. Andere Systeme als Jeti sollen z. T. eine LED haben, die das Vorhandensein solcher Fehler anzeigt oder über Display anzeigen?

Und da liegt meine Frage: Welche Anzahl Fehler könnt ihr an anderen Systemen auslesen - resp. sind diese Fehler normal? Wie bereits gesagt, im Flug sind diese Holds und Beinahe-Holds nicht zu bemerken. Ja, ja ich weiß - hätten wir nur keine Telemetrie ;) aber da sie nun einmal da ist...


Danke schon mal für Eure Antworten

Gruß Bernd



Anhang Messungsprotokoll:

Modell: Krick Piper Super Cub 2,05 m
Start 17.08.2012 18:53
max. Entfernung 300 m

Jeti TU(1) in MC3030
Jeti R8(alt) - Einstellungen:
by Transmitter
Failssave nach 0,5 s, Kanal 4 = 0,8 ms

Arduino-Messauflösung 4 µs
per Arduino gemessene RC-Puls an Kanal 4 (Regler):

Start Low Dauer L+H Low High Pulstyp
[m:s,ms] [m:s,ms] [ms] [ms]
00:00,000 01:44,921 23,440 1,577 (4.194 * Ok-Pulse, Werte = Durchschnitt aus Addition)
01:44,921 00:00,019 17,096 1,716 (Estbl. Hold)
01:44,940 00:06,330 23,304 1,716 (253 * Ok-Pulse)
01:51,270 00:00,050 48,320 1,712 (Hold)
01:51,320 00:01,376 23,302 1,716 (55 * Ok-Pulse)
01:52,696 00:00,049 47,444 1,716 (Hold)
01:52,745 00:34,978 23,293 1,727 (1.398 * Ok-Pulse)
02:27,723 00:00,019 17,728 1,756 (Estbl. Hold)
02:27,743 01:19,022 23,364 1,651 (3.159 * Ok-Pulse)
03:46,765 00:00,034 32,684 1,712 (Estbl. Hold)
03:46,800 00:00,017 14,908 1,716 (Estbl. Hold)
03:46,816 01:26,752 23,341 1,674 (3.468 * Ok-Pulse)
05:13,568 00:00,032 30,544 1,684 (Estbl. Hold)
05:13,600 00:00,043 41,144 1,680 (Estbl. Hold)
05:13,643 01:19,551 23,333 1,683 (3.180 * Ok-Pulse)
06:33,194 00:00,020 17,888 1,680 (Estbl. Hold)
06:33,214 02:00,668 23,340 1,674 (4.824 * Ok-Pulse)
08:33,881 00:00,050 48,316 1,756 (Hold)
08:33,931 00:39,202 23,309 1,708 (1.567 * Ok-Pulse)
09:13,133 00:00,020 17,996 1,628 (Estbl. Hold)
09:13,153 00:35,245 23,662 1,352 (1.409 * Ok-Pulse)
09:48,397
Missed Pulses L = 0 H = 0


Bei einem anderen Flug mit einem anderen Modell (Epsilon Comp.) gab's z.B. folgende Werte:

L H L+H
Minimum 11 1,04 12,06
Maximum 64 2,15 65,06

14328 Normale Pulse
2 Holds
0 Failsaves
5 Rest. Holds
0 Rest. Failsaves
1 sonst. Errors
 
Moin,

äh ich hab da ein paar grundsätzliche Verständnissprobleme.

Nach meinem Stand bedeutet Hold das der letzte als gültig erkannte Eingangswert vom Empfänger ausgegeben wird bis entweder ein neuer, gültiger Wert ankommt oder Failsafe nach seiner eingestellten Zeit greift.

Wie willst Du bitte an einem Servoausgang ein Hold oder beinahe Hold wie Du schreibst, erkennen ?

Ein Failsafe läßt sich klar erkennen da man ja zB einen nicht per Steuereingabe erreichbaren Wert setzen kann. OK. Aber Hold ?

Klar könnte man einen Vergleich machen wenn man die Eingangsimpulse ins HF-Modul loggt und gleichzeitig das was am Empfänger ausgegeben wird. Da würde ich dann noch empfehlen dem Logger im Modell eine eigene Stromversorgung zu stiften um auch Fehler in der Stromversorgung der Empfangsanlage erkennen zu können.

Und da sehe ich auch Dein Eingangs beschriebenes Problem mit dem 0-Impuls. Da der Unilog sich seinen Strom von allen verfügbaren Quellen holt kann er in einem E-Modell halt auch Probleme mit der RX-Versorgung aufzeichnen. Und nur ohne RX-Spannung liegt an einem RX ein 0-Impuls an. Oder halt einen kurzen Moment direkt nach dem Einschalten.

Ach und beschreib doch bitte mal kurz was Dein Arduino besser kann als der Unilog ?

Gruß

gecko
 

B. de Keyser

Vereinsmitglied
Hallo Gecko,

Danke für Deine Anfrage.

Natürlich hast Du Recht, dass man Holds bei bestimmten Einstellungen des TX nicht erkennen kann, z.B. bei Einstellung "alle 20 ms Impulse ausgeben". Dann kommt auch der Hold-Impuls alle 20 ms und bietet keine Erkennungsmöglichkeit.

Aber:
In der Einstellung "per Transmitter" werden Hold- und Failsaveimpulse nur ~ alle 50 ms generiert, sind also zum normalen Impuls hin unterscheidbar. Desweiteren treten Holds und Failsave-Impulse mit "irregulären" Cyclenzeiten auf. Diese werden insbesondere ausgegeben, wenn von Hold oder Failsave wieder in die normale Sendefolge gewechselt wird. Sehr schön zu erkennen, wenn man den Sender aus- und wieder einschaltet, s.u.

Das ganze Erkennungsschema sieht bei mir so aus:

Fail-Save am Regler-Kanal 0,8 ms (Motor aus, normal ist etwa 1,04 Motor aus)
Transmittercyclus "by TX" (~ 25 ms)

Interpretierung:
Ok-Impulse: High-Duration >= 0,90 .. <= 2,25 ms, Low-Duration >= 18 .. <= 29 ms (enger eingrenzen könnte man noch auf 22 .. 26 ms)
Hold: High-Duration >= 0,90 .. <= 2,25 ms, Low-Duration >= 46 .. <= 57 ms
Failsave: High-Duration >= 0,77 .. < 0,90 ms, Low-Duration >= 46 .. <= 57 ms
Hold estbl.: High-Duration >= 0,90 .. <= 2,25 ms, Low-Duration >= 10 .. < 46 ms
FS estbl.: High-Duration >= 0,77 .. < 0,90 ms, Low-Duration >= 10 .. < 46 ms
alle anderen Werte gelten als sonstwie fehlerhaft


Was kann meine Schaltung "besser" (eher anders) als der Unilog? Unilog sampelt mit minimum 1/16 s - gibt also von mehreren (~ 2,5 normalen, bis zu 5 establ. Pulsen) nur einen aus - welchen ? Impulse mit 0-Zeit kommen nach meiner Auswertung nicht vor (auch parallel zu Unilog gemessen), sondern wie vermutet Holds/Failsaves mit längerem Cyclus).

Neben der Aufaddition/Durchschnitt der Ok-Pulse kann der Arduino auch alle Pulse einzeln ausgegeben - dann aber nur für c. 6 Minuten aufzeichnen.

Die Spannungsversorgung "dürfte" nicht betroffen sein - sowohl Arduino als auch Unilog zeigen keine Ausfälle oder Resets ihrerselbst an. Ist übrigends ein ext. BEC 7,5 A an sep. 2S-Lipo 2200 mit 6V im Ausgang. Kann das zwar nicht 100% ausschließen, aber mangels Messmöglichkeitsolcher solcher Unterspitzen...

Interessieren tut mich nur das Endergebnis der Sendekette - der tatsächlich am Servo anliegende Impuls. Ob innerhalb der Kette zu einer Impulsausgabe x mal der Wert gesendet und als fehlerhaft verworfen oder als ok genommen wird, spielt für mich keine Rolle. Auch die HF-Stärke kann ich nicht beurteilen. VSpeak gibt jedenfalls keine akkustische Warnung aus - minimum ist schon mal 0 auf einer Antenne. Aber auch hier wird natürlich nur eine Situation von vielen dazwischenliegenden angesagt.


Gruß
Bernd



Anhang:

Testbeispiel Hold und FS durch Sender - Aus/Einschalten:

Satz Zeitp. Low [ms] High [ms] Cycle [ms] Pulstyp
1 0,000 26,00 1,05 27,05 0 Normal
2 0,027 22,00 1,05 23,05 0
3 0,050 23,00 1,05 24,05 0
4 0,074 24,00 1,05 25,05 0
5 0,099 24,00 1,05 25,05 0
6 0,124 25,00 1,05 26,05 0
7 0,150 26,00 1,05 27,05 0
8 0,177 22,00 1,05 23,05 0
9 0,200 26,00 1,05 27,05 0
10 0,227 23,00 1,05 24,05 0
...
345 8,616 23,00 1,05 24,05 0
346 8,640 25,00 1,05 26,05 0
347 8,666 23,00 1,05 24,05 0
348 8,690 25,00 1,05 26,05 0
349 8,716 23,00 1,05 24,05 0
350 8,740 25,00 1,05 26,05 0
(Sender länger ausschalten bis Fail-save)
351 8,766 49,00 1,05 50,05 3 Hold
352 8,817 49,00 1,05 50,05 3 Hold
353 8,867 49,00 1,05 50,05 3 Hold
354 8,917 49,00 1,05 50,05 3 Hold
355 8,967 49,00 1,05 50,05 3 Hold
356 9,017 49,00 1,05 50,05 3 Hold
357 9,067 49,00 1,05 50,05 3 Hold
358 9,117 49,00 1,05 50,05 3 Hold
359 9,167 49,00 1,05 50,05 3 Hold
360 9,217 49,00 1,05 50,05 3 Hold
361 9,267 49,00 1,05 50,05 3 Hold
362 9,317 49,00 1,05 50,05 3 Hold
363 9,367 49,00 1,05 50,05 3 Hold
364 9,417 49,00 1,05 50,05 3 Hold
365 9,467 49,00 1,05 50,05 3 Hold
366 9,517 49,00 1,05 50,05 3 Hold
367 9,567 49,00 1,05 50,05 3 Hold
368 9,617 49,00 1,05 50,05 3 Hold
369 9,667 49,00 1,05 50,05 3 Hold
370 9,717 49,00 1,05 50,05 3 Hold
371 9,767 49,00 0,80 49,80 4 Failsave
372 9,817 49,00 0,80 49,80 4 Failsave
373 9,867 49,00 0,80 49,80 4 Failsave
374 9,917 49,00 0,80 49,80 4 Failsave
375 9,967 49,00 0,80 49,80 4 Failsave
376 10,016 49,00 0,80 49,80 4 Failsave
377 10,066 49,00 0,80 49,80 4 Failsave
378 10,116 49,00 0,80 49,80 4 Failsave
(Sender wieder einschalten)
379 10,166 37,00 0,80 37,80 2 Estbl. Failsave
380 10,204 49,00 0,80 49,80 4 Failsave
381 10,253 11,00 0,80 11,80 2 Estbl. Failsave
382 10,265 22,00 0,80 22,80 2 Estbl. Failsave
383 10,288 24,00 0,80 24,80 2 Estbl. Failsave
384 10,313 23,00 0,80 23,80 2 Estbl. Failsave
385 10,337 24,00 0,80 24,80 2 Estbl. Failsave
386 10,361 25,00 0,80 25,80 2 Estbl. Failsave
387 10,387 23,00 0,80 23,80 2 Estbl. Failsave
388 10,411 26,00 0,80 26,80 2 Estbl. Failsave
389 10,438 22,00 0,80 22,80 2 Estbl. Failsave
390 10,461 25,00 1,05 26,05 0
391 10,487 24,00 1,05 25,05 0
392 10,512 24,00 1,05 25,05 0
393 10,537 24,00 1,05 25,05 0
394 10,562 26,00 1,05 27,05 0
395 10,589 22,00 1,05 23,05 0
396 10,612 25,00 1,05 26,05 0
...
814 23,141 22,00 1,05 23,05 0
815 23,164 26,00 1,05 27,05 0
816 23,191 23,00 1,05 24,05 0
817 23,216 24,00 1,05 25,05 0
818 23,241 23,00 1,05 24,05 0
819 23,265 26,00 1,05 27,05 0
820 23,292 22,00 1,05 23,05 0
821 23,315 26,00 1,05 27,05 0
822 23,342 23,00 1,05 24,05 0
(Sender kurz ausschalten für Hold)
823 23,366 49,00 1,05 50,05 3 Hold
824 23,416 49,00 1,05 50,05 3 Hold
825 23,466 49,00 1,05 50,05 3 Hold
826 23,516 49,00 1,05 50,05 3 Hold
827 23,566 49,00 1,05 50,05 3 Hold
828 23,616 49,00 1,05 50,05 3 Hold
829 23,666 49,00 1,05 50,05 3 Hold
830 23,716 49,00 1,05 50,05 3 Hold
831 23,766 49,00 1,05 50,05 3 Hold
832 23,816 49,00 1,05 50,05 3 Hold
833 23,866 49,00 1,05 50,05 3 Hold
834 23,916 49,00 1,05 50,05 3 Hold
835 23,966 49,00 1,05 50,05 3 Hold
836 24,016 49,00 1,05 50,05 3 Hold
837 24,067 49,00 1,05 50,05 3 Hold
(Sender wieder anschalten)
838 24,117 16,00 1,05 17,05 1 Estbl. Hold
839 24,134 25,00 1,05 26,05 0
840 24,160 23,00 1,05 24,05 0
841 24,184 24,00 1,05 25,05 0
842 24,209 24,00 1,05 25,05 0
843 24,234 25,00 1,05 26,05 0
844 24,260 24,00 1,05 25,05 0
845 24,285 24,00 1,05 25,05 0
846 24,310 23,00 1,05 24,05 0
847 24,334 25,00 1,05 26,05 0
...
 
Moin Bernd,

das mit der "by Transmitter" Einstellung und daraus Holds abzuleiten ist ne clevere Idee.

Und ich habe verstanen das Dein Arduino nicht nur die Pulslänge, sondern auch den Abstand zwischen 2 Pulsen loggt.

Gut wenn Dir der interne Speicher zu klein wird nimmt man hier normalerweise eine SD-Karte und schreibt darauf. Ist bei Arduino dank der Bibliotheken eher kein Hexenwerk. Oder Du schreibst es seriell raus und schliesst ein OpenLog an den Arduino. Der loggt halt alles was nicht zu schnell ( <= 115kBaud ) in 8N1 bei ihm ankommt.

Zurück zum eigentlichen Problem.

Den Trick mit der Framerate werden wohl die Benutzer der nicht - Jeti - Systeme nicht nutzen können - dafür haben Wea und Hott andere Werte im Log die auf fehlende Frames rückschliessen lassen.

Dein Problem mit Aussetzern wird man erst wieder angehen können wenn der Zeitraum den Du loggen kannst länger ist als ein Flug.

Gruß

gecko
 

ingo_s

User
Hi,

Anfang 2010 habe ich auch mal Hold+Failsave Untersuchungen an verschiedenen Systemen gemacht.
Da bin ich aber von einem sich stetig ändernden Impuls ausgegangen, da bei einem Hold ja wiederholt die alte Impulsbreite ausgegeben wird.
Je nach Sender habe ich ein Servo-Test Signal selber erzeugt (bei MC3030 mit AVR) oder den internen Sender Servo-Test (Royal) benutzt.
Am Empfänger wurde dann überprüft, ob sich die Impulsbreite stetig ändert und bei gleichen Impulsbreiten wurde auch der Hold-Zeitraum mit festgehalten.

Fazit war: Es kommt nur sehr selten zu einem Frame Ausfall, wobei in den meisten Fällen der Hold nur eine Framrate (20 - 25ms) lang ist. Zusätzlich konnte ich bei meinen Testkandidaten feststellen, das Systeme mit Empfänger Diversitiy etwas besser abschneiden.

Versuche auch mal mit diesem Aufbau zu testen. Die Impuls Überprüfung auf der RX Seite sollte für Dich ja kein Problem sein. Auf der Sender Seite notfalls einen Sägezahl oder Dreieck Impuls im geeigneten Spannungsbereich erzeugen und in einen Prop-Kanal einspeisen.

Gruß Ingo
 

B. de Keyser

Vereinsmitglied
Hallo Gecko,

mit SD-Karten habe ich auch rumprobiert. Leider hat es bei mir nur mit zwei, drei älteren Karten 16MB bis 512 MB funktioniert. Frisst auch viel vom wenigen SRAM (512 Byte IO-Buffer) und die Schreibzyklen dauern z. Teil zu lange, wohl manchmal bis zu 65 oder mehr ms. Bei dem von mir verwendeten 32k I2C-EEProm dauert ein Schreibcyclus 5 ms, egal ob für 1 oder 30 (64) Byte und an der 64-Byte Grenze werden davon 2 Cyclen verbraucht. Durch Aneinanderreihen von bis zu 4 dieser ICs könnte ich auf 128K kommen, also rund 26 Minuten in der Alle-Impulse-einzeln-loggen-Art. Da die OK-Impulse aber normalerweise nicht so wichtig sind, werden sie in der zweiten Log-Art von mir nur summiert und als Durchschnitt ausgegeben. Das reicht je nach Anzahl der Fehlerframes für mehrere Stunden.

Openlog müsste ich mir mal ansehen, kenne ich noch nicht. Was ist das? Die Pulse selber gebe ich bei Tests auch über SIO auf den seriellen PC-Monitor aus, die Geschwindigkeit reicht.

Den Trick mit der Framerate werden wohl die Benutzer der nicht - Jeti - Systeme nicht nutzen können
ja, die Besonderheit ist mir klar, außerdem fehlen ja das Arduino-System als Einzelaufbau und die Programme dazu.

dafür haben Wea und Hott andere Werte im Log die auf fehlende Frames rückschliessen lassen.
und genau hiervon interresieren mich Aussagen über die Häufigkeit von fehlerhaften Frames während eines Fluges als Orientierungswerte.


Für mich merkwürdig ist halt auch, dass der Unilog nur bei der Piper einige Servoimpulse mit Wert Null ausgibt, die es so aber nicht gibt. Bei anderen Fliegern zeigt der Unilog solche nicht an. Ich habe im Anhang mal Unilog- und Arduino-Protokoll eines Epsilon-Fluges und ein Piper Unilog-Protokoll beigefügt.


Hallo Ingo,

auch ein sehr interessanter Ansatz, Holds und Failsaves zu messen.
Das klappt dann wohl nur über einen freien, unbelegten Kanal während des Fluges? Da ich nur Jeti in der 3030 mit o.g. Einstellungen fliege, kann ich auch bei unveränderter Pulslänge durch Auswertung von Low- und High-Time am Servoausgang die entsprechenden Schlüsse ziehen. Und solange der Flieger einen Motor hat, kann ich diesen Kanal auswerten (wichtig wg. des Failsave-Wertes). Dadurch sind auch voll belegte 4- oder 5-Kanal-Empfänger ausmessbar.

Ein zweiter freier Servokanal (belegt mit einem 3-Status-Schalter von ~ 1000, 1600, 2100 ms (und Failsave auf 1600) vereinfacht allerdings die Bedienung - gezieltes (Wieder-)Starten/Stoppen der Aufzeichnung oder Löschen des Speichers. Ansonsten läuft die Aufzeichnung sofort beim Einschalten los oder - bei anderer Einstellung- wenn der zu messende Kanal eine bestimmte wählbare Impulszeit überschreitet. Leider funktioniert das gerade bei der Piper nicht - der verwendete Schulze-Regler erfordert zum Einstellen der Bremse zunächst einmal Vollgas, dann Gas Aus. Aber da habe ich zum Glück genau noch diesen einen Hilfskanal frei.


Fazit war: Es kommt nur sehr selten zu einem Frame Ausfall, wobei in den meisten Fällen der Hold nur eine Framrate (20 - 25ms) lang ist.
Das ist denn doch einmal schon eine Aussage, mit der ich etwas anfangen kann.
Den zweiten Teil Deiner Aussage kann ich nach meinen bisherigen Logs unterstreichen. Wäre halt nur noch etwas genauer zu klären, was "sehr selten" ist - etwa 2, 10 oder 50 mal pro 10-minütigem Flug - oder eine Reihe Flüge ohne und dann einer mit ein paar Fehlern?


Danke schon mal
und liebe Grüße
Bernd

PDF-Anhang mit Unilog/LogView/Arduino-Protokoll:
Anhang anzeigen RCPulse Forum 4.pdf
 

B. de Keyser

Vereinsmitglied
N' schön'n Abnd, Gecko,

establishing oder restoring -> soll so was wie "wieder am stabilisieren der Impulsfolge" heißen und ist schlicht ein Ausdruck von mir für den Zustand zwischen Hold- oder Failsave und der normalen Impulsfolge. Ich kommentier' meine Programme schon seit c. 45 Jahren in so einem Mix aus Deutsch und Englisch... da kommt manchmal so was bei raus.

Zur Erklärung:
Wenn der Jeti-Empfänger in den Holdmodus geht (z.B. Sender aus), wechselt die Pulswiederholzeit auf c. 50 ms und die alte Pulsweite wird weiterhin ausgegeben. Wenn nun der Sender wiederangeschaltet wird, bevor Failsave aktiv wird, versucht der Empfänger wohl irgendwie wieder Takt aufzunehmen und die Pulswiederholzeit schwankt von c. 10 .. 35 ms, bis sie sich schließlich wieder auf c. 25 ms einstellt.

Noch besser sieht man bei Fail-Save, dass diese "establishing Pulses" noch keine normalen Pulse sind: Faissave behält in etwa die Pulswiederholzeit von Hold von c. 50 ms bei, aber mit der Pulsweite entsprechend der Failsavevorgabe, hier 0,8 ms. Wenn nun der Sender wieder eingeschaltet wird, gibt der Empfänger auch hier Pulse mit einer Pulswiederholzeit von c. 10 .. 35 ms, aber noch mit Pulsen in Failsave-Länge, also mit 0,8 ms - das sind damit eindeutig noch keine normale Impulse, weichen aber in der Cycluszeit von den echten Failsaves stark ab.

Wie die Messungen zeigen, treten die "establishing" Hold-Pulse auch schon mal einzeln oder zu zweit mitten im normalen Pulsdiagramm auf. Vielfach, wenn's zwei sind, hat einer eine Cyclusdauer von ~32 ms und der andere Puls von ~17 ms - zusammen also eine mittlere Impulsfolge von ~25 ms.

Nun zu der Vermutung einer nicht ausreichenden Stromversorgung:
Soll sicherlich heißen, der Empfänger geht auf Grund negativer Spannungsspitzen in den Reset und startet neu.

Dies sollte aber auch bei Jeti länger als 0,06 Sekunden dauern - den einzigen Wert, den ich einmal in dieser Größe gemessen habe - und das nicht bei der Piper.

Der Arduino wird aus dem Empfänger mit Strom versorgt und läuft einwandfrei durch. Ebenso der Unilog, auch er gibt alle Werte fortlaufend korrekt aus (neben den Servoimpulsen auch die üblichen Verdächtigen wie Akkuspannung, Akkustrom, Kapazität, Drehzahl, Temparaturen, Empf. Spannung, Höhe.

Die über den Unilog gemessene Empfängerspannung zeigt durchgehend 5,89 V, eine Reihe 5,88 V, wenige 5,87 V und drei einzelne Messpunkte nach der Landung mit 5,86 V an. (Ich weiß, die ganz kurzen Negativspitzen bekommt Unilog nicht mit). Aber dass würde heißen, es müssten negative Spitzen mit 3 - 3,5 V vorliegen! Und die Spannungsversorgung läuft wie gesagt über einen eigenen 2200 2S Lipo und ext. 7,5A Switch-BEC. Mein Flugstil ist auch sehr moderat - wenig Servobewegung. Diese laufen auch nicht zusammen an. Ich werde aber noch versuchen, am Empfänger einen Kondensator anzustecken und noch mal zu messen.

Die Epsilon hat ebenfalls eine separate ext. 7,5A Switch-BEC (anderes Fabrikat). Sie zeigt zwar auch über den Arduino einige einzelne Hold-Impulse genau wie die Piper - aber der Unilog keine Null-Impulse.


Gruß Bernd
 
Moin Bernd,

danke für die Erläuterungen.

Ist für mich so gedanklich gut nachvollziehbar.

Bleibt das Problem mit den Null-Werten.

Ich stimme Dir zu das bei laufendem, stabilen System auch mit Holds und Failsafes ein Impuls der Länge 0 nicht vorkommen kann.

Wenn Du mit dem Unilog mehrere Aufzeichnest dann hat das ja irgendeine Ursache. Das kann natürlich irgendwo in der Kette Dateneingang, Aufzeichnung, Auslesen und Darstellen sein. Wenn es dann nur bei einem Modell auftritt dann fällt mein Verdacht zuerst auf das Modell. Und wenn es ein Elektroflieger ist dann hat das Unilog halt noch eine 2. Stromquelle und ist daher erst in der Lage so was überhaupt zu registrieren.

Einen Zeitstempel alla Echtzeituhr hat erst das Unilog2 - also eine Aussage ob die Aufzeichnung ohne Unterbrechung war ist beim Unilog nur indirekt möglich. Daher auch der Tip mit separater Stromversorgung der Messmimik.

Spannungseinbrüche wegen Überlast - da würde ich bei einer 16 Hz-Aufzeichnung auch erwarten das es - auch bei einem Reboot des Empfängers - im Log sichtbar wird.

Wackelkontakte, also zB kalte Lötstellen, evtl dort nicht. Vor allem weil ja da oft nur Ruheströme fliessen.

Der Wackelkontakt kann natürlich auch in der Zuleitung zum Unilog liegen ...

Aber auch viele andere Probleme können hier die Ursache sein.

Gruß

gecko
 

B. de Keyser

Vereinsmitglied
Hallo Gecko,

das mit dem Wackel bringt mich auf eine Idee zum Ausprobieren.

Da alle anderen Messwerte sinnvolle Werte beinhalten, dürfte der Wackel, wenn, am Kabel RX-Ausgang - Unilog RC-Impuls-Eingang liegen. Da will ich Brüche und Wackelmöglichkeiten nicht ausschließen - es sind schon sehr kleine Steckerchen am Unilog (die ich auch schon mal erneuern lassen mußte).

Die Idee ist nun, den zweiten Unilog aus dem anderen Modell auch noch an den RX zu hängen und beide paralell messen zu lassen. Wenn dann Unterschiede auftreten, ist es klar. Mal sehen...

Leider muss ich mit dem Messflug noch ein bischen warten, bis die Piper wieder komplett flugfähig ist. Beim letzten Flug habe ich sie 2 Meter zu kurz in die Wiese vor unserer Landefläche gesetzt, und obwohl diese fast so kurz gemäht war wie der Platz, hat sie sich doch im letzten Moment noch langsam überschlagen und dabei den Randbogen des Seitenruders zerbrochen. Ist nur eine Kleinigkeit, aber muß halt noch gemacht werden.

Also bis zu diesen weiteren Messflügen erst einmal

Bernd
 

B. de Keyser

Vereinsmitglied
So, nun lichtet sich etwas das Dunkel um die "0-Impulse", die angeblich der Unilog misst.

Gestern Abend hatte ich einen Flug mit zwei Unilogs, welche über V-Kabel am Regler-Servoanschluss des Empfängers hingen.

Und siehe da, bei Messperioden von 1/16 Hz zeigt der eine nach wie vor zunehmend die 0-Impulse, der andere keine, sondern einen sauberen Impulszug:

Unilog 1, SW: V1.18, Seriennr.: 65535 ??
Es gibt 25 Null-Impulse innerhalb der Flugzeit 2:26 - 10:01. Alle Fehlpulse sind 0, auch wenn dies in der Grafik nicht immer so aussieht.

Unilog-1.gif

Unilog 2, SW: V1.18, Seriennr.: 33063
keine Fehlpulse gemessen, evtl. Holdimpulse kann Unilog natürlich nicht interpretieren:

Unilog-2.gif

Beim Vergleich fällt außerdem auf, dass der Unilog mit den Fehlern die Flugzeit c. 10 s länger angibt (= 148 Messungen).

Ich denke einfach, dass der Unilog nicht ganz ok ist und werde einmal per Mail bei SM diesbezüglich anfragen. Jetzt beim Durchforsten der Logs und Rechnungen etc. wird das alles klarer - die Fehlpulse auf 0 traten bisher nur bei diesem einen Unilog auf.

Dass die Fehlpulse nur bei der Piper auftraten, ist auch erklärlich: Dort werkelte meist Unilog 1 wegen der Alarmeinstellungen auf 6S, während Unilog 2 in den anderen Fliegern mit 3S arbeitete. Werd mal ein Programm schreiben, welches mir die LogView-Dateien nach 65535 durchsucht, ob ich diesen Unilog auch mal bei anderen Fliegern eingesetzt habe.

Dass die Fehlpulse erst voriges Jahr auffielen, dürfte einer Reparatur/Austausch des Unilog 1 Mitte vorigen Jahres geschuldet sein. Auf der Rechnung steht zwar "Com Stecker ausgetauscht, getestet - OK" (der hatte sich gelöst), aber ich denke, an Hand der Seriennummer, dass der Unilog in Wirklichkeit getauscht wurde.


Nichts desto trotz - ich habe mal wieder viel gelernt - über Arduino, C/C++, über Jeti, Holds/Failsaves usw. und über die eigene Blindheit - auf den Rückschluss hätte ich schon viel früher kommen können.


Auch wenn meine eigentliche Fragestellung: "Über wie viele Fehlerpulse berichten andere Systeme während eines Fluges?" nicht ganz beantwortet ist, vielen Dank für die Diskussion, die mich auf den richtigen Weg brachte.


Gruß Bernd

P.S. Über Arduino bin ich hier im Forum gestolpert - und wollte zuerst den nur zum Licht an-Ausknipsen programmieren - Landelicht durch Landeklappen setzen und Blitzer bei Motor an.
 

Wolfgang Fleischer

Vereinsmitglied
"Über wie viele Fehlerpulse berichten andere Systeme während eines Fluges?" nicht ganz beantwortet ist....
Über Holds mit HoTT kann ich folgendes berichten:
Bei RX mit Antennen-Diversity mit dem Heli zwischen 10 und 20ms. Beim Flächenmodell zwischen 20 und 60ms. Beim Segler sind es manchmal auch mehr aber immer unter 100ms.

Mit einem RX ohne Antennen-Diversity sind es auch mal 200ms.
 
Moin,

na das freut mich ja das sich letztendlich die Ursache gefunden hat.

Die Seriennummer in Hex wäre 0xffff. Ich behaupte mal frech das die irgendwie nicht sauber gesetzt wurde. Entweder hat das Unilog nen Schuß oder das letzte Update ist verunglückt.

Ich würde es also noch mal updaten und wenn es danach immer noch mit dieser Seriennummer oder dem Fehler kommt eintüten und dem Hersteller zur Klärung zuschicken.

Gruß

gecko
 

B. de Keyser

Vereinsmitglied
Danke Wolfgang,

mit den Zahlen kann ich etwas anfangen. Wenn, so wie ich annehme, die angegebenen ms sich aus n Impulsweiten ergeben und ein Impuls immer so 1 - 2 ms ist, ergeben sich bei 20 ms so c. 10 bis 20 Fehlerpulse. Die Größenordnung habe ich auch mit dem Arduino und Jeti gemessen.

@gecko,

so hab' ich's vor. Neueste Version ist noch eine Nummer höher als die genutzte.

Gruß Bernd
 

B. de Keyser

Vereinsmitglied
So, Neues von der Unilog-Mess-Front:

Das Problem scheint sich endgültig geklärt zu haben.

Ich wollte, bevor ich SM mit einem "angeblich defekten" Unilog belästigte, noch ganz sicher gehen und habe weiter getestet.

Nach mehreren weiteren Versuchen mit parallel laufenden Unilog-1, die komplett kreuz-getauscht wurden (auch mit Servo-Kabel), ist seit gestern die Ursache klar:

Es ist nicht "der eine Unilog", der defekt ist, sondern beide zeigen dasselbe Verhalten (sowohl mit den Softwareständen 1.18 und 1.19), wenn sie komplett mit den u.g. Sensoren messen:

Unilog-1 mit Sensoren:
RX-Regler-Servoausgang
80 A Stromsensor
ext. Temperatur
brushless RPM-Sensor
Jeti-Ext-Verbindung
= Fehlpulse


Der parallele Unilog-1 hatte dagegen jeweils nur
RX-Regler-Servoausgang
= keine Fehlpulse

Mit angestecktem RPM-Sensor traten die Fehlpulse nur auf, während der E-Motor lief.
Das Abstecken des brushless RPM-Sensors sorgte dann dafür, dass auch der Unilog mit den mehreren Sensoren die Servopulse korrekt aufzeichnete!

Den brushless RPM-Sensor habe ich erst seit vorigem Jahr und nur in der Piper angeschlossen - deshalb traten die Fehlmessungen verwirrenderweise auch nur in der Piper auf.

Hatte heute einen (wie üblich sehr guten und schnellen) Mailverkehr mit SM. Herr Merz kannte das Problem bisher zwar noch nicht, er könne sich aber ein derartiges Verhalten vorstellen, weil die Impulse von der Drehzahl eine höhere Priorität hätten. Ein von ihm durchgeführter Test mit einem Unilog-2 zeigte keine derartigen Auffälligkeiten.

Alles wird gut...

Bernd
 
Oben Unten