Hallo, ich habe vor ein paar Tagen ein Entwicklungsboard (STK500) und ein paar Servos geschenkt bekommen. Nach ein paar Spielereien mit den LED's hab ich mich mal an die Ansteuerung der Servos herangemacht. Hab dann hier auf der Seite etwas gestöbert und mir erstmal das Prinzip der Servosteuerung veranschaulicht. Hab dann auch den angefügten Quellcode gefunden, soweit angepasst und ausprobiert. Die Servos an das STK500 angeschlossen und los dachte ich. Doch leider dreht der Servo nur bis zum linken Anschlag und das wars. Sind leider meine ersten Erfahrungen auf dem Gebiet, für ein paar Ratschläge wäre ich echt dankbar. Grüße Daniel
Hallo Eventuell wäre noch ein Schaltplan nützlich. Ich vermute aber: Dein Signal ist zu lange oder zu kurz auf H. Ein H-Signal ist aber vorhanden, sonst würde das Servo stehen. Kontrolliere mal, ob... ...der Pin, an dem das Servo hängt, auch tatsächlich ein H/L-Signal bekommt oder eventuell immer auf H bzw. L ist. ...dieses Signal auch tatsächlich mit dem vorgesehenen Timing abläuft. (Am besten im Simulator das Programm jeweils bis zum Umschalten des Pins laufen lassen und dann die Zeitspanne messen.) ...du das Timing richtig Interpretiert hast. Ein 'Taktzyklus' dauert 20 ms. In diesem Taktzyklus geht das Signal für 1 - 2 ms auf H. Vielleicht hast du es so interepretiert: 20 ms L, dann 1 - 2 ms H. Gruss Michael
Mit welcher Taktfrequenz betreibst du den AVR? Verwendest du einen externen Quarz, oder den internen Oszillator? Wenn du einen externen Quarz verwendest (oder meinst zu verwenden)... bist du dir sicher, daß du den Controller entsprechend vorbereitet hast (Stichwort Fusebits)? Was passiert, wenn du via RS232 Daten an den Controller schickst? Soweit ich das beim ersten Überfliegen des Codes erkennen konnte, wird die Sollposition des Servos über die serielle Schnittstelle vorgegeben. Gruß, Magnetus
Hi, erst einmal Danke für eure Antworten. Also ich verwende den externen Quartz auf dem STK500, die Fusebits sind richtig gesetzt (auf externen Quartz umgestellt). Das mit dem schicken über RS232 versteh ich nicht ganz. Wie kann ich ihm denn da Daten schicken?
"Also ich verwende den externen Quartz auf dem STK500, die Fusebits sind richtig gesetzt (auf externen Quartz umgestellt)." Aha, und mit welcher Frequenz schwingt nun dieser Quarz? "Das mit dem schicken über RS232 versteh ich nicht ganz. Wie kann ich ihm denn da Daten schicken?" Ganz einfach: Du verbindest die entsprechenden Portpins des Controllers mit den RX-/TX- Pins nahe der 8 Ausgabe-LEDs. Ausserdem verbindest du die serielle Schnittstelle deines PCs mit der 9poligen SUBD-Buchse (welche mit "SPARE" beschriftet ist). Um nun die Daten vom PC zum µC und umgekehrt vom µC zum PC zu schicken benötigst du natürlich noch ein entsprechendes Programm auf dem PC (im einfachsten Fall ein stinknormales Terminalprogramm z.B. "Hyper Terminal") Gruß, Magnetus
Hallo Daniel, nachdem ich mich nun etwas intensiver mit der ganzen Thematik beschäftigt habe, ist der Stang der Dinge folgendermaßen: Der Mikrocontroller läuft nicht wie oben beschrieben mit einem externen Quarz, sondern mit dem internen Oszillator. Die Fuses habe ich wieder dementsprechen umgestellt. Das mit dem Daten schicken über die RS232-Schnittstele hab ich nun auch kapiert. Habe meinen PC mit der SUBD-Buchse(SPARE) des STK500 und die UART-Ausgänge des Boards (RX&TX) mit den UART-Eingängen des Mikrocontrollers verbunden. Dann wollte ich dem Controller mit meinem Terminal die Werte für die entsprechenden Servostellen schicken. Hat leider nicht hingehauen. Der Servo dreht sofort bis Anschlag links und das wars. Wird wohl daran liegen, dass das Programm für einen Takt mit 8MHz geschrieben ist und der interne maximal 3,69MHZ beträgt. Ob High oder Low Pegel anliegt, kann ich schwer sagen da ich leider kein Oszi hab. Mit nem normalen Messgerät geht das nicht oder? Bin jetzt gerade dabei das Programm auf meinen Takt umzuschreiben. Da ich dass zum ersten mal mache wird das wohl noch ein wenig dauern. Für Tipps und Ratschläge wäre ich echt dankbar....!!! Gruß
"Der Mikrocontroller läuft nicht wie oben beschrieben mit einem externen Quarz, sondern mit dem internen Oszillator" Wenn du mit dem internen Oszillator arbeitest wirst du höchstwahrscheinlich keine seriellen Daten zwischen µC und PC austauschen können (interner Oszillator ist zu ungenau). Gruß, Magnetus
Nur mal so zum Schaun, wie man Servos ansteuern kann: http://www.hanneslux.de/avr/mobau/7ksend/7ksend02.html Ist allerdings ohne serielle Schnittstelle zum PC, dafür mit Steuerknüppeln und Tastern. ...
Die Ansteuerung eines Servos ist eigentlich recht einfach. Du muß einen Impuls generieren der 1-2ms auf High liegt und dann 18ms auf Low. 1ms entspricht der einen Endlage 1,5ms Mitte und 2ms die andere Endlage. Ich habe in Assembler ein Programm geschrieben das 32 Servos gleichzeitig ansteuern kann.
> Die Ansteuerung eines Servos ist eigentlich recht einfach. Schwieriger wird's da schon, wenn man mehrere Servosignale von einem Empfänger einlesen und gleichzeitig welche generieren will. Ich überlege mir gerade, wie ich mit einem AVR einen Servomischer mit jeweils fünf Ein- und Ausgängen so hinbekomme, dass er jitterfrei ist.
Die Generierung der Servosignale ist nur im Bereich der 1-2ms zeitkritisch. In der Pause von 18ms kann der Prozessor so ziemlich alles machen (bei mir die Dekodierung des DCC Signals). Die Pause kann auch mal verlängert werden ohne das der Impuls darunter leidet.
> Die Generierung der Servosignale ist nur im Bereich der 1-2ms > zeitkritisch. Da ist überhaupt nichts zeitkritisch, denn das Generieren der Impulse kann ein Timer "nebenher" machen. Zwischen den Timer-Interrupts steht dann mindestens eine Millisekunde Rechenzeit (das sind bei 1MHz 1000 Takte!!) für andere Aufgaben zur Verfügung. Man sollte beim Programmieren nur keine Scheu vor Interrupts haben. ...
Das ist richtig wenn du nur einen Servo steuern willst. In meinem Programm werden aber 32 Servos gleichzig mit völlig unterschiedlichen Werten gesteuert. Den ersten Teil von 1ms übernimmt bei mir auch ein Timer der variable Teil ist aber der zeitkritische Teil weil da ein Zähler läuft und je nach Zählerstand dann die einzelnen Servoimpulse beendet werden. Die reine Impulsausgabe benötigt ungefähr 5% Rechenleistung bei 8MHz Takt. Der Rest ist frei verfügbar.
@Jürgen: Da üblicherweise die Servoimpulse mehrerer Kanäle nacheinander übertragen werden, kann ein Timer mehrere Impulse generieren. Will man sich dabei an die Vorgabe 20ms Wiederholrate halten, dann bekommt man (knapp) 10 Kanäle in einem Timer-Kanal unter. Erhöht man den Wiederholabstand geringfügig, so schafft ein Timerkanal 11 Servokanäle. Die dafür in Frage kommenden 40-poligen AVRs haben alle mindestens Timer0 und Timer1. Timer1 hat zwei Compare-Einheiten, jede dieser Compare-Einheit kann dann 11 Servokanäle generieren. Timer0 kann über Überlauf-Interrupt weitere 11 Servokanäle generieren. Mit dem (meist auch vorhandenem) Timer2 kann man die 23ms generieren, die die Impulserzeugung wieder "anschubsen". Alternativ lässt man jede der 3 Gruppen einfach im Kreis laufen, dann ist die Wiederholrate eben nicht konstant, sondern variiert mit der Summe aller Kanalimpulse einer Gruppe. Da Timer1 aufgrund der Nutzung beider Compare-Interrupts frei durch läuft (nie im Zählerstand manipuliert wird), kann man mit dem Input-Capture-Interrupt auch noch ein Impulstelegramm von einem RC-Empfänger (das Demodulator-Signal, das alle Kanalimpulse enthält) einlesen und hat bei Bedarf im Hauptprogramm noch genügend Zeit, daraus die Servopositionen der zu generierenden Impulse zu errechnen. Denn die gesamte Impulserzeugung läuft im Interrupt und bremst das Programm nicht aus. Ich denke mal, dass das Erzeugen deiner 32 Servoimpulse im Interrupt weniger als 20% Rechenzeit eines mit 1MHz laufenden ATMegas benötigt und der AVR die restliche Zeit rechnen oder pennen kann. ...
> Da Timer1 aufgrund der Nutzung beider Compare-Interrupts frei > durch läuft (nie im Zählerstand manipuliert wird), kann man mit > dem Input-Capture-Interrupt auch noch ein Impulstelegramm von > einem RC-Empfänger (das Demodulator-Signal, das alle Kanalimpulse > enthält) einlesen Dazu muss man aber entweder den Empfänger modifizieren oder alle Pins mit einem Oder zusammenschalten (und hoffen, dass der Empfänger die Signale auch tatsächlich noch so ausgibt, wie man's erwartet - bei welchen mit Prozessor kann's auch anders sein). Außerdem muss man ja irgendwann auch auf das Input-Capture-Signal reagieren. Der Timer-Wert wird zwar automatisch in das Capture-Register geladan, aber irgendwann muss man den auch mal woanders hinschreiben. Wenn ich dazu aber den Input-Capture-Interrupt verwende, kann der wieder die Output-Compare-Interrupts verzögern und damit wieder Jitter auslösen.
> Wenn ich dazu aber den Input-Capture-Interrupt verwende, kann der > wieder die Output-Compare-Interrupts verzögern und damit wieder > Jitter auslösen. Diese paar Takte dürften den Kohl nicht fett machen. Natürlich sollte man keine ellenlangen Routinen in der ISR ausführen. Es ist ja nur die Differenz zum Timerstand des letzten ICP-Interrupts zu bilden und zu sichern (SRAM über Pointer), sowie der neue Timestamp zu sichern (Register). Es ist nichtmal eine Flankenumschaltung vorzunehmen, da ja der Impulsabstand relevant ist und daher immer auf dieselbe Flanke getriggert werden kann. Das Aufarbeiten der Werte geschieht dann in der Mainloop. > Dazu muss man aber entweder den Empfänger modifizieren oder alle > Pins > mit einem Oder zusammenschalten (und hoffen, dass der Empfänger die > Signale auch tatsächlich noch so ausgibt, wie man's erwartet - bei > welchen mit Prozessor kann's auch anders sein). Gut, das geht nicht bei allen Empfängern. Einige Empfänger haben dieses Signal aber an der Stromversorgungsbuchse anliegen. Man kann aber auch die einzelnen Kanäle mittels RC-Differenziergliedern und ODER-IC zusammenfassen, so dass Nadelimpulse im Kanalimpulsabstand entstehen, die dann per ICP ausgewertet werden. Wer sich Anlagen mit Prozessor kauft, muss natürlich damit rechnen, dass sie nicht mehr der bisher üblichen Norm entsprechen und dass er sie nicht (so leicht) für andere Zwecke missbrauchen kann. Mir ging es mit meinem Beitrag aber nur darum, zu zeigen, dass man Servoimpulse (auch viele davon) recht effizient in Timer-Interrupts erzeugen kann und nicht auf Warteschleifen im Hauptprogramm angewiesen ist. ...
>> Wenn ich dazu aber den Input-Capture-Interrupt verwende, kann der >> wieder die Output-Compare-Interrupts verzögern und damit wieder >> Jitter auslösen. > > Diese paar Takte dürften den Kohl nicht fett machen. Naja, der Sprung in den Interrupt-Vektor beim Auftreten eines Interrupts braucht schon mal 5 Taktzyklen. Falls gerade ein Befehl ausgefuehrt wird, der mehrere Taktzyklen braucht, wird der zuerst zuende abgearbeitet. Bei einem call oder ret waeren das je nach Controller (Flash kleiner oder groesser als 64k) 4 oder 5 Taktzyklen. Im Unguenstigsten Fall (Interrupt nach dem ersten Taktzyklus eines call) kommen also nochmal 4 dazu. Im Interrupt-Vektor steht dann ein rjmp, der nochmal 2 Taktzyklen braucht. Am Ende der Interrupt-Routine kommt ein reti dazu mit 5 Taktzyklen. Insgesamt haben wir damit bis zu 16 Taktzyklen, ohne ueberhaupt irgendwas gemacht zu haben. > Es ist ja nur die Differenz zum Timerstand des letzten > ICP-Interrupts zu bilden und zu sichern (SRAM über Pointer), Dazu braucht man Register, die vorher gesichert werden muessen und nachher wieder zurueckgeholt. Pro Register 4 Taktzyklen. Zum Differenz bilden muss man noch das SREG sichern und wiederherstellen, macht 6 Taktzyklen. Selbst, wenn man sehr minimalistisch im Interrupt arbetitet, ist man ruckzuck bei 30 Taktzyklen, was schon fast vier Mikrosekunden sind. Um soviel kann sich dann die OCR-Interrupt-Routine und damit die Pulsausgabe verzoegern. Man koennte hoechstens die Interrupts in der Input-Capture-Routine gleich am Anfang wieder freischalten, um das zu minimieren. Das koennte aber zu Stackueberlaeufen fuehren, wenn am Eingang mal nur Rauschen ankommt. > sowie der neue Timestamp zu sichern (Register). ok, das geht in nur einem Taktzyklus. > Es ist nichtmal eine Flankenumschaltung vorzunehmen, da ja > der Impulsabstand relevant ist und daher immer auf dieselbe Flanke > getriggert werden kann. Relevant ist die Differenz zwischen steigender und fallender Flanke. > Das Aufarbeiten der Werte geschieht dann in der Mainloop. Dazu muss man aber zumindest irgenwdo mitzaehlen, welcher Impuls zu welchem Kanal gehoert. Eine Sychronisation braucht man auch, um sicherzustellen, dass nicht mal versehentlich ein Impuls verlorgengegangen ist. > Einige Empfänger haben dieses Signal aber an der > Stromversorgungsbuchse anliegen. Hmm, das wusste ich nicht. Allerdings hat von denen, die ich hier habe, kaum einer eine solche Buchse. Die Stromversorgung geschieht ueber einen der Servoausgaenge. > Mir ging es mit meinem Beitrag aber nur darum, zu zeigen, dass man > Servoimpulse (auch viele davon) recht effizient in > Timer-Interrupts erzeugen kann und nicht auf Warteschleifen im > Hauptprogramm angewiesen ist. Ja klar, das geht sicherlich auch prima. Nur will ich mir halt einen Servomischer bauen, und dazu muss man eben auch parallel zum Ausgeben noch einlesen.
> Selbst, wenn man sehr minimalistisch im Interrupt arbetitet, ist > man ruckzuck bei 30 Taktzyklen, was ... bei einem Takt von 8 Mhz ... > schon fast vier Mikrosekunden sind.
> Nur will ich mir halt einen > Servomischer bauen, und dazu muss man eben auch parallel zum > Ausgeben noch einlesen. Sorry, aber ich vermute, dass dieses Vorhaben ohne Verwendung von Interrupts schwieriger zu realisieren ist und sicherlich auch mehr Jitter aufweist. ...
Da werde ich meine Idee eines Servo-Mischers wohl doch mal realisieren
müssen...
Mal sehen, ob mein futaba-Empfänger auch die Signale am
Batterie-Anschluß "preisgibt".
Bis jetzt kam es bei meinen Servo-Anwendungen noch nie zu einem Jitter
- liegt vermutlich daran, dass ich von Anfang an mit Interrupts
gearbeitet habe, und den neuen Wert für die Servo-Ausgabe erst nach der
Ausgabe des momentanen Telegramms aktualisiert habe.
> schon fast vier Mikrosekunden sind.
Das klingt fast nach "Eins Punkt Einundzwanzig Gigawatt!"...
Wie hoch soll denn die Auflösung sein?
4 Mikrosekunden liegen vermutlich unter der Auflösung des
Servo...(Unbewiesene Behauptung meinerseits)
@Daniel:
Für die Verwendung der seriellen Schnittstelle in Verbindung mit einem
PC bieten sich Baudraten-kompatible Frequenzen an; 3,686MHz gehört
dazu.
Hast du schon mal die Übertragungsfunktion alleine zum Laufen
bekommen?
Ich baue meine Programme meist modular auf, so dass ich z.B. einen
Block mit der Servo-Impuls-Erzeugung und einen Block mit der
UART-Kommuniktation habe. Wenn beides einzeln funktioniert, sollte es
in der Regel auch zusammen arbeiten...
Hi, wie wäre es denn, alle Impulsausgänge der jeweiligen Kanäle über jeweils eine Diode zusammenzufassen? Das müßte doch das komplette Kanal-Impulsdiagramm ergeben, oder? Gruß Fred
Das würde auch gehen. Wenn man aber das Signal vor dem Ausgangsdecoder (CD4017 oder so bei den meisten älteren Empfängern) bekommt, kann man sich die Dioden und das Zusammenfassen sparen. Ich verfolge noch einen anderen Ansatz, und werde berichten, wenn es funktioniert.
@HanneS > Sorry, aber ich vermute, dass dieses Vorhaben ohne Verwendung von > Interrupts schwieriger zu realisieren ist und sicherlich auch mehr > Jitter aufweist. Vielleicht hat man eine Chance, wenn man ausgagsseitig mit Interrupts arbeitet und eingangsseitig nicht, denn dann werden die OC-Interrupts nicht mehr durch andere verzoegert und man hat zumindest ausgangsseitig den Jitter soweit wie moeglich minimiert. Das Eingangssignal kann man dan noch nachbearbeiten (z.B. filtern). So richtig gefallen will mir das aber auch nicht. >> schon fast vier Mikrosekunden sind. > Das klingt fast nach "Eins Punkt Einundzwanzig Gigawatt!"... > Wie hoch soll denn die Auflösung sein? > 4 Mikrosekunden liegen vermutlich unter der Auflösung des > Servo...(Unbewiesene Behauptung meinerseits) Vermutlich eher nicht. Analogservos haben keine Aufloesung in dem Sinne und Digitalservos haben meines Wissens zwischen 1024 und 4096 Schritten, was deutlich kleinere Schritte als als 4 Mikrosekunden sind. Ausserdem verdoppelt sich der Jitter noch, denn es kann ja sowohl die steigende Flanke verzoegert werden (Puls 4 Mikrosekunden zu kurz) als auch die fallende (Puls 4 Mikrosekunden zu lang). Dann ist der Jitter immerhin schon etwa 1/125 des Gesamtwegs des Servos. Welche Aufloesung ich haben will, ist dabei eigentlich gar nicht so wichtig, denn der Jitter ist trotzdem da.
Ich hatte auch schon daran gedacht, das Problem ganz zu umgehen, indem ich zwei Prozessoren verwende, von denen einer die Signale einliest, die Mischerberechnungen macht und dann per SPI an den zweiten weitergibt, der dann nur noch die Servopulse generiert.
Noch was zu ICP: Bei ICP wird der Timer-Wert ins ICP-Register geschrieben und bleibt dort solange, bis er von einem weiteren ICP-Ereignis (oder manuell) überschrieben wird. Somit ist es irrelevant, wann innerhalb der 1-2ms das ICP-Register abgefragt wird. Bei 4-5 Servo-Signalen sollte es wirklich keine Probleme geben, wenn man die Signale der Reihe nach ausgibt.
> Somit ist es irrelevant, wann innerhalb der 1-2ms das ICP-Register > abgefragt wird. Natuerlich. Aber dennoch muss es dann irgendwann mal abgefragt werden. Man muss also entweder doch einen Interrupt verwenden oder in einer Warteschleife auf das ICP-Ereignis warten. Ich will auch nicht sagen, dass es nicht geht, sondern nur, dass es nicht so einfach ist, wie man auf den ersten Blick vielleicht denkt.
Rolf, wer hindert dich denn daran, auf den ICP-Interrupt zu verzichten und stattdessen das ICP-Interrupt-Flag per Software in der Mainloop abzufragen? Dann hat dein OC-Interrupt für die Kanalimpulserzeugung (wieviele Kanäle willst du erzeugen?) immer freie Bahn. In der Mainloop fragst du dann das ICP-Flag ab und übernimmst den jeweils neuen Wert, prüfst ihn auf Impulsbreite (dabei nebenbei die Synchronpause erkennen) und legst ihn über Pointer aufs RAM. Da der Pointer ja mitzählt, kannst du ihn zur Ende-Kennung nutzen und hast in der Synchronpause genug Zeit, deine Impulsbreiten durchzuwürfeln und neu zu sortieren (mixen). Danach gehts wieder in die Abfrageschleife. Sicher geht das auch ohne die ICP-Hardware (Flag und Register) durch direkte Portabfrage und Auslesen des Timerstandes, aber mit der ICP-Funktionalität dürften die eingelesenen Werte genauer (jitterfreier) sein. Übrigens haben meine Programme zur Auswertung von Servoimpulsen alle eine Hysterese zur Unterdrückung des Jitters. Ansonsten sind sie aber sicherlich nicht optimal programmiert, denn es sind Anfängerprojekte. Sie tun aber ihre Arbeit, weshalb sie nicht nochmal optimiert (dem heutigen Wissen angepasst) werden. Bit- & Bytebruch... ...HanneS... (...nur echt mit Pünktchen und ohne WM...)
> Rolf, wer hindert dich denn daran, auf den ICP-Interrupt zu > verzichten und stattdessen das ICP-Interrupt-Flag per Software in > der Mainloop abzufragen? Keiner. Das meinte ich doch mit "oder in einer Warteschleife auf das ICP-Ereignis warten." Das scheint mir bisher auch die beste Loesung zu sein. > Dann hat dein OC-Interrupt für die Kanalimpulserzeugung (wieviele > Kanäle willst du erzeugen?) immer freie Bahn. Im aktuellen Fall 5 Kanaele, spaeter dann aber auch mehr. > In der Mainloop fragst du dann das ICP-Flag ab und übernimmst den > jeweils neuen Wert, prüfst ihn auf Impulsbreite (dabei nebenbei > die Synchronpause erkennen) und legst ihn über Pointer aufs RAM. Wie lang ist die Synchronpause denn eigentlich mindestens? > Sicher geht das auch ohne die ICP-Hardware (Flag und Register) > durch direkte Portabfrage und Auslesen des Timerstandes, aber mit > der ICP-Funktionalität dürften die eingelesenen Werte genauer > (jitterfreier) sein. Ja, das denke ich auch.
> Wie lang ist die Synchronpause denn eigentlich mindestens? Eigentlich 20ms minus Summe aller Kanalimpulse. Vor 30 Jahren, als Kanalimpulserzeugung/Auswertung mit NE555 noch als Innovation galt, reservierte man mindestens 4...5ms für die Synchronpause, die ja mittels RC-Glied erkannt werden musste. Heute, im digitalen Zeitalter, ist das einfacher, da kann man zählen, ist der Impulsabstand größer als der maximal erlaubte Kanalimpuls, dann war es halt die Synchronpause. Zusätzlich prüfe ich meist auch noch den Telegrammabstand... ...
>> Wie lang ist die Synchronpause denn eigentlich mindestens? > > Eigentlich 20ms minus Summe aller Kanalimpulse. Aber zwischen den Kanaelen muss doch auch noch eine Pause sein. Wie sieht das Impulstelegramm denn nun eigentlich exakt aus? Ich hab das so verstanden, dass zwischen zwei Impulsen immer eine einigermassen konstant lange Pause ist. Am Ende ergibt sich eine Synchronisationspause mit variabler Laenge (je nach Summe der Impulslaengen).
Das Impulstelegramm für den Sender besteht aus Impulsen von 0,5ms Breite, deren Abstand die Kanalimpulsinformation enthalten. Beim Decodieren (vor 30 Jahren per Schieberegister) wird immer die gleiche Flanke (eigentlich egal ob steigend oder fallend) genutzt um den aktuellen Kanalimpuls zu deaktivieren und den nächsten Kanalimpuls zu aktivieren. Zwischen den einzelnen (decodierten) Kanalimpulsen ist also keine Pause. Die Pause ist nur im Mixed-Signal vorhanden, da dort die Impulse nur 0,5ms breit sind, die Information steckt ja nicht in der Impulsbreite, sondern im Flankenabstand. Deine Frage suggeriert mir aber, dass du dir den oben angegebenen Link nicht oder nicht richtig angeschaut hast. Dort wird nämlich das gesamte Impulstelegramm und die einzelnen Servoimpulse generiert. 8-) ...
> Beim Decodieren (vor 30 Jahren per Schieberegister) Ich habe einen ca 3 Jahre alten Empfaenger, der das immer noch so macht. > wird immer die gleiche Flanke (eigentlich egal ob steigend oder > fallend) genutzt um den aktuellen Kanalimpuls zu deaktivieren und > den nächsten Kanalimpuls zu aktivieren. Zwischen den einzelnen > (decodierten) Kanalimpulsen ist also keine Pause. Ach so. Ich meine, irgendwo mal eine Beschreibung gesehen zu haben, nach der das anders aussieht. Das bedeutet dann auch, dass man nicht so einfach alle Empfaengerausgaenge verODERn kann, um wieder das Impulstelegramm zu erhalten. Man muss schon das Original-Impulstelegramm nehmen oder auf kompliziertere Art wieder rekonstruieren, wenn man am Mikrocontroller mit nur einem Eingang (eben ICP in dem Fall) arbeiten will. > Die Pause ist nur im Mixed-Signal vorhanden, da dort die Impulse > nur 0,5ms breit sind, die Information steckt ja nicht in der > Impulsbreite, sondern im Flankenabstand. Das war mir nicht klar. > Deine Frage suggeriert mir aber, dass du dir den oben angegebenen > Link nicht oder nicht richtig angeschaut hast. "nicht richtig" trifft es wohl. Danke jedenfalls. das hat mir doch einiges an Klarheit verschafft.
Kann es sein, dass kein Modellbau-Empfänger-Hersteller alle Informationen zu seinen Empfängern rausgibt? Ich finde keine Angaben zum "kanalstream-Ausgang" meines Robbe-Empfängers. Dafür schädige ich die Jungs aber dadurch, dass ich die Signale der Multi-Switch und Multi-Prop-Module auswerten kann - Keine >60Euro für son Decoder mehr ausgeben...
> Ich finde keine Angaben zum "kanalstream-Ausgang" meines > Robbe-Empfängers. Außer der Tatsache, daß es ihn gibt, dürfte es auch nicht viel dazu zu sagen geben. Mittlerweile tendiere ich doch zu der Zweiprozessorlösung. So ein Tiny2313 kostet nicht die Welt, und die Timingprobleme sind weg. Außerdem kann ich einfach alle Kanäle einzeln aus dem Empfänger lesen und muß ihn daher nicht modifizieren. Ich glaube, keiner meiner Empfänger führt das Impulstelegramm schon ab Werk nach außen. Ich hab eigentlich keine Lust, immer erst am Empfänger rumbasteln zu müssen, um mal den Mischer dran anschließen zu können.
Übrigens: Selbst die heutigen Modellbauempfänger (die, die "nix" kosten) funktionieren noch genau so. Ich wollte meinen mal demnächst mal mit meinem Oszilloskop nach diesem "Impulstelegramm" untersuchen.
>Außer der Tatsache, daß es ihn gibt, dürfte es auch nicht viel dazu >zu
sagen geben.
Gibt es ihn wirklich? Wenn ja, wo? Und wie kann ich ihn belasten?
Früher gab es ein DSC-Kabel (oder so ähnlich), das eine direkte
Verbindung zwischen Sender und Empfänger herstellte, ohne dass man
funken musste (HF-Modul musste ausgebaut werden).
Hat das was miteinander zu tun? Gibt's das noch?
Angehängte Dateien:
-
empfaenger_1.JPG
170 KB
Ok. Hier die Auflösung: Auf dem Bild sieht man einen 40MHz Empfänger von SANWA (SRC-2322RS). Auf der Rückseite ist ein SO14 IC zu sehen. Die Bezeichnung ist leider vom Hersteller heruntergeschliffen worden. Die Pin1 Markierung war aber noch zu sehen. -Pins mit ? haben irgndein komisches Signal ausgegeben, dass ich auf die Schnelle nicht zuordnen konnte. -Pins ohne Namen haben Low-Pegel geliefert (Bei Pin 14 hab ich einfach mal GND drangeschrieben, weils ja meistens so ist) -IT (=Impulstelegramm) ist zweimal wiederzufinden. Ich vermute, dass das "IT" auf der rechten Seite (vom Betrachter aus gesehen) ein Carry Ausgang ist. Hier ist, soweit ich das sehen kann, auch nichts angeschlossen.
Angehängte Dateien:
-
IT.jpg
580 KB
Oszillogramm des Impulstelegramms (sollte ja nix spannendes sein), wenn alle Regler in Neutralstellung stehen.
Angehängte Dateien:
-
K.jpg
520 KB
Irgndein Kanal, nicht invertiert. Neutralstellung (PS: Am Chip werden zwei der drei Kanäle invertiert, und nicht invertiert herausgeführt. Merkwürdig ist, dass Kanal 1 die erste Flanke des Impulstelegramms ist und Kanal 2, die dritte Flanke des ITs. Die zweite Flanke ist immer in Neutralstellung: ton = 1,5ms)
Und dazu kommt noch das hier: (Versehentlich falsch gepostet) http://www.mikrocontroller.net/forum/read-1-376637.html?reload=yes#376941 Ist einfach zu warm hier im Zimmer (33°C). Ich glaub ich geh mal wo anders hin.
> Gibt es ihn wirklich? Wenn ja, wo? Und wie kann ich ihn belasten?
Sorry, hatte mich unglücklih ausgedrückt. Ich meinte, falls es ihn
gibt, ist außer dieser Tatsache nicht viel zu sagen.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.