www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik RC Summensignal erzeugen aus 6 Kanälen (Modellbau)


Autor: C. S. (chrisdask8)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Edit: Ich vergass zu erwähnen, das ist was bei der klassichen 
Fernsteuertechnik PPM passiert. PCM funktioniert anders.

Autor: C. S. (chrisdask8)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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_pag...
??

Dann bin ich wohl wirklich ein wenig in die falsche Richtung gedriftet 
;)
Danke nochmal

MfG

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
C. S. schrieb:

> tatsächlich... Dann wäre ja folgendes Produkt komplette Abzocke:
> https://www.mikrocontroller.com/index.php?main_pag...
> ??

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.

Autor: Simon L. (simon_l)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stephan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Barny (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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_pag...
http://tt-rc.ath.cx/SHOP/ITEM-10

Autor: C. S. (chrisdask8)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/?O...
Empfänger:
http://www.helibude.de/epages/61385467.sf/de_DE/?O...

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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. :-)

Autor: empfangnix (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
C. S. schrieb:

> Als Sender verwende ich:
> 
http://www.helibude.de/epages/61385467.sf/de_DE/?O...
> Empfänger:
> 
http://www.helibude.de/epages/61385467.sf/de_DE/?O...

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.

Autor: Barny (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: C. S. (chrisdask8)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Barny (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: C. S. (chrisdask8)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Barny (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: C. S. (chrisdask8)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Barny (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: C. S. (chrisdask8)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Barny (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 |_| 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.

Autor: C. S. (chrisdask8)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: C. S. (chrisdask8)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
sry hier die überarbeitete Datei, mit deinen Tipps

Autor: Barny (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: C. S. (chrisdask8)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: C. S. (chrisdask8)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
bei Interesse findet sich der aktuelle Stand im Anhang.

Autor: C. S. (chrisdask8)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: C. S. (chrisdask8)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Chris __ (_chris_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: C. S. (chrisdask8)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stefan Weßels (swessels)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

warum erlaubst Du den Overflow-Interrupt? In Deiner ISR machst Du 
nichts.....
Ansonsten: Schöne Arbeit.

Gruß,
Stefan

Autor: C. S. (chrisdask8)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Marco K (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.