Weis denn keiner bescheid?
Hallo zusammen,
ich bin neu hier und will in den Modelbau einsteigen. Deswegen beschäftige ich mich gerade mit der Signalübertragung des RC-Signals. Also wie es aufgebaut ist, wie es generiert wird und wie man es wieder decodiert. Den HF-Teil mit der Modulation mal außen vor.
Dazu habe ich einen AVR (ATMega programmiert, der mir ein 8-Kanal RC-Summensignal (PPM) bereitstellt. Das Signal sieht sehr gut aus und müßte meiner Meinung nach funktionieren. (Mit Oszi überprüft)
Nun meine Frage an eingefleische RC-User:
Macht es überhaupt einen Sinn, einen Encoder und einen Decoder aufzubauen? Oder kann man so etwas überhaupt nicht für Prüfzwecke oder ähnliches verwenden, um Empfänger, Servos usw. zu testen?
Meines wissens decodieren Empfänger das Signal gleich mit und stellen die kanäle bereit.
Oder anders gefragt: Gibt es im Modelbau irgend eine Situation, wo man ein Summensignal direkt benötigt?
Für eure Antworten wäre ich dankbar!
Gruß Mitch.
Weis denn keiner bescheid?
Diese Situation gibt es des öfteren, z.B. wenn man mehrere Kanäle mit nur einem Eingang eines Controllers überwachen bzw. auswerten will.Oder anders gefragt: Gibt es im Modelbau irgend eine Situation, wo man ein Summensignal direkt benötigt?
Das Problem ist , das die Auswertung in verschiedenen Empfängerfabrikaten auf verschiedene Weise funktioniert.
Einige legen so ein Summensignal auf ein Schieberegister, andere werten das Signal vom Demodulator direkt aus, wieder andere bewerten die Signale mit einem Microcontroller.
Man hat somit keinen gemeinsamen Punkt, an dem man für Prüfzwecke so ein Summensignal einspeisen könnte.
Wo man so etwas des öfteren braucht sind Anwendungen bei denen mehrere Servos in bestimmten Abläufen sequentiell angesteuert werden müssen.
Eine Anwendung wären sogenannte Door Sequencer für Einziehfahrwerke bei Modellflugzeugen. Also Fahwerksschächte auf, Fahrwerk einfahren, Fahrwerksschächte zu oder umgekehrt. In diesem Beispiel müssen 2 oder sogar noch mehr Servos nach einem programmierbaren Schema angesteuert werden.
Angesteuert wird die Schaltung über einen einzigen Fernsteuerkanal.
Wenn Du dazu eine konkrete Frage hast, solltest Du sie auch stellen.
Wenn Du z.B. Fragst wie das Timing so eines Fernsteuersignales mit 8 Kanälen aussieht- wirst Du sicher bald eine befriedigende Auskunft kriegen.
Auf so Allgemeine Anfragen - Ich möchte mal irgendwas bauen, weis zwar nicht was - braucht man denn sowas - tut man sich mit der Beantwortung schwer
Hallo,
also das mit dem Door-Sequenzer höre ich zum ersten mal, klingt aber plausiebel. Das erinnert mich irgendwie an Multiswitsch, wo man mehrere Schalterstellungen ebenfalls über einen einzigen Kanal nacheinander überträgt.
Was ich da bauen will dient zum einen für Lernzwecke. Wenn man es beim richtigen Modellbau auch verwenden kann umso besser.
Ich will mal kurz beschreiben, wie mein RC-Encoder aussehen soll:
Ich möchte mit dem ATmega8 ein RC-Summensignal erzeugen. Dazu verwende ich die 6 ADC-Eingänge des Controllers , die mir Analog-Kanäle K1 bis K6 zur Verfügung stellen. K7 und K8 werden als AN/Aus (Schalter-Funktion) gesendet. Dafür lese ich einfach 2 Pins ein.
Über die serielle Schnittstelle soll das ganze noch über PC parametrierbar werden, um beispielsweise festzulegen, ob ein 1, 2, 4 oder 8-Kanal Summen-Signal erzeugt werden soll.
Ein I²C-Bus ist ebenfalls vorgesehen, um ein Multiswitsch-Signal auf Kanal 7 oder 8 (anstelle der normalen Ein/Aus-Funktion) zu legen.
Neben dem Ausgang für das Summensignal ist ein weiterer Port vorgesehen, der ein Sync-Signal ausgibt. Der kann für die Triggerung des Oszilloskops verwendet werden.
Das ganze habe ich auf einem Steckbord bereits aufgebaut und liefert schön brav, wie erwartet die Signale. Das Timing ist meines erachtens perfekt.
Die serielle Schnittstelle und der I²C-Bus ist noch nicht (Softwaremaßig) integriert. Das Programm habe ich in Bascom-AVR ungesetzt.
Als nächster Schritt wäre dann die Dekodierung des RC-Signale auf die einzelnen Kanäle. Da habe ich auch schon eine Software-Vorstellung, die müßte funktionieren.
Was hältst du davon.
Könntest du so etwas für dein Modellbau brauchen?
Leider kann ich das nicht real Testen, da ich keinen Empfänger habe, dem ich das RC-Summensignal anbieten könnte.
Hast du eine Möglichkeit das mal soweit zu testen? Das wäre toll.
Ich würde dir dann den Source-Code schicken mit ein paar Infos, wie der Controller beschaltet ist.
Mitch.
Jetzt versteh ich erstmal, was Du da überhaupt vor hast.
Du möchtest also eine Servoansteuerung für 8 Servos basteln, die entweder über 6 Potis + 2 Schalter, oder über die serielle Schnittstelle betätigt werden können.
Hier bei Roboternetz wurden schon öfter mal Anfragen nach so einem Teil gestartet, mir als Flugmodellbauer bringt es relativ wenig.
Wenn Du eine Funkstrecke dazwischen baust hast Du wieder eine normale Fernsteueranlage und ein Laptop kriegt man immer so schwer in einem Flugmodell unter .
Für eine Roboterbauer, dürfte vor allem die Option mit der Ansteuerung und Parametrierung vom PC aus interessant sein.
Das Summensignal auf verschiedene Ausgänge per Software zu verteilen dürfte nicht wirklich ein Problem sein.
In älteren Fernsteuerempfängern wurde für die Einzelkanaldekodierung oft ein CD 4017 verwendet, der mit dem Kanaltakt weitergeschaltet und durch die etwas längere Pause nach dem letzten Puls resettet wurde.
Für meine Servoimpulserkennungen hab ich den ICP Pin des Controllers verwendet, wobei das natürlich nur eine der Möglichkeiten ist.
Guck mal unter http://www.rclineforum.de in der Elektronik Rubrik.
Da haben die Leutz da sich schon intensiv mit der Servoimpuls Erkennung und Dekodierung mit verschiedenen Methoden befasst.
Was Du mit dem I²C Bus vorhast leuchtet mir auch noch nicht so ganz ein, wenn es für Übungszwecke genutzt werden soll ist es natürlich OK.
Für die Überprüfung deines Summensignales müsste ich einen voll funktionsfähigen Empfänger zerlegen, was ich nur sehr ungern tun würde - Sorry.
Wenn deine Funke eine Schüler-Buchse hat, kann man da ein PPM-Signal einspeisen und so das Signal übertragen?
Klar ich verstehe dich, dass du deine Funke nicht zerlegen willst. Ich dachte da eigentlich eher an die Einspeisung auf der Empfängerseite.
Der I²C-Bus habe ich mir als optionale Erweiterung vorgestellt, um Multiswitch zu realisieren. Im Netz habe ich irgendwo gelesen, wenn man mehrere Schalter-Positionen über einen Kanal übertragen möchte, macht man dies seriell. Im ersten Frame wird die Position des 1. Schalters gesendet, im 2. Frame Schalterposition 2 usw.
Man kann so fast beliebig viele Schalter-Positionen übertragen.
Ich habe mir gedacht, an den I2C-Bus ein Expander-Baustein vom typ PCF8574 zu hängen. Der hat 8 Quasi Bidirektionale IO-Ports. Dann also 8 Schalter verarbeiten. Für weitere 8 Schalter nimmt man einen 2. Baustein.
Mit 2 Solchen Bausteinen könnte man also bereits 16 Schaltfunktionen realisieren, die über einen einzigen Kanal übertragen werden.
Um 20 Schalter-Funktionen am Empfänger einzustellen benötigt man beispielsweise 1 Frame pro Schalter-Position und zum Synchronisieren ein weiteres, sind zusammen 17 Frames a 20ms = 0,34 Sekunden.
Das klingt doch gut!
Man könnte aber auch ein LCD-Display dran hängen und die Analogwerte anzeigen lassen, die man sendet.
Den Encoder dafür hab ich schon in der Schublade....wenn man mehrere Schalter-Positionen über einen Kanal übertragen möchte, macht man dies seriell. Im ersten Frame wird die Position des 1. Schalters gesendet, im 2. Frame Schalterposition 2 usw.
Guck mal auf :
http://www.toeging.lednet.de/flieger...tic/nautic.htm
Das Coding ist 2x Überlanger Impuls mit ca. 2100µs ( Framebeginn )
8 x Kanalinformation mit 1200, 1500, oder 1900µs für die Schalterstellungen. Du musst allso 10 komplette Fernsteuerframes übertragen.
Durch die 1200 und 1900µs sind 2 Schaltfunktionen möglich die jeweils exklusiv angesteuert werden können. Somit erhältst Du insgesamt 16 Schaltfunktionen.
Das ist übrigens auch kompatibel zum Graupner "Multiswitch" Coding.
Der Nachteil ist nur, das das ellenlange Dauert, ca. 200ms Verzögerung.
Bei meinem Modul müssen aber 2x richtige Impulslängen übertragen werden, bis daer Schalter reagiert, also dauert es bis zu 400ms bis der Empfänger reagiert
habe gerade mal auf der Seite geschaut und das Schaltbild gemustert. In etwa ist es das, was ich mir vorgeschwebt hat, um die Multiswitch-Funktion zu dekodieren.
Mir ist klar, dass ich mich an die Standards halten muss damit alles spielt. Das war von Anfang an meine Absicht. Nix neues erfinden, sondern etwas kompatibles selber bauen.
Aber dieser Dekoder ist erst später geplant. So weit bin ich noch nicht. Im Augenblick bin ich noch am Encoder für das RC-Summensignal.
Auf jeden Fall verstehst du jetzt, was ich mit Multiswitch meine.
Ich bin gerade dabei Oszilogramme aufzunehmen, die das Summensignal und das Timing des Encoders aufzeigen. Wenn du dich ein paar Minuten geduldest, kann ich es mal kurz ins Netz stellen. Hast du Interesse das mal zu sehen?
Hallo Mitch,
danke für die PN.
Ich hab mir mal deine Oszillogramme angeschaut.
Ich meine die Pause zwischen den Impulsketten sollte als 0 übertragen werden. Das lässt sich mit einemm RC Glied relativ einfach auswerten und bringt einen sicheren Reset wenn das Frametiming mal etwas durcheinander gekommen ist ( Störung ).
Ansonsten schaut das doch sehr gut aus.
Kann es sein, das deine Versorgungsspannung etwas verrauscht ist ? Oder sind das Fehler des A/D Wandlers deines Speicheroszis ?
Ich melde mich gleich nochmal. Warte kurz. (10:40:00)
Lesezeichen