Hallo, ich erzeuge mit einem Arduino und einer R2R Leiter ein Sinus Signal. Diese Signal wird verstärkt und über einen Transformator hochtransformiert (100V-300V) Nun ist es so das beim Erzeugen des Sinus mittels der R2R Leiter einiege Ausbrüche am Signal entstehen (siehe Anhang), und auch durch das Verstärken und Hochtransformieren wird das Signal am ende sehr unsauber und hat ein hässliches rauschen. Meine Frage nun: reicht ein einfacher Tiefpass aus um dieses Signal am Ausgang zu Filtern? Grenzfrequenz wäre bei ca 70Hz Daraus habe ich folgendes errechnet: R=2,2k Ohm und C=1uF Der Kondesnsator muss natürlich die dementsprechende Spannungsfestigkeit haben.. Vielen Dank für eure Anworten und Vorschläge. lg, poschi8
Angehängte Dateien:
-
rauschen.jpg
140 KB
Heinz peter P. schrieb: > Meine Frage nun: reicht ein einfacher Tiefpass aus um dieses Signal am > Ausgang zu Filtern? Das hängt vom Verhältnis der Abtastrate zur maximal auszugebenden Frequenz ab. Allerdings wäre die erwartete Kurvenform erstmal eine Art Treppe, nicht so ein Dingens mit so vielen Spikes. Das riecht nach schlechter Abblockung des Controllers und/oder Masseführung.
Da scheint ein systematisches Problem vorzuliegen, denn die Peaks sind immer an der gleichen Stelle im Wellenzug. Ich schlage dir vor, die Software erstmal sauber zu machen, dann hat sich das Filterproblem darauf reduziert, die Umschalttreppchen zu glätten.
Ich werde mal meinen Code überprüfen ob das sicherlich so passt, danke für den Hinweis :) lg, poschi8
@Heinz peter Posch (poschi8) >Nun ist es so das beim Erzeugen des Sinus mittels der R2R Leiter einiege >Ausbrüche am Signal entstehen (siehe Anhang), Das sind möglicherweise Meßfehler. Oder Programmierfehler bei deiner DAC-Ausgabe. > und auch durch das >Verstärken und Hochtransformieren wird das Signal am ende sehr unsauber >und hat ein hässliches rauschen. Außerdem fehlt dir der Rekonstruktionsfilter, den eigentlich jeder DAC braucht. >Meine Frage nun: reicht ein einfacher Tiefpass aus um dieses Signal am >Ausgang zu Filtern? Ja, wenn man ihn richtig dimensioniert. >Grenzfrequenz wäre bei ca 70Hz Nö. Der Filter orientiert sich an der DAC-Samplingfrequenz, nicht deiner Ausgabefrequenz. >Daraus habe ich folgendes errechnet: R=2,2k Ohm und C=1uF Das Problem ist aber, daß der Filter am Ausgang mit einem OPV entkoppelt werden muss.
@Heinz peter Posch (poschi8)
>ich erzeuge mit einem Arduino und einer R2R Leiter ein Sinus Signal.
Zeig mal deine Software. Wenn du auf dem normalen Arduino-Framework
aufbaust, spuckt dir ggf. der 1ms Timer0 dazwischen.
Baldrian schrieb: > Kann es sein, dass in der Tabelle fehlerhafte Sinuswerte abgelegt > wurden? Um das zu verifizieren würde ich vorschlagen, einmal höherauflösend zu oszillogrfieren, sprich: so einen Spike mal genauer darzustellen, so dass man sieht, ob hier eine komplette Stufe den falschen Wert hat oder ob es sich nur um einen kurzen Störimpuls handelt (kürzer als die Stufenweite, meine ich damit).
Falk B. schrieb: >> Grenzfrequenz wäre bei ca 70Hz > > Nö. Der Filter orientiert sich an der DAC-Samplingfrequenz, nicht deiner > Ausgabefrequenz. Am Verhältnis beider. Wenn du mit sehr vielen Stützstellen nur langsame Signale ausgeben willst, kommst du mit einem deutlich einfacher gestrickten Filter hin, als wenn du kurz vor der „Erbrechensgrenze“ fast an der Nyquist-Grenze arbeiten willst.
Ergänzung: Du schreibst, das Signal wird mittels R2R-Leiter erzeugt. Ist evtl. die Übernahme der Bit-Werte an den einzelnen Ausgängen nicht synchron? Hier wäre nun tatsächlich ein Blick in die Firmware interessant...
>Ist evtl. die >Übernahme der Bit-Werte an den einzelnen Ausgängen nicht synchron? Bzw. ist die R2R Leiter auf mehrere Ports verteilt?
Matthias S. schrieb: > Da scheint ein systematisches Problem vorzuliegen, denn die Peaks sind > immer an der gleichen Stelle im Wellenzug. Vielleicht ist auch nur der Dimmer der Arbeitsplatzbeleuchtung schuld.
Heinz peter P. schrieb: > Nun ist es so das beim Erzeugen des Sinus mittels der R2R Leiter einiege > Ausbrüche am Signal entstehen (siehe Anhang) Du setzt nicht einen Port, sondern die Pins einzeln nacheinander. Das ergibt dann Zwischenwerte (Glitches).
Falk B. schrieb: > Außerdem fehlt dir der Rekonstruktionsfilter, den eigentlich jeder DAC > braucht. Ja, allerdings kann man in in diesem Fall wohl sehr gut auf ein dediziertes Rekonstruktionsfilter verzichten. Es gibt nämlich nach der Beschreibung des TO gleich zwei Baugruppen nach dem DAC, die sich förmlich dafür anbieten, gleichzeitig auch Rekonstruktionsfilter zu sein (oder zumindest ein Teil davon). Als erstes wäre da der Verstärker. Wie auch immer der aufgebaut ist: es dürfte sehr leicht und billig umzusetzen sein, seinen Frequenzgang nach oben dramatisch zu beschränken. Und danach kommt dann auch noch der Trafo. Auch der schreit geradezu danach, mit einem Kondensator (und evtl. einem Widerstand) zu einem Resonator ergänzt zu werden. Das eigentliche Problem des TO wird allerdings beides nicht lösen: die extremen Glitches im Signal stammen entweder von einem Programmierfehler oder von massiven Mängeln in der Konstruktion. Oder auch von beidem... [Implizierte Beleidigung gelöscht - Mod.]
:
Bearbeitet durch Moderator
Duck&Wech schrieb: > Matthias S. schrieb: >> Da scheint ein systematisches Problem vorzuliegen, denn die Peaks sind >> immer an der gleichen Stelle im Wellenzug. > > Vielleicht ist auch nur der Dimmer der Arbeitsplatzbeleuchtung schuld. Wenn der R2R DAC bereits mit der Beleuchtung synchron läuft, hat der TE meinen Respekt :-P Sieht allerdings doch mehr nach einem Portschreib-Problem aus.
Für einen 70 Hz Sinus braucht man auch keinen R2R DAC, da tut es ein EINZELNER PWM-Ausgang locker. Den füttert man mit ein paar kHz, fertig. Siehe DDS Beitrag "Re: SPWM auf Atmega8, bitte um Feedback hinsichtlich Optimierung"
Das Stichwort 'Glitches' wurde schon genannt. Man bekommt sie mit einer SampleHold Stufe weg. Dazu wird, nachdem alle Bits korrekt am DAC anliegen und sich die Ausgangsspannung beruhigt hat, diese mit einer S&H gesamplet. Gruß Jobst
Hi, ich habe das Problem bereits gefunden es werden bei mir 2 Ports verwendet, geht leider nicht anders.. Wie bekomme ich das den nun am besten in den Griff? LG, poschi8
Heinz peter P. schrieb: > Wie bekomme ich das den nun am besten in den Griff? Man kann die beiden Ausgaben so schreiben, daß sie direkt nacheinander erfolgen. Bei 16MHz wäre dann der Glitch nur 63ns breit, d.h. bei 1ms Zeitbasis nicht mehr sichtbar.
Du kannst auch beide Ports zusammen auf einen z.B. 74HC574 führen und dann mit einem einzigen Latch Impuls auf den R2R legen. Kostet aber einen Pin extra für den Latchpuls. Heinz peter P. schrieb: > ich habe das Problem bereits gefunden es werden bei mir 2 Ports > verwendet, geht leider nicht anders. Klassischer Planungsfehler, wenn ich das mal so sagen darf.
:
Bearbeitet durch User
Peter D. schrieb: > Heinz peter P. schrieb: >> Wie bekomme ich das den nun am besten in den Griff? > > Man kann die beiden Ausgaben so schreiben, daß sie direkt nacheinander > erfolgen. Bei 16MHz wäre dann der Glitch nur 63ns breit, d.h. bei 1ms > Zeitbasis nicht mehr sichtbar. Meinst du damit das ich die beiden Werte als byte abspeichere und dann nacheinander auf die Ports schreibe? Der Grund warum ich 2 Ports hab ist das ich nur einen Arduino Nano zur Verfügung habe (http://www.pighixxx.com/test/pinouts/boards/nano.pdf) Dort ist das etwas schwierig.. Ich verwende PD5,PD6,PD7 und PB0-PB4. Den Port D kann ich nicht verwenden da ich eine serielle Kommuniaktion verwende und die Ports PD0 und PD1 dafür benötige. LG, Poschi8
Matthias S. schrieb: > Du kannst auch beide Ports zusammen auf einen z.B. 74HC574 führen und > dann mit einem einzigen Latch Impuls auf den R2R legen. Kostet aber > einen Pin extra für den Latchpuls. Und ein zusätzliches Bauteil auf der Platine. Und wenn man sich schon zu einem weiteren Bauteil auf der Platine durchgerungen hat dann kann man auch gleich einen fertigen externen DAC mit SPI-Interface nehmen, dann spart man sich auch gleich die ganze Batterie an Widerständen und viele Portpins. Oder gleich einen µC mit DAC nehmen. Oder wenns auf Biegen und Brechen dieses eine Arduino-Board sein muss und kein anderes dann vielleicht mal über einen Delta-Sigma DAC nachdenken, da gibts auch simple Codebeispiele (kaum mehr als ein Dutzend Zeilen C-Code), auch hier im Forum wurde das schon diskutiert und das spart gegenüber R2R dramatisch Hühnerfutter und Portpins.
:
Bearbeitet durch User
Heinz peter P. schrieb: > Ich verwende PD5,PD6,PD7 und PB0-PB4.
1 | void output( uint8_t val ) |
2 | {
|
3 | uint8_t pb, pd; |
4 | pb = PORTB & 0b11100000 | val & 0b00011111; // PB4..0 |
5 | pd = PORTD & 0b00011111 | val & 0b11100000; // PD7..5 |
6 | PORTB = pb; |
7 | PORTD = pd; |
8 | }
|
@Heinz peter Posch (poschi8) >ich habe das Problem bereits gefunden es werden bei mir 2 Ports >verwendet, geht leider nicht anders.. >Wie bekomme ich das den nun am besten in den Griff? Nimm PWM. Damit machen andere sogar eine Audioausgabe mit mehreren kHz Bandbreite. Beitrag "Re: Sinus aus R2R filtern"
Lösungsmöglichkeiten sind ja nun genug aufgezeigt... Unabhängig von allem wäre trotzdem mal die Software interessant. Ich verstehe nicht, wieso da glitches von 2,5V auftreten, d.h. 1MSB. Das kann doch gar nicht passieren? Es sei denn, man beschreibt die Portbits einzeln :-)
@H.Joachim Seifert (crazyhorse)
> Es sei denn, man beschreibt die Portbits einzeln :-)
Das ist keineswegs abwegig, schon gar nicht im Arduino-Universum :-0
Falk B. schrieb: > Das ist keineswegs abwegig, schon gar nicht im Arduino-Universum :-0 Aber selbst da dürfte deine PWM-Idee völlig problemlos umsetzbar sein – und spart sogar noch Bauteile. Allerdings ist das Rekonstruktionsfilter dafür ein wenig aufwändiger.
Naja, nun ist die Hardware einmal da. Und wenn die Software im Rahmen des möglichen richtig gemacht wird, genügt es ja vielleicht.
H.Joachim S. schrieb: > Naja, nun ist die Hardware einmal da. Und wenn die Software im Rahmen > des möglichen richtig gemacht wird, genügt es ja vielleicht. Genau das ist das Problem.. Die Platine ist eigentlich schon vorgegeben. Ich kann nur mehr den Code verändern, aber ich werde einfach die beiden Ports beschreiben dann sollte das schon laufen. Vielen Dank für die zahlreichen Antworten :) LG, poschi8
Heinz peter P. schrieb: > Die Platine ist eigentlich schon vorgegeben. Und dein Rekonstruktionsfilter? Das wirst du ja wohl oder übel irgendwo unterbringen müssen. Da könntest du es auch gleich auf einen PWM-Pin hängen. Die Arduino-Nano-Dok meint: „PWM: 3, 5, 6, 9, 10, and 11. Provide 8-bit PWM output with the analogWrite() function.“
Falk B. schrieb: > @Heinz peter Posch (poschi8) > >>ich habe das Problem bereits gefunden es werden bei mir 2 Ports >>verwendet, geht leider nicht anders.. > >>Wie bekomme ich das den nun am besten in den Griff? Nicht tragisch. Einfach von einem Ausgabewert zum nächsten nur jene Bits kippen welche Wertänderung in die gewünschte Richtung verursachen aber in sinnvoller Reihenfolge. So mögen immernoch Zwischenwerte rauskommen, aber nur welche Ni < zw < Ni+1. Ja: das erfordert etwas mehr als bloss 2 aufeinanderfolgende Portoperationen, geht aber auch in der "Arduinowelt" (ist ja auch bloss C/C++).
ich trinke ein Bit schrieb: > Einfach von einem Ausgabewert zum nächsten nur jene Bits kippen welche > Wertänderung in die gewünschte Richtung verursachen aber in sinnvoller > Reihenfolge. Na dann: Von 64 auf 32. Welche Änderung schlägst Du vor? zuerst auf 96 oder auf 0? Oder von 64 auf 63. Welches Bit bringt hier Annäherung? ich trinke ein Bit schrieb: > geht aber auch in der "Arduinowelt" Das geht sogar in der nicht-Arduinowelt nicht. Heinz peter P. schrieb: > Wie bekomme ich das den nun am besten in den Griff? Patch oder Redesign. Entweder ein Busregister oder die Sample&Hold-Schaltung. Oder einen externen DAC, der keine Glitches erzeugt. PWM wurde ja auch schon genannt. Gruß Jobst
Moin, Bernd K. schrieb: > ... dann vielleicht mal über einen Delta-Sigma DAC > nachdenken, Das wuerd' ich auch. Aber in Tateinheit mit z.B. den 4 Bits eines Ports, an denen der R2R Wandler haengt und die gleichzeitig beschrieben werden koennen. Man kann auch mehrbittige SD-DACs bauen. Mit R2R Netzwerken sind eh' nicht mehr als 4..6Bit vernuenftig zu realisieren. Was drueber hinausgeht sind eh' Hausnummern. Am Ausgang eines R2R Wandlers hat man uebrigens auch eine ziemlich genau definierte Impedanz, d.h. da kann man z.b. prima mit einem C nach Masse gehen und hat einen TP 1. Ordnung. Oder entsprechend Richtung OpAmp oder einzelner Transistor fuer TP 2..3 Ordnung. Gruss WK
Da scheint wohl programmiertechnisch etwas zu bremsen. Die R2R müssen natürlich voll parallel geschaltet werden. Im Rahmen dieser Genauigkeit des höchsten Bits packt man das in der Tat auch mit einer PWM.
Markus W. schrieb: > Da scheint wohl programmiertechnisch etwas zu bremsen. Eher vom Hardwaredesign des Nano. Wenn der die PWM aber schon unter Analog-Ausgabe sortiert, dann liegt es nahe, sie genau dafür zu nehmen.
Am Besten einen vordefinierten PDM-Datenstrom wie sowas in der Abbildung unten: [Pulsdichtemodulation]. Damit kommt man auch bei einem einfachen RC-Filter mit einem overhead von 10 Oktaven aus und hat trotzdem an die 60dB sfdr für die volle Bandbreite nach unten. Wenn es nur 70Hz fest sein sollen, wäre ein Sperrfilter noch besser und es reichen 5 Oktaven. Ein selbsschwingendes 24dB-Resonanz-Filter kann man sogar fast mit einem Rechteck ansteuern. Kommt alles auf die Präzisionsanforderung an.
@Jürgen S. (engineer) >Am Besten einen vordefinierten PDM-Datenstrom wie sowas in der Abbildung >unten: >[Pulsdichtemodulation]. >Damit kommt man auch bei einem einfachen RC-Filter mit einem overhead >von 10 Oktaven aus und hat trotzdem an die 60dB sfdr für die volle >Bandbreite nach unten. Wenn es nur 70Hz fest sein sollen, wäre ein >Sperrfilter noch besser und es reichen 5 Oktaven. Ein selbsschwingendes >24dB-Resonanz-Filter kann man sogar fast mit einem Rechteck ansteuern. >Kommt alles auf die Präzisionsanforderung an. Wollen wir wetten, daß diese Lösungen den OP um mindesten 40dB überfordern . . .?
So ich hab das Problem jetzt gelöst :) Hab den Code noch mal angeschaut und überarbeitet, zusätzlich habe ich noch einen Tiefpass am Ausgang nachgeschalten, jetzt schaut mein Sinus wie gezeichnet aus ;) Vielen Dank für eure Hilfe!! Ihr seid spitze :)) LG, poschi8
Thread beobachten
Seitenaufteilung abschaltenBitte 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.