RC-Signal Encoder / Decoder

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 8) 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?

Zitat:

---

Oder anders gefragt: Gibt es im Modelbau irgend eine Situation, wo man ein Summensignal direkt benötigt?

---

Diese Situation gibt es des öfteren, z.B. wenn man mehrere Kanäle mit nur einem Eingang eines Controllers überwachen bzw. auswerten will.

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.

Zitat:

---

...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.

---

Den Encoder dafür hab ich schon in der Schublade.

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)

Also was die Pause angeht zwischen den Pulsketten, da habe ich mich an das gehalten was hier steht:

http://www.mftech.de/ppm.htm

Dort steht aber auch, dass ein Pulszug eine Länge von 22,5ms hat.
Wie ist denn nun die Länge des Pulszug wirklich? 20ms oder 22,5ms?
Habe ich das was falsch rausinterpretiert?

Wo das Rauschen im Oszillogramm herkommt weis ich nicht. Damit muß ich wohl leben.

Den Link, den ich dir gestern geschickt habe, den kannst du nochmal aufrufen. Wenn die Seite angezeigt wird, editierst du die Adresszeile und nimmst den Namen der html-Datei weg. Den Rest stehen lassen und Enter.

Es wird dir dann der Inhalt des Verzeichnisses angezeigt. Ich Stelle da mal das Schaltbild rein, das ich eben fertig gestellt habe. Es ist ne PDF.

Schau sie dir mal an. Deine Meinung hierzu würde mich schon interessieren.

Noch was: Würdest du nur mal zum Prüfen die Absendezeit mit rein schreiben bei deiner nächsten Antwort? Ich wundere mich über die angezeigte Zeit des Beitrags im Forum. Da scheint die Uhrzeit nicht zu stimmen. Oder woran liegt das?

[11:15]
Die Länge des kompletten Pulszuges ist nicht wirklich kritisch.
Es werden alle Zeiten zwischen 18ms und 30ms funktionieren.

Bei kürzeren Framezeiten könnten vor allem ältere Servos Probleme kriegen, bei über 30ms werden die Servos zunehmend "lahm" und "kraftlos".

Mir gings eigentlich eher um die Pegel.
Ich hab mal an meiner FC 16 nachgemessen, anscheinend liegt da tatsächlich zwischen 2 Frames eine 1 an - Sorry, Du hattest recht.

Ich habe das Signal einmal nicht invertiert aufgenommen. Das Diagramm ist jetzt auch auf meiner Seite.
Kannst das ja auch nochmal anschauen.

Aber so wie du sagst, müßte das Signal dann invertiert rausgehen, also so wie in den ersten 4 Diagrammen.

Du sagst, dass Framelängen zwischen 18ms und 30ms funktionieren, könnte man ja die Framelänge verlängern und hätte so nochmal Platz für 1 oder 2 Kanäle. sehe ich das richtig? Wie lang ist denn deine Framelänge, wenn du nachmißt.

Hasu du mal einen Blick auf mein Schaltbild geworfen?

[11:40]

Zitat:

---

Du sagst, dass Framelängen zwischen 18ms und 30ms funktionieren, könnte man ja die Framelänge verlängern und hätte so nochmal Platz für 1 oder 2 Kanäle. sehe ich das richtig?

---

So ist es, und wurde auch schon so gemacht.
Da die Servos dabei aber neue Informationen seltener kriegen lässt aber die Stellkraft nach.
Da Du die Signale ja selber generierst, kannst Du immer auch 2 Kanäle gleichzeitig bearbeiten und kommst so auf 16Servos mit 20ms Framerate.
Ich würde dieses Verfahren vorziehen.
Beim Impulsempfang musst Du dich aber mit dem zufrieden geben, was dein Sender da so abgibt.

Zum PPM Empfang mit deinem ATMEGA8 würde ich mir den ICP Pin freihalten.
Mit dem lassen sich solche Impulszeiten prima messen.

Dein Schaltbild hab ich mir auch schon mal kurz angeschaut - Für mich sieht das soweit in Ordnung aus. Als seriellen Schnittstellentreiber würde ich nicht mehr auf einen MAX 232 setzen, schau Dir mal den FT 232 RL an. Das ist ein USB Schnittstellenbaustein der auch einen virtuellen COM Port emulieren kann. Damit bist Du dann auch für USB gerüstet.

Zur Framelänge kann ich Dir leider keine konkreten Angaben liefern, hab nur ein Analog Oszi, un da ist das Ganze ein böses Gezitter.
Mit "Netz- Triggerung" laufen die Oszillogramme nach links, also würde ich behaupten die Framezeit liegt etwas über 20ms.

Das andere Verfahren, das du Vorziehen würdest, ist das das PWM?
Darüber habe ich Leider noch keine Infos finden Können. Kannst du mir das bitte erklären, wie das mit den 16 Servos funktioniert? Frame-Signale, Timing etc. ?

Den Tip mit dem ICP-Pin werde ich mir vormerken, Danke für den Tip.

Die serielle Schnittstelle auf dem Schalbild ist wie du siehst ohne MAX232-Baustein. Das ist auch mit Absicht so, denn den Baustein FT232RL hatte ich schon im Sinn, um eine Parametrierung/Programmierung/Steuerung über USB machen zu können.

Mit dem FT232RL habe ich vor kurzem erst eine USB-RS485-Schnittstelle gebaut. Das Ding brauchte ich, um mit meinem Notebook das selbst entwickelte und gebaute Hausnetzt bei meinem Kumpel zu parametrieren. Habe sogar ein Bootloader in die Komponenten integriert. Firmware wird übers Hausnetz upgedatet. Software habe ich in Visual-Basic geschrieben.

Das Spielt prima und mein Kumpel ist sehr zufrieden.

Jetzt bin ich aber vom Thema abgekommen.
Hast du Infos ober das andere Verfahren?

Ich bin mal etwa für ne Stunde weg vom Computer. Bin spätestens 13:00 wieder online. Bist Du dann auch noch da?

Mitch.

[fade:d13f22dbe4]Bin wieder online.[/fade:d13f22dbe4]

[13:56]

Zitat:

---

Das andere Verfahren, das du Vorziehen würdest, ist das das PWM?

---

Die Idee die dahinter steckt ist folgende.
Du generierst deine Servoimpulse für jedes Servo einzeln.
Das bedeutet ein Ausgang deines Microcontrollers steuert ein Servo.
Da wird es allerdings mit den Pins an einem ATMEGA 8 mehr als knapp, da sollte dann schon ein ATMEGA 16 ran.
Die Ausgabe der Impulse erfolgt dann an 2 Ausgängen gleichzeitig, also z.B. Kanal 1 und 9, dann 2 und 10 usw.
Die Impulsausgabe liesse sich dann mit den beiden Comparmatch Interrupts steuern. Einer für die Kanäle 1..8 der andere für die Kanäle 9..16.
Wenn Du zu den aktuellen Impulslängen die neue Impulslänge dazuaddierst und dann den Ausgang um 1 weiterschaltest, sollten sich die beiden Interrupts nicht ins Gehege kommen und Du könntest die Servoimpulsaufnahme auch noch Durch den Timer 1 über ICP Interrupt machen lassen. Das bedeutet, die komplette Servoimpulsaufzeichnung und Ausgabe läuft komplett über den Timer 1 im Interrupt.
Wenn Du die Impulsketten parout seriell übertragen willst, was spricht dagegen einen 2ten Ausgang für das 2te Summensignal zu verwenden.

Was natürlich nicht funktioniert ist von einer gegebenen Servoimpulskette ( z.B. von einem Fernsteuersender ) dieses Signal direkt weiterzugeben, weil es ja üblicherweise nur 8 Kanäle hat.

Du sprichst hier, wenn ich richtig verstehe, von der Generierung der Servoimpulse auf der Empfängerseite. Das leuchtet ein. Aber wie willst du so ein Signal übertragen? Ist das denn noch kompatibel zum PPM-Standard und was es da so gibt?

Ich habe mal was von digitaler Übertragung gelesen. Da sind bis zu 14 Kanäle möglich. Dieser Standard ist allerdings zum PPM nicht kompatibel. Aber er scheint langsam aber sicher seine Anhänger zu finden.

Weist du wie dieses Signal aussieht?
Übrigens: Wenn man die Beschreibung von Fernsteuerpulten so liest fällt immer der Begriff PWM. Manche Fernsteuerungen können beides senden.

Hast du darüber Info's oder nen Link?

[14:55]

Zitat:

---

Du sprichst hier, wenn ich richtig verstehe, von der Generierung der Servoimpulse auf der Empfängerseite. Das leuchtet ein. Aber wie willst du so ein Signal übertragen? Ist das denn noch kompatibel zum PPM-Standard und was es da so gibt?

---

Richtig, ich meine hier die Empfängerseite.
Von der Senderseite aus lässt sich so ein Signal nicht zu Heute üblicher Technik kompatibel per PPM übertragen.

Zitat:

---

Ich habe mal was von digitaler Übertragung gelesen. Da sind bis zu 14 Kanäle möglich. Dieser Standard ist allerdings zum PPM nicht kompatibel. Aber er scheint langsam aber sicher seine Anhänger zu finden.

---

Ich kenn das jetzt nur als PCM Übertragung.
Die ist aber leider firmengebunden und Empfängerseitig auch ziemlich teuer.
Deshalb ist die Verbreitung üblicherweise eher bei Großmodellen und Benzinern ( Zündfunken ) zu finden, weil hierbei auch eine Fehlererkennung mittels Checksumme eingebaut ist.
Wie die Fernsteuersigane da Codiert werden hab ich noch nicht so richtig rausgekriegt - Hab aber auch noch nicht wirklich intensiv danach gesucht.

Bei Graupner werden die oberen Kanäle per PCM nicht so oft übertragen wie die unteren - hab ich jedenfalls mal irgendwo gelesen.

Was denn künftig mit der 2,4GHz technik möglich sein wird kann man jetz noch nicht so richtig abschätzen.

Mir ist zwar immer noch nicht so ganz klar, was Du da eigentlich bauen willst, offenbar soll es ein "normales" Fernsteuersystem ohne HF Strecke werden. Ich will Dich sicher nicht ausspionieren, aber ein kleiner Tipp, was es denn mal werden soll wäre schon hilfreich.

Da es "normale" Sender und Empfängergeräte schon für kleines Geld gibt, würde ich mich eher auf die Entwicklung von Expansionsmodulen einschießen.
Die sind, wenn überhaupt erhältlich, Schweineteuer und meistens von geringer Funktionalität.
Ein großes Thema im Bereich Flugmodellbau ist zur Zeit Modellbeleuchtung.
Sicherlich wurde diese Entwicklung durch die Verfügbarkeit von High - Power LED's gepusht.
Bei den Funktionsmodellbauern sind, soweit ich das mitkriege, vor allem Kanal- Expansionsmodule gefragt.

Zitat:

---

Wenn man die Beschreibung von Fernsteuerpulten so liest fällt immer der Begriff PWM

---

Da gibt es ein großes Verwirrspiel in den Begrifflichkeiten.
Der Begriff PPM ( Pulsphasenmodulation ) ist eigentlich für Fernsteueranlagen falsch. Er würde bedeuten, das ein Impuls einen bestimmten Abstand zu einem festen Zeitraster hat.
PWM ( Puls Width Modulation ) wäre da schon richtiger, allerdings ist damit meistens eine Leistungsregelung über das Puls/ Pausen Verhältnis gemeint.
Am ehesten wird der Begriff PDM ( Puls Dauer Modulation ) der Geschichte gerecht, den aber kaum jemand verwendet. Seitens der Modellbauhersteller hat sich aber der Begriff PPM eingebürgert.
PCM ( Pulse Code Modulation ) ist ein etwas neueres Übertragungsverfahren, bei dem die Steuerknüppelstellungen digitalisiert und als binäre Wörter übertragen werden.
Leider konnten sich die großen Modellbauhersteller nicht auf ein einheitliches Verfahren zur Bildung eines PCM Rahmens einigen.
So kocht da jeder sein eigenes Süppchen und die Komponenten sind Firmenübergreifend untereinander nicht kompatibel.

Das irrste dabei ist auch noch, das z.B. bei Graupner der Einsatz von Multiswitch Modulen nur bei Verwendung der PPM Modulation möglich ist. Bei PCM geht es nicht.
Wie es bei den anderen Herstellern aussieht weiß ich nicht, aber ich befürchte, da wird es ähnlich sein.

Multiplex verwendet für die Servomittelstellung meines Wissens eine Impulslänge von 1,52ms, während fast alle anderen Hersteller 1,5ms benutzen. Bei den neueren Anlagen kann man aber auf 1,5ms Servomitte umstellen.

Du hast also beim Parametrieren so einiges zu tun. ;-)

Zitat:

---

Hast du darüber Info's oder nen Link?

---

Nach ein bischen Googeln hab ich das hier gefunden:
http://www.aerodesign.de/peter/2000/PCM/PCM_PPM.html

Den Weg den ich hier mache ist folgender:
Einen Encoder zu bauen (der kompatibel sein soll, erstmal PPM). Dazu einen passenden Decoder, der das wieder aufschlüsselt. Das dient zum einen zum Lernen und zum anderen kann ich mir Vorstellen, daß man damit auch diverse Fehler-Diagnosen an Funkmodellen machen kann.

Im Encoder habe ich ja bereits eine Möglichkeit vorgesehen für Multiswitch. Einen entsprechenden Decoder auf der Empfangsseite, der dann an einen normalen Empfangskanal angeschlossen werden soll, macht die Schalter wieder Verfügbar. Was man dann dran hängt bleibt dem Modellbauer überlassen. - Z. B. Modellbeleuchtung.

Wer weis, vielleicht fällt mir ja auch was neues ein, was man da übertragen könnte und wie man es überträgt.

Das ist aber momentan noch Zukunftsmusik.

Ich könnte mir Vorstellen, das man in Flugmodellen und anderen einen I²C-Bus auch gut einsetzen könnte. Was haltst du von der Idee?

Aber nochmal zurück zum Multiswitch.
Wenn ich von einer gekauften Fernsteuerung ausgehe (Sender) und will da ein Kanal für Multiswitch verwenden. Kann man das überhaupt einbauen?
Ich meine ist da Platz, ist alles im inneren Modular zusammen gesetzt oder eine einzige Platine? Schließlich müßte ja dann eine zusätzliche Platine rein.

Da du gerade von Expansionsmodulen sprichst. Auf diese Weise wäre vielleicht eine Möglichkeit gegeben, den Sender etwas zu erweitern (muß ja Kanalbezogen nicht mal kompatibel sein) und mir den entsprechenden Expansionsmodul wieder dekodieren.

Was ich hier konkret meine ist, daß ich die Stelle (z.B. Kanal 8) im Sendetrame verwende, aber keine PPM dort hinsetze, sondern ein eigenes Format, mit dem man neue Möglichkeiten hat.

Aber um solche Dinge zu testen nimmt man als Entwickler normalerweise nicht gleich die gesamte Funkstrecke, sondern Teilt diese Auf, um den Weg des Signals verfolgen zu können.

Zitat:

---

Wenn ich von einer gekauften Fernsteuerung ausgehe (Sender) und will da ein Kanal für Multiswitch verwenden. Kann man das überhaupt einbauen?
Ich meine ist da Platz, ist alles im inneren Modular zusammen gesetzt oder eine einzige Platine? Schließlich müßte ja dann eine zusätzliche Platine rein.

---

Klare Antwort - Ja.
Allerdings gibt da keiner der Modellbauhersteller sein verwendetes Coding, geschweige denn Schaltpläne raus.
Bei Graupner Multiswitch ( bin da zur Zeit eh etwas am basteln wie Du merkst ) wird senderseitig anscheinend ein Rahmen Sync Signal verwendet, das ein neues Frame anzeigt. Durch dieses Sync wird die Multiswich Information um 1 Kanal weitergeschoben und je nach eingestellter Schlterstellung eine andere Spannung an einen normalen Kanaleingang im Fernsteuersender gelegt.
Insgesamt gibt es 4 Spannungen ( Sync, lang, mitte und kurz ), die dann nach gewünschten Funktionen auf den Servoeingang gelegt werden. Da bei Graupner 8 Schalter + 2 Sync Impuls Übertragen werden, kommt man auf insgesamt 10 Impulsrahmen, bevor das Spielchen von neuem beginnt.

In den neueren Sendern sind 2 solcher Originalmodule zum Straßenpreis von 117,-€ !? einbaubar. Die Signale werden über entsprechende Stecker den Modulen zu verfügung gestellt.

Zitat:

---

Da du gerade von Expansionsmodulen sprichst. Auf diese Weise wäre vielleicht eine Möglichkeit gegeben, den Sender etwas zu erweitern (muß ja Kanalbezogen nicht mal kompatibel sein) und mir den entsprechenden Expansionsmodul wieder dekodieren.

---

Das ist sicher möglich, blos blöderweise muss man sich dabei trotzdem an das Timing des Senders halten. Man könnte aber allein schon durch die aktivierung von mehr " Spannungen " als 4 einen höheren Datendurchsatz erreichen.
Im RC Lineforum hat sich mal einer mit einem Stufenschalter und angeschlossenen Widerständen einen 1 aus 8 Selektor gebastelt, der dann mittels eines 2 Stufen Schalters 16 Raketen abfeuern konnte. Die Links stehen auf unserer oben bereits genannten Page.

Zitat:

---

Was ich hier konkret meine ist, daß ich die Stelle (z.B. Kanal im Sendetrame verwende, aber keine PPM dort hinsetze, sondern ein eigenes Format, mit dem man neue Möglichkeiten hat.

---

Das ist theoretisch möglich, aber in den zur Zeit üblichen Computersendern können dermassen viele Mischfunktionen integriert sein, das das schon wieder eine schwierige Aufgabe werden wird. Ausserdem soll ja das Ganze zu heute üblichem Equipment kompatibel bleiben.

Ja und da sind wir wieder beim Thema. Hier ist mein Encoder und Decoder auch wieder nützlich. Natürlich entscheidet dann am Schluß, wenn alles soweit funktioniert, ob das auch über die Funkstrecke und mit herkömmlichen Empfängern noch auswertbar ist und funktioniert.

In jedem Fall steckt ein großer Lerneffekt dahinter.
Ich denke mal die wenigsten Modellbauer wissen, was sie da eigentlich durch den Äther schicken.
Erst wenn mal was nicht funktioniert, dann ist das gemammer groß. Ists nun die Fernsteuerung, der Empfänger, oder der Serveo oder vielleicht das Expansionsmodul?

Wenn man die Signale kennt und ein Oszi hat, dürfte das alles halb so wild sein und der Fehler schnell lokalisiert.

An dieser Stelle fällt mir auf, dass du dir recht viel Zeit für mich nimmst. Wie kommts?

Hast auch Interesse an einem Multiswitch oder ähnlichem aus meiner Feder? Oder ist es eher das Fachsimpeln, wie man so schön sagt?

Wie dem auch sei, ich denke, wir könnten eine Menge voneinander lernen.

Zitat:

---

Ich könnte mir Vorstellen, das man in Flugmodellen und anderen einen I²C-Bus auch gut einsetzen könnte. Was haltst du von der Idee?

---

Die Idee halt ich für prinzipiell schon für gut, die Frage ist nur was willst Du damit ?
Eine sinnvolle Anwendung wäre eventuell ein Diversity System, mit dem sich 2 getrennt voneinander arbeitende Empfänger synchronisieren lassen.
Guck mal auf die Seite http://www.acteurope.de/ .
Leider gibt es bei Funkfernsteuerungen keinen Rückkanal, über den man z.B. Telemetriedaten übertragen kann.
In Turbinen ECU gibt es üblicherweise eine normale serielle Schnittstelle mit eingebaut, mit der man nach der Landung die Betriebsparameter der Turbine nach der Landung abfragen und einen Fehlerspeicher auslesen kann.

Ich hoffe, das sich das mit den fehlendem Rückkanal mit der einführung der 2,4GHz Sender endlich erledigt.

Im RC Lineforum gibt es einen schönen Threat, der aufzeigt was da alles ( eventuell ) möglich sein wird. Link : http://www.rclineforum.de/forum/thre...e7af954453a56c

Zitat:

---

An dieser Stelle fällt mir auf, dass du dir recht viel Zeit für mich nimmst. Wie kommts?
Hast auch Interesse an einem Multiswitch oder ähnlichem aus meiner Feder? Oder ist es eher das Fachsimpeln, wie man so schön sagt?

---

Wie Du ja schon mitgekrigt hast hab ich ja ein Nautic Empfängermodul schon fertig.
Was mir noch fehlt ist ein Nautic Sende Modul zum Einbau in den Fernsteuersender.
Da bin ich zur Zeit gerade dran sowas zu entwickeln.

Aus diesem Grund bin ich in der Materie einigermassen tief drin und es macht echt mal Spaß sich mit jemadem auszutauschen, der eine Ahnung hat, über was man da überhaupt redet.

Es ist also beides - Interesse wie Du so ein Multiswitch realisieren willst und natürlich auch die Fachsimpelei.

Eventuell könnten wir uns bei der Entwicklung für so ein Multiswitch- Sendemodul auch zusammentun ?

Ich schick Dir auf jeden Fall mal meine E-Mail Adresse per PN.

Klingt interessant.
Vor allem das mit dem Rückkanal wäre praktisch. Man könnte Batterie-Status zurücksenden oder Messdaten wie Luftdruck, Temperatur usw.

Hast du schon mal was von Quadro-Coptern gehört? Manche nennen das Ding auch ein X-Ufo. Das ist ein Fluggerät mit 4 auslegern. An jedem ein Propeller. Funktioniert ganz grob wie ein Hubschrauber.

So ein Ding hat mal jemand beim Vermessen von Straßenzügen verwendet. Hier wurden aus der Luft Telemetriedaten gesendet. Manche Senden auch Video-Bilder oder schießen Fotos.

Wenn du mal bei YouTube.de vorbei kommst, such mal nach X-Ufo und Quadro-Copter. Da sind teilweise echt geniale Ansätze dabei!

Hey, klasse Idee, das mit dem zusammen tun.
ICH BIN DABEI !!!

Zitat:

---

Wenn du mal bei YouTube.de vorbei kommst, such mal nach X-Ufo und Quadro-Copter. Da sind teilweise echt geniale Ansätze dabei!

---

Hab die Dinger schon live auf der Modellbaumesse in Sinsheim gesehen.
Was mich von der Realisierung so eines Projekts abschreckt ist die Sensorik, sowie die nötige Regelungstechnik für sowas selbst zu proggen.

Find Super, das Du dabei bist \:D/

Ich meine wir sollten uns über weiternen Dinge per E-Mail austauschen und nur konkrete Fragen oder Lösungsansätze hier einstellen, sonst wirds etwas OT.

Ubrigens - ich progge in CodeVision AVR und nicht in Bascom.

Ich hab dir ne Mail geschickt. Dann hast du meine auch.

OK, alles weiter per eMail!
See you on Outlook!

Hi Mitch,
ich sehe Deinen Beitrag zu dem RC-Summensignal erst jetzt.
4 AnalogIn + 2 Schalter -> AVR -> RC Summensignal! das ist genau das was ich suche!
Die Hardware habe ich fertig. Nur mit der Software tu ich mich schwer. Ich habe keine Ahnung von C und bräuchte den Code in BASCOM. Würdest Du mir helfen?
tschüß slavezero

Hi slavezero,

natürlich helfe ich dir gerne, wenn ich kann.
Ich schlage vor, du sendest mir eine Private Nachricht mit deiner eMail, alles weitere können wir dann per Mail durchgehen.

OK?

Gruß Mitch.

Servus,

ich bin selbst gerade am Rechergieren, weil ich mir für meine Graupner MC-14 einen Multiswitch und den passenden Decoder dazu selbstbauen möchte.

Deswegen wollte ich mal nachfragen ob ihr den schon irgendwelche Fortschritte in der Richtung erzielt habt.

Danke schonmal.

@bemvo
Suchst Du sowas http://www.toeging.lednet.de/flieger...tic/nautic.htm hier, oder das Gegenstück für den Sender ?

Das Empfängermodul ist bereits fertig, wie Du siehst.
Das Sendermodul ist in der Entwicklung gestern sind die ersten Prototypenplatinen eingetroffen.

Jetzt müssen wir die erstmal bestücken und dann die Software dafür schreiben.

den link kenn ich schon.

ich möchte aber auch noch das Modul für den Sender bauen.
Schön das ihr schon Platinen habt. Würde mich gern mit anschließen und euch deswegen schon mal meine Hilfe anbieten.

Meldet euch einfach.

Wäre es zudem möglich, das ich die Pläne für die Hardware bekomme?

Gruß

@bemvo
Es gibt bereits einen Schaltplan und ein Layout für den Senderbaustein, das ist aber beides noch in keinster Weise getestet.
Wir werden in den nächsten Wochen mal 2 von den Dingern bauen, Software schreiben und die Module ausprobieren.
Wenn Du willst, kann ich dir diese "Alpha Layouts" im EAGLE Format zukommen lassen. Dazu könntest Du mir deine E-Mail Adresse per PN schicken.
Im wesentlichen besteht die Hardware aus einem digitalen Poti ( DS 1803 ), das per SPI angesteuert werden kann und einem ATMEGA8 Controller.

Du könntest uns aber schon behilflich sein.
Kannst Du an deinem Graupner Sender mal austesten welche Spannung an den Geber Eingängen anliegt.
Im günstigsten Fall sollten das 5V sein.
Ist die Spannung dort höher, kannst Du das Modul ohnehin nicht einsetzen.