automatische Bereichsumschaltung (TRMSC) funktioniert nicht

Fragen zur Software des digitalen Funktionsgenerators und des True-RMS-Messaufsatzes bitte hier stellen.
Antworten
kadun
kann c't-Lab-Bausätze bestellen
kann c't-Lab-Bausätze bestellen
Beiträge: 14
Registriert: 09.11.2008, 12:07
Wohnort: Baden-Württemberg

automatische Bereichsumschaltung (TRMSC) funktioniert nicht

Beitrag von kadun »

Hallo an das Forum,

Ich bitte um Hilfe.
Ich betreibe ein DDS mit TRMSC und habe die aktuelle Rev. 1.15 der c-Firmware geladen. Gegenüber der 1. Version gibt es viele neue Features. Vielen Dank für Eure Arbeit und die ebenfalls für dieneue Doku. Da habt Ihr eine Menge Arbeit reigesteckt. Viel mehr Bytes wird der ATmega32 wohl nicht schlucken.

Die Standard-Funktionen funktionieren prima. Ehe ich mich an den Hardwareumbau für die PWM-Funktion mache, möchte ich sicherstellen, daß sonst alles läuft.

Dabei ist mir aufgefallen, daß die automatische Bereichsumschaltung nicht arbeitet. Die manuelle Bereichsumschaltung funktioniert, ebenso werden RMS und Peak-Value auf dem TRMSC korrekt ermittelt. Beim Umschalten auf Automatik werden die Bereiche nacheinander kontinuierlich angewählt, die Firmware mag sich jedoch für keinen Bereich entscheiden, das Signal an TP5 (C4) schwankt städig zwischen Minimum und FS. Im Manuellen Betrieb funktionieren die Leds für "Overload" und "Signal" korrekt.

Ich war längere Zeit "außer Gefecht" aber ich glaube zu erinnern, daß die Automatik bei der Vorgängerversion der Firmware funktioniert hat. Variation des Wertes von C4 bringt nichts.

Hat jemand eine Idee was bei meinem ct-Lab falsch läuft?

BTW- ich habe für U8 und U10 auf der DDS Platine den AD829 eingesetzt und damit gute Ergebinsse erzielt. Tr und Tf liegen beim Rechteck unter 300nsec. Ich habe meine Ergebnisse und die Änderungen im Hardware-Forum dokumentiert.

Im Voraus vielen Dank für Eure Hilfe

Gruß
kadun
psclab38
kann c't-Lab-Konstrukteure konstruieren
kann c't-Lab-Konstrukteure konstruieren
Beiträge: 942
Registriert: 25.01.2008, 23:34

Re: automatische Bereichsumschaltung (TRMSC) funktioniert ni

Beitrag von psclab38 »

Hallo Kadun,
kadun hat geschrieben:Ich betreibe ein DDS mit TRMSC und habe die aktuelle Rev. 1.15 der c-Firmware geladen. Gegenüber der 1. Version gibt es viele neue Features. Vielen Dank für Eure Arbeit und die ebenfalls für dieneue Doku. Da habt Ihr eine Menge Arbeit reigesteckt. Viel mehr Bytes wird der ATmega32 wohl nicht schlucken.
Och, da geht schon noch was. Mit dem neuen Compiler 4.7.2 oder "compile-in-one" ist noch ein Kilobyte mehr frei.
kadun hat geschrieben:Die Standard-Funktionen funktionieren prima. Ehe ich mich an den Hardwareumbau für die PWM-Funktion mache, möchte ich sicherstellen, daß sonst alles läuft.

Dabei ist mir aufgefallen, daß die automatische Bereichsumschaltung nicht arbeitet. Die manuelle Bereichsumschaltung funktioniert, ebenso werden RMS und Peak-Value auf dem TRMSC korrekt ermittelt. Beim Umschalten auf Automatik werden die Bereiche nacheinander kontinuierlich angewählt, die Firmware mag sich jedoch für keinen Bereich entscheiden, das Signal an TP5 (C4) schwankt städig zwischen Minimum und FS. Im Manuellen Betrieb funktionieren die Leds für "Overload" und "Signal" korrekt.

Ich war längere Zeit "außer Gefecht" aber ich glaube zu erinnern, daß die Automatik bei der Vorgängerversion der Firmware funktioniert hat. Variation des Wertes von C4 bringt nichts.
Welches Messignal verwendest Du? Blinken die LEDs "Overload" und "Signal" abwechselnd?

In bestimmten Situationen kann ich das auch nachvollziehen, da müßte man (wahrscheinlich ich) mal in den Code schauen. An der Stelle ist aber sicher schon ewig nicht mehr gedreht worden. Ich vermute, es wird ein Meßbereichswechsel ausgelöst aber die Hysterese ist z. B. durch Toleranzen nicht ganz sauber. Durch den ständigen Meßbereichswechsel wackelt die Spannung an TP5 natürlich heftig.

Grüße
Paul

EDIT:
Ich hab's mir doch noch angesehen. Also: je nach Stellung des Vernierpotis oder auch abhängig zwischen welchen Bereichen man schaltet, gibt es teilweise heftige Einschwinger bei den Meßwerten.

#1:Value=101.900000
#1:Range=0
#1:Value=101.900000
#1:Range=0
#1:Value=101.900000
#1:Range=0
#1:Value=-9999.000000
#1:Range=1
#1:Value=332.000000
#1:Range=1
#1:Value=49.000000
#1:Range=1
#1:Value=117.000000
#1:Range=1
#1:Value=102.000000
#1:Range=1
#1:Value=103.000000
#1:Range=1
#1:Value=103.000000
#1:Range=1
#1:Value=103.000000

Der Knackpunkt war der Unterschwinger mit dem Wert 49.0. Der liegt natürlich deutlich unter der Hysterese (80.0) und damit schaltet die Automatik gleich wieder zurück.

Woher die Einschwinger kommen, habe ich nicht untersucht, aber da sie wohl mit der Standard-Hardware auftreten, müssen wir sie halt in Software unterdrücken. Nach einer automatischen Bereichsumschaltung des TRMSC wird nun für die nächsten 5 Meßwerte eine weitere Umschaltung unterdrückt. Das hat die Sache bei meinem Aufbau behoben.

Bitte mal ausprobieren:
Wenn's funktioniert, dann werde ich den Code einchecken.

Grüße,
Paul
Dateianhänge
DDSFirmware.hex
Testversion
(83.31 KiB) 348-mal heruntergeladen
kadun
kann c't-Lab-Bausätze bestellen
kann c't-Lab-Bausätze bestellen
Beiträge: 14
Registriert: 09.11.2008, 12:07
Wohnort: Baden-Württemberg

Re: automatische Bereichsumschaltung (TRMSC) funktioniert ni

Beitrag von kadun »

Hallo Paul,
vielen Dank für Deine schnelle Antwort kurz vor Mitternacht.

Ich habe am Oszilloskop das Signal an C4 (TP5)der TRMSC beobachtet. Bei der Fehlfunktion der Automatik blinken die beiden Leds abwechselnd und das Signal schwingt im Sekunden-Rhythmus.

Ich nehme an, daß die c-Firmware für die Bereichsumschaltung dieses Signal (bzw PA3 ADC3) auswertet. Wenn ich Deine Pläne für den Firmware-Fix nachvollziehe, müßte die Fehlfunktion verschwinden, wenn man Pin1 von U8 über eine Diode (Kathode an Pin1) und einen nachgeschalteten 200kOhm Widerstand mit dem Pin für PA3 ADC3 verbindet. Der Peak-Amplifier würde dann auf Bereichsumschaltung "nach oben" rascher reagieren und die "Software-Unterdrückung" wäre nicht notwendig. "Peak and Hold-Amplifier" sind ja stets in einer Richtung träge. Der "Hardware-Fix" ist allerdings nur dann sinnvoll, wenn die Schwelle für das Einschalten von U8A mit den Schwellen der Firmware harmoniert und das Signal an PA3 ADC3 für die Bereichsumschaltung auch verwndet wird.

Ich werde das heute probieren (bei ü72 dauert das Löten etwas länger) und mich spätestens morgen (Montag) wieder melden.

Gruß
Kadun
psclab38
kann c't-Lab-Konstrukteure konstruieren
kann c't-Lab-Konstrukteure konstruieren
Beiträge: 942
Registriert: 25.01.2008, 23:34

Re: automatische Bereichsumschaltung (TRMSC) funktioniert ni

Beitrag von psclab38 »

Hallo Kadun,
kadun hat geschrieben:Ich habe am Oszilloskop das Signal an C4 (TP5)der TRMSC beobachtet. Bei der Fehlfunktion der Automatik blinken die beiden Leds abwechselnd und das Signal schwingt im Sekunden-Rhythmus.
Das deckt sich dann mit meinen Beobachtungen.
kadun hat geschrieben:Ich nehme an, daß die c-Firmware für die Bereichsumschaltung dieses Signal (bzw PA3 ADC3) auswertet.
Nein, die Automatik wertet nur den RMS-Meßwert aus.
kadun hat geschrieben:Wenn ich Deine Pläne für den Firmware-Fix nachvollziehe, müßte die Fehlfunktion verschwinden, wenn man Pin1 von U8 über eine Diode (Kathode an Pin1) und einen nachgeschalteten 200kOhm Widerstand mit dem Pin für PA3 ADC3 verbindet. Der Peak-Amplifier würde dann auf Bereichsumschaltung "nach oben" rascher reagieren und die "Software-Unterdrückung" wäre nicht notwendig. "Peak and Hold-Amplifier" sind ja stets in einer Richtung träge.

Der "Hardware-Fix" ist allerdings nur dann sinnvoll, wenn die Schwelle für das Einschalten von U8A mit den Schwellen der Firmware harmoniert und das Signal an PA3 ADC3 für die Bereichsumschaltung auch verwndet wird.
Weil die Firmware das Signal nicht auswertet, bringt das leider nichts.
kadun hat geschrieben:Ich werde das heute probieren (bei ü72 dauert das Löten etwas länger) und mich spätestens morgen (Montag) wieder melden.
Von einer Hardwareänderung wäre ich nicht begeistert, weil dann alle DDS-Verwender das wieder einzeln manuell nachrüsten müßten. Außerdem kuriert sie am Symptom und nicht an der Ursache. Der Überschwinger ist ja auch bei der RMS-Messung sichtbar (siehe mein letztes Posting).

Die Firmwareänderung wäre keineswegs unelegant oder unüblich. Probiere sie bitte aus, ob sie Dein Problem behebt.

Grüße
Paul
kadun
kann c't-Lab-Bausätze bestellen
kann c't-Lab-Bausätze bestellen
Beiträge: 14
Registriert: 09.11.2008, 12:07
Wohnort: Baden-Württemberg

Re: automatische Bereichsumschaltung (TRMSC) funktioniert ni

Beitrag von kadun »

Hallo Paul,
ich habe meine Lötarbeiten abgeschlossen, hatte aber -wie von Dir vorausgesagt-keinen durchschlagenden Erfolg.

Ich habe jedoch bei weiteren Messungen sehen können, daß bei jeder Bereichsumschaltung an den Ausgängen der Opamps U9 und U7 Glitches entstehen. Das wird wohl auch durch Einstreungen in die hochohmige Beschaltung von U9 gefördert und ändert sich auch mit dem Abstand der TRMSC zur Grundplatte.

Nachdem Du mir das Firmware-Funktionsprinzip der Automatik erklärt hast, erscheint mir Dein Lösungsansatz logisch und erfolversprechend.
Wenn die Automatik eine Bereichsumschaltung auslöst, muß man für eine erneute Auslösung warten, bis sich der neue Wert an PA2 ADC2 stabilisiert hat. Dabei spielt sowohl die Signallaufzeit im LTC 1967 als auch die Verzögerung der anschließenden Filterschaltung eine Rolle.

Mit der neuen Test-Firmware läuft die automatische Bereichsumschaltung auf meiner TRMSC fast perfekt. Lediglich in einem ganz eingen Amplitudenbereich zappelt es noch ein bißchen. Vielleicht kannst Du vor dem Einschecken Bei der Verzögerug noch ein Bit dazupacken.

Nochmals vielen Dank für Deine schnelle Hilfe.

Gruß
Kadun
psclab38
kann c't-Lab-Konstrukteure konstruieren
kann c't-Lab-Konstrukteure konstruieren
Beiträge: 942
Registriert: 25.01.2008, 23:34

Re: automatische Bereichsumschaltung (TRMSC) funktioniert ni

Beitrag von psclab38 »

kadun hat geschrieben:Mit der neuen Test-Firmware läuft die automatische Bereichsumschaltung auf meiner TRMSC fast perfekt. Lediglich in einem ganz eingen Amplitudenbereich zappelt es noch ein bißchen. Vielleicht kannst Du vor dem Einschecken Bei der Verzögerug noch ein Bit dazupacken.
Bevor ich jetzt rate, wieviel noch nötig ist, kommt hier nochmal eine neue Testversion. Da ist die Verzögerung jetzt eine Sekunde = 8 Messungen. Aber: es ist eine Testausgabe auf dem Bus eingebaut, damit ich sehen kann, was bei Dir / Euch da abgeht. Ich habe vorhin gesehen, daß sich vier Leute die alte Testversion runtergeladen haben. Bitte nur verwenden, wenn Ihr mittesten und das Ergebnis hier posten wollt.

Mit einem Terminalprogramm kann man dann z.B eine solche Ausgabe abfangen:

#1:Range=0, Value=101.800000
#1:Range=0, Value=101.800000
#1:Range=0, Value=102.000000
#1:Range=0, Value=-9999.000000
#1:Range=1, Value=332.000000
#1:Range=1, Value=48.000000
#1:Range=1, Value=117.000000
#1:Range=1, Value=101.000000
#1:Range=1, Value=103.000000
#1:Range=1, Value=103.000000
#1:Range=1, Value=103.000000

Ich vermute aber mal, daß Du gar kein Problem der Automatik siehst sondern eine Nervosität der Komparatoren aus U8; die haben keine Hysterese.
kadun hat geschrieben:Nochmals vielen Dank für Deine schnelle Hilfe.
Gerne geschehen.

Grüße
Paul
Dateianhänge
DDSFirmware.hex
Testversion!!! siehe Text!
(83.68 KiB) 319-mal heruntergeladen
kadun
kann c't-Lab-Bausätze bestellen
kann c't-Lab-Bausätze bestellen
Beiträge: 14
Registriert: 09.11.2008, 12:07
Wohnort: Baden-Württemberg

Re: automatische Bereichsumschaltung (TRMSC) funktioniert ni

Beitrag von kadun »

Hallo Paul,
Bei mir hat es leider etwas länger gedauert.
Ich vermute aber mal, daß Du gar kein Problem der Automatik siehst sondern eine Nervosität der Komparatoren aus U8; die haben keine Hysterese.
Ich kann definitiv ausschließen, daß mein Problem mit den Komperatoren an U8 zusammenhängt, da ich beim Testen des Fehlerzustands immer das Signal an TP5 (Peak-Amplifier) am Scope beobachtet habe.
Dies schwankt dann im Sekundenrhthmus zwischen 0V und einem Maximalwert von ca. 3V und wird dabei nie negativ.

Die neue Testsoftware hat sich zunächst ähnlich verhalten wie der Vorgänger. In einem schmalen Bereich um den Umschaltpunkt traten immer noch Instabilitäten auf. Ausgehend von kleinen Werten traten im Automatic-Mode bei Level 103mV dauerhaft Instabilitäten auf (siehe Anlage 103mV 1kHz.txt, dieTRMC Skalierwerte waren noch nicht justiert, daher die Abweichung beim ersten Wert des Logs). Bemerkenswert sind die negativen Werte die sich auch bestätigen ließen,wenn man das Scope an TP4 (Buffer Amplifier) anschließt. Ich habe das Log abgebrochen, es traten immer nur die Range0 und Range1 auf.

Offenbar ist der LTC1967 und siene Außenbeschaltung in der Lage bei bestimmten Überlastzuständen negative Ausgangsspannungen zu generieren. Evtl. wird dabei auch die Ausgangsspannung von U6 (7805) temporär in Mitleidenschaft gezogen, auch die Zeitkonstante C7 * R21 und der Elko C11 wird eine Rolle spielen.

Beim langsamen Erhöhen auf Level 107mV (siehe Anlage 107mV 1kHz.txt) war der Spuk vorbei.

Ich benutze deshalb die Vergangenheitsform, weil ich beim Versuch die Vörgänge zu dokumentieren den Portausgang für "Gain10" zerstört habe (vermutlich Kurzschluß per der Tastkopfspitze mit Pin 6 von U5 zu einem Nachbarpin, bitte nicht nachmachen). Da ich augentechnisch nicht in der Lage bin den ATIMEGA 32 zu wechseln, kann ich nicht nun nicht weiter testen.
Ich kann aber den 10V-Bereich per Hardware erzwingen und damit die TRMSC weiterhin nutzen.

Sicher ist, daß der Ausgang des Peak-Amplifier schneller reagiert als der LTC1967 und bei Übersteuerung und keine negativen Spannungen erzeugt. Vielleicht ist dieses Signal eine bessere Basis für die Automatik.

Nochmals vielen Dank für Deine Hilfe, leider kann ich momentan nichts weiter unternehmen.

Gruß
Kadun
Dateianhänge
Log 107mV 1KHz.txt
(1.42 KiB) 336-mal heruntergeladen
Log 103mv 1kHz.txt
(595 Bytes) 339-mal heruntergeladen
psclab38
kann c't-Lab-Konstrukteure konstruieren
kann c't-Lab-Konstrukteure konstruieren
Beiträge: 942
Registriert: 25.01.2008, 23:34

Re: automatische Bereichsumschaltung (TRMSC) funktioniert ni

Beitrag von psclab38 »

Hallo Kadun,
kadun hat geschrieben: Bei mir hat es leider etwas länger gedauert.
Kein Problem.
kadun hat geschrieben:
Ich vermute aber mal, daß Du gar kein Problem der Automatik siehst sondern eine Nervosität der Komparatoren aus U8; die haben keine Hysterese.
Ich kann definitiv ausschließen, daß mein Problem mit den Komperatoren an U8 zusammenhängt, da ich beim Testen des Fehlerzustands immer das Signal an TP5 (Peak-Amplifier) am Scope beobachtet habe.
Dies schwankt dann im Sekundenrhthmus zwischen 0V und einem Maximalwert von ca. 3V und wird dabei nie negativ.
Der Sekundenrhythmus kommt von der derzeitigen Verzögerung um 8*125ms.
kadun hat geschrieben:Die neue Testsoftware hat sich zunächst ähnlich verhalten wie der Vorgänger. In einem schmalen Bereich um den Umschaltpunkt traten immer noch Instabilitäten auf. Ausgehend von kleinen Werten traten im Automatic-Mode bei Level 103mV dauerhaft Instabilitäten auf (siehe Anlage 103mV 1kHz.txt, dieTRMC Skalierwerte waren noch nicht justiert, daher die Abweichung beim ersten Wert des Logs). Bemerkenswert sind die negativen Werte die sich auch bestätigen ließen,wenn man das Scope an TP4 (Buffer Amplifier) anschließt. Ich habe das Log abgebrochen, es traten immer nur die Range0 und Range1 auf.
Die neue Software hat ja auch nur etwas mehr Verzögerung gehabt; das war nur zum Testen.
kadun hat geschrieben:Offenbar ist der LTC1967 und siene Außenbeschaltung in der Lage bei bestimmten Überlastzuständen negative Ausgangsspannungen zu generieren.
Hmm. Wenn Du den "-9999.0" Meßwert meinst, der wird von der Firmware auf dem Bus als Anzeige für "Overflow" genutzt. Der Wert ist nicht echt. Der LTC1967/8 kann übrigens gar keine negativen Ausgangssignale produzieren, der kommt nicht mal ganz bis Null runter; allenfalls schwingt der DC Ripple Filter.
kadun hat geschrieben:Evtl. wird dabei auch die Ausgangsspannung von U6 (7805) temporär in Mitleidenschaft gezogen,...
Das glaube ich nicht.
kadun hat geschrieben:... auch die Zeitkonstante C7 * R21 und der Elko C11 wird eine Rolle spielen.
Ersteres weniger, letzteres eher. Ich habe nämlich grade nachgesehen und festgestellt, daß ich gar nie den C11 auf 10µF getauscht hatte (oder wieder zurückgegangen bin, aus welchem Grund auch immer; ein Elko ist vielleicht auch suboptimal). Damit ist die Zeitkonstante für's Einschwingen bei Dir um den Faktor 5 höher, was man auch aus dem heftigen Klingeln bei diesen Deinen Meßwerten rauslesen kann:

#4:Range=1, Value=93.000000
#4:Range=1, Value=86.000000 <<--- Meßwert sinkt unter die Schwelle von 90, Umschaltung auf Range 0
#4:Range=0, Value=41.700001
#4:Range=0, Value=-9999.000000
#4:Range=0, Value=-9999.000000
#4:Range=0, Value=-9999.000000
#4:Range=0, Value=89.700005
#4:Range=0, Value=79.000000
#4:Range=0, Value=97.500000
#4:Range=0, Value=-9999.000000
#4:Range=0, Value=-9999.000000 <<--- Verzögerung abgelaufen, Meßwert im Overflow, Umschaltung auf Range 1
#4:Range=1, Value=-9999.000000
#4:Range=1, Value=-9999.000000
#4:Range=1, Value=811.000000
#4:Range=1, Value=427.000000
#4:Range=1, Value=168.000000
#4:Range=1, Value=110.000000

Leider ist das Log etwas kurz, aber ich vermute Folgendes:
Bei konstanter Eingangsspannung von 103mV ergibt der eingeschwungene Meßwert
- im Range 1 ca. 85mV (das liegt unterhalb der Automatikschwelle)
- im Range 0 ca. 101mV (bzw. etwas mehr, eben im Overflow)

Dabei ist es egal wie lange die Verzögerung ist, das muß immer schwingen! Die Verzögerung beeinflußt dann nur die Frequenz.
Damit sind wir wieder bei meiner allerersten Theorie aus meinem ersten Posting: Toleranzen. Hast Du 1%ige Widerstände an U7 verwendet? Wäre das Verhalten nicht besser geworden durch die Kalibrierung?

Ein Oszillogramm würde Klarheit bringen, ob es wirklich so stark klingelt: Das Einschwingen beim Umschalten des 10*Gain (beide Richtungen) an C11 und TP4 im Vergleich.

kadun hat geschrieben:Ich benutze deshalb die Vergangenheitsform, weil ich beim Versuch die Vörgänge zu dokumentieren den Portausgang für "Gain10" zerstört habe (vermutlich Kurzschluß per der Tastkopfspitze mit Pin 6 von U5 zu einem Nachbarpin, bitte nicht nachmachen). Da ich augentechnisch nicht in der Lage bin den ATIMEGA 32 zu wechseln, kann ich nicht nun nicht weiter testen.
Ich kann aber den 10V-Bereich per Hardware erzwingen und damit die TRMSC weiterhin nutzen.
...
Nochmals vielen Dank für Deine Hilfe, leider kann ich momentan nichts weiter unternehmen.
Schick' mir mal eine PM.
kadun hat geschrieben:Sicher ist, daß der Ausgang des Peak-Amplifier schneller reagiert als der LTC1967 und bei Übersteuerung und keine negativen Spannungen erzeugt. Vielleicht ist dieses Signal eine bessere Basis für die Automatik.
Davon bin ich nicht überzeugt, weil das TRMSC-Modul eben für RMS-Messungen gedacht ist und der Peak-Wert stark von der Signalform beeinflußt wird. Das könnte man für Sinus einrichten, aber was ist dann wenn es eben kein Sinus ist? Ja, ich weiß, daß der AC-Peak-Amp um U1 und der PeakDetector um U8 auf Sinus fixiert sind. Der LTC1967/8 ist es aber nicht.

Viele Grüße
Paul
kadun
kann c't-Lab-Bausätze bestellen
kann c't-Lab-Bausätze bestellen
Beiträge: 14
Registriert: 09.11.2008, 12:07
Wohnort: Baden-Württemberg

Re: automatische Bereichsumschaltung (TRMSC) funktioniert ni

Beitrag von kadun »

Hallo an das Forum,

Nachdem meine DDS nun wieder funktioniert, konnte ich das Zeitverhalten beim Umschalten der Bereiche auf der TRMSC-Baugruppe untersuchen. Ich habe manuell zwischen den Bereichen 1V und 10V umgeschaltet.

Meine TRMSC ist mit U4=LTC1968, C11=4,7µF und R15=47kOhm bestückt. Damit können bei sinusförmiger Ansteuerungen RMS Werte bei Frequenzen >10Hz korrekt gemessen werden.

Für das Zeitverhalten (siehe Bild1 und Bild2) habe die TRMSC mit einem Sinussignal mit Level 860mV (Effektivwert) und 500 Hz angesteuert. Das Scope ist an Meßpunkte auf der TRMSC angeschlossen:
Kanal4 U5Pin6 (Gain10, Bereichsumschaltung, Vorsicht Kurzschluß zerstört Port des ATIMEGA)
Kanal3 TP4 (RMS-Signal)
Kanal3 TP5 (Peak-Signal)

Bild 1 zeigt den Signalverlauf nach dem Umschalten vom 10V in den 1 V Bereich.
Das RMS-Signal steigt nach einer Totzeit von ca.50 msec mit einer Anstiegszeit von ca.500msec auf den neuen Endwert. Das Peak-Signal erreicht seinen neuen Endwert in ca. 20msec (Sample-Funktion des Peak-Amplifiers mit Stufen von 2msec wegen des 500Hz-Sinus).

Bild2 zeigt den Signalverlauf nach dem Zurückschalten in den 10V-Bereich.
Das RMS-Signal fällt nach einer Totzeit von ca. 50 msec mit einer Fallzeit von ca. 500 msec auf den neuen Endwert. Das Peak-Signal erreicht seinen neuen Endwert erst nach ca. 900msec (Hold-Funktion des Peak-Amplifiers nach einer e-Funktion mit der Zeitkonstante C4*(R1+R4+R3+R8)).

Die Messungen zeigen, daß das Peak-Signal schon aus Zeitgründen ungeeignet als Kriterium für die Bereichsumschaltung ist.

Im Automatik-Betrieb für die Bereichsumschaltung können Schwingungen nach der Bereichsumschaltung vermieden werden, wenn man die TRMSC mit den Potis R5 und R6 so abgleicht, daß sich für 10% des Bereichsendwerts 100% des Bereichsendwerts korrekte RMS-Werte (entsprechend den Level-Werten der DDS) ergeben und die Firmware nach der Bereichsumschaltung im Automatikbetrieb erst nach einer Wartezeit von ca. 500msec den RMS-Wert für eine Bereichsumschaltung erneut auswertet.

Nachmals vielen Dank an das Forum, insbesondere an Paul, für die Hilfe.
Mein Problem wurde gelöst.

Gruß
Kadun
Dateianhänge
Bild2  nach Reparatur.jpg
Bild2 nach Reparatur.jpg (17.4 KiB) 6823 mal betrachtet
Umschalten 10V Bereich =&gt; 1V
Umschalten 10V Bereich => 1V
Bild1 nach Reparatur.jpg (17.57 KiB) 6823 mal betrachtet
psclab38
kann c't-Lab-Konstrukteure konstruieren
kann c't-Lab-Konstrukteure konstruieren
Beiträge: 942
Registriert: 25.01.2008, 23:34

Re: automatische Bereichsumschaltung (TRMSC) funktioniert ni

Beitrag von psclab38 »

Hallo an alle, die das Thema verfolgt haben:

es gibt eine neue Firmware für die DDS-C, die beim automatischen Bereichswechsel der TRMSC jetzt ein paar Messungen lang wartet, bevor sie evtl. erneut wechselt.
Sie liegt bei Sourceforge; neu ist je eine Version für die Standardhardware und den Umbau mit der PWM. Viel Spaß!

Viele Grüße
Paul

PS: die Versionen weiter oben im Thread bitte NICHT verwenden, die enthalten Debugausgaben!
Antworten