Hallo Leute, habe mir für einen Tiny24 ein kleines Programm geschrieben (s. Anhang), das 6 Kanäle eines Modellbau-Empfängers einlesen soll, und dann ein RC Summensignal ausgeben soll. Mir ist bewusst, dass sich schon diverser Code im Forum dazu findet, aber leider scheint mein Programm nicht zu funktionieren. Wäre nett wenn daher mal jemand drüber schaut, ist ja nicht umfangreich. Der Tiny läuft mit 8Mhz internem RC Oszillator. Die "Eingänge" A0 bis A5 sind mit 330 Ohm an jeweils 1Kanal angeschlossen, und mit 10 kOhm Pull-down versehen. Der Ausgang für das Summensignal ist PB0. Für konstive Verbesserungen schonmal danke im vorraus. MfG Christian
C. S. schrieb: > Für konstive Verbesserungen schonmal danke im vorraus. Ehe ich da jetzt ins Programm einsteige: RC-Fernsteuerungen sind normalerweise so gestrickt, dass sich das RC-Summensignal ergibt, indem man die einzelnen Servosignale ganz einfach miteinander verodert. Das Summensignal ist das Signal welches über die Funkstrecke geht. D.h da müssen die Servopulse im Gänsemarsch hintereinander kommen. Im Empfänger wird dann überhaupt kein Aufwand getrieben um alle Servopulse zum gleichen Zeitpunkt beginnen zu lassen. Das Summensignal wird einfach nur reihum auf die einzelnen Servokanäle ausgegeben. Das Weiterschalten auf den nächsten Kanal wird vom Summensignal selbst gesteuert, indem die nächste Flanke den Empfängerinternden Zähler für den Demultiplexer um 1 weiterschaltet. D.h. sieht man sich die Servopulse an den Ausgängen der einzelnen Kanälen in Relation zueinander an, so sehen die so aus: Signal +----+ +----+ +--------+ +--+ vom | | | | | | | | Funk ---+ +-+ +-+ +-+ +---------------- +----+ Kanal 1 | | ---+ +--------------------------------------- +----+ Kanal 2 | | ----------+ +-------------------------------- +--------+ Kanal 3 | | -----------------+ +--------------------- +--+ Kanal 4 | | ----------------------------+ +---------------- Auf jedem Kanal wiederholt sich der Puls alle 20 Millisekunden aber die Pulse sind zueinander versetzt. Der Grund dafür ist: Es gibt keinen Grund allen Servos einen Signalpuls anzubieten, der bei allen Servos gleichzeitig die steigende Flanke aufweist. Da das nicht notwendig ist, muss man auch den ganzen Aufwand dafür nicht treiben. Da man den Aufwand nicht treiben muss, ist die Aufteilung des Summensignals auf die einzelnen Kanäle trivial Trivial ist gut, da es dann zuverlässig läuft. Um also diese 4 Kanäle wieder zu einem Summensignal zusammenzubringen, genügt es völlig die einfach alle miteinander zu verodern und man erhält ... +----+ +----+ +--------+ +--+ | | | | | | | | ---+ +-+ +-+ +-+ +---------------- ... das Summensignal (in genau der Form, wie es über die Funkstrecke übertragen wurde) Ehe du also weiter Aufwand treibst, würde ich mein Glück mal in diese Richtung versuchen.
Edit: Ich vergass zu erwähnen, das ist was bei der klassichen Fernsteuertechnik PPM passiert. PCM funktioniert anders.
Hallo Karl Heinz, vielen Dank erstmal für deine ausführliche Antwort!!! ich dachte das RC Summensignal ist sowas: http://thomaspfeifer.net/ppm2usb_adapter.htm_2.jpg ?? Also die Zeit (1-2ms) zwischen den steigenden Flanken ist ein Maß für die Stickposition (dachte ich). Desswegen mein "Aufwand". Karl heinz Buchegger schrieb: > Um also diese 4 Kanäle wieder zu einem Summensignal zusammenzubringen, > genügt es völlig die einfach alle miteinander zu verodern und man erhält tatsächlich... Dann wäre ja folgendes Produkt komplette Abzocke: https://www.mikrocontroller.com/index.php?main_page=product_info&products_id=371 ?? Dann bin ich wohl wirklich ein wenig in die falsche Richtung gedriftet ;) Danke nochmal MfG
C. S. schrieb: > ich dachte das RC Summensignal ist sowas: > http://thomaspfeifer.net/ppm2usb_adapter.htm_2.jpg > ?? Ist es ja auch. > Also die Zeit (1-2ms) zwischen den steigenden Flanken ist ein Maß für > die Stickposition (dachte ich). Auch richtig. > Desswegen mein "Aufwand". Du übersiehst, dass du vom Empfänger ja schon die Einzelsignale für einzelnen Kanäle fix fertig bekommst. Du musst sie nur zusammensetzen.
C. S. schrieb: > tatsächlich... Dann wäre ja folgendes Produkt komplette Abzocke: > https://www.mikrocontroller.com/index.php?main_page=product_info&products_id=371 > ?? Ist es nicht. Wie gesagt: Bei PCM Anlagen sieht die Sache anders aus. Und im Kleingedruckten steht dort ja auch: Bei PCM Anlagen .... > Dann bin ich wohl wirklich ein wenig in die falsche Richtung gedriftet Welche Anlage hast du denn? Die Mehrzahl der Fernsteuerungen auf dem Markt sind immer noch PPM. Erst wenn dezidiert PCM auf dem Sender steht (das ist ein Marktinginstrument für die Firmen, steht also mit Sicherheit drauf) bzw. wenn es sich um eine der neuen 2.4Ghz Anlagen handelt, funktioniert die Generierung des Summensignals nicht mehr so einfach.
Hi,
wie ist es denn bei PCM, sind da die Servoimpulse am Empfänger dann
synchron zueinander?
> tatsächlich... Dann wäre ja folgendes Produkt komplette Abzocke:
Wenn die Impulse für die Servos synchron wären, dann wäre das Teil sogar
noch sinnvoll;)))
Und wenn du dich nicht scheust den Empfänger zu öffnen, vor den
Ausgängen ist ein Multischalter-IC, dieses bekommt das summierte Signal,
man könnte es dort abgreifen.
Gruß Simon
Karl heinz Buchegger schrieb: > Du übersiehst, dass du vom Empfänger ja schon die Einzelsignale für > einzelnen Kanäle fix fertig bekommst. Du musst sie nur zusammensetzen. oder direkt im Empfänger abgreifen. Kommt ja als Summe schon so rein.
Karl heinz Buchegger schrieb: > RC-Fernsteuerungen sind normalerweise so gestrickt, dass sich das > RC-Summensignal ergibt, indem man die einzelnen Servosignale ganz > einfach miteinander verodert. Dass stimd leider so nicht umbedingt. So haben nur die alten Analoganlagen gearbeitet. Bei den neueren Anlagen ist die Pause zwischen den Signalen, die ausgegeben wird zu kurz. Da würde ein Zusammenführen über einen Oder-Baustein oder über Dioden nur ein langes Signal ergeben. Die Pausen werden dabei verschluckt. Dass musste ich leider bei meiner Anlage feststellen. Die neuen 2g4 Anlagen sind da noch komplizierter. Die starten bei mehreren Kanälen gleichzeitig das Signal. Bei der Graupner mx16 iFS kommen zum Beispiel alle 8 Kanäle gleichzeitig daher. Wenn man eine Analoge Anlage verwendet, kann man am Empfänger ganz einfach das Summensignal abgreifen, bevor es vom Prozessor verarbeitet wird. Anleitungen dazu findet man unter anderem hier: http://www.mikrokopter.de/ucwiki/KategorieEmpf%C3%A4nger Es gibt aber auch schon Empfänger die von sich aus Summensignal ausgeben. Wenn man nicht umbaun will oder eine Digitalanlage hat, kann man auch schon fertige Wandler kaufen. Unter angerem hier: https://www.mikrocontroller.com/index.php?main_page=product_info&cPath=76&products_id=371&zenid=8cca3aaf616bbe498c8b3531fbd784e3 http://tt-rc.ath.cx/SHOP/ITEM-10
Karl heinz Buchegger schrieb: > C. S. schrieb: > >> ich dachte das RC Summensignal ist sowas: >> http://thomaspfeifer.net/ppm2usb_adapter.htm_2.jpg >> ?? > > Ist es ja auch. > >> Also die Zeit (1-2ms) zwischen den steigenden Flanken ist ein Maß für >> die Stickposition (dachte ich). > > Auch richtig. jetzt bin ich verwirrt. bei deinem Beispiel eines Summensignals oben war doch die Zeit zwischen steigender und fallender Flanke ein Maß für die Stickposition. In dem gezeigten Beispiel ist diese Zeit immer konstant (ca 0,3ms), aber nicht die Zeit zwischen 2 auf einanderfolgenden steigenden Flanken. Als Sender verwende ich: http://www.helibude.de/epages/61385467.sf/de_DE/?ObjectPath=/Shops/61385467/Products/EK2-0406J Empfänger: http://www.helibude.de/epages/61385467.sf/de_DE/?ObjectPath=/Shops/61385467/Products/EK2-0424
C. S. schrieb: > In dem gezeigten Beispiel ist diese Zeit immer konstant (ca 0,3ms), aber > nicht die Zeit zwischen 2 auf einanderfolgenden steigenden Flanken. Das ist dasselbe Signal, nur invertiert. :-)
Hallo für alte/analoge Emfänger ist das mit einen Tiny sicher problemlos zu machen. Bei modernen (2,4GHz) Emfängern werden die Servoimpulse aber per Software/PWM erzeugt und folgen nicht einem Standardschema. Verschachtelte Impulse und mehrere Impulsflanken zur gleichen Zeit sind durch Software Campturing nicht oder nur eingeschränkt möglich.
C. S. schrieb: > Als Sender verwende ich: > http://www.helibude.de/epages/61385467.sf/de_DE/?ObjectPath=/Shops/61385467/Products/EK2-0406J > Empfänger: > http://www.helibude.de/epages/61385467.sf/de_DE/?ObjectPath=/Shops/61385467/Products/EK2-0424 2.4 Ghz OK. Dann vergiss alles was ich bisher von mir gegeben habe. Da funktioniert alles anders und man muss tatsächlich die Kanäle ausmessen.
Die von mir verlinkten Summensignalwandler funktionieren eigenlich recht anständig bei 2G4 Anlagen. Wobei der Rec-Inc weniger Jitter hat und der Quadro PPM besser geschützt ist. Ich vermute einmal du willst dir einen Quadro-/Multikopter bauen. Hast du schon einmal in diesen Foren vorbeigeschaut: http://www.modellflug-online.at http://www.X-Ufo.de http://forum.mikrokopter.de/ http://www.qc-copter.de/forum/ http://www.armokopter.at/forum/index.php Die beschäftigen sich alle mit Quadrocoptern.
empfangnix schrieb: > Hallo > > für alte/analoge Emfänger ist das mit einen Tiny sicher problemlos zu > machen. Bei modernen (2,4GHz) Emfängern werden die Servoimpulse aber per > Software/PWM erzeugt und folgen nicht einem Standardschema. > Verschachtelte Impulse und mehrere Impulsflanken zur gleichen Zeit sind > durch Software Campturing nicht oder nur eingeschränkt möglich. Du meinst den QuadroPPM? Das ist Unsinn. Gerade dafür ist dieser QuadroPPM ja gemacht. Das "Input Capturing" wird in Software gemacht (Polling) und ist somit parallel auf mehreren Kanälen anwendbar.
ok vielen Dank für alle Antworten. Ich habe meinen Code jetz mal etwas angepasst. Der Code aus dem 1. Post war noch fehlerhaft, da ich das Summensignal invertiert ausgab, sowie die "Pause" zwischen den Pulsen mit zur Pulsdauer eines Kanals dazurechnete. Denke nach der Anpassung passt der Code jetzt. Wäre trotzdem nett wenn jemand mal drüberschauen könnte. Ist jetzt sozusagen ein selbstbau "Quaddroppm" ;) MfG
Wie groß ist denn bei dir der Jitter? (Schwankungen des Signals um den Sollwert.) Ich würde außerdem eine Signalüberwachung einbauen und im Notfall in den Fail-Save Modus gehen. So mach's ich jedenfalls.
das kann ich noch nicht sagen, der Code scheint noch fehlerhaft zu sein. Lasse ich die Fernsteuerung aus, so verwendet der Tiny24 die "Startpulsbreite" von ca 1ms für jeden Kanal und gibt das dazugehörige Summensignal aus. Mein Modell zeigt keine Fehlercodes an. Schalte ich nun die Fernsteuerung ein, und der Tiny soll nun die wahren Pulslängen der einzelnen Kanäle ausmessen und als Summensignal ausgeben, zeigt das Modell Empfangsausfall an. D.h. irgendwo bei der Pulslängenmessung in meinem Code (2Posts weiter oben) müsste ein Fehler stecken... Wäre euch wirklich sehr sehr dankbar wenn sich jemand den Code ansehen würde....!!!! MfG Christian
C. S. schrieb: > Lasse ich die Fernsteuerung aus, so verwendet der Tiny24 die > "Startpulsbreite" von ca 1ms für jeden Kanal und gibt das dazugehörige > Summensignal aus. > Mein Modell zeigt keine Fehlercodes an. > > Schalte ich nun die Fernsteuerung ein, und der Tiny soll nun die wahren > Pulslängen der einzelnen Kanäle ausmessen und als Summensignal ausgeben, > zeigt das Modell Empfangsausfall an. Welches Modell verwendest du? TCC, PCC, Quadro Control, Multicopter,... Manche wollen das Signal speziell formatiert haben. Hast du dir das ausgegebene Signal schon einmal auf dem Oszi angeschaut? Deinen Quellcode muss ich mir genauer anschaun, wei du eine ganz andere Herangehensweise hast wie ich.
Barny schrieb: > Welches Modell verwendest du? Ich verwende die Flight Control 2.0 ME für den Mikrokopter. Barny schrieb: > Hast du dir das ausgegebene Signal schon einmal auf dem Oszi angeschaut? Habe leider keines :-( Barny schrieb: > Deinen Quellcode muss ich mir genauer anschaun, wei du eine ganz andere > Herangehensweise hast wie ich. Wäre dir wirklich sehr dankbar!!!! Und meine Herangehensweise ist evtl auch noch nicht perfekt ;-) MfG
Was mir aufgefallen ist, ist dass du nur 8 Bit Variablen zum Messen der Pulsdauer verwendest. Dass ist verdammt wenig. Ich würde dir raten, 16 Bit Variablen zu verwenden und Timer1 mit 1Mhz laufen zu lassen. Dann entspricht 1ms genau 1000. Soviel ist mir jetzt einmal aufgefallen. Um mehr sagen zu können, muss ich mir dass Programm genauer anschauzn.
Barny schrieb: > Dass ist verdammt wenig. > > Ich würde dir raten, 16 Bit Variablen zu verwenden und Timer1 mit 1Mhz > laufen zu lassen. > Dann entspricht 1ms genau 1000. hmm........., da hast du allerdings recht. Barny schrieb: > Um mehr sagen zu können, muss ich mir dass Programm genauer anschauzn. Das wäre echt nett MfG
Also die Zeit-Stoppfunktion hast du etwas aufwendig gemacht. Ich würde es an deiner Stelle so versuchen: Lasse den Timer 1 mit 1Mhz laufen. Sobald ein PCINT Interrupt kommt, sicherst du dir den aktuellen Wert des Timers. Beim Signalstart speicherst du diesen Wert. Beim Signalende sicherst du du den aktuellen Zählerwert Minus dem Wert, den du beim Signalstart gehabt hast. Dadurch hast du ganz einfach die Signalbreite gestoppt. Wenn du alle Werte in ein Array schreibst, kannst du die Werte dann einfach in einer Schleife ausgeben. Bin ich Blind, oder gibst du keine ordentliche Synchronisationspause nach deinem Datenpaket aus? Dass Summensignal sieht nämlich normalerweise so aus: Signal1, ca 300us Pause, Signal2, ca 300us Pause, Signal3, ca 300us Pause, Signal4, ca 300us Pause, Signal5, ca 300us Pause, Signal6, ca 300us Pause, ca. 6 ms Signal zum Synchronisieren, ca 300us Pause, Nächstes Datenpaket.
1 | ___ ___ ___ ___ ___ ___ _________ |
2 | | 1 |_| 2 |_| 3 |_| 4 |_| 5 |_| 6 |_| Pause |_ |
Diese Synchronisierungspause (ein überlanges Signal) ist normalerweise mindestens 3x so lange wie ein Kanal-Impuls. Und ein wenig Dokunkentation im Quellcode schadet nie. Was das Messen des PPM-Signals angeht. Mit einem Soundblaster-Oszi oder einem anderen uC kannst du es messen und analysieren.
Barny schrieb: > Ich würde es an deiner Stelle so versuchen: > > Lasse den Timer 1 mit 1Mhz laufen. > Sobald ein PCINT Interrupt kommt, sicherst du dir den aktuellen Wert des > Timers. > > Beim Signalstart speicherst du diesen Wert. > Beim Signalende sicherst du du den aktuellen Zählerwert Minus dem Wert, > den du beim Signalstart gehabt hast. Danke für deine Tipps. Habe sie versucht umzusetzten (s. Anhang). Leider funktioniert die Ausgabe des Summensignals immernoch nicht. PB0 bleib dauerhaft LOW. an PB1 ist nur eine "Debugg-LED" angeschlossen ;-) Deine Tipps haben mich schon weiter gebracht, aber könntest du trotzdem nochmal kurz drüber sehen?? habe die Funktion "wait" dazugebastelt, da muss irgendwo der Fehler liegen ;) Vielen Dank!!! MfG
sry hier die überarbeitete Datei, mit deinen Tipps
Meide Divisionen und Multiplikationen im Interupt wie der Teufel das
Weihwasser.
Die Überlaufkompensation brauchst du übrigens nicht.
Rechne einfach einmal Startwert minus Stopwert und überlege was passiert
wenn es einen Timerüberlauf gibt.
>kanal1_overflow*65536
Du multiplizierst einen 8 Bit Wert mit 65536.
Dass ist einfach nur imense Prozessorzeitverschwendung.
Denn Sinnvolles kommt da nicht raus.
Dass funktioniert so nicht.
Da du dass überall drinnen hast, würde ich alles nocheinmal
überarbeiten.
Bedenke dass das eine ziemlich knappe Angelegenheit ist und dass jede
Berechnung dir die Genauigkeit beeinträchtigt.
Aber ohne Möglichkeit zu überprüfen ob dass was da ausgegeben wird
wirklich passt, wirst du dir sehr schwer tun ein Sinnvolles Signal
auszugeben.
Danke Barny für alle deine bisherigen Tipps und deinen Einsatz!!!! Habe mir deine Tipps zu Herzen genommen und nochmal alles überarbeitet. Die "imense Prozessorzeitverschwendung" wollte ich dabei vermeiden. (Berechnungen teils in die main ausgelagert etc.) Jetzt kommen schonmal Pulse am Ausgang an. (Gleichspannungsmessgerät zeigt weder 0V noch 5V) Barny schrieb: > Aber ohne Möglichkeit zu überprüfen ob dass was da ausgegeben wird > wirklich passt, wirst du dir sehr schwer tun ein Sinnvolles Signal > auszugeben. Da hast du auch recht. Barny schrieb: > Was das Messen des PPM-Signals angeht. > Mit einem Soundblaster-Oszi oder einem anderen uC kannst du es messen > und analysieren. Ich werd versuchen das Signal mit nem anderen uC zu analysieren, und erst dann das Programm weiter zu optimieren. MfG
bei Interesse findet sich der aktuelle Stand im Anhang.
Angehängte Dateien:
-
summensignal_startstellung.PNG
3,6 KB -
summensignal_maximalgas.PNG
3,8 KB
Hallo an Alle ;) das Programm zum Erzeugen eines Summensignals aus den 6 Kanälen eines Modellbau-Empfängers funktioniert nun!!!! Habe noch Testaufnahmen mit "AudioTester 0.30" gemacht (s. Anhang). Zu beachten ist , dass das Signal invertiert dargestellt wird ;) Die Pulslängen passen gut mit der Stickposition überein. Es wäre nett, ob jemand das Programm kurz überfliegen könnte, um evtl immernoch vorhandene "imense Prozessorzeitverschwendung" zu entlarfen. Habe mir allerdings beste Mühe gegeben. Wäre froh über ein Feedback von euch, da dies mein erstes "aufwändigeres" Programm ist. Immerhin ist der Flash des Tiny24 nahezu randvoll :-) MfG Christian
Hallo, habe nun noch ein Problem erkannt. Die gemessenen Kanaldaten aus obigen Programm schwanken unangenehm stark (ca. 10%), sodass eine feinfühlige Regelung eines Modells nicht möglich ist. Barny schrieb: > Wie groß ist denn bei dir der Jitter? zu hoch!! wie könnte ich diesen minimieren??? Wäre dankbar für jeden Tipp MfG Christian
Futaba specify:
* Centre: 1.52ms
* 100% ATV: 1.52+/-0.43ms
* 140% ATV: 1.52+/-0.60ms (Max)
JR specify:
* Centre: 1.50ms
* 100% ATV: 1.5+/-0.40ms
* 150% ATV: 1.5+/-0.60ms (Max)
Hatte gerne auch 8µS als Referenz genommen, bzw als vielfachen mit einem
Offset für Servosteuerungen (0.5-2.5ms Pulse length ca).
Konkret dürfte ein analoges Servo 64 mögliche Positionen ansteuern
können.
Wenn du 16µS für eine Einheit nimmst, dann kannst du damit 1mS abdecken,
eventuell auch mit offset, ich spreche hier nur für die effectiv
variable Servopulsdauer, aber wenn du vielfaches von 16µS nimmst, und
zusätzlich
die Werte filters, z.B. Mittelwert von 3 Werten, dann dürftest du keinen
Jitter mehr haben.
C. S. schrieb: > Barny schrieb: >> Wie groß ist denn bei dir der Jitter? > > zu hoch!! > > wie könnte ich diesen minimieren??? war ein Software Fehler. Die Kanaldaten wurden dauernd in einer "aufwändigeren" for- Schleife aktualisiert, obwohl es genügt sie einmal am Ende der Syncronisationspause des Summensignals zu aktualisieren. Jetzt funktioniert es einwandfrei. Werte schwanken nur noch gering. Bei der Anzeige im Mikrokoptertool das für die Stickposition 256 Werte auflöst, schwanken die Werte höchstens um +-2. Für meine Zwecke voll ok. Programm findet sich im Anhang falls es mal jemand benötigen sollte. MfG
Hallo, warum erlaubst Du den Overflow-Interrupt? In Deiner ISR machst Du nichts..... Ansonsten: Schöne Arbeit. Gruß, Stefan
Stefan Weßels schrieb: > warum erlaubst Du den Overflow-Interrupt? In Deiner ISR machst Du > nichts..... ja das kann noch weg, im früheren Stadium des Codes hatte ich da was stehen, was jetzt wieder weg gekommen ist ;-) Stefan Weßels schrieb: > Ansonsten: Schöne Arbeit. Dankeschön :-) MfG
sorry das ich das alte Thema wieder nach oben hole. Ich habe die Schaltung nachgebaut und den letzen code verwendet, mit ist aufgefallen das bei einem Empfangsverlust der letzte Zustand des PPM Signals erhalten bleibt. Wäre es viel Aufwand, den Pegel beim wegfallen der Servosignale auf 0 zu ziehen?
Beitrag #5681771 wurde von einem Moderator gelöscht.
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.