Sinus aus R2R filtern

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...

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).

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.

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.

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

Genau das befürchte ich :-)

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.“

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

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