Fehlfunktion bei der Rechteckspannungseinstellung mit Offset

[Bernd_Stein]

Hallo zusammen,

ich wollte mein c't-Lab nutzen ( DDS mit huckepack TRMSC ) um einen Transistorschalter anzusteuern.
Hierbei ist mir aufgefallen, das es in der Funktion Rechteckspannung ( squ ) in Verbindung mit der Offseteinstellung zu einer Fehlfunktion kommt und wollte nun erstmal wissen, ob dies auch bei Euch der Fall ist oder nur bei mir.

Die Firmwareversion des DDS-Boards ist 3.64.
Die Frequenz ist die voreingestellte => 1000Hz.
Der Eingangsspannungsbereich der TRMSC ist auf In => 10V eingestellt.
Der Ausgangsspannungspegel ist auf 3460mV ( PeakL ) eingestellt.
Und wie bereits erwähnt ist die Signalform squ ( Funktion ).

Der GND-Anschluß PL2 (AC Input ) der TRMSC-Huckpackplatine ist nicht an der BNC-Buchse angeschlossen ( PIN 1 )
und der Eingang ( PIN 2 ) geht auf den mittelpin von der BNC-Buchse, wo das DDS-Signal für die Außenwelt abgenommen wird.

Nun zum Problem :

Wenn ich nun den Offset schnell über den Drehschalter auf über +1,8V stelle, wird das Display dunkel und ich höre Summgeräusche und das Osziloskopbild zeigt undefinierbare Striche und Punkte.

Wenn ich den Drehschalter sehr langsam drehe springt der Offset auf dem Oszi sichtbar ab ca. +1,7V zurück auf ca. +0,8V zurück.



Bernd_Stein

[ylf]

Ich habe eine neuere Firmware Version und kann das Problem auf die Schnelle nicht nachvollziehen.
Habe gerade keine Zeit, melde mich später noch mal, wenn ich das genauer nachvollziehen kann.
War denn der Abgleich beider Module erfolgreich?
Q1 ist sehr ESD empfindlich. Bei Problemen mit der Rechteckform war dieser öfters beteiligt.

[psclab38]

Hierbei ist mir aufgefallen, das es in der Funktion Rechteckspannung ( squ ) in Verbindung mit der Offseteinstellung zu einer Fehlfunktion kommt und wollte nun erstmal wissen, ob dies auch bei Euch der Fall ist oder nur bei mir.

Die Firmwareversion des DDS-Boards ist 3.64.

Der Bug ist bekannt und in der Pascal-Firmware V3.70 vom 22.02.2008 behoben: "Logik-Gleichspannungpegel-Bug behoben".

Nun zum Problem :

Wenn ich nun den Offset schnell über den Drehschalter auf über +1,8V stelle, wird das Display dunkel und ich höre Summgeräusche und das Osziloskopbild zeigt undefinierbare Striche und Punkte.

Wenn ich den Drehschalter sehr langsam drehe springt der Offset auf dem Oszi sichtbar ab ca. +1,7V zurück auf ca. +0,8V zurück.

Und bei der gleichen Version steht dann noch dabei "Inkrementageber-Beschleunigungsfunktion stark verbessert".

Vielleicht versuchst Du erst mal ein Update auf die neueste Version 3.70.

Grüße
Paul

[Bernd_Stein]

Die Firmwareversion des DDS-Boards ist 3.64.

Der Bug ist bekannt und in der Pascal-Firmware V3.70 vom 22.02.2008 behoben: "Logik-Gleichspannungpegel-Bug behoben".

Vielleicht versuchst Du erst mal ein Update auf die neueste Version 3.70.



Bin erstaunt so schnell und dazu auch noch gute Antworten zu erhalten.
Vielen Dank.
Das c't-Lab Projekt liegt ja nun schon gute 5 Jahre zurück. Weiß gar nicht mehr wie ich dazu gekommen bin.
Die Zeitschrift c't ist ja eher für PC-Freaks interessant. Das Projekt ist wirklich eine gute Idee und ich freue mich, das es immer noch nicht tod ist.
In diesem zusammenhang vielen Dank an CM ( Carsten Meyer ), seine unterstützenden Kollegen bei c't und natürlch allen Usern, die dieses Projekt verbessert und dadurch natürlich am Leben erhalten.

...
War denn der Abgleich beider Module erfolgreich?
Q1 ist sehr ESD empfindlich. Bei Problemen mit der Rechteckform war dieser öfters beteiligt.

Ja, der Abgleich war so weit ich mich erinnern kann erfolgreich. Das ganze liegt schon ein paar Jahre zurück.
Q1 der BS170 ist wirklich sehr ESD empfindlich, habe schon öfters bei Basteleien mit diesem feststellen müssen,
das er defekt war. Werde mich jetzt erstmal mit dem Firmwareupdate beschäfitgen.

Bernd_Stein

[Bernd_Stein]

Der Bug ist bekannt und in der Pascal-Firmware V3.70 vom 22.02.2008 behoben: "Logik-Gleichspannungpegel-Bug behoben".

Dies war ein Volltreffer. Ich benutze zwar die Version 3.71 aber es funktioniert. Es war gar nicht so einfach wie ich dachte, denn Firmware DDS-V3.70 oder so, gibt es irgendwie nicht in solch eindeutiger Form bzw. habe ich nicht gefunden.
Sich das hier vorher durchzulesen ist ganz nützlich, wenn man Erfolg haben möchte :
http://www.heise.de/ct/projekte/machmit ... i/FirmWare
Habe meine Version hierher :
https://www.heise.de:444/svn/ctlab/Firmware/

Nochmals Danke.


Bernd_Stein

[psclab38]

Dies war ein Volltreffer. Ich benutze zwar die Version 3.71 aber es funktioniert. Es war gar nicht so einfach wie ich dachte, denn Firmware DDS-V3.70 oder so, gibt es irgendwie nicht in solch eindeutiger Form bzw. habe ich nicht gefunden.

Sorry, ich hatte einfach direkt im Code nachgesehen und da steht als letztes:

Code: Alles auswählen

22.02.2008 #3.70 Bug in Peak-Anzeige beseitigt, 1000-Hz-Anfangseinstellung,
                 Inkrementageber-Beschleunigungsfunktion stark verbessert,
                 Logik-Gleichspannungpegel-Bug behoben,
                 Init-Parameter OPT 0 für Logikpegel eingeführt

Erst ein ganzes Stück weiter unten steht dann:

Code: Alles auswählen

  Vers1Str                   = '3.71 [DDS by CM/c''t 03/2007]'; 
  Vers3Str                   = 'DDS 3.71'; 

Damit hast Du schon das richtige gefunden. Die wichtige Aussage war, daß die Fehler bei der von Dir verwendeten Version bekannt waren. Neuer ist meistens besser.

Nochmals Danke.

Gerne.
Paul

[Bernd_Stein]

Damit hast Du schon das richtige gefunden.
...

Da bin ich mir jetzt gar nicht mehr sicher.
Die DDS-C Version finde ich laut der Beschreibung um ein vielfaches besser. Ich blicke im Moment nicht durch, was an Hardwareänderungen zu machen ist.

PWM-Erweiterung mit zwei Varianten OC1A und OC1B.
Die Verwendung von OC1B scheint ja von Vorteil, da hier nur eine neue Verbindung gemacht werden muß ( U2 Pin 13 nach C7 ) sowie das Entfernen von C7
und der Sync-Ausgang muß auch noch modifiziert werden durch die Transistorschaltung ( BC337, BC327 ).

Ist dies wirklich alles an Harwareänderungen am DDS-Board ?

Bernd_Stein

[psclab38]

Damit hast Du schon das richtige gefunden. ...

Da bin ich mir jetzt gar nicht mehr sicher.

Naja, wenn Du bei der Original-Firmware bleiben wolltest, dann ist die V3.71 die letzte.

Die DDS-C Version finde ich laut der Beschreibung um ein vielfaches besser.

Das gefällt mir natürlich, weil ich dran mitgearbeitet habe.

Ich blicke im Moment nicht durch, was an Hardwareänderungen zu machen ist.

Im Prinzip brauchst Du keine Hardwareänderungen, wenn Du PWM und den Burst+Sweep (und damit Sync-OUT) nicht unbedingt nutzen willst (ich weiß gar nicht, ob die Pascal-FW den Sync-Ausgang überhaupt ansteuert). Wenn aber doch...

PWM-Erweiterung mit zwei Varianten OC1A und OC1B.
Die Verwendung von OC1B scheint ja von Vorteil, da hier nur eine neue Verbindung gemacht werden muß ( U2 Pin 13 nach C7 ) sowie das Entfernen von C7
und der Sync-Ausgang muß auch noch modifiziert werden durch die Transistorschaltung ( BC337, BC327 ).

Ist dies wirklich alles an Hardwareänderungen am DDS-Board ?

Die PWM-Option ist exklusiv (entweder/oder) mit dem Audio Ext-In. Dies und die PWM-Varianten OC1A und OC1B sind Compileroptionen.

Die Hardware-Beschreibung in dem PDF ist bezüglich dem PWM-Umbau nicht ganz vollständig; da gibt es noch Probleme mit dem Offset, der vor U8 eingehalten werden muß. Nachdem Thoralt zeitbedingt nicht mehr dran arbeiten konnte, habe ich noch ein paar Ergänzungen vorgenommen. Schau mal in dem Thread ganz am Ende (Datum 10.05.2012):
viewtopic.php?f=13&t=443&start=75
Es hatte sich leider niemand mehr dafür interessiert, oder zumindest hat sich keiner gemeldet. Drum ist das leider in der Luft hängengeblieben.

Gruß,
Paul

Ach ja, da fällt mir ein, daß ich mich noch über diesen Satz in Deinem ersten Posting gewundert habe:

Der GND-Anschluß PL2 (AC Input ) der TRMSC-Huckpackplatine ist nicht an der BNC-Buchse angeschlossen ( PIN 1 )
und der Eingang ( PIN 2 ) geht auf den mittelpin von der BNC-Buchse, wo das DDS-Signal für die Außenwelt abgenommen wird.

Der TRMSC_Eingang ist ein selbstständiger Eingang, der auf eine extra-Buchse geführt werden sollte. Man kann ihn natürlich mit dem DDS-Ausgang verbinden, aber wozu?

[Bernd_Stein]

Die PWM-Option ist exklusiv (entweder/oder) mit dem Audio Ext-In. Dies und die PWM-Varianten OC1A und OC1B sind Compileroptionen.

Die Sache wird leider immer komplizierter für mich.
Heute aufgewacht, denke ich was soll ich da lange überlegen und hier im Forum die Zeit der anderen in Anspruch nehmen, die haben schließlich auch nicht mehr davon als ich :
" Mach einfach die Brücke von U2 ( ATmega32 ) Pin 13 zu C7 bzw. U12a Pin 3, entferne C7 und brenne die Firmware DDS-C , also die .hex und .eep Dateien ".
Aber nach dem gefummel mit der Brücke kommt nun eine für mich undurchschaubare Flut von Dateien.
http://dcg-firmware.cvs.sourceforge.net ... mware/dds/

Meine Gedanken hierzu.
DDSFirmware.aps ist wahrscheinlich das richtige, aber da sind ja keine .hex und .eep Datein. Also wieder nachforschen was unter der Dateienendung .aps zu verstehen ist. Aha, Visual C++ Resource File.
Und wieder ein Problem : " Was ist ein Resource File ? "
Das www bringt viele Erklärungen in englisch, das ist schon mal nichts für mich. Nächster Gedanke : " Ist das Überhaupt wichtig für mich zu wissen ? und überhaupt war nicht ursprünglich die Rede von der Version 1.7, also eher unter .cprojekt gucken ?

Die Hardware-Beschreibung in dem PDF ist bezüglich dem PWM-Umbau nicht ganz vollständig; da gibt es noch Probleme mit dem Offset, der vor U8 eingehalten werden muß.

Wenn also die Änderung von Orginalsoftware ( 3.71 von CM ) auf DDS-C ( Gemeinschaftsarbeit von Thoralt Franz, Jörg Wilke, Paul Schmid, Karsten Schmidt ), die geschilderten Verbesserungen hervorbringen soll, muss ich ausser der Brücke nur noch R22 ersetzen ?
Die schnöde Lösung die unten in deinem Post hierzu nötig wäre, würde mir eingentlich reichen.

Vorschlag zur Modifikation für PWM statt Audio-in:
...
Notfalls täte es auch ein ausgemessener Widerstand von Pin2/U12a nach -15V (bei mir ca.230k). Aber wer will schon eine solch schnöde Lösung.

Ist hier mit " PWM in " der Pin 13 von U2 zu verstehen ?
viewtopic.php?f=13&t=443&start=75#p3925

Es hatte sich leider niemand mehr dafür interessiert, oder zumindest hat sich keiner gemeldet. Drum ist das leider in der Luft hängengeblieben.

Meinst Du mit niemand deine drei Mitstreiter ?
Ansonsten könnte ich mir schon vorstellen, das es da genug andere Interessenten gab, diese jedoch genauso wie ich da nicht durchgestiegen sind und es deshalb gleich sein gelassen haben.

Gruß,
Paul

Demnach bist Du Paul Schmid.

Ach ja, da fällt mir ein, daß ich mich noch über diesen Satz in Deinem ersten Posting gewundert habe:
...
Der TRMSC_Eingang ist ein selbstständiger Eingang, der auf eine extra-Buchse geführt werden sollte. Man kann ihn natürlich mit dem DDS-Ausgang verbinden, aber wozu?

Ach so. Ich dachte immer der DDS-Ausgang muß wieder mit der TRMSC-Platine eingelesen werden, um Beispielsweise den Menüpunkt In = xyz Volt anzeigen zu können.

Wie Du siehst bin ich einfach ein User, der schon froh ist die DDS-Platine komplett selbst nachgebaut zu haben und dies sogar funktionsfähig.
Ich würde gerne von Eurer Mühe bezüglich dieser Sache mitprofitieren. Es wäre wiklich schade falls Eure Mühe nicht den Nutzen bringen würde den Ihr damit erreichen wolltet.

Also bitte ich Dich bzw. Euch, schreibt für einen DAU welche Hardwareänderungen nun genau vorgenommen werden müssen und wo er die passende Software hierzu findet.

Bernd_Stein

[ylf]

Ach so. Ich dachte immer der DDS-Ausgang muß wieder mit der TRMSC-Platine eingelesen werden, um Beispielsweise den Menüpunkt In = xyz Volt anzeigen zu können.

Um die Ausgangsspannung vom DDS anzuzeigen, ist der TRMSC nicht nötig, lediglich für die sicherlich von dir gemeinte Funktion "In 1V" am Panel, die das Messen von externen Wechselspannungen ermöglicht. Deshalb der separate Eingang. Richtig Sinn macht die Erweiterung aber erst in Verbindung mit entsprechenden Computeranwendungen, wie z.B. der Sweep Analyzer VI von Carsten Meyer. Damit lassen sich dann automatisch Frequenzgänge ermitteln. Das sieht dann so aus:DDS Spielereien
Eigentlich braucht man die TRMSC beim DDS nicht, wenn man ein DIV hat. Das DIV kam aber erst viel später.

[psclab38]

Die Sache wird leider immer komplizierter für mich.
... und brenne die Firmware DDS-C , also die .hex und .eep Dateien ".
Aber nach dem gefummel mit der Brücke kommt nun eine für mich undurchschaubare Flut von Dateien.
http://dcg-firmware.cvs.sourceforge.net ... mware/dds/

Meine Gedanken hierzu.
DDSFirmware.aps ist wahrscheinlich das richtige, aber da sind ja keine .hex und .eep Datein. Also wieder nachforschen was unter der Dateienendung .aps zu verstehen ist. Aha, Visual C++ Resource File.
Und wieder ein Problem : " Was ist ein Resource File ? "
Das www bringt viele Erklärungen in englisch, das ist schon mal nichts für mich. Nächster Gedanke : " Ist das Überhaupt wichtig für mich zu wissen ? und überhaupt war nicht ursprünglich die Rede von der Version 1.7, also eher unter .cprojekt gucken ?

Der erste Gedanke ist doch richtig gewesen, denn Du kannst nur ein Hexfile in den Controller brennen. In dem Verzeichnis auf Sourceforge liegt aber keines, weil das "nur" die Quellen sind (und die Konfigurationsdateien für die Entwicklungsumgebung, wie etwa das aps-File).
Die fertigen Hexfiles findest eine Ebene höher und dann da "ct-lab c-firmware" mit den Hexfiles:
http://dcg-firmware.cvs.sourceforge.net ... -firmware/.
Allerdings hatte ich aufgrund des schwachen Echos dort schon einige Zeit keine neue Version des Hexfiles für das DDS abgelegt. Das kann ich später gerne nachholen. Selbstcompilieren ist aber auch nicht allzu schwer, wir verwenden ja eben einen frei verfügbaren Compiler.

Es gibt übrigens kein eep-File, die C-Firmwaren initialisieren das EEPROM selbständig.

Ist hier mit " PWM in " der Pin 13 von U2 zu verstehen ?
viewtopic.php?f=13&t=443&start=75#p3925

Genau. Den zusätzlichen Serienwiderstand nicht vergessen. Der ist in dem PDF nicht drin.

Also bitte ich Dich bzw. Euch, schreibt für einen DAU welche Hardwareänderungen nun genau vorgenommen werden müssen...

Wie gesagt, die Arbeit ist offen liegengeblieben. Ich hatte da ein paar Sachen notiert:

Code: Alles auswählen

	- new connection from controller PWM out to PIN3/U12a via new resistor 47k
	- replace R19 with 4k7
	- replace R13 with adjustable resistor 10k or 4k7 (recommended)
	- replace C28 with bridge

	- PWM offset option 1a: additional 180k + adj_100k from Pin2/U12a to -15V (Pin4/U12a)
	- PWM offset option 1b: additional -15V (Pin4/U12a) - 47k + adj_100k (to Pin2/U12a) - 47k - +15V (Pin8/U12a)

	- PWM amplitude: adjust R13 to get correct amplitude in PWM mode
	- PWM offset: 	adjust new adjustable resistor for correct offset
	- repeat both of the above for the offset option 1a/b as both settings influence each other.

Nochmal, das ist mein Experimentierstadium. Ansonsten bitte ich um Geduld; ich helfe Dir gerne, aber eine fertige Komplettanleitung auf dem letzten Stand gibt's halt noch nicht.
Wenn Du dann bestätigen kannst, daß das so funktioniert, erweitere ich auch gerne die Doku.

Grüße
Paul

[Bernd_Stein]

Nochmal, das ist mein Experimentierstadium. Ansonsten bitte ich um Geduld; ich helfe Dir gerne, aber eine fertige Komplettanleitung auf dem letzten Stand gibt's halt noch nicht.
Wenn Du dann bestätigen kannst, daß das so funktioniert, erweitere ich auch gerne die Doku.

Bis auf die Synchronisierschaltung habe ich nun die erforderlichen Hardwareänderungen vorgenommen und zwar mit der schöden Lösung, um PWM mittels OC1B des µCs nutzen zu können und das Hexfile 1.14 ( Firmware ) gebrannt. Auch wenn nicht alles perfekt ist ( dies kann auch an meiner selbstgeätzten Platine liegen ), finde ich das man mit der DDS-C Firmware einen vielfältigen Frequenzgenerator parat hat.

Leider habe ich an dem Ding soviel experimentiert, das sich die Frequenz nicht mehr sofort verstellen ließ, sondern diese Änderung erst nachdem Wechsel zu einer anderen Wellenform angenommen wurde.
Aus,- und nach einer Weile wieder einschalten brachte leider keine Besserung.
Aber ein nochmaliges brennen der Firmware schaffte abhilfe.

Nochmals vielen Dank an Dich und deine ehemaligen Mitstreiter für diese wunderbare Erweiterung des DDS-Moduls.


Bernd_Stein

[psclab38]

... und das Hexfile 1.14 ( Firmware ) gebrannt.

Die 1.14 ist die Revision des CVS-Systems von Sourceforge, die wird einfach hochgezählt. Aber das File ist schon das richtige, das habe ich gestern noch hochgeladen.

Auch wenn nicht alles perfekt ist ( dies kann auch an meiner selbstgeätzten Platine liegen ), finde ich das man mit der DDS-C Firmware einen vielfältigen Frequenzgenerator parat hat.

Leider habe ich an dem Ding soviel experimentiert, das sich die Frequenz nicht mehr sofort verstellen ließ, sondern diese Änderung erst nachdem Wechsel zu einer anderen Wellenform angenommen wurde.
Aus,- und nach einer Weile wieder einschalten brachte leider keine Besserung.
Aber ein nochmaliges brennen der Firmware schaffte abhilfe.

Wundert mich. Wenn ein nochmaliges Brennen der Firmware Abhilfe schafft, dann ist beim ersten Laden was schiefgegangen. Kontrolliere mal die Taktfrequenz Deines ISP-Programmers, die muß weniger als 1/4 der Taktfrequenz des Controllers betragen, also unter 4 MHz liegen.

Nochmals vielen Dank an Dich und deine ehemaligen Mitstreiter für diese wunderbare Erweiterung des DDS-Moduls.

Gerne. Für die Dokuanpassung muß ich aber erst noch LaTEX installieren und mich da nochmal durchquälen.

Grüße
Paul

[UPDATE] Die Dokumentation (dds-german.pdf) enthält nun die Änderungsliste für PWM. [/UPDATE]

[Bernd_Stein]

[UPDATE] Die Dokumentation (dds-german.pdf) enthält nun die Änderungsliste für PWM. [/UPDATE]

Als DAU will ich mal zeigen wie man nun die Firmware hierzu findet und als HEXdatei abspeichert,
um diese dann in den Mikrocontroller ( µC ) laden zu können. Wahrscheinlich geht es auch einfacher.
Ich benutze Windows XP.

Hier
http://dcg-firmware.cvs.sourceforge.net ... -firmware/
geht man auf DDSFirmwareRC0.hex. Dort auf download. Mit der Tastenkombination Strg + A ( Alles markieren ) und Strg + C ( Kopieren, ist jedoch nicht sichtbar ) ist nun diese HEXdatei im Zwischenspeicher des PCs.

Nun auf Start ( Win XP ) gehen => Alle Programme => Zubehör => Editor.

In diesem Editorfenster nun rechte Maus klick und einfügen.
Jetzt klicken Datei => Datei speichern unter...
In diesem Fenster nun unter Dateiname : unbedingt *.txt als .hex unbenennen. ( Punkt => " . ", also den Punkt nicht übersehen ).
Und auch bei Dateityp : unbedingt Pfeil klicken und Alle Dateien einstellen.
Nun kann der Button Speichern geklickt werden und fertig ist die HEXdatei.

Zur Überprüfung kann man nun im Editor Datei => öffnen => alle Dateien => Details auswählen und muß dann als Dateityp HEX-Datei stehen haben.

Bernd_Stein

[psclab38]

... will ich mal zeigen wie man nun die Firmware hierzu findet und als HEXdatei abspeichert,
um diese dann in den Mikrocontroller ( µC ) laden zu können. Wahrscheinlich geht es auch einfacher.

Das CVS-System von Sourceforge ist in der Tat wenig intuitiv.
Das Abspeichern geht aber erheblich einfacher. Einfach mit Rechtsklick auf den "Download"-Link klicken und dann "Ziel speichern unter..."; den Knopf sollte jeder Browser haben.
Fertig. Umbennenen und Editor sind nicht nötig.