Searcher

Interessant.

Der ADC lässt sich also doch und ziemlich leicht beeinflussen? Dann war das nicht nur so ein "Gefühl" bei mir. Ich hatte schon den selben Verdacht. Deswegen habe ich auch den AREF mit einem Kondensator gegen GND verbunden. Steht auch irgendwie im Datenblatt bei den µCs, wie dem ATmega328P. Dann habe ich da nichts Überflüssiges gemacht, auch wenn ich den Sensoren einen extra Spannungsregler zugestanden habe. Aber ich hätte nicht gedacht, dass selbst Digitaleingänge Einfluss auf den ADC haben würden.

Wenn Du jetzt noch messen tust, wenn ein Motor läuft ....

Wenn eben alles an einer Versorgung dran hängt und nichts getrennt ist.

Bei den µCs ist es ja doch rel. einfach, einen Spannungsregler extra dafür einzusetzen, mit den entsprechenden Kondensatoren dazu. Ich hatte mir für div. Zwecke ein paar LM2936 zugelegt.

MfG

Ich konnte es erst auch nicht glauben. Anscheinend hatte ich so eine Konstellation vorher noch nicht oder hab nicht drauf geachtet.

Die ADC Wandlung in meinem Afbau ist jetzt jedenfalls auch mit beiden laufenden Motoren gut. Die ADC Frequenz ist auf 125kHz eingestellt. Im Programm werden in einer Schleife die beiden Potis an Kanal 1 und 2 abwechselnd im Single Conversion Mode gemessen. Nach Application note AVR126 verwerfe ich nach Kanalwechsel die erste Messung. An AREF habe ich auch einen 100nF nach GND geschaltet (ist aber glaube ich nur notwendig, wenn interne Referenz genutzt wird. Ich verwende Vcc als Referenz) Durch die SW-Hysterese, wie oben verlinkt, sende ich über RS232 die Meßwerte nur an den PC, wenn der aktuelle Meßwert um mehr als drei Einheiten vom vorherigen abweicht. Solange ich nicht an Potis fummele, herrscht am PC-Terminal Ruhe.

Die UP/DOWN Leitungen, die ja durch die laufenden Motore über die Enkoder aktiv sind, liefern gemeinsam je nach Drehzahl vielleicht 500 bis 6000 Flankenwechsel pro Sekund zwischen 0 und 5V. Sind die aber auch an PortC Eingängen angeschlossen, gibt es am PC-Terminal Betrieb. Von beiden Potis gab es dann 10 Bit Werte vom ADC, die bis zu ±10 Einheiten und auch mehr pendelten. Oszi an Vcc zeigte im Takt der PWM Frequenz für die Motore kurzzeitig minimale Schwingungen höherer Frequenz, die vielleicht zusammen mit den UP/DOWN Wechseln die Schwankungen der Messungen verursachten. Tatsache ist: UP/DOWN an anderen Port: ADC gut (Ruhe am PC-Terminal)! Ich hatte noch, teils halbherzig versucht die UP/DOWNs auf die I2C Pins zu legen und auch die Buffer an den Meßpins im DIDR0 Register abzuschalten. Kleine Kondensatoren (1nF nach GND) an den Eingängen der UP/DOWNs. Ferrit bead nach AVR042 an AVCC. Nix. Einzig das Verlegen der UP/DOWNs auf einen anderen Port hat geholfen.

Wenn sich tatsächlich die Störungen an den Eingängen innerhalb des Ports negativ auf die Messung auswirken, wüßte ich nicht, wie man das verhindern könnte. Bei Gelegenheit würd ich es auch mal mit Spannungswandlern und externer/interner AREF versuchen und mehr Aufwand bei Filterung der Spannungen treiben. Im Augenblick laß ich es mal so, da ich möglichst wenig Aufwand bei der Schaltung treiben möchte und der ADC jetzt meinen Ansprüchen genügt.


Gruß
Searcher

Hallo Searcher,

laut Datenblatt gibt es wohl tatsächlich einige Probleme mit ADC.
Die Decodersignale also nicht auf den ADC Port (Portc) zu legen ist durchaus sinnvoll.

Dieser Hinweis laut Datenblatt 28.6.2 macht es nochmal deutlich:
If any ADC [3:0] port pins are used as digital outputs, it is essential that these do not switch
while a conversion is in progress. Das gleiche gilt natürlich auch für extern angelegte Signale.
Wenn hier deine Encodersignale drauf liegen ist das äußerst ungünstig, da anscheinend die Signalflanken
auf den ADU übersprechen.

Durch die ratiometrische Messung ist VREF nicht so entscheidend, obwohl ich trotzdem immer gegen VREF arbeite.
Wie in der Zeichnung im Datenblatt Figure 28-9 sollte man den AVCC Bin über ein LC Glied einspeisen.
Das ist sicher gut, brachte bei mir aber keine Verbesserung.

Ich habe bei meinen Messungen einen Software Ringpuffer gebaut.
Dieser beinhaltet immer die letzen 10 ADC Messwerte.
Von diesen 10 Messwerten schmeisse ich den Kleinsten und den Größten weg,
die restlichen 8 werden aufadiert und durch 8 mittels 3 mal rechts schieben dividiert.
Mein ADU Streuung lag ohne dieser Maßnahme bei 15 ADU Counts. Nach dieser Maßnahme nur noch bei 5.
Im Prinzip wirkt es wie ein Tiefpassfilter.Hier kann man natürlich noch weitere Filter einbauen
oder auch den Puffer größer machen. Das Ein/Ausschwingverhalten der ADU Werte ändern sich natürlich entsprechend,
vermutlich tut ein externer Kondensator ähnliches.

Meine Encoderscheibe am Pumpenmotor lieferte mir auch, je nach Drehzahl, bis zu 7000 Impulse pro Sekunde.
Anhand der Zeitdifferenz zweier Flanken konnte ich die Drehzahl erstaunlich schnell und präzise regeln.

Laut Datenblatt gibt es noch einen
"Analog Noise Canceling" Mode.
Hier werden während der AD Wandlung diverse Komponenten im Controller ausgeschaltet um Störungen zu vermeiden,
nach der Wandlung werden diese dann wieder aktiviert.
Wenn die Störungen aber extern durch Signalflanken der Decoderscheibe enstehen, nützt Dir das leider auch nichts.

Siro

Hallo Siro,

danke für die Bestätigung. Immer gut zu hören, daß man nicht der Einzige ist, der so eine Beobachtung macht.

Ich hatte noch weitere Tests zur Überprüfung gemacht. Dazu hatte ich einen anderen ATmega88PA und später noch einen ATmega88A genommen, ein Poti an einen ADC Pin geschaltet und von einem ATiny25 aus Impulse an andere Eingänge des PortC angelegt. Am Ende war es in verschiedenen Zusammenschaltungen so, daß immer, wenn zusätzlich Impulse am PortC ankommen, der ADC für das Poti keine stabilen Meßergebnisse liefert. Der Höhe der Abweichungen kann anders sein, wenn der Impulseingang innerhalb des PortC geändert wird, der Meßeingang aber gleich bleibt. Meine Versuche fanden auf dem Steckbrett statt und ich dachte schon vorsichtig an einen Einfluß der Eigenarten des Steckbretts.

Fazit mag wohl sein: Sich des Verhaltens bewußt sein. Keine unkontrollierten Zustände an PortC während einer Messung zulassen bzw. entsprechende Toleranzen einkalkulieren. Fehler durch verschiedene, in Datenblatt und App-Notes empfohlene Maßnahmen so gering wie nötig zu halten.

Gruß
Searcher

PS. Ich versuche bei der Regelung mit der Anzahl der Impulse in einem Zeitintervall zu arbeiten und tue mich da schon schwer weil ich differentielle Lenkung, Gesamtgeschwindigkeit und Vorwärts-/Rückwärtsgang implementieren möchte und merke, daß das nicht so wirklich mein Ding ist. Deine Regelung mit Messung der Impulsabstände halst mir noch eine weitere Idee auf Ist nicht ernst gemeint und ich finde die Tests auf dem "Prüfstand" echt interessant.

sorry, hab das eben wieder gelöscht.
Hatte noch etwas über meine Pulsauswertung geschrieben, habe dann aber gesehn, dass es ja schon perfekt funktioniert bei Dir.

Zitat von Siro

sorry, hab das eben wieder gelöscht.
Hatte noch etwas über meine Pulsauswertung geschrieben, habe dann aber gesehn, dass es ja schon perfekt funktioniert bei Dir.

Hallo Siro,
hab ich trotzdem über die Benachrichtigungsemail gelesen und fand den Beitrag toll. Hättse ruhig stehen lassen können. Deine Timermessung ist wirklich interessant und scheint vom Konzept her besser zu sein, als die Methode mit Ticks pro Zeiteinheit zu arbeiten. Mich reizt es, Deine Methode auch mal auszuprobieren. Zunächst habe ich jedoch noch den Ehrgeiz herauszufinden, warum es bei mir nicht so gut klappt.

Ein Haken ist die aktive Bremse. Da habe ich es noch nicht geschafft, sie bei allen Fahrsituationen richtig zu dosieren. Falls ein Motor zu schnell läuft, zB angetrieben durch die Trägheit des Vehikels beim Gas wegnehmen, soll die H-Brücke umpolen. Also nicht nur vorwärts regeln sondern auch bei negativer Beschleunigung regeln. Im Moment lasse ich die aktive Bremse nicht sanft einsetzen, sondern nur bei großem Unterschied zwischen Soll- und Istgeschwindigkeit, als Notbremse sozusagen.

Andere Hürden habe ich inzwischen genommen. Bei scharfem Lenkeinschlag soll ein Rad beginnen rückwärts zu drehen und zwar so weit, daß das Ding sich um seinen Achsmittelpunkt dreht. In der Bewegung kann dann der "Rückwärtsgang" eingelegt und die Drehung soll mit gleicher Geschwindigkeit in engegengesetzter Richtung einsetzen. Das hatte ich schon bei früheren "Geräten" verwirklicht aber dort einen Bug übersehen, der sich nur recht selten zeigte. Deswegen habe ich jetzt im Unterschied zu früheren Programmen, die Übersetzung von der Bedienung zur Steuerung umgestellt. Gerade fertig, hoffentlich.

Ich versuche eine PI-Regelung zu implementieren. In einigen Situationen setze ich den I-Anteil auf 0, da sonst "unübersichtliche" Dinge passieren Bei Versuchen hatte ich auch Regelungen probiert, die vermutlich auch nicht in Lehrbüchern auftauchen. Wenn ganz simple Algorithmen schnell genug angewandt werden... - ... geht es auch.

Du erwähntest, daß eventuell Räder durchdrehen könnten. Ich habe eher ein entgegengesetztes Problem. Ich verwende recht schwache Motore, die auch entsprechend lahm reagieren. Da werden Schwachstellen geradezu in Zeitlupe offengelegt

Reale Fahrten habe ich bis jetzt noch nicht durchgeführt. Mittlerweile stimmt die Drehzahlregelung beim aufgebockten Vehikel. Ich müßte so langsam mal den µC auf eine Platine und aufs Vehikel bauen. Muß dann mal schauen, ob sich die frühere Beobachtung, des Schrägziehens in der Beschleunigungs- bzw Verzögerungphase eventuel geändert hat.

Ein Traum wäre, falls nötig, die Regelungen der beiden Motore zu synchronisieren und noch die aktive Bremse zu kultivieren.

Gruß
Searcher