Neue Firmware: DDS-C 1.0beta

Fragen zur Software des digitalen Funktionsgenerators und des True-RMS-Messaufsatzes bitte hier stellen.
psclab38
kann c't-Lab-Konstrukteure konstruieren
kann c't-Lab-Konstrukteure konstruieren
Beiträge: 942
Registriert: 25.01.2008, 23:34

Beitrag von psclab38 »

Das Problem mit der TRMSC-Anzeige ist mir inzwischen nochmal aufgefallen, ich hab aber keinen Schimmer, was ich da vorher getrieben habe. Mit dem Range hat es aber nichts zu tun.

Die Auflösungswechsel beim Autorange sind ja nicht zu vermeiden, da kann man höchstens optisch was drehen. Aber wenn man die Kalibrierung der vier Eingangsbereiche schön aufeinander abgleicht, dann geht das Autorange ohne Sprünge ab. Daher mein Wunsch für die Abgleichparameter.

Den Test mit meinen verlorenen Zeichen aus LabView mache ich asap, ich bin bislang aber an Syntax-Fehlermeldungen beim JLab hängengeblieben. Könnt Ihr da Euch, wenn nötig, mit MagicRoomy zusammentun, daß beide Seiten das gleiche Verständnis vom Protokoll haben...

Wir haben jetzt verschärfte Kompatibilitätsprobleme vor uns, Original Firmware bzw. C-Firmware und Labview und JLab auf der anderen Seite. Macht schon mal vier Kombinationsmöglichkeiten...

Aber das wird schon...
Viele Grüße
Wilkeltus
kann c't-Lab-Bausätze löten
kann c't-Lab-Bausätze löten
Beiträge: 36
Registriert: 29.11.2007, 10:06
Wohnort: Bad Soden / Ts.

Beitrag von Wilkeltus »

Wir sind mit Magicroomy im Gespräch (wg. Unterstützung der neuen Features).
Thoralt und ich haben Labview und JLab mit der neuen Software intensiv getestet.
Er auf Mac und ich auf Windows

Einen Syntax error haben wir noch nie gesehn. Kannst Du bitte kurz beschreiben, wie Du das hinbekommst und wo Jlab sich da beschwert?

Danke, Jörg
linux-is-sexy
kann c't-Lab-Module umbauen
kann c't-Lab-Module umbauen
Beiträge: 65
Registriert: 29.11.2007, 14:38
Wohnort: Aachen

Beitrag von linux-is-sexy »

Wir haben jetzt verschärfte Kompatibilitätsprobleme vor uns, Original Firmware bzw. C-Firmware und Labview und JLab auf der anderen Seite. Macht schon mal vier Kombinationsmöglichkeiten...
Vllt. sollte man schon anhand des Befehls erkennen ob es eine neue Fkt ist oder nicht. Dann koennten alle Frontends die die C-Firmware brauchen das melden und als Anwender erkennt man schon anhand des Befehls ob das jetzt eine FKT ist, die fuer die Original Firmware ist oder eben nicht.
Aber das wird schon...
Da bin ich mir sicher.

Gruesse LiS
“Intelligence is the ability to avoid doing work, yet getting the work done” Torvalds
Benutzeravatar
thoralt
Site Admin
Site Admin
Beiträge: 262
Registriert: 10.04.2006, 08:48
Wohnort: Chemnitz
Kontaktdaten:

Beitrag von thoralt »

psclab38 hat geschrieben:Das Problem mit der TRMSC-Anzeige ist mir inzwischen nochmal aufgefallen, ich hab aber keinen Schimmer, was ich da vorher getrieben habe. Mit dem Range hat es aber nichts zu tun.
Könntest Du bitte nochmal genauer beschreiben, wie sich das Problem äußert? Möglicherweise finde ich es auch mit der "Methode des genauen Hinsehens" im Quelltext.

Viele Grüße
Thoralt
There are 10 kinds of people in this world: Those who understand binary and those who don't.
Wilkeltus
kann c't-Lab-Bausätze löten
kann c't-Lab-Bausätze löten
Beiträge: 36
Registriert: 29.11.2007, 10:06
Wohnort: Bad Soden / Ts.

Beitrag von Wilkeltus »

Ich könnte mir einen Seiteneffekt bei Permanent TRMSC und anschliessendem Optobusbefehl vorstellen, wenn auf dem Panel zufälligerweise das zum Befehl passende Menü eingestellt ist. Dann greifen 2 Updatefunktionen im gleichen Zyklus.

Passt das zu Deinen Beobachtungen?
psclab38
kann c't-Lab-Konstrukteure konstruieren
kann c't-Lab-Konstrukteure konstruieren
Beiträge: 942
Registriert: 25.01.2008, 23:34

Beitrag von psclab38 »

Zuerstmal zu den Syntaxfehlern, da habe ich im Heise-Forum schon mal einen Dialog mit MagicRoomy begonnen, siehe dieser Link (ich hoffe, der ist erlaubt).

http://www.heise.de/ct/foren/S-Re-JLab- ... 9079/read/

Ich hatte aus einer Parallelkonversation heraus den Eindruck, daß das Protokoll (das ja ohne Hardware- oder Software-Flußkontrolle und ohne große Puffer in den Controllern auskommen muß) so läuft, daß der PC ein Kommando sendet und dann erstmal die Antwort abwartet, bevor er das nächste schickt. Wenn das anders ist, dann lasse ich mich gerne vom Gegenteil überzeugen.

Ich kann mir eigentlich nicht vorstellen, daß nur ich da bei diesem Setup diese Effekte sehe, da

a) die Bussignale mit dem Oszi betrachtet einwandfrei waren (dh. da würde noch eine viel höhere Baudrate gehen)

und b) (und diese ist die Antwort zu meinem ursprünglichen Problem) daß die Sprünge der Ausgangsspannung bei dem DDS-Panel aus dem DemoAll.vi wohl mit der DDS-C-Firware weg sind. Ich konnte das vorhin aus Zeitmangel noch nicht lange testen, aber der erste Anschein ist gut... Aber hier ging es um einen Fehler, der innerhalb (!) der Übertragung eines Kommandos auftrat, wohingegen es oben u. U zu Überschneidungen zwischen Kommandos kommen kann.

Zu dem TRMSC-Effekt melde ich mich nochmal mit Details, wenn ich weiß wie ich das reproduzieren kann. Es ist nichts mit der Anzeige an sich, sondern der Meßwert des TRMSC "hängt" dann auf einem Wert fest und läßt sich nicht mehr beeinflussen. Da half bislang nur AEG (ausschalten - einschalten - geht wieder)
Viele Grüße
psclab38
kann c't-Lab-Konstrukteure konstruieren
kann c't-Lab-Konstrukteure konstruieren
Beiträge: 942
Registriert: 25.01.2008, 23:34

Beitrag von psclab38 »

> Zu dem TRMSC-Effekt melde ich mich nochmal mit Details, ...

Ha, jetzt kann ich wenigstens den Fehler beschreiben, auch wenn ich immer noch nicht weiß, wie ich den provoziere.

Also:
- Default-Einstellung ist TRMSC autorange, alles bestens
- Ich stelle auf ein manuelles Range ein,
- Mache irgendwas *keine Ahnung*
- stelle wieder zurück auf Autorange.
- Dann hängt der Output der TRMSC-Messung auf dem Mindest-"Rauschpegel" des Wandlers, und zwar im Bereich 100V von doch ca. 200mV. Und die kriegt man ja prinzipiell nicht weg, was mit dem Wandlerprinzip zu tun hat. Aber es auto-ranged nicht mehr, das ist die mittelbare Ursache für das Symptom.

Nur wie mache ich das nur immer... ?! (Meine Kollegen geben mir schon nix mehr, wenn der Releasetermin näher rückt, weil ich immer Ungereimtheiten finde und die den Termin nicht sprengen wollen ;-)) )
Viele Grüße
psclab38
kann c't-Lab-Konstrukteure konstruieren
kann c't-Lab-Konstrukteure konstruieren
Beiträge: 942
Registriert: 25.01.2008, 23:34

Beitrag von psclab38 »

So, jetzt hab ich mir das nochmal angesehen:

- Default-Einstellung ist TRMSC autorange, alles so wie es sein soll, die Meßbereiche werden automatisch durchgeschaltet.
- Ich stelle auf ein manuelles Range 0.1/1/10/100V ein,
- Mache irgendwas, evtl. auch gar nix
- stelle wieder zurück auf Autorange.
- Dann hängt der Output der TRMSC-Messung auf dem Mindest-"Rauschpegel" des Wandlers, und zwar im Bereich 100V von doch ca. 200mV.

Das passiert nicht immer, aber sehr oft. Ich kann aber nicht feststellen, unter welchen Bedingungen sich der Autorange wieder aktivieren läßt.

Könnt Ihr das nicht auch beobachten?
Viele Grüße
Benutzeravatar
thoralt
Site Admin
Site Admin
Beiträge: 262
Registriert: 10.04.2006, 08:48
Wohnort: Chemnitz
Kontaktdaten:

Beitrag von thoralt »

psclab38 hat geschrieben:Könnt Ihr das nicht auch beobachten?
Ja, ich kann es nachvollziehen. Ich bin mir zwar auch nicht über die auszuführenden Aktionen im Klaren, aber ich habe den Effekt gerade auf dem LCD. Der Autorange hängt offenbar im 100-V-Bereich. Ich werde mich drum kümmern.

Viele Grüße
Thoralt
There are 10 kinds of people in this world: Those who understand binary and those who don't.
psclab38
kann c't-Lab-Konstrukteure konstruieren
kann c't-Lab-Konstrukteure konstruieren
Beiträge: 942
Registriert: 25.01.2008, 23:34

TRMSC: wirklich RMS?

Beitrag von psclab38 »

Hallo Thoralt,

kann es sein, daß die DDS-C Firmware 1.0 beta als RMS-Werte die umgerechneten Werte vom Peak-Amp anzeigt, anstelle vom LTC1968? Ich wollte nämlich mal bei meinem Modul mit der C-Firmware nochmal komplett nachgleichen, und da fiel mir auf, daß sich am RMS-Meßwert an Panel und in JLab auch rein gar nichts bewegt hat, wenn ich an den Potis R5 und R6 gedreht habe...

Nur bei wenn ich an R4 (Peak-Amp) drehe, da verändert sich der RMS-Wert. ??!??
:?:

Außerdem zappelt der Peak-Meßwert in JLab ziemlich, das ist - glaube ich - nicht normal...

Bin ich da auf was gestoßen?
Viele Grüße
Benutzeravatar
thoralt
Site Admin
Site Admin
Beiträge: 262
Registriert: 10.04.2006, 08:48
Wohnort: Chemnitz
Kontaktdaten:

Beitrag von thoralt »

Hallo Leute,

nach einer kurzen schöpferischen Pause setzen wir nun die Arbeit an der DDS-Firmware fort.

Aktueller Stand der Änderungen:
- der Bug mit dem festhängenden Autorange ist mittlerweile beseitigt
- Umschaltung der Sweep-Formel (linear, dekadisch, oktavisch) ist vorbereitet (Anregung von ompf)
- kleiner Bug bei der Anzeige von OVERLOAD des TRMSC-Wertes behoben

Was noch offen ist:
- im JLab-Sweep traten manchmal negative Spikes auf, ich hatte die mal auf dem Bildschirm, kann sie aber nicht mehr nachvollziehen; wer kann mir Informationen hierzu liefern?
- die von psclab38 erwähnten merkwürdigkeiten von TRMSC Peak- und RMS-Werten und das Zappeln des Peak-Meßwertes

Eine neue Hexdatei gibt es, wenn die oben erwähnten offenen Punkte erledigt sind. Wer unbedingt will, kann sich den aktuellen Stand aus dem CVS holen und selber compilieren (http://sourceforge.net/projects/dcg-firmware).

Habt Ihr sonst noch Wünsche oder sind Euch noch Fehler aufgefallen? Habe ich in der obigen Zusammenfassung etwas vergessen, was vorher evtl. gepostet wurde?

Viele Grüße
Thoralt
There are 10 kinds of people in this world: Those who understand binary and those who don't.
amd-65
kann c't-Lab-Module konstruieren
kann c't-Lab-Module konstruieren
Beiträge: 130
Registriert: 29.11.2007, 16:28

Beitrag von amd-65 »

Welche Version vom GCC für AVR benutztz Du eigentlich? Ich habe Probleme mit WinAVR 4.1.2 (WinAVR 20070525) festgestellt. Wenn da Variablen innerhalb einer Funktion deklariert werden, die größer 4Byte sind (z.B. Strings), vertut sich GCC gelegentlich. Der ATMega friert dann scheinbar ein. Wenn ich die Variablen als 'static' deklariere, geschieht nichts. Im Assembler-Listing sieht es so aus, als würde GCC zu wenige Bytes auf dem Stack reservieren.

Gruß
amd-65
Benutzeravatar
thoralt
Site Admin
Site Admin
Beiträge: 262
Registriert: 10.04.2006, 08:48
Wohnort: Chemnitz
Kontaktdaten:

Beitrag von thoralt »

Hallo amd-65,
amd-65 hat geschrieben:Welche Version vom GCC für AVR benutztz Du eigentlich? Ich habe Probleme mit WinAVR 4.1.2 (WinAVR 20070525) festgestellt. [...]
bei mir ist die Version 4.0.2 installiert (auf dem Mac), da ist mir dieses Problem noch nicht aufgefallen. Versuch doch mal WInAVR 20071221, dort ist der gcc 4.2.2 enthalten. Ich habe eben die ->Bugliste des avr-gcc durchgesehen, aber mir ist auf die schnelle kein Kandidat für Dein Problem ins Auge gesprungen.

Viele Grüße
Thoralt
There are 10 kinds of people in this world: Those who understand binary and those who don't.
Benutzeravatar
ompf
kann c't-Lab-Module konstruieren
kann c't-Lab-Module konstruieren
Beiträge: 168
Registriert: 19.01.2008, 13:03
Wohnort: Dortmund

nochwas zur Wobbelfunktion

Beitrag von ompf »

nochwas zur Wobbelfunktion:

Der interne Sweep hat den Nachteil, daß man die aktuelle Frequenz nicht kennt. Üblicherweise gibt man ja die Frequenz auf die X-Achse des Oszilloskops, und die Amplitude auf die Y-Achse. So sieht man die Durchlaßkurve. Ohne die Frequenzinformation muß man die Zeitablenkung benutzen. Daher macht es Sinn, in definierten Abständen Indexmarken auszugeben. Ein Triggerausgang ist ja vorhanden. Zur Zeit erscheint dort eine Marke beim Start des Sweeps.

Es wäre praktisch, wenn man in definierten Abständen (z.B. Beginn jeder Dekade, Oktave) weitere Marken erzeugen könnte. Ob das passiert, und in welchen Abständen, sollte parametrierbar sein.

Das Ganze könnte z.B. so aussehen:
-Sweep aus --> TRIG=1
-Sweep startet --> Trig=0 (auf die Flanke springt das Oszilloskop an)
-Sweep erreicht Dekaden/Oktavengrenze --> für eine kurze Zeit geht TRIG auf 1
-Sweep durchgelaufen --> TRIG=1

Die Marken kann man dann als Achsen-"Teilstriche" auf dem zweiten Kanal darstellen.


Mit Labview stellt sich das Problem natürlich nicht, da dann die Frequenzen Punkt für Punkt angefahren werden.



BTW: die Boxenbauer unter uns würden sich über einen gewobbelten Sweep freuen. D.h. die jeweils gerade aktuelle Frequenz wird ihrerseits nochmal um einen gewissen Bereich verändert. Das ist materialschonender, da Resonanzstellen nicht ganz so hart angeregt werden.



Gruß
Patrick
Benutzeravatar
thoralt
Site Admin
Site Admin
Beiträge: 262
Registriert: 10.04.2006, 08:48
Wohnort: Chemnitz
Kontaktdaten:

Re: nochwas zur Wobbelfunktion

Beitrag von thoralt »

Hallo Patrick,
ompf hat geschrieben:nochwas zur Wobbelfunktion:
[...] Indexmarken [...] Ein Triggerausgang ist ja vorhanden. Zur Zeit erscheint dort eine Marke beim Start des Sweeps.
ööhm - was habe ich verpaßt? Eine solche Variante für einen Triggerausgang schwebte mir in der Tat vor, denn wir holen uns unsere Anregungen aus den Bedienungsanleitungen professioneller Geräte. Dort sind solche Mechanismen ebenfalls vorhanden. Was meinst Du mit "Ein Triggerausgang ist ja vorhanden"? In unserer Firmware gibt es sowas noch nicht.
ompf hat geschrieben:Es wäre praktisch, wenn man in definierten Abständen (z.B. Beginn jeder Dekade, Oktave) weitere Marken erzeugen könnte. Ob das passiert, und in welchen Abständen, sollte parametrierbar sein.
Ich gebe Dir recht, sowas wäre schön. Ich werde es mal mit auf die Agenda setzen. Es wird aber sicherlich noch etwas dauern, bis das realisiert werden kann. Vorher müssen wir erstmal den Code aufräumen und Platz schaffen.
ompf hat geschrieben:BTW: die Boxenbauer unter uns würden sich über einen gewobbelten Sweep freuen. D.h. die jeweils gerade aktuelle Frequenz wird ihrerseits nochmal um einen gewissen Bereich verändert. Das ist materialschonender, da Resonanzstellen nicht ganz so hart angeregt werden.
Nun, die Frequenzmodulation erfolgt momentan mit einer Update-Rate von 5 ms. Wenn der Sweep nicht gerade sehr langsam verläuft, dann läßt sich an der Sweep-Frequenz nicht mehr viel modulieren. Und schneller läßt sich das Zeitregime kaum machen, da ja auch eine gewisse Zeit für die serielle Kommunikation mit dem AD9833 draufgeht und am Ende noch ein wenig Zeit für die restlichen Funktionen (Panel, Parser) übrigbleiben muss. Schnelle Sweeps kann man also nicht modulieren, langsame Sweeps könnte man modulieren. Wo soll man die Grenze ziehen? Solche Sachen sind irgendwie immer unschöne Kompromisse.

Viele Grüße
Thoralt
There are 10 kinds of people in this world: Those who understand binary and those who don't.
Antworten