Lieber Besucher, herzlich willkommen bei: RCLine Forum. Falls dies Ihr erster Besuch auf dieser Seite ist, lesen Sie sich bitte die Hilfe durch. Dort wird Ihnen die Bedienung dieser Seite näher erläutert. Darüber hinaus sollten Sie sich registrieren, um alle Funktionen dieser Seite nutzen zu können. Benutzen Sie das Registrierungsformular, um sich zu registrieren oder informieren Sie sich ausführlich über den Registrierungsvorgang. Falls Sie sich bereits zu einem früheren Zeitpunkt registriert haben, können Sie sich hier anmelden.

241

Freitag, 2. Oktober 2009, 08:12

Guten Morgen!

Ich habe heute früh die Kontaktbuchsen mit einem 1/4W Widerstandsfüßchen geprüft. Dieses ist zwar rund, hat haber genau 0,6mm und ist lang genug.
Ergebnis bei meinem Modul hält nur einer von 5 Buchsen den Draht fest - die anderen klemmen nicht. Es schein also schon ein Federmechanismus "weit drin im Modul vorhanden zu sein, dieser scheint aber nicht für 0,6mm Kontaktstifte auszureichen. Evtl könnte man das Modul öffnen und die "Kontaktfedern" etwas zubiegen.

Evtl. wäre ein Hinweis an EZC China notwendig andere Buchsen zu verbauen. Die vom Original Robbe Sendemodul machen z.B. einen soliden Eindruck Es macht wirklich keinen Sinn an den Kontakten zu sparen. Da kann die Funkstrecke noch so sicher und ausgeklügelt sein - ein Wackelkontakt macht alles zu nichte. Außerdem dämpft ein schlechter Übergangswiderstand den Signalpegel (hier scheint es ja auch schon Problem gegeben zu haben). Ein Festeinbau kommt für die meisten Modul User nicht in Frage, da dies ja der Vorteil des Modulschachts ist mal schnell auf 35MHz zu wechseln.

Viele Grüße Tom
Belt CP V2 [SIZE=1]mit BAD-Chassis / Align 315 Pro / TP SG90
[SIZE=2]CX450 AE[/SIZE] [SIZE=1]Align 325 / ES08A / KDS800 / FS 550 BB Ca. Di. Sp. / Phoenix ICE50 :ok: / TGY E500 [/SIZE]
ESky Lama V4
Graupner Terry S
Robbe FF9-S - 2,4GHz
[/SIZE]

Wimmi

RCLine User

Wohnort: kleinste Großstadt im Ruhrgebiet

Beruf: Dipl.-Ing. Nachrichtentechnik

  • Nachricht senden

242

Freitag, 2. Oktober 2009, 09:55

Hallo,

mit dem Oszillator haben wir also kein Problem. Es gibt keinen Grund, warum man das Signal des Oszis nach 4:20 Minuten resetten sollte. Warum macht man das dann trotzdem?
Die state-machine des Transceivers zeigt Übergänge vom TX-Mode zur Kalibrierung des Synthesizers und danach in den Idle-status. Von Idle geht es dann die Schlange durch über wake_up und settling wieder in den TX mode.
Ich habe noch nicht verstanden, wie die Hopping-Sequenz aufgesetzt wird. Über den schnellen Synthesizer (90 µs settling time) kann ein neuer Kanal recht flott angesprungen werden. Die Ansteuerung wird über den µC vorgegeben werden. Ob hier das Problem liegt? Also in der Synchronisierung der hopping-sequenz zwischen Empfänger und Sendemodul? Klar ist, die Hopping-Sequenz wird nicht vom Transceiver durchgeführt, die Zeitbasis für das Hopping muss vom µC kommen. Karsten, hast du mal die Synchronität zwischen Empfänger und Sender angeschaut? Was macht der Empfänger, wenn der Sender nach 4:20 Minuten aussetzt? Im zeitlichen Ablauf muss diese Unterbrechung eigentlich auf beiden Geräten berücksichtigt sein, sonst stimmt die Hopping-Sequenz zwischen Sender und Empfänger komplett nicht mehr. Geschickter könnte man dieses Problem umgehen, indem man einen Rückkanal einbaut und dessen Signale in einer Regelschleife zur Synchronisierung des Empfängers und Senders benutzt.
Da der Empfänger mit einiger Wahrscheinlichkeit in der Luft weit entfernt und mit höherer Geschwindigkeit unterwegs ist, ergibt sich zusätzlich eine geringe Laufzeitverschiebung und der Dopplereffekt. Ob diese Einflüsse jetzt gravierend sind müsste man mal abschätzen.
Was mich auch wundert ist die Aussage "flackern der LED bedeutet Ausfall eines Sub-Trägers". Warum Ausfall? Wegen Störungen? Wegen zeitlicher Asynchronität? Dies bedeutet aber auch, dass der Empfänger den Ausfall erkennt, er also in der Lage ist die Hopping-Sequenz im Voraus zu kennen und das momentane Enmpfangsverhalten zu bewerten.


EDIT:

wie synchronisieren sich Sendemodul und Empflangsmodul eigentlich wenn der Sender aus und wieder eingeschaltet wird? Gibt es gewisse Kanäle die man hierfür benutzt? Oder werden die Daten zur aktuellen hopping-sequenz und für die folgenden Sequenzen mit den Nutzdaten im Protokoll verpackt?
==> Da Sender und Empfänger zu unterschiedlichen Zeiten initialisiert werden, muss das Aufspringen auf die hopping-Sequenz durch die übertragenen Daten erfolgen.

Habe gerade noch etwas gefunden: der RX mode des Transceivers bietet preamble-detection,d.h. Sender und Empfänger sollten sich eigentlich selbständig (zeitlich) synchronisieren können. Zudem gibt es einen16/32 bit Identifizierungscode der die Trennung von verschiedenen Teilnehmern ermöglicht, sozusagen die GUID des Sendemoduls.

VG

Wimmi
400er China-Quirl (Heli) an MPX Cockpit SX, Mini Titan, Velocity II, robbe Arcus, Brilliant vom Lindinger, diverse (Heavy)-Dizzy :ok:, Bretter und verbogenes Schaumgedöne
... und natürlich VERSICHERT!

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »Wimmi« (2. Oktober 2009, 10:09)


roger-1

RCLine User

Wohnort: Hannover

  • Nachricht senden

243

Freitag, 2. Oktober 2009, 10:47

Hallo Wimmi, Biberfieber und Datong,

ich glaube, ihr solltet mal kurz mit Herrn Eder nach China jetten und mithelfen :D ;)

Leider verstehe ich von dem was ihr beschreibt überhaupt nichts. Aber es ist gut zu wissen, dass sich hier im Forum ein paar Leute mit diesen Anwendungen auskennen und gute Tips und Hinweise geben können.
Vielleicht hilft es in der weiteren Entwicklung und Behebung der Probleme.

Gruß
Martin

Datong

RCLine User

Wohnort: Martinsheim

Beruf: Techniker

  • Nachricht senden

244

Freitag, 2. Oktober 2009, 10:57

Hallo,

meine Tests sollten nur dazu dienen Hardware Problem, kalte Lötstellen, defekte Durchkontaktierungen und Wärmeunverträglichkeit zu finden, bzw. wenn vorhanden Nachweisen.

Ich kann heute, bzw. Morgen die Synchronität überprüfen, jedoch schrieb Gorgon Zola schon, der TX und RX laufen asynchron. In der V2.0 soll nach Verlusst eines Kanals wieder bei 0 angefangen worden sein, bei V2.2 soll der Sender weiterlaufen, hier sehe ich das Problem, er findet den momentanen Sendekanal nicht, wie Du es beschreibst. Jedoch geht es nach dem Aussetzer bei 4:20 ja weiter, das kurze Flackern hört auf, manche Komponenten zeigen ein Fehlverhalten , aber ansteuerbar sind die Servos noch, Zittern dann aber um den Nullpunkt, Gyro (GY401) spinnt total, wechselt zwischen HH und Normal Modus. Nur ein Reset, also das wiederholte Anschalten des Senders und Empfängers erbringt Abhilfe, bis zum Punkt der 4:20 Minuten.

Grüsse Karsten, der es super findet wie sachlich und informativ die Diskussion verläuft, Danke!!!
Copter X 450, 3G, CopterX 500, 3G, CoperX 500 mit Hughes 500 Rumpf, 3G. Aurora 9

Torsten19701

RCLine Neu User

Wohnort: Niederkassel bei Bonn

  • Nachricht senden

245

Freitag, 2. Oktober 2009, 12:47

V.2.2

Hallo
Ich hatte vor kurzem auch ein Verhalten meines Empfängers den ich nicht nachvollziehen konnte.
Ist zwar schon ne Woche her aber ich habe darüber auch schon mit A.Eder gesprochen.

Mir ist mit meiner PKZ Corsair im Abstand von knapp 300 metern zweimal an fast der gleichen Stelle aufgefallen das urplötzlich der Flieger nicht mehr reagiert hat.
Beim ersten Mal noch abgefangen , beim zweiten Mal in den Boden, (fast nix passiert).
Ich bin dann nochmal mit dem Flieger zur Absturzstelle und da ist die blaue LED ausgegangen und nach einer Sekunde sind die Servos für Höhe und Seite in den Endausschlag gefahren.Dann habe ich den Flieger so hingedreht das er wieder Verbindung hat und die Servos liefen in die Neutralstellung.

Im Keller habe ich dann auf anraten von Hern Eder mal die Servos getauscht und getestet.
Ergebnis: Die eingebauten Digitalservos fahren auf allen Kanälen nach Verbindungsabriss in den Endanschlag.
Andere analoge Servos, auch Nonameservos, verhalten sich bei Verbindungsabriss neutral.
Komisch ist nur da ja hier schon erwähnt worden ist das die Servos eigentlich in einen Hold gehen wenn keine Verbindung besteht.

Ich möchte mit meinen Erkenntnissen keinen Langweilen, nur dazu beitragen das das was mir passiert ist nicht noch mehreren passiert.

Viele Grüße
Torsten

Wimmi

RCLine User

Wohnort: kleinste Großstadt im Ruhrgebiet

Beruf: Dipl.-Ing. Nachrichtentechnik

  • Nachricht senden

246

Freitag, 2. Oktober 2009, 12:54

Hi Karsten,

bei dem Systemdesign ist meiner Meinung nach ein klassischer Kompromiss zum Suboptimalen begangen worden, indem man versucht hat die normale Funktionsweise eines PPM oder PCM Senders nachzubauen: Einbahnstraßenbetrieb vom Sender zum Empfänger.
Anders ausgedrückt: mit ein bischen mehr Mut zu Innovationen hätte man jetzt weniger Probleme und für die Zukunft ein nahezu unschlagbares Produkt.

Man stelle sich das mal vor: man hat im Orbit einen voll funktionsfähigen Messempfänger genannt TRANSCEIVER, d.h. einen Sender und Empfänger, der in der bidirektionalen Kommunikation als Messsystem vor Ort (im Flieger) eingesetzt werden kann und in der Erprobungsphase einfach wie ein Funkrelais die empfangenen Signale (Daten) 1-zu-1 hätte wieder herunter senden können.

Ich hätte deshalb ein 2-Wege System mit dem CC2500 aufgesetzt und mir die empfangene Steuerungsinfo etc. per Rückkanal übertragen. Dabei kann man gleichzeitig die Vorteile des Transceivers ausnutzen (z.B. die Synchronisierung zwischen Sendemodul und Empfänger). Sämtliche Mechanismen sind auf dem Chip vorhanden, also Synchronisation, VCO Steuerung und Kalibrierung, Ausmessen der Feldstärke im Empfangskanal (RSSI), Fehlerschutz, Teilnehmererkennung, schneller und leistungsfähiger Synthesizer und und und.

So eiern wir jetzt herum und betrachten 2 mehr oder weniger irgendwie über einen Zeitraum noch synchron zu betreibende Geräte von denen einer immer spricht, nicht weiss ob er gehört wird, einer immer hört und sich Gedanken machen muss wann der Partner wieder was sagt. Das ist meiner Meinung nach der Hintergrund zu den 4:20 Minuten.

Das Prinzip wird funktionieren, solange man in Kauf nimmt, dass der Empfänger eben mal kurz in den Reset geht und garantiert ist, dass der Empfänger das Signal des Senders wieder empfängt und dekodieren kann.

Karsten, die Fehler hinter denen du herspürst sind ernst zu nehmen und müssen ausgeräumt werden. Allerdings bezweifle ich, dass es mit der Peripherie an RC Komponenten noch zu großen Problemen kommen wird. Themen wie verseuchte Spannungsversorgung, Einstreuung von Oberwellen in die Elektronik etc müssen aber im Auge behalten werden.

Bitte stellt euch vor, welches Potential das EZC haben könnte: adaptive Spektrumsnutzung durch Nutzung der bidirektionalen Kommunikation zwischen Empfänger und Sender. Im Vergleich zu FASST mit seinem aggressiven Algorithmus (ohne Rücksicht auf andere bzw. mit Kanonen auf Spatzen schießen, meine Meinung) ein großer Fortschritt in der Nutzung des ISM Bandes.

Aber auch so steckt einiges an know-how in dem System.

Jetzt habe ich Blut geleckt und würde gerne tiefer in die Materie einsteigen. Herr Eder, ist es wohl möglich nähere Details zur Implementierung zu erfahren? Strikte Verschwiegenheit bin ich bereit zu garantieren.

VG

Wimmi
400er China-Quirl (Heli) an MPX Cockpit SX, Mini Titan, Velocity II, robbe Arcus, Brilliant vom Lindinger, diverse (Heavy)-Dizzy :ok:, Bretter und verbogenes Schaumgedöne
... und natürlich VERSICHERT!

Wimmi

RCLine User

Wohnort: kleinste Großstadt im Ruhrgebiet

Beruf: Dipl.-Ing. Nachrichtentechnik

  • Nachricht senden

247

Freitag, 2. Oktober 2009, 13:02

Re: V.2.2

Hallo Torsten,

du gibst dir die Antwort selber:

Zitat:
Komisch ist nur da ja hier schon erwähnt worden ist das die Servos eigentlich in einen Hold gehen wenn keine Verbindung besteht.

Die Servos waren nicht im Hold, der Empfänger war komplett weg und hat sich resettet und u.a. auch die Hold-Register gelöscht. Weil kein Ansteuerungssignal anlag gingen die Servos auf Vollausschlag, danach kam der Empfänger wieder und setzte die Servos auf Neutral.

Gruß

Wimmi
400er China-Quirl (Heli) an MPX Cockpit SX, Mini Titan, Velocity II, robbe Arcus, Brilliant vom Lindinger, diverse (Heavy)-Dizzy :ok:, Bretter und verbogenes Schaumgedöne
... und natürlich VERSICHERT!

Torsten19701

RCLine Neu User

Wohnort: Niederkassel bei Bonn

  • Nachricht senden

248

Freitag, 2. Oktober 2009, 13:13

Re: V.2.2

Hallo
Aber Warum bleiben die analogen Servos auf Neutral und die digitalen gehen in den Endausschlag?
Das ist das was mich stutzig macht

Torsten

249

Freitag, 2. Oktober 2009, 13:35

Re: V.2.2

Also erst mal würde ich vorraussetzen das die Hoppingsequenz nicht notwendigerweise zufällig ist sondern nur "pseudo" zufällig. Alles andere würde auch keinen Sinn machen es sei denn ich möchte nicht das Sender und Empfänger eine dauerhafte Kommunikation zu stande bringen weil ich dann den Aufwand exorbitant in die Höhe treiben dürfte was die Genauigkeit der Zeitbasen und den Austausch von Startinformationen angeht.
Gehen wir also mal einfacherweise davon aus das beim binden entweder ein Schlüssel ausgetauscht wird aus dem ich die Sprungsequenz eineindeutig ableiten kann oder sogar die Sprungsequenz direkt. Damit kann ich weiterhin voraussetzen das ich wenn ich Zeitpunkt und Frequenz einer Paketübermittlung weiss schlussfolgern kann wohin die Reise geht und wann das etwa sein wird.
Dann habe ich verschiedene Domänen die ich betrachten muss von denen ich die Codedomäne gleich wieder vergessen kann.
Die Ortsdomäne ist ja vorgegeben weil ich da ja fliegen will.
Bleiben Frequenzdomäne und Zeitdomäne in der ich mich bewegen kann und oder muss.
Die Zeitdomäne unterliegt den Einschränkungen das ich Informationen relativ regelmässig wenigstens alle 20ms, das führe ich jetzt ein weil es etwa dem normalen historisch enstandenen Zeitraster entspricht indem Servos neue Infos wollen, übermitteln möchte und das mir nur ein begrenzter Zeitraum zur Verfügung steht weil ich den Frequenzraum nicht zuspammen möchte. Ausserdem muss ich auf andere Mitnutzer achten so das ich Pakete nicht notwendigerweise immer sofort los werde sondern erst warte bis die anderen fertig sind und dann sende oder möglicherweise auch mal gar nicht dazu komme sondern weiterhüpfen muss.
Die Frequenzdomäne ist dadurch limitiert das der zur Verfügung stehende Raum limitiert ist und andere Nutzer in der selben Ortsdomäne den gleichen Frequenzraum zum selben Zeitpunkt nutzen wollen.

Ok, das interessiert wahrscheinlich eh keinen aber machen wir mal ein Beispiel.

Nehmen wir an es gibt einen großen Platz mit genau 4 Ecken und ich verabrede mit meinem Freund das er alle 20 Minuten in einer Ecke des Platzes genau eine Strophe einer unendlichen Ballade vorträgt und dann weiter zieht.
Was für Informationen brauche ich?
Ich muss wissen wann wir starten und welche Ecke des Platzes er aufsuchen wird.
Ob unsere Uhren synchron gehen weiss ich nicht genau aber wir können zu ANfang in einer Ecke des Platzes einen Uhrenvergleich machen und haben damit dann gleich auch den Startplatz. In welcher Reihenfolge er die Plätze aufsucht kann er mir da sicher auch noch sagen.

Für den Fall das mein Freund und ich die "absolute" Zeit hätten würden wir bis in die Ewigkeit synchron laufen und es gäbe überhaupt keine Probleme.

Nun haben wir aber jeder eine Uhr und eingebildet wie wir sind glauben wir beide das natürlich die eigene Uhr die richtige Zeit anzeigt.
Leider zeigt uns die Realität, na eigentlich mir, das dem nicht so ist.
Wir hatten zu ANfang ausgemacht das wir uns exakt an unsere Uhren halten und so kommt es das ich wenn ich ein wenig zu früh, oder er zu spät, eine Ecke aufgesucht habe das Ende der Strophe nicht mehr mit bekomme weil ich mich auf den Weg zur nächsten Ecke machen muss oder wenn ich zu spät komme, oder er zu früh, bekomme ich den Anfang nicht mit.
Da wir uns genau an das Zeitraster der Uhren halten vergrössert sich der Fehler, er eskaliert, je länger die Ballade geht. Wir driften auseinander bis wir uns schliesslich gar nicht mehr treffen.
Was soll ich machen. Da ich nicht weiss wo er sich gerade befindet und auch nicht vorhersagen kann wohin er als nächstes geht warte ich einfach in einer Ecke bis er wieder vorbei kommt und damit beginnt alles wieder von vorne.

Ich hoffe die Idee und das Dilemma ist klar.

Nun, was gibt es für Möglichkeiten das Problem zufrieden stellend zu lösen?

sanfte Grüße
"Die Deutsche Rechtschreibung ist Freeware, du kannst sie kostenlos nutzen. Allerdings ist sie nicht Open Source, d.h. du darfst sie nicht verändern oder in veränderter Form veröffentlichen."
Quelle: GBO

Wimmi

RCLine User

Wohnort: kleinste Großstadt im Ruhrgebiet

Beruf: Dipl.-Ing. Nachrichtentechnik

  • Nachricht senden

250

Freitag, 2. Oktober 2009, 14:25

Re: V.2.2

Hi Gorgon Zola,

:ok:

Deine Vereinfachung und Verbildlichung meiner Überlegungen sind klasse! Genau so sehe ich das Problem bei der V 2.x.

VG

Wimmi
400er China-Quirl (Heli) an MPX Cockpit SX, Mini Titan, Velocity II, robbe Arcus, Brilliant vom Lindinger, diverse (Heavy)-Dizzy :ok:, Bretter und verbogenes Schaumgedöne
... und natürlich VERSICHERT!

251

Freitag, 2. Oktober 2009, 14:47

Hallo zusammen,

ich habe mir die vielen tollen Hinweise angehört , werde die auch zusammenfassen und weiterleiten. Ich muss allerdings auch sehr deutlich sagen, dass es im Forum Teilnehmer mit tollem technischem Wissen gibt, dagegen bin ich völliger Laie.
Daher vielen Dank für all die Anregungen und Hinweise.

Das Thema der Futaba Stecker ist natürlich absolut wichtig und wird sicher in der Serie
korrigiert.

Zu den Aussetzern nach 4:XX Minuten . Soweit meine Kenntnis reicht, ist das nicht der Normalfall. Es gibt ja genügend Module wo das Problem nicht auftritt, eigentlich alle. Von daher gehe ich aktuell am besagten Modul von einem Hardwareproblem aus.
Dass es dafür Gründe in der Produktion und beim Transport gegeben haben könnte ist inzwischen nahezu klar.

Von daher werde ich aktuell das Thema des Aussetzer nach 4:XX Minuten nicht als höchste Priorität sehen. Wir erhalten einige neue optimierte Module und werden diese auf Ihre Funktion testen. Sobald da klare aussagekräftige Ergebnisse vorliegen, werden wir sehen ob das überhaupt noch ein Thema ist.

@WImmi Deine Ausführungen sind toll, aber, ich verstehe das fachlich sicher nur zum geringesten Teil. Bin leider kein Techniker. Ich werde aber versuchen dies ins Englische zu übersetzen und an EZC weiterleiten. Was die daraus machen kann ich allerdings nicht sagen. Sofern es zur Stabilität beiträgt und zum System passt, wird man sich aber sicher Gedanken darüber machen.
Allerdings denke ich, müssen wir uns auch über eines im Klaren werden, nicht alles was theoretisch und technisch machbar ist kann hier umgesetzt werden.

Unser Ansinnen ist und war immer, ein solides, top funktionierendes System ohne
Schnickschnack zu verwirklichen. Es muss problemlos und sicher funktionieren.

Viele Grüße

ArmiN Eder

252

Freitag, 2. Oktober 2009, 15:24

Re: V.2.2

Zitat

Original von Wimmi
Deine Vereinfachung und Verbildlichung meiner Überlegungen sind klasse! Genau so sehe ich das Problem bei der V 2.x.


Moment, moment!!!!
Ich bin noch gar nicht fertig!

Eigentlich enthält ja meine vereinfachende Beschreibung schon Lösungsansätze über die ich hier gerne offen diskutieren würde bevor ich weitere Störgrössen einführe die wir, um zu einem sicheren Übertragunsgsystem zu gelangen welches sich auch noch kollegial verhält, definitiv betrachten müssen.
Ich hab aber nicht immer Bock alles als Monolog zu gestalten weswegen es nett wäre wenn wir in einen freundschaftlichen Dialog eintreten würden.
Nett wäre es auch wenn wir uns darauf einigen können das wir versuchen technische Sachverhalte so einfach wie möglich aber nicht zu stark vereinfachend wieder zu geben.
Das hat ganz einfach aus meiner Sicht zwei Vorteile:
1. man muss das Problem wirklich durchdenken und kann sich nicht hinter Fachbegriffen verstecken
2. der geneigte Mitleser wird auf eine möglicherweise interessante Reise mitgenommen die ihm ein paar Zusammenhänge offenbart

sanfte Grüße
"Die Deutsche Rechtschreibung ist Freeware, du kannst sie kostenlos nutzen. Allerdings ist sie nicht Open Source, d.h. du darfst sie nicht verändern oder in veränderter Form veröffentlichen."
Quelle: GBO

253

Freitag, 2. Oktober 2009, 15:25

Re: V.2.2

@ Thorsten @ Wimmi

das Thema Vollausschlag der Servos bei signallosem Zustand.

Es wurde in diesem Thread schon ein paar Seiten vorher beschrieben.

Es gab bei Thorsten tatsächlichen einen Hold mit einem gefolgten siganllosen Zustand.

Im Hold wird das letzte gute Signal noch eine Zeit lang gehalten, danach wird auf signallos geschaltet.

Normalerweise bewegt sich ein Servo wenn es kein Siganl mehr hat einfach nicht mehr.

Es gibt aber einige, sehr wenige Exemplare, die laufen im signallosen Zustand auf Vollausschlag. Das geht quer durch alle Hersteller, man kennt aber nicht alle genauen Typen. Es gibt z.b das eine odere andere aus dem Hause Hitec.

Um die Reaktion seines Systems bei diesem signanlosen Zustand zu testen, ist es daher nötig, einfach einmal testweise den Sender auszuschalten und zu sehen was die Servos tun. Natürlich am Boden ...........;-))

Viele Grüße
ArmiN Eder

Wimmi

RCLine User

Wohnort: kleinste Großstadt im Ruhrgebiet

Beruf: Dipl.-Ing. Nachrichtentechnik

  • Nachricht senden

254

Freitag, 2. Oktober 2009, 16:08

Re: V.2.2

Hi Gorgon Zola,

EINVERSTANDEN! Ich mache mit.

Ich versuche auch meine Gedanken etwas einfacher zu strukturieren und verständlicher zu beschreiben. Ab und zu werde ich aus dem Application Sheet dann einige Stellen/Funktionen hervorholen und diese vorstellen. Vielleicht gewinnen wir so "mit Boardmitteln" einen Lösungsansatz.

Bleiben wir daher bei deinem Beispiel mit dem großen Platz, den 4 Ecken und dem Lied mit unendlich vielen Strophen.

Ich muss jetzt so knapp für 2 Stunden von der Tastatur weg. Heute Abend melde ich mich dann gerne wieder.

VG

Wimmi
400er China-Quirl (Heli) an MPX Cockpit SX, Mini Titan, Velocity II, robbe Arcus, Brilliant vom Lindinger, diverse (Heavy)-Dizzy :ok:, Bretter und verbogenes Schaumgedöne
... und natürlich VERSICHERT!

Datong

RCLine User

Wohnort: Martinsheim

Beruf: Techniker

  • Nachricht senden

255

Freitag, 2. Oktober 2009, 18:23

Re: V.2.2

Hallo und guten Abend,

finde ich eine gute Idee, ich würde gerne an der Reise teilnehmen.

Grüsse Karsten
Copter X 450, 3G, CopterX 500, 3G, CoperX 500 mit Hughes 500 Rumpf, 3G. Aurora 9

Wimmi

RCLine User

Wohnort: kleinste Großstadt im Ruhrgebiet

Beruf: Dipl.-Ing. Nachrichtentechnik

  • Nachricht senden

256

Freitag, 2. Oktober 2009, 18:47

Re: V.2.2

Ok,

ein paar Verfeinerungen.

Randbedingungen:
Nachdem der Zuhörer eine Strophe gehört hat, muss er der Strophe Schlüsselwörter entnehmen und an einen externen Prozess weitergeben.

Verfeinerung die ich sofort mit einbauen möchte, um von vornherein externe Störungen zu berücksichtigen.

Jetzt stehen in den Ecken plötzlich auch noch andere Sprecher und Zuhörer. Und es ist dunkel, ich kann meinen Erzähler nur noch an seiner Stimme erkennen und selbst die ist mal lauter, mal leiser und die Stimmlage schwankt auch irgendwie. Aber ich habe ja 2 Ohren. Für den Moment konzentriere ich mich auf meinen Erzähler. Eigentlich müsste er doch da sein. Ich merke oft, dass auch andere Gespräche um mich herum stattfinden. Oft höre ich viel Kauderwelsch, aber auch Inhalte, die den Erzählungen meines Sprechers ähneln. An einigen Ecken des 'Platzes höre ich meinen Erzähler aber sehr laut und deutlich, ohne Hintergrundgeräusche, endlich ungestört. Dann wieder brüllt mir jemand in einer fremden Sprache etwas ins Ohr und ich kann meinen Erzähler gar nicht mehr hören.
Wenn andere in der Nähe sind, stelle ich fest, dass ich mich auf meinen Erzähler konzentrieren muss, da alle irgendwie durcheinander sprechen. Gott sei Dank benutzt mein Erzähler immer zu Anfang die gleiche Redewendung: "ich bin es". Damit kann ich genau feststellen, dass mein Erzähler mir etwas sagen will und konzentriere mich auf seine Erzählung. Und zum Schluss sagt er immer "das war's. Bis gleich". Dann weiss ich, ich kann die Schlüsselwörter aus seiner Erzählung nehmen und an den Prozess weitergeben. Probleme bekomme ich, wenn ich meinen Erzähler nicht anhand seiner Redewendung erkenne, weil ich z.B. zu spät zur Ecke gekommen bin oder jemand dazwischen plappert mit größerer Lautstärke. Die Stimmen auf dem Marktplatz hören sich alle so gleich an. Wenn ich nicht dieses unverwechselbare "ich bin es" höre, wie soll ich mir dann sicher sein meinem Erzähler gelauscht zu haben? Vielleicht sind auch schon einige Schlüsselwörter gesagt worden und da sie nicht wiederholt werden fehlen sie mir letztendlich in meinem Parametersatz zur Weitergabe. Also ignoriere ich alles was nicht mit "ich bin es" beginnt. Ok, dann muss der externe Prozess erst mal so weiter laufen wie bisher. Was ist denn wenn ich seine Verabschiedung "das war's, Bis gleich" nicht mehr mitbekomme? Zum Beispiel wenn ich schon unterwegs zur nächsten Ecke bin? Eigentlich sollte ich ja warten bis zur Verabschiedung. Ist besser so. Sonst fehlt mir vielleicht das letzte Schlüsselwort und ich gebe einen unvollständigen Satz an Informationen weiter. Besser nicht. Soll der externe Prozess auch in diesem Fall erst mal so weiter laufen wie er ist. Versuche ich mein Glück an der nächsten Ecke. War ich jetzt zu spät zur Rede meines Erzählers gekommen? Dann sollte ich mich sputen. Gott sei Dank weiss ich in welcher Ecke er gleich erscheinen wird. Mal einen Schritt zulegen... Oder bin ich zu früh zur anderen Ecke aufgebrochen und habe die Verabschiedung nicht mehr mitbekommen? Na gut, ich schlendere mal hinüber.


Gruß

Wimmi
400er China-Quirl (Heli) an MPX Cockpit SX, Mini Titan, Velocity II, robbe Arcus, Brilliant vom Lindinger, diverse (Heavy)-Dizzy :ok:, Bretter und verbogenes Schaumgedöne
... und natürlich VERSICHERT!

Helijue

RCLine User

Wohnort: Siegelsbach

Beruf: hab ich

  • Nachricht senden

257

Freitag, 2. Oktober 2009, 19:17

Hallo zusammen

Habe hier die letzten Tage fließig mitgelesen.
Super Spezialisten hier, aber verstehe nur Bahnhof.

Also bei mir kommen die Aussetzer wie schon ein paar Seiten vorher beschrieben nach 6:xx min.
Ich hoffe, dass es ein Softwareproblem ist, was upgedatet werden kann.
Was soll ich sonst mit meinen 4 Empfängern der Vers. 2.2 machen ???

Ich bin grundsätzlich ja nicht bereit wie auf Anraten von Herrn Eder meine Servo Regler usw. zu ersetzen, denn dann spare ich ja schließlich nichts und kann mir gleich eine neue Funke kaufen. Schließlich hat der Rex über 100 Akku mit 35 MHz top funktioniert.

Habe übrigens ein anders 2,4 GHz System in dem Rex getestet, mit dem auch immer die Probleme nach 6:xx min auftraten.

Also nun muß doch sagen, dass der Rex mit den bestehenden Komponenten und einen anderen 2,4 GHz System ohne Störungen fliegt.
Das war eine richtige Wohltat, wenn man sich auf was velassen kann.

Im Moment kann ich das Teil ja nicht mal ohne schlechtem Gewissen in der Bucht verhökern, da hilft nur eins und zwar zurück an den Absender, wenn die Ursache nicht gefunden werden kann.
Gruß Jürgen :w
ECO8 Bell 222 Rumpf Klick
T-REX 450,T-Rex 250, T-Rex 250 Hughes 500, T-Rex 600
Kopter DJI 450, DJI Phantom 2 Vision Plus, Blade 200QX, La Traxx Alias u.a.
FF10, DX6 V2
Homepage: www.seitz-jue.de

Wimmi

RCLine User

Wohnort: kleinste Großstadt im Ruhrgebiet

Beruf: Dipl.-Ing. Nachrichtentechnik

  • Nachricht senden

258

Freitag, 2. Oktober 2009, 21:33

Hi,

mal ein Versuch, die unterschiedlichen Zeitgeber in den Griff zu bekommen und die Probleme verständlicher darzustellen. Sagen wir, den Versammlungsort oder die Ecke haben wir jetzt mal so ziemlich im Griff.

Ich nehme mal an, die Uhr des Erzählers geht genau. Dann geht meine entweder zu langsam oder zu schnell. Wenn meine Uhr zu schnell läuft, treffe ich früher in der Ecke ein als mein Erzähler, läuft meine Uhr nach, dann komme ich zu spät. Kann ich feststellen um wieviel ich zu spät oder zu früh bin? Wenn ja, dann könnte ich meine Uhr doch entsprechend einstellen. Was ich wohl brauche ist eine externe Zeitbasis mit der ich meine Zeit vergleichen kann. Schön wäre es, wenn mein Erzähler sich auch an diese Zeitbasis orientieren würde. Dann nehme ich doch mal einfach die Zeitbasis des Erzählers. Also an der nächsten Ecke frühzeitig dasein, die Ankunftzeit vermerken, Stopuhr starten und warten bis ich die magischen Worte "ich bin es" höre. Hm, ein kleines Problem. Mein Gehörgang ist etwas träge, die Synapsen zwischen Ohr und Gehirn benötigen etwas an Zeit um die Information zu verarbeiten. Bis die eröffenden Worte des Erzählers in meiner Eiweiß-CPU verarbeitet wurden und das Signal ER_IST_DA mich aus meinem Wartezustand reißt und ich die Stopuhr betätige ist schon wieder einiges an Zeit vergangen und ich stoppe meine Uhr etwas zu spät. Na gut, besser etwas ungenau den Zeitunterschied gemessen als gar nicht. Ich kann die Messung ja wiederholen und mich so langsam der Uhrzeit des Erzählers annähern. Die Verarbeitungsgeschwindigkeit meiner Synapsen kann ich nicht wirklich verbessern. Aber ist doch eigentich auch gar nicht unbedingt notwendig. Ich habe doch den Anfang der Erzählung mitbekommen! Das ist doch schon mal sehr wichtig. Jetzt muss ich nur noch solange Zuhören wie der Erzähler mir was zu sagen hat. Mal die Zeit weiterhin stoppen bis zum Eintreffen der Worte "das war's. Bis gleich". Mal sehen, ich musste also um soviel früher da sein und um soviel länger bleiben. Mein Termin mit dem Erzähler war eigentlich zu meiner Zeit für jenen Zeitpunkt angesetzt. Und ich weiss, die nächste Strophe wird mir der Erzähler dann und dann erzählen, denn er richtet sich streng nach seiner Uhr. Jetzt kann ich anfangen mit der Rechnung. Die Differenz meiner Zeit und die Zeit des Erzählers bilden ist einfach. Danach verstelle ich meine Uhr einfach um die errechnete Differenz und kontrolliere beim nächsten Treffen die Abweichung der beiden Uhrzeiten. Zur Not kann ich ja nochmals die Differenz der Uhrzeiten bilden und meine Zeit der Zeit des Erzählers annähern. Nun gut, es funktioniert. Ich muss zwar öfter mal die Zeitdifferenz nachrechnen und korrigieren, aber im Großen und Ganzen klappt es. Vielleicht verpasse ich mal ein Treffen, macht aber nichts. Der externe Prozess kommt auch mal ohne neue Parameter klar. Und ich treffe den Erzähler mit Sicherheit in einer der Ecken wenn ich denn nur lange genug warte. So ungefähr weiss ich auch welche Ecke er als nächstes ansteuert. Ich kann ja mal so auf Verdacht sofort dahin gehen wenn meine Zeitkorrektur völlig daneben lag. Ich darf ihn nur nicht nochmal verpassen, sonst wird mein externer Prozess langsam ungeduldig.

Schöner wäre es allerdings, wenn ich meine Zeit je nach Unterschied zum Erzähler mal schneller oder langsamer laufen lassen könnte, so wie bei Momo und der Schildkröte. Hm, es gibt solche Uhren wirklich. Ich weiss nur nicht ob meine Uhr (Anmerkung: die im Empfänger) diese Manipulation meiner Zeit ermöglicht und ich muss einen Weg finden die Uhr mit einem Regelwert zu korrigieren.

(Anmerkung: dies ist die Funktion eines VCO, also eines mit einer Spannung gesteuerten Oszillators. Die Spannung erhöhen, dann läuft der Oszillator schneller=höhere Frequenz, geringere Spannung, dann läuft derOszillator langsamer=niedrigere Frequenz
Ausnutzen kann ich das, in dem ich die Differenz der Uhrzeiten als Regelsignal meinem VCO über eine Regelschleife zuführe. Solange über mehrere Strophen die Differenz der Uhrzeiten zu groß ist, wird für den Empfänger der Takt erniedrigt, im ungekehrten Fall wird der Takt erhöht. Dies führt zur Angleichung der Zeitbasis des Zuhörers an die Zeitbasis des Erzählers.)

VG Wimmi
400er China-Quirl (Heli) an MPX Cockpit SX, Mini Titan, Velocity II, robbe Arcus, Brilliant vom Lindinger, diverse (Heavy)-Dizzy :ok:, Bretter und verbogenes Schaumgedöne
... und natürlich VERSICHERT!

259

Freitag, 2. Oktober 2009, 21:44

Re: V.2.2

Hmm, Wimmi, du bist zu schnell. Lass uns erst mal mein stark vereinfachtes Beispiel zu Ende führen damit wir "Störungen"einführen können.

So, eine oft geäusserte Idee um den Synchronisationsverlust zu verhindern oder zumindest einzuschränken ist den Sender der Nachricht, meinen Freund, die Nachricht mehrfach wiederholen zu lassen. Mal davon abgesehen das mein Freund das sicher ermüdend findet den selben Text sagen wir 3 mal wiederholen zu müssen hilft uns das eigentlich nicht weiter weil:

1. die Verweildauer in der Ecke zwar erhöht wird wir aber wenn wir z.B. zu spät kommen gar nicht abschätzen können wann wir genau gekommen sind
2. wir die Ecke mit unnötigem Gesülze blockieren
3. wir keine wirkliche Aussage darüber treffen können warum uns eine Widerholung verloren gegangen sein könnte. Dafür kann es viele Gründe geben. Störungen eben, aber die kommen später.

Also eigentlich schieben wir das Unvermeidbare, den kompletten Synchronisationsverlust, nur nach hinten hinaus aber wir behalten das Wiederholen von Nachrichten mal im Hinterkopf weil es uns möglicherweise an anderer Stelle helfen könnte. Hier aber leider nicht wirklich.

Was könnte uns wirklich helfen?

Nun, z.B. der Zugriff auf eine externe Referenzuhr wie z.B die Turmuhr auf dem Platz. Wir benutzen also in meinem Beispiel nicht unsere eigenen vergoldeten Armbanduhren sondern einen zentralen möglichst von überall her sichtbaren Zeitanzeiger. Tatsächlich wurde dieses Verfahren früher in der Realität benutzt. :) Für die Fernsteuerung von Modellen ist es aber leider unpraktikabel weil es bedeuten würde das wir einen extra Empfänger nur für diesen Zweck mitführen müssten und wir hätten das Problem das uns die Laufzeitunterschiede bei unterschiedlichen Entfernungen zwischen Sender und Empfänger durchaus einen Strich durch die Rechnung macht wenn wir versuchen würden die Zeit absolut zu nutzen.
Alternativ könnten ich und mein Freund natürlich auch ausmachen das seine Armbanduhr unsere Referenzzeit ist. Das würde aber bedeuten müssen das ich ständig Zugriff auf seine Armbanduhr habe oder er mir eben halt auch noch die Zeit ansagen muss. Und zwar ständig weil ich ja keine Uhr mehr habe und mir damit das Zeitgefühl abhanden gekommen ist. Wenn ich ihn also auf dem Weg in die Ecke mal kurz nicht hören sollte war es das möglicherweise weil ich ja auch nicht mehr weiss wie viel Zeit verloren gegangen ist und wann ich dort auftauchen sollte.
Ist vielleicht auch nicht sooo optimal.
Hmm, wir hatten gerade Zeitgefühl. Das ist ja so eine relative Sache. Mal vergeht sie schneller und mal lamgsamer. Es gibt aber Dinge von denen man weiß, wenigstens ungefähr, wie lange sie dauern. Sagen wir Eis essen. Sagen wir ich brauche für eine Kugel Eis etwa 6-7 Minuten.
Nun könnte ich ja folgende Übereinkunft treffen:
Nach dem Ursprungstreffen in der ersten Ecke und dem Austauschen der INformation in welcher Reihenfolge die Ecken aufgesucht werden höre ich mir die erste Strophe an und hole mir eine Kugel Eis. Ich weiss das ich etwa 6-7 Minuten brauche um sie zu schlecken was mir genügend Zeit lässt die nächste Ecke aufzusuchen und darauf zu warten das mein Freund auftaucht und die nächste Strophe aufzusagen. Wenn er die nächste Strophe aufgesagt hat geh ich mir eine Kugel Eis holen und geh zur nächsten Ecke.....
Hmm, das sollte schon mal nicht so schlecht funktionieren auch wenn ich keine wirklich genaue und synchrone Zeitbasis mit mir herumtrage. Ich muss einfach nur ein bisschen schneller in der nächsten Ecke sein und wann ich wieder los muss wird dadurch bestimmt wann mein Freund die Strophe fertig aufgesagt hat.

Easy oder? :D Nur leider auch nicht ganz ohne Tücken aber dazu komme ich übermorgen falls sich kein anderer erbarmt.

sanfte Grüße
"Die Deutsche Rechtschreibung ist Freeware, du kannst sie kostenlos nutzen. Allerdings ist sie nicht Open Source, d.h. du darfst sie nicht verändern oder in veränderter Form veröffentlichen."
Quelle: GBO

260

Freitag, 2. Oktober 2009, 22:02

Re: V.2.2

Wimmi, du bist wirklich zu schnell. Und zu kompliziert.

Ich unterstelle mal das du die Funktionsweise von Fernsehern ungefähr kennst. Der einzige ungefähr genaue Takt in der Anfangszeit vom Fernsehen war der der ausgestrahlten Sendung. Die Zeitbasen in den Fernsehern waren irgend welche muchtigen LC Oszillatoren. Wichtig war lediglich das sie über die Synchronsignale zwangssynchronisiert wurden. Also letztlich genau das was ich über die Strophe erreiche. Wenn mein Freund sie fertig aufgesagt hat startet einfach ein neuer Zyklus.
Die zweite Zeitbasis, die des Zuhörers, muss nur resynchronisierbar sein. Sie braucht nur hinreichend genau zu sein weil ich Erwartungsfenster definieren kann innerhalb derer etwas passieren muss um sie neu zu starten. Wenn es kein Ereignis gibt welches mich zwangssynchronisiert mache ich halt mit meiner eigenen Zeitbasis so lange mit einem Notfahrplan weiter bis wir wieder aufeinandertreffen.
Das ist ziemlich exakt das Verhalten von FASST wenn was richtig schief geht.

sanfte Grüße
"Die Deutsche Rechtschreibung ist Freeware, du kannst sie kostenlos nutzen. Allerdings ist sie nicht Open Source, d.h. du darfst sie nicht verändern oder in veränderter Form veröffentlichen."
Quelle: GBO