Problem bei PWM Messung am Rx Ausgang

[sungamer]

Guten Morgen Heliflieger,

im Rahmen des Sticki Logger Projekts bin ich im Moment meine "PWM Mess Funktion" am optimieren. Dabei ist mir aufgefallen, dass noch immer ein starkes Rauschen in den Messergebnissen ist. Das bringt den CCPM Demixer leider etwas durcheinander. Also muss es beseitigt werden
Im Anhang findet ihr ein Chart das eine einfache Bewegung des Hecks zeigt. Wisst ihr wie das Rauschen zu stande kommen könnte und wieso es z.B. beim Heck Kanal plötzlich aufhört? Der Messbereich ist mit der Funktion 1600 Digits groß. (+800/-800 im Chart)
Das ist die (simple) Funktion um die PWM vom Empfänger zu messen: Die Funktion wird per Timer Interrupt mit 60 Hz aufgerufen.

Code: Alles auswählen

inline static uint16_t pwmIn(volatile uint8_t *port, uint8_t pin) 
{
	unsigned short counter;

	counter = 0;
	while (! (*port & (1 << pin)) )	// wait on PIN == LOW
	{
		if (0 == ++counter) return (0);	// overflow --> return 0
	}	
	counter=0;
	//Dauer zählen
	while (*port & (1 << pin))	// wait on PIN == HIGH
	{
		if (0 == ++counter) return (0);	// overflow --> return 0
	}
	
	//return the result
	return (counter);
}

Vielen Dank schonmal für eure Hilfe!

[ER Corvulus]

m.E. sind 60hz bei Impulsbreiten von 1,0 bis 2,0 ms einfach zuwenig für ne vernünftige Auflösung - oder bin ich da so daneben? (ich lese das so, dass Du ab Signal High die Anzahl der Interrupts zählst, bis das Signal wieder auf Low geht)
Normalerweise sollte die Samplingrate doch mindest doppelt so gross wie die höchste zu messende frequenz sein - damit wäre man für ein Impuls von 1ms bei 2kHz. Müsstest aber noch deutlich höher gehen, weil du ja die zwischen 1ms und 2ms noch "Auflösen" musst.
Falls ich da völlig daneben stehe - sag bescheid

Grüsse wolfgang

[sungamer]

(ich lese das so, dass Du ab Signal High die Anzahl der Interrupts zählst, bis das Signal wieder auf Low geht)

Ups, dann habe ich wohl etwas ungenau geschrieben. Die Funktion wird mit 60 Hz aufgerufen. In der Funktion wird dann der Counter mit 8mHz (Systemtakt) hochgezählt.
Das mit dem Interrupt hat den Sinn, dass ich so in der PC Software wieder genau den 60Hz Takt bei der Wiedergabe treffen kann und so keine Synchronitäts Probleme bekomme.

[FPK]

In der Funktion wird dann der Counter mit 8mHz (Systemtakt) hochgezählt.

Wie stellst Du sicher, dass der Counter mit 8 MHz hochgezählt wird? Hast Du Dir den generierten Assemblercode für die Messchleife angeschaut? Wie schnell läuft die CPU?

[sungamer]

Wie stellst Du sicher, dass der Counter mit 8 MHz hochgezählt wird? Hast Du Dir den generierten Assemblercode für die Messchleife angeschaut? Wie schnell läuft die CPU?

Okay, es sind nicht ganz 8mHz, die ganze Schleife benötigt für jeden Durchlauf 12 Zykles. Tut aber auch nichts zu Sache, auf jeden Fall schneller als die Impulsbreite des Rx.
Der CPU läuft mit 8 mHz.

[FPK]

Wie stellst Du sicher, dass der Counter mit 8 MHz hochgezählt wird? Hast Du Dir den generierten Assemblercode für die Messchleife angeschaut? Wie schnell läuft die CPU?

Okay, es sind nicht ganz 8mHz, die ganze Schleife benötigt für jeden Durchlauf 12 Zykles.

Gemessen oder geschätzt ?

Tut aber auch nichts zu Sache, auf jeden Fall schneller als die Impulsbreite des Rx.

Doch, weil Du alleine durch den Code eine Ungenauigkeit von zwei (Anfang- und Ende) Schleifendurchläufen erhälst. Aber das ist nur ein Punkt Kann natürlich auch noch am Signal (Sender/Empfänger) oder an der Eingangselektronik liegen.

[fireball]

Falsches herangehen würde ich fast sagen - reagier lieber auf einen I/O state change per Interrupt und merke Dir da jeweils den Stand eines Timers - und nicht mit einer Routine, die regelmäßig aufgerufen wird...

[sungamer]

reagier lieber auf einen I/O state change per Interrupt und merke Dir da jeweils den Stand eines Timers - und nicht mit einer Routine, die regelmäßig aufgerufen wird...

Das wäre mir auch am liebsten! Problem ist, dass ich keine 5 Interrupts habe die auf steigende Flank am Pin reagieren...

[fireball]

Reicht nicht einer, der auf alle Ports reagiert? Musst Du Dir halt den letzten State von allen Ports merken und vergleichen, welcher ausgelöst hat.

[FPK]

Naja, soviel sollte das trotzdem nicht ausmachen, vor allem die teilweise symmetrischen Ausschläge nach oben und unten von zwei Kanälen (und das ist nicht nur zwischen TS-Kanälen der Fall, was eher auf ein Senderpotiproblem deuten würde) sind schon komisch. Kannst Du die Pulse mal mit einem Oszi anschauen?

[sungamer]

Kannst Du die Pulse mal mit einem Oszi anschauen?

Schon gemacht, aufm Oszi ist das PWM Signal vom Empfänger ohne Rauschen oder Ähnliches. Die Flanke steigt auch sehr Steil an, es kann also nicht da dran liegen, dass HIGH unterschiedlich erkannt wird.
Komisch finde ich, dass ab Frame 357 das starke Rauschen auf dem Heckkanal verschwindet. Wo dran liegt das wohl?

EDIT: Habe im Anhang mal noch einen neuen Log angehangen! Auffallend ist, dass die Messungen manchmal sehr gut sind. Aber leider auch schlechte Phasen vorkommen.

[ER Corvulus]

Das Problem liegt daran, dass Du nicht "Herr über die CPU" bist. Kannst du sicherstellen, das der Rechenknecht in deinem Timer-Interupt wirklich nix - also gaaaaarnix macht als die Zählroutine aufzurufen? In som Echtzeitsystem laufen ja "nebenbei" noch so nette Sachen wie Schnittstellen-Handling, die so ein "lumpigen" Timer schlicht mal eben unterbrechen.
Zeitkritische Sachen haben in so einem Interupt mit niedriger Priorität nix zu suchen. Der Ansatz (vonFireball) mit dem Interrupt vom Change des I/Os mit Zeitstempel macht da sicher mehr sinn. den Timer benutzt dann, um aktuellen Werte der Kanäle in die schnittstellen-Puffer zu schieben.

Grüsse Wolfgang

[sungamer]

Ich könnte den Timer immer auf steigene Flanke am Eingang Reseten und diesen Wert dann benutzten. Wäre am besten! Nur wie oben schon geschrieben, weis ich nicht wie das bei 5 Eingänge um zu setzen ist...

[ER Corvulus]

Na, du hast für jeden Eingang 3 variablen: Status (High/Low) und istTimer, altTimer
In jedem IRQ guckst erstmal, wo der herkommt.
Dann ob steigend oder fallend.
Steigend: istTimer auf systemzeit stellend, Status setzten
Fallend: Aktuellen istTimer von der systemzeit abziehen und nach altTimer schieben

In Deinem 60Hz-IRQ holst dann die Werte aus altTimer ab, rechnest sie um schiebst sie zu deinem USB-Puffer (jeweils für alle 5 Ports/Pins)
Damit bist bei einem "Versatz"/latenz von 1 Pediode (als <20ms), sollte für ne Sync fürn Sim reichen.

Grüsse Wolfgang

[FPK]

Auch bei dem neuen Log sind die Ausschläge oft symmetrisch auf zwei Kanälen. Denk mal drüber nach, ob das irgendwie systematisch verursacht sein könnte, ich kenne leider das komplette Programm nicht.