Hallo zusammen, Ich bin gerade an der Einarbeitung zu Messtechniken mit dem PIC-AD-Wandlers. Nun mal zu einem sehr gut erarbeitetem Beispiel der Sprud.de_Seite im Anhang. Da steht was von einer 64-fachen Messfolge? Ist diese hier wirklich nötig? Würde da auch zb. 32 fache Messungen ausreichen um nicht unnötig Rechenzeit zu verbraten?? [[https://www.sprut.de/electronic/pic/projekte/luefter/luefter.htm]]
Vermutlich ist 32x od. 16x od. 1x auch genug. Möglicherweise wird die Anzeige und die Regelung dann etwas "zappeliger". Oft genügt auch je 1 Messung. In dem Beispiel ist aber gleichzeitig das PWM-Modul in Verwendung und das bewirkt natürlich eine Störung. Für hohe Ansprüche kann man auch den PIC in den "sleep" schicken während man die AD-Wandlung durchführt.
Aha...das wird eine Sache die ich dann mal probieren muss! Danke erstmal... Und ansonsten ist Dir alles weitere dort auf den erstem Blick einleuchtend? Ich versuche noch die aritmetischen Herleitungen dort nachzuvollziehen, was mir bisher noch nicht 100%ig gelungen ist!?Aber in der Simulation funktioniert die 16bit Division hier!
Ist oft auch eine Frage des Preises. Die meisten denken hierbei an die Rechenzeit - stimmt auch. Ist aber nicht der einzige Preis. Am höchsten sind die Kosten, die auf eine vernünftige, analoge Eingangsstufe, verwandt werden sollten. Schon 12 Bit überfordern oft ein 08/15 Design. Über den Schrott, der zusammen mit Zusatzboards, mit mehr als 12 Bit Auflösung, angeboten wird, möchte ich mich erst gar nicht auslassen. Oft reichen da 65 Messzyklen nicht aus. Aber ein Tipp: Schau Dir doch einfach mal eine richtig lange Messreihe an einer normalen Spannungsquelle an und anschließend eine in der zukünftigen Umgebung. Die Messdaten dazu einfach in eine Datei umleiten.
Rudi R. schrieb: > Würde da auch zb. 32 fache Messungen ausreichen um nicht unnötig > Rechenzeit zu verbraten?? Du wirst die Rechenzeit brauchen: Ein Lüfter reagiert relativ träge. Da führt eine hohe Regelgeschwindigkeit zu ungewollten Schwingungen. Ansonsten: bei korrekter Verdrahtung wirst Du bei 10 Bit Auflösung außer wenn der Analogwert genau zwischen 2 ADC-Werten steht immer 64 gleiche Messungen haben. Siehe auch die "Stufen" einer 10-Bit Langzeitmessung bei der pro dargestelltem Messpunkt ca 300 Messwerte gemittelt werden. Gruß Anja
Rudi R. schrieb: > Und ansonsten ist Dir alles weitere dort auf den erstem Blick > einleuchtend? Ja, ist einleuchtend. (Ich hab mehrere ähnliche Aufgaben mit PIC gelöst.) Er muss mit 1,578 multiplizieren und wählt die Methode mit (1/1,578)=0,6337... zu multiplizieren. Das erfolgt durch Multiplikation mit 64 und Division durch 101. Die Multiplikation mit 64 wird gleich durch Summenbildung der 64 Messwerte erledigt. Die Division durch 101 durch fortlaufende Subtraktion. Vermutlich wird deshalb das oversampling gleich mit 64 festgelegt - nicht unbedingt wegen einer Genauigkeitsforderung bzw. wegen zu hohem Rauschen. So hohes Oversampling braucht man normalerweise nicht bei 8-bit od. 10-bit Auflösung. Ja, das macht die Regelung und die Anzeige langsam aber das ist hier eher ein Vorteil. Die Temperaturen ändern sich auch langsam und eine Ziffernanzeige die z.B. 100-fach in einer Sekunde aktualisiert wird kann niemand ablesen.
Danke für eure Tips! ich bin erstmal die mathematische Routinen durch und habe die mir erstmal mit Werten so simulieren müssen! Nun ist mir endlich mal klar,dass ein Registerunterlauf das Carrybit genullt lässt.Mit den Statusbits muss man erstmal durchsehen aber langsam kommt es... Nun, die Lüftersteuerung würde ich so erstmal nicht brauchen, mir ging es eigentlich vorerst nur um Messungen mit dem ADC und deren Anpassung an Sensoren.Und hier sieht man ja in dem Beispiel schon viel, was man für andere Sachen ableiten könnte.Ich bräuchte das vorerst für Spannungsmessung.Aber ich werde mal so nebenbei natürlich auch rumexperimentieren um davon zu lernen! Ich bin auch noch beim ASM-Code den ich mit Picas compiliere.... aber das ist halt schön nah an der Hardware, Codegenerator MCC erzeugt mir zu viele Sprünge(laut Disassembling zu sehen)...viel zu umständlich an einigen Stellen....aber das nur nebenbei...
:
Bearbeitet durch User
hier im Beipiel sind es 16bit auf zwei 8 verteilt...macht die Sache etwas komplizierter aber es wird schon gehen, habe jetzt 3 Stück PIC16F1877,die ich erstmal ausprobieren will(das Ding kann eigentlich schon recht viel, an die 700 Seiten Dokumentation dazu)Hier scheinen die meisten eher AVR-Controller zu verwenden,wenn man hier so die Themen durchgeht??
Rudi R. schrieb: > Hier scheinen die > meisten eher AVR-Controller zu verwenden Ja, das ist hier so - und meistens C und kaum assembler. Ich hab bisher nur 8-bit-PIC's verwendet - und nur in assembler programmiert. Die Basics hab ich auch von sprut.de gelernt - und dann von tausenden Seiten Datenblättern.... Was mir an assembler gefällt ist, dass man volle Kontrolle über die Hardware hat, ein sehr schneller und kleiner code möglich ist, und vor allem hat man völlig exakte zeitliche Kontrolle.
Hans B. schrieb: > t, ein sehr schneller und kleiner code möglich ist, und vor allem hat > man völlig exakte zeitliche Kontrolle. Wobei da aber i.d.R. jeweils ein Punkt gegenüber C/C++ auf der Strecke bleibt, sobald das mehr als zwei Seiten Code ist.
Rudi R. schrieb: > Hier scheinen die > meisten eher AVR-Controller zu verwenden Ich wähle meine Controller eher an Hand der benötigten Peripherie aus. Bei den großen Designs mit vielen Pins (40) gewinnt eher ein ATMEGA. Bei kleineren Designs (8 Pin) eher ein PIC. Bei 28 PIN Designs ist es oft so daß beim ATMEGA auf Grund höherer Anzahl nicht für Peripherie nutzbarer (Versorgungs-) Pins immer genau ein Pin zu wenig da ist. Ansonsten meine Lieblingsbausteine: ATMEGA1284 (5 x 16 Bit PWMs, viel RAM) ATMEGA168p "hochstrom" Pins für Direktansteuerung gelatchter 5V Relais PIC18F2520 "Nachfolger" des PIC16F876 PIC12F1840/PIC12F675/PIC12F683 8-Pin Device PIC24FV16KA302 12 Bit ADC 16 Bit PWM und 5V Peripherie. PIC18F06Q40/PIC18F16Q40 12 Bit ADC Die letzteren PICs programmiere ich hauptsächlich auch in "C" Rudi R. schrieb: > habe jetzt 3 Stück PIC16F1877 Du meinst den PIC16F877? für den PIC16F877 (und Assembler Programmierung) empfehle ich das Midrange Handbook https://ww1.microchip.com/downloads/en/DeviceDoc/33023a.pdf Gruß Anja
Rudi R. schrieb: > Da steht was von einer 64-fachen Messfolge? > Ist diese hier wirklich nötig? Die ADCs sind SAR-Wandler, d.h. sie nehmen immer nur eine Stichprobe. Ist das Signal gestört, kann man über mehrere Meßwerte integrieren. Um z.B. eine 50Hz Unterdrückung zu erreichen, unterteilt man eine Periode (20ms) in mehrere gleich lange Abschnitte und löst dann mit einem Timerinterrupt die Messungen aus: 20ms / 64 = 312µs Die AVRs haben dafür einen Auto Trigger Mode, d.h. der Timer kann ohne Jitter eine Messung starten.
:
Bearbeitet durch User
Hallo, Peter D. schrieb: > Die AVRs haben dafür einen Auto Trigger Mode, Beim PIC16F877 heißt dieser Trigger "trigger special event" im CCP-Modul Gruß Anja
Anja schrieb: > Ein Lüfter reagiert relativ träge. Da > führt eine hohe Regelgeschwindigkeit zu ungewollten Schwingungen. Hans B. schrieb: > Vermutlich ist 32x od. 16x od. 1x auch genug. Möglicherweise wird die > Anzeige und die Regelung dann etwas "zappeliger". Dann ist der Regler falsch ausgelegt.
Rudi R. schrieb: > hier im Beipiel sind es 16bit auf zwei 8 verteilt...macht die Sache > etwas komplizierter aber es wird schon gehen, habe jetzt 3 Stück > PIC16F1877,die ich erstmal ausprobieren will(das Ding kann eigentlich > schon recht viel, an die 700 Seiten Dokumentation dazu) Und nicht vergessen die Errata auch zu lesen ;-)
Hallo, ich habe auch festgestellt, dass die 10 Bit-AD-Wandler der PICs bei vernünftigem Aufbau eisern stehen, das heißt sie springen nur zwischen zwei Stellen hin und her, wenn sie auf einer Grenze stehen. Aufsummieren ist also nur nötig, wenn die Eingangsspannung verrauscht ist, was man möglicherweise besser mit Hardware filtern kann oder wenn man tatsächlich einen Mittelwert bilden möchte. Bernd
> Er muss mit 1,578 multiplizieren und wählt die Methode mit > (1/1,578)=0,6337... zu multiplizieren. Das erfolgt durch > Multiplikation mit 64 und Division durch 101. > Die Multiplikation mit 64 wird gleich durch Summenbildung > der 64 Messwerte erledigt. Die Division durch 101 durch > fortlaufende Subtraktion. Erstmal, Sprut will nicht mit 1,579 multiplizieren, sondern durch 1,579 dividieren, um aus dem 64-fachen Oversampling auf den Temperaturwert zu kommen (0,633° pro 10bit-ADC). 64 deshalb, weil damit die 16 Bit-Rechnung optimal genutzt wird (10 Bits vom ADC und 6 Bits durch Oversampling). Die Division hätte er einsparen können, wenn er nur 0,633*64=40,512 Additionen gemacht und dann durch 64 geteilt hätte, was wesentlich einfacher geht (6 shifts). 40,5 erreicht man durch 40 Additionen, einen Shift (halber ADC-Wert) und eine weitere Addition. 0,1° Auflösung (zum besseren Erkennen von Tendenzen) wäre wie folgt möglich: Multiplikation des 10bit-ADC-Wertes mit 6,33, indem 25 oder 50 mal addiert und dann durch 4 bzw. 8 dividiert (geshifted) wird (25/4=6,25 ~10*0,633). Wenn es genauer sein soll, addiert man noch einen durch 4 dividierten ADC-Wert.
1 | (25,25 / 4 = 50,5 / 8 = 6,3125) |
2 | Beispiel mit Sprut-Werten ADC 300 und 40°C: |
3 | (50 * 300 + 0,5 * 300 - 8 * 10 * 150) / 8 = 393,75 |
4 | angezeigt als 39,4° |
Die Division immer zum Schluss machen, dann kann man den Offset (150)
genauer subtrahieren (8x150 bzw 80x150).
> oder wenn man tatsächlich einen Mittelwert bilden möchte.
Es ist von Vorteil, wenn beim Oversampling etwas ggf. künstlich
erzeugtes Rauschen/Brummen dabei ist.
Rudi R. schrieb: > Da steht was von einer 64-fachen Messfolge? > Ist diese hier wirklich nötig? > Würde da auch zb. 32 fache Messungen ausreichen um nicht unnötig > Rechenzeit zu verbraten?? Unnötig Rechenzeit verbraten ist hier nicht das Kriterium erster Wahl! Eher ist wichtig, wie dein zu messendes Signal aussieht. Je "schlechter" dies ist, desto mehr mußt du in Software "aufbereiten". Bei deiner konkreten Aufgabe mußt du selbst herausfinden, was nötig ist. Am Besten, indem du verschiedene Varianten ausprobierst. So bekommst du auch einen guten Eindruck davon, was man überhaupt "weggerechnet" bekommt! Viel Spass und Gruß, Rainer
eProfi schrieb: > Es ist von Vorteil, wenn beim Oversampling etwas ggf. künstlich > erzeugtes Rauschen/Brummen dabei ist. Ein verdoppelte Abtastrate (ohne noise shaping) wird mit 3 dB bezahlt - also einem halben Bit. Das kann ganz schön hartes Brot sein, da weitere 2 oder 3 bit hinzuzaubern ... Dithering wendet man an, um die Nichtlinearitäten des ADCs auszubügeln. Erzeugt, so man es falsch macht, aber zusätzliche Störkomponenten.
Hannes schrieb: > Das kann ganz schön hartes Brot sein, da weitere > 2 oder 3 bit hinzuzaubern ... Die Mär vom Gewinn von Bits durch Mittelwertbildung ist nicht totzukriegen. Nur funktioniert sie bestenfalls bei bereits integrierenden Wandlern (Dual-Slope). Ein SAR-Wandler ist auf den Quantisierungsfehler des DAC festgenagelt. Da kannst Du jahrelang aufsummieren und kriegst kein halbes Bit mehr Auflösung. Ich hab mal versucht, mit einem ATmega8 (10Bit-ADC) bis 3000V anzuzeigen. Es war schön zu sehen, wie sich die Anzeige auf 3V-Schritte einpendelte. Nur bei Änderungen erschienen kurz Zwischenwerte. Ob 16 oder 1024 Meßwerte, das machte keinen Unterschied. Die Anzeige wurde nur träger.
eProfi schrieb: > Die Division hätte er einsparen können, wenn er nur > 0,633*64=40,512 Additionen gemacht und dann durch 64 > geteilt hätte, was wesentlich einfacher geht (6 shifts). > 40,5 erreicht man durch 40 Additionen, einen Shift > (halber ADC-Wert) und eine weitere Addition. Echt jetzt? Ich hätte einfach 81 Messwerte genommen und durch 128 geteilt...
Peter D. schrieb: > Die Mär vom Gewinn von Bits durch Mittelwertbildung > ist nicht totzukriegen. Könnte daran liegen, dass es keine Mär ist... > Ein SAR-Wandler ist auf den Quantisierungsfehler > des DAC festgenagelt. Der WANDLER ja -- nicht aber das gesamte messwerterfassende System... > Da kannst Du jahrelang aufsummieren und kriegst kein > halbes Bit mehr Auflösung. Die Methode setzt sich ändernde Signale voraus. Notfalls erzeugt man diese Änderung künstlich --> Dithering.
Egon D. schrieb: > Ich hätte einfach 81 Messwerte genommen und durch 128 > geteilt... Da brauchst Du aber 17-Bit Variablen. Egon D. schrieb: > Die Methode setzt sich ändernde Signale voraus. Notfalls > erzeugt man diese Änderung künstlich --> Dithering. Naja streng genommen braucht man "statistisch" verteiltes Rauschen um ein Bit zu gewinnen. Das hat man in den seltensten Fällen. Gruß Anja
Gut mitgedacht, Anja! Ich wollte es schon oben erwähnen, dachte aber, die Erklärung mit 10+6=16 wäre ausreichend gewesen. Eine Erweiterung der Variablen auf 24 oder 32 Bit wäre einfach möglich. Das Asm-Programm hat über 1400 Zeilen. Hut ab, wer sich das heute noch antut. In C schreibt man das in vielleicht 200 Zeilen hin.
eProfi schrieb: > Das Asm-Programm hat über 1400 Zeilen. Hut ab, wer sich das heute noch > antut. > In C schreibt man das in vielleicht 200 Zeilen hin. In C nehme ich nur noch float. Die ADC-Werte stimmen ja eh nicht mit den exakten Eingangswerten überein (Widerstandstoleranzen, Referenzspannung), d.h. es sind keine Berechnungen mit Konstanten möglich. Gain und Offset werden kalibriert und im EEPROM des MC abgelegt. Ein umständlicher Abgleich über Trimmpotis entfällt.
Peter D. schrieb: > Hannes schrieb: >> Das kann ganz schön hartes Brot sein, da weitere >> 2 oder 3 bit hinzuzaubern ... > > Die Mär vom Gewinn von Bits durch Mittelwertbildung ist nicht > totzukriegen. Ich bin dann mal raus ...
Peter D. schrieb: > Die Mär vom Gewinn von Bits durch Mittelwertbildung ist nicht > totzukriegen. Es wird wohl Zeit, die AVR121 zu nennen. Da steht die Begründung und Vorgehensweise zur Erhöhung der Genauigkeit. Ich mache immer Oversampling mit einem anschließenden Software-Tiefpass. Es stimmt schon, dass das Signal einen Rauschanteil enthalten muss, der wohl immer vorhanden ist. Aber auch wenn das Rauschen vielleicht nicht weiß ist, kann ich sehr schön feststellen, dass die Auflösung erhöht ist.
Hermann W. schrieb: > Es wird wohl Zeit, die AVR121 zu nennen. Hast Du die auch mal genau gelesen und die Randbedingungen die dort genannt werden verstanden? Die Randbedingungen lassen sich eher nicht einhalten. Also wirst Du durch dein "Rauschen" eher eine ungewollte Offset-Verschiebung messen als eine echte Auflösungserhöhung. (schon mal gegen ein höher auflösendes DMM nachgemessen?) Hast Du auch mal die statistische Verteilung der Meßwerte angeschaut? Überlege dir auch was bei 0V und bei 5V passiert (schiefe Verteilung durch clipping). Und zuletzt wo soll denn ein Rauschen (nicht Störung) bei 10 Bit also 5 mV Schrittweite herkommen? Ein normaler 5V Spannungsregler LM7805 hat 0.2 mV Rauschen. Das reicht leider nicht. Es sei denn Deine Schaltung hat einen Design-Fehler. Bei meinen 24 BIT ADCs mit statistischer Verteilung des Ausgangssignals kann man die Aufösung (Standardabweichung) durch Mittelung schon noch etwas erhöhen. Gruß Anja
Wenn man weiß, was man tut, kann man die Auflösung der ADC-Messung durch Dithering – natürlich auf Kosten der Messrate oder der Bandbreite – sehr wohl verbessern. Man kann dabei grundsätzlich zwei Fälle unterscheiden: 1. Hat das zu messende Signal – aus welchen Gründen auch immer – ein unvermeidbares "natürliches" Rauschen mit ausreichender Amplitude, kann man dieses als Dithersignal für die Erhöhung der Auflösung verwenden. Die Qualität des Ergebnisses hängt dann allerdings von der Art und der Amplitude des Rauschens ab. 2. Ist das Rauschen zu schwach, muss man das Dithersignal selber erzeugen. Da man dann bei der Signalform die freie Wahl hat, nimmt man am besten kein Rauschen (das nicht deterministisch und auch nicht so leicht zu erzeugen ist), sondern bspw. ein Dreieckssignal mit einer Amplitude von 0,5 LSB und einer Periode, die einem kompletten Messzyklus entspricht. Das kann man bspw. über ein Digitalausgang des Mikrocontrollers, zwei Widerständen und einem Kondensator leicht mit hinreichender Genauigkeit erzeugen und dem zu messenden Signal beaufschlagen. Dadurch wird der Mittelwert des Summensignals abhängig vom Signalpegel ein wenig verschoben, was man aber auf Softwareseite wieder leicht kompensieren kann. Diese Signalverschiebung ist sogar vorteilhaft, weil dadurch verhindert wird, dass auf Grund des Hinzufügens des Dithersignals zu dem zu messenden Signal der Signalpegel den Messbereich des ADC verlässt.
Anja schrieb: > hast Du die auch mal genau gelesen Ich habe mir Mühe gegeben, aber ich bin kein "Voltnut". Natürlich möchte ich trotzdem so genau wie möglich messen. Deshalb freue ich mich über deine Experten-Anmerkungen. In der AVR121 find ich aber zum Rauschen nicht so detaillierte Infos. Da steht hauptsächlich, dass die Amplitude >0,5Bit sein muss. Zum Spektrum steht da unter Noise eher nichts (ich werde noch mal genauer gucken). Ich mache mit der Oversamplingfrequenz die Messung, die Skalierung auf den Physikalischen Wert und einen Software-Tiefpass. Die nicht signifikanten Stellen schneide ich ab und mache eine Rundung. Ich denke, das entspricht der Addition mit Decimation. Das Ergebnis hat mich immer überzeugt, aber ich habe es nicht so detailliert überprüft. Was muss ich zur Überprüfung genau machen? Ein 6,5-stelliges DVM (34401) steht zur Verfügung. Vielen Dank für eine Antwort, das hat mich schon lange interessiert.
Yalu X. schrieb: > Wenn man weiß, was man tut, kann man die Auflösung der ADC-Messung durch > Dithering – natürlich auf Kosten der Messrate oder der Bandbreite – sehr > wohl verbessern. Und genau das ist doch der Punkt! Was will ich letztendlich messen und wie erreiche ich das am besten?? Die schwammige Beschreibung "so genau wie möglich" oder ähnliches bringt doch nur Märchenerzählen. Wenn dann natürlich auch die Software überhaupt nicht mitmacht, dann ist wohl Landunter! Gruß Rainer
Hermann W. schrieb: > Was muss ich zur Überprüfung genau machen? @Anja: Ich habe deine Zweifel an meiner Oversampling-Auflösungserhöhung noch einmal genauer gelesen und jetzt besser verstanden. Ich habe zwar die Zwischenwerte unterhalb der ADC-Auflösung plausibel sehen können, aber ich habe die Werte und das Rauschen nicht überprüft. Als Antwort auf meine eigene Frage werde ich jetzt die Ausgangswerte gegen die Eingangsspannung mit dem DVM überprüfen und die Verteilung der ADC-Rohwerte aufnehmen. Wie stelle ich ausreichend weißes Rauschen fest? Reicht es, wenn die Verteilung annähernd gaussförmig ist? Entsprechend deiner Vermutung erwarte ich ein unzureichendes Ergebnis und werde dann eine definierte Rauschquelle hinzufügen. Entweder mit dem in AVR121 vorgeschlagenen Timer oder einer analogen Rauschquelle. Das wird etwas dauern, weil ich dazu eine Testschaltung aufbauen will für einfache Änderung und Aufzeichnung. Nochmal Danke für deine Aufklärung und frohes Fest
eProfi schrieb: > Gut mitgedacht, Anja! Ich wollte es schon oben erwähnen, dachte aber, > die Erklärung mit 10+6=16 wäre ausreichend gewesen. Eine Erweiterung der > Variablen auf 24 oder 32 Bit wäre einfach möglich. > > Das Asm-Programm hat über 1400 Zeilen. Hut ab, wer sich das heute noch > antut. > In C schreibt man das in vielleicht 200 Zeilen hin. Tja, warum tut man sich das an!? Jedoch ist es nachher, wenn man weiß was man tut oder auch mit Macros arbeitet, mit copy and paste ebenso einfach, denke ich mal.(gut ausdokumentieren macht auch Sinn) Ich, als noch Lernender, halte es erst einmal noch für notwendig ASM-Code zu verstehen und so schlimm finde ich den Code gar nicht!Zumal man später garantiert eher Fehler finden könnte oder?...Zumindest wenn zb.der Codegenerator doch mal wirres Zeug kriert.:)
Wollte noch mal das Ergebnis des ersten Oversampling-Tests in der Weihnachtspause berichten. Anja schrieb: > wo soll denn ein Rauschen (nicht Störung) bei 10 Bit also 5mV Schrittweite herkommen? ... Es sei denn Deine Schaltung hat einen Design-Fehler. Anja hat natürlich recht, auf meinem ADC-Testboard kommt tatsächlich ein Rauschen von 0Bit zustande. Gottseidank habe ich wohl keinen Design-Fehler gemacht. Liegt der Wert auf einer Bit-Schwelle, kommt bei der AVR121-Methode auch nur der Mittelwert des Bit-Klapperns heraus. Als erstes Ergebnis reicht mir das. Jetzt werde ich mich um eine Rauschquelle bemühen, die eine Gaussverteilung liefert. Habe bisher noch keinen Plan. Die Klassierung habe ich gleich im Programm vorgenommen, sie wird auf dem Display ausgegeben.
Hermann W. schrieb: > Anja hat natürlich recht, auf meinem ADC-Testboard kommt tatsächlich ein > Rauschen von 0Bit zustande. Genau das war auch mein Ergebnis. Ein sauberes Layout vorausgesetzt, stehen die Wandlerergebnisse 0..1023 wie ne Eins. Hinzu kommt der Wandlerfehler des SAR-DAC. Ein 10Bit DAC wird kaum eine höhere Genauigkeit als 10 Bit haben. Ein idealer DAC erzeugt z.B. exakt 500, 600, 700mV. Ein realer DAC aber vielleicht 560, 620, 780mV. D.h. die durch Rauschen hinzu geschummelten Bits haben je nach aktuellem DAC-Schritt ein völlig unterschiedliches Gewicht. Sie sind bestenfalls immer noch monoton, sonst aber nur Lottozahlen. Man treibt also einen hohen schaltungstechnischen Aufwand ohne realen Gewinn. Diese alten Schaltungen stammen noch aus Zeiten, wo hochauflösende ADCs sehr teuer waren. Heutzutage nimmt man einfach echte ADCs mit der gewünschten Auflösung. Z.B. der bekannte LTC2400 schafft bis 24Bit, bei entsprechendem Layout, Eingangsverstärker und Referenz.
:
Bearbeitet durch User
Hermann W. schrieb: > Jetzt werde ich mich um eine > Rauschquelle bemühen, die eine Gaussverteilung liefert. nimm doch einfach einen +- halbes Bit Sägezahn oder Sinus. Das ist vorhersagbarer.
Peter D. schrieb: > Hinzu kommt der Wandlerfehler des SAR-DAC. Ein 10Bit DAC wird kaum eine > höhere Genauigkeit als 10 Bit haben. Schauen wir mal in ein Datenblatt: z.B. der ATMega328P hat eine DNL von 0.7 LSB. -> ein Bit des ADC kann statt der nominalen Schrittweite von 5 mV auch mal 1.5 mV oder 8.5 mV Schrittweite haben. (immerhin ist der ADC monoton). Bei einem SAR ADC sind die größten Fehler dort zu erwarten wo die MSBs schalten. Also beim 10 Bit ADC von 0x1FF auf 0x200 bzw. 0x0FF auf 0x100... A. S. schrieb: > nimm doch einfach einen +- halbes Bit Sägezahn oder Sinus. Das ist > vorhersagbarer. Halbes Bit von was? 5mV, 1.5 mV oder 8.5 mV? Und wo genau wird abgetastet damit sich kein systematischer Offset ergibt? Normalerweise wird beim Rauschen der RMS-Wert (= Effektivwert bzw. Standardabweichung) angegeben. 1 Bit RMS-Wert entspricht dann ca 6.6 Bit peak-peak bei statistischer Verteilung. Damit wird dann auch besser die DNL von benachbarten Bits ausgeglichen. Bleibt aber immer noch das Problem der schiefen Verteilung bei 0V und in der Nähe der Referenzspannung. Gruß Anja
Anja schrieb: > A. S. schrieb: >> nimm doch einfach einen +- halbes Bit Sägezahn oder Sinus. Das ist >> vorhersagbarer. > Halbes Bit von was? 5mV, 1.5 mV oder 8.5 mV? > Und wo genau wird abgetastet damit sich kein systematischer Offset > ergibt? Wenn die Auflösung eines 10Bit-AD-Wandlers, der weitaus akkurater ist, gesteigert werden soll, dann kann man das Signal mit +- >= einem halben Bit (+-2.5mV@5V)-Dreieck beaufschlagen und in der Periodendauer z.B. 100 Messungen machen. Ist der Wert mittig, bleibt er es. Ist er genau zwischen 5 und 6, wird es ~50 mal 5 und 6 messen.
Anja schrieb: > Bleibt aber immer noch das Problem der schiefen Verteilung bei 0V und in > der Nähe der Referenzspannung. Stimmt - man verliert an den Bereichsgrenzen wenige Promille Aussteuerbarkeit. Wem's weh tut, der kann sein Signal um wenige Promille abschwächen. Mit tat's nie weh...
Anja schrieb: > ATMega328P hat eine DNL von 0.7 LSB In alten und in den neuesten Datenblättern finde ich DNL=0,25 LSB. Aber es bleibt wohl dabei, dass mit Oversampling nicht viel herauszuholen ist. Ich habe jetzt nach der AVR121-Methode einen Sägezahn mit dem Timer erzeugt und am Eingang eingespeist. Eine volle Periode über die 16 Oversamplingwerte. Eine Gauss-Verteilung gibt es nicht, sondern ein flaches Plateau über +-2 Bit, das ist wohl auch zu erwarten.
Hermann W. schrieb: > In alten und in den neuesten Datenblättern finde ich DNL=0,25 LSB. Ich habe hier nachgeschaut (Table 28-8): 0.3 LSB typ und 0.7 LSB max: https://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-7810-Automotive-Microcontrollers-ATmega328P_Datasheet.pdf Gruß Anja
Nun habe ich den Oversamplingtest fertig. Nach den vielen kritischen Anmerkungen kann ich es immer noch nicht glauben. Meine Erwartungen sind weit übertroffen. Die Testanordnung stur nach AVR121: Oversampling von 16 Werten, d.h. 16 Werte addiert, 2Bit-Rechtsshift und Teilen durch 4 sollte ein Ergebnis mit 12Bit Auflösung, d.h 0,27mV bei Vref=1,1V ergeben. Auch das Rauschen wurde wie vorgeschlagen mit einem Timer erzeugt, das +-2Bit nicht überschritten hat. Es wurde am Eingang aufaddiert. Ich habe den ganzen Bereich in engen Stufen durchgefahren mit Rohwerten von 10 bis 1021. Die Eingangswerte wurden mit meinem HP34401 gemessen und mit den intern kalibrierten Werten verglichen. Kaum zu glauben: es wurde im ganzen Bereich kein einziges Mal eine Abweichung größer 0,27mV erreicht. Jetzt werde ich natürlich weiter machen: - Test mit 13 Bit (mehr macht wohl keinen Sinn) - Rauschen an Aref einspeisen (bei mehreren Kanälen ist der Filter zu aufwendig) - Statt adieren, shiften, teilen meine bisher verwendete Methode mit SW-Tiefpass, das gibt nach jeder Abtastung einen neuen Wert
Hermann W. schrieb: > Die Testanordnung stur nach AVR121: Oversampling von 16 Werten, d.h. 16 > Werte addiert, 2Bit-Rechtsshift und Teilen durch 4 sollte ein Ergebnis > mit 12Bit Auflösung, d.h 0,27mV bei Vref=1,1V ergeben. Meine Rede: 0.5 bit pro Faktor 2 Oversampling... Beitrag "Re: Verständnissfrage zur nötigen Mehrfachmessung eines AD-Messwertes mit µC" > Auch das Rauschen > wurde wie vorgeschlagen mit einem Timer erzeugt, das +-2Bit nicht > überschritten hat. Es wurde am Eingang aufaddiert. Gegenüber drögem Rauschen hat das synchronisierte Dither-Signal den Vorteil, dass es sich vollstandig rausrechnen lässt. > Jetzt werde ich natürlich weiter machen: > - Test mit 13 Bit (mehr macht wohl keinen Sinn) > - Rauschen an Aref einspeisen (bei mehreren Kanälen ist der Filter zu > aufwendig) Einspeisen am Aref wird vermutlich nicht hinhauen. > - Statt adieren, shiften, teilen ... So funktioniert das primitivste Tiefpassfilter - entspricht dies doch einem FIR-Filter mit allen Koeffizienten = 1. Trick bei der ganzen Oversampling-Geschichte ist, einen Teil des Quantisierungs-Rauschens los zu werden. Dieses Rauschen verteilt sich gleichmäßig zwischen 0 und f(Nyquist). Filterst Du z.B. bis 1/2*f(Ny), bist du die Hälfte der Rauschleistung los (also 3dB) - und hast damit 0.5 bit gewonnen. Dithering ist dabei nur ein Trick, um ein technisches Problemchen zu eliminieren... Falls dich die Technik hinter Oversampling ADCs interessiert, schau dir mal die Delta-Sigma-ADC-Geschichte an. Dort wird Oversampling in Reinstform betrieben. Z.B. https://e2e.ti.com/tags/delta_2D00_sigma%2bADC%2bbasics bietet einen brauchbaren Einstieg. Falls echtes Interesse besteht, such ich dir gerne noch was Besseres raus.
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.