Neue Firmware: DDS-C 1.0beta

Fragen zur Software des digitalen Funktionsgenerators und des True-RMS-Messaufsatzes bitte hier stellen.
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

Re: nochwas zur Wobbelfunktion

Beitrag von ompf »

thoralt hat geschrieben: Was meinst Du mit "Ein Triggerausgang ist ja vorhanden"? In unserer Firmware gibt es sowas noch nicht.
Das ist der Pin PC4, bzw. die SYNC-Buchse. Irgendwo (im TRMS-Artikel?) hatte ich mal gelesen, daß die von der cm-Firmware zur Kennzeichnung des Sweep-Beginns verwendet wird. Bloß, daß in der aktuellen cm-FW gar keine Wobbelfunktion enthalten ist...

thoralt hat geschrieben: 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.
Das hatte ich fast erwartet. Die Audio-Sweeps laufen mit 10-30s pro Dekade, da wird's dann doch zu eng.


Gruß
Patrick
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

Beitrag von ompf »

Was ist denn aus dem DDS-Firmware-Projekt geworden? Der letzte Release (1.0beta) ist ja nun schon eine Weile her. Seit Ihr noch aktiv?

Wäre ja schade, wenn das Thema einschläft -- die beta war ja schon ziemlich klasse.


fragt
Patrick
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 »

Hallo Patrick

das ist ja witzig, daß Du grade die Tage nach Fortschritt fragst. Ich mußte das c't-lab schon eine ganze Weile aus Zeitmangel links liegen lassen, aber grade letztes Wochenende hab' ich mal die ganze Entwicklungsumgebung etc. wieder installiert.

Die DDS C-1.0beta war ja in der Tat schon klasse, ich hatte aber auch mit dieser Version immer irgendwelche Kommunikationsprobleme, die sonst niemand nachstellen konnte. Ich habe mir deshalb jetzt mal den Quellcode vorgenommen und einige Dinge geändert und eingebaut, wobei ich seit heute abend endlich keine Fehlermeldungen etc beim Betrieb mehr gesehen habe. Die Ergänzungen sind leider noch nicht so "schön", wie ich sie gerne hätte, zudem habe ich im Nachhinein festgestellt, daß Hartmut bei seiner "Original-Implementierung" der DCG2 bereits schon einige Sachen eingebaut hatte, die in der DDS noch fehlten. Jetzt hab ich quasi die Wahl zwischen seinem und meinem Code. :?

Um's kurz zu machen, ich wollte mich dann die Tage mal mit den "Kollegen" der DDS-C-Firmware in Verbindung setzen und über den Einbau in den Softwarestamm reden. Ich wollte nur gleich mal auf Dein Posting antworten, denn es ist in der Tat recht still geworden in der Zwischenzeit.

Aber es geht ja wieder aufwärts: die Teile für die EDL sind schon bestellt und das FPGA-Modul macht ja auch einen sehr interessanten Eindruck. Und allein für cm's Asteroids-Nachbau lohnt es sich allemal. Ich mußte ja laut lachen, als ich sah, was er da wieder gezaubert hat.

Bis bald, zu einer einer RC1-Version der DDS-C
Paul
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 »

Hallo Ihr Beiden,

ja wir sind ziemlich abgetaucht. Ich war damals mit den Features der DDS ziemlich zufrieden und habe nur noch einen halbwegs lauffähigen Prototyp für DIV auf die Beine gestellt, der aber nicht reif für eine Veröffentlichung ist. Und interessanten Sachen, die ich so zur Widerstands-, Induktivitäts und Kapazitätsmessung vorhatte, sind noch gar nicht angefangen. Ich habe mich auch gefragt, ob ich das nicht lieber über Jlab realisiert sehen möchte, da mein Konzept eine bestimmte Reihenfolge der Module auf dem Optobus vorsieht und man da evtl. umstöpseln muss.
Meine TRMSC habe ich auf DIV umgebaut und die kann ich also im DDS-Umfeld nicht mehr so gut testen. Pauls TRMSC Problem habe ich nicht nachvollziehen können.
Danach ist bei mir der Auftragsoverkill eingetreten und auch bei Thoralt hat sich privat etwas Arbeit ergeben. Vor Ende September wird es also von mir keine neuen Features geben. Mal sehn, ob Thoralt noch was machen will.

Aber Pauls Änderungen baue ich gerne ein. Soviel Zeit ist immer...
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

Beitrag von ompf »

Wilkeltus hat geschrieben:und habe nur noch einen halbwegs lauffähigen Prototyp für DIV auf die Beine gestellt, der aber nicht reif für eine Veröffentlichung ist. Und interessanten Sachen, die ich so zur Widerstands-, Induktivitäts und Kapazitätsmessung vorhatte, sind noch gar nicht angefangen.
In dem Zusammenhang hatte ich schon wiederholt angeregt, dem DIV eine schaltbare 2mA-Konstantstromquelle zu verpassen. Damit kann man Widerstand (R=U/2mA) messen, Dioden testen (UF=U) und den berühmt-berüchtigten Durchgangspiepser realisieren.

Der DIV-FW von cm fehlt immer noch der Autorange. Die Lampe am Panel ist ja schon da.



Aber nochmal zur DDS:

* der stand-alone - Sweep ist ja nun drin. Um dem richtig Sinn zu verleihen, sollte er dekadisch (für Filter) und oktavisch (für Musiker) möglich sein und die Sync-Buchse unterstützen. Schließlich muß die Auswertung der Übertragungsfunktion synchron mit der Signalerzeugung erfolgen, und das setzt eine Startmarke zwingend voraus. Damit kann man das Oszi triggern und bekommt die Durchlaßkurve angezeigt.

* HF-Wobbler liefern auch Eichmarken. Da wird dann bei bestimmten Frequenzen die Amplitude des Ausgangssignales kurzzeitig verdoppelt, so daß man in der Durchlaßkurve einen Peak sieht. Sowas wäre auch eine Idee.

* Modulation, wie in Eurer ToDo-Liste aufgeführt, wird man wohl vergessen können, da die ja komplett in SW erfolgen müßte. Viel mehr als FSK oder Burst dürfte da nicht möglich sein.



Gruß
Patrick
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 »

Hallo Patrick,
hallo Jörg,

ich hoffe, jetzt wieder etwas regelmäßiger Zeit für das c't-Lab zu haben. Zunächst muß ich mich mal in die Software einarbeiten, damit ich weiß, wie die C-Implementierungen so ticken. :idea:

Wie schon geschrieben, habe ich einige Dinge in der DDS-C Firmware im Parser gefunden, die quasi einfach nur nachgezogen werden müssen, weil sie Hartmut in seiner DCG-C Implementierung schon drin hatte.

Eingebaut habe ich jetzt mal:
- XOR-Prüfsumme
- Test-Kommando 253
- Unterbinden des "#1:255=0 [OK]", wenn ein einzelnes /n oder /r kommt. (Das behebt auch zunächst mal mein Protokollproblem)
- Korrektur der Veff/Vss-Messung (A/D-Kanäle korrigiert)

Letzter Punkt hatte mich schon ziemlich gefoppt, weil ich extra den RMS-C-Filter auf der TRMSC umgebaut hatte und überhaupt keinen Effekt gesehen hatte. Nachdem ich den Filter wieder zurückgebaut hatte, ist mir aufgefallen, daß mit der DDS-C beide Meßwerte bis auf den Umrechnungsfaktor immer genau gleich waren, auch bei verschiedenen Eingangssignalformen. Die Filteränderung kann ich mir auch sparen, weil in der DDS-C die Eingangwerte über vier Messungen gemittelt werden.
Mit der Behebung der Kanalzuordnung dürften auch die "negativen" Spikes auf dem Sweep-Plot des JLab weg sein, die werden nämlich vom Peakdetektor geliefert, warum auch immer.

Im Augenblick hänge ich immer noch an meinem kritischen Punkt mit den Protokollfehlern, den sonst keiner nachvollziehen kann, aber ich glaube inzwischen, daß ich langsam verstehe, woher das Problem kommt:
Es ist wohl eine Mischung aus schneller Kommandofolge aus JLab, Kommandoverarbeitung in den Modulen, begrenzter Puffergröße und undefinierter Reaktion auf Pufferüberläufe. Das Problem hat mit Anzahl der Module besonders verwirrt, weil beim zweiten Modul der Puffer überläuft, sobald hinten ein drittes Modul dranhängt. :?

Leider habe ich keinen Protokollanalyzer mit Timingaufzeichnung zur Hand, sonst würde ich mich leichter tun.

Für mich haben jedenfalls die "Bugfixes" zunächst Priorität, aber wenn es einfache Features sind, kann ich ja mal schauen, ob ich die auch einbauen kann...

'Ne Frage zum Sweep: ich hab mir den noch nicht genau angesehen, aber im Panel-Menü gibt es ihn, in linear, octave und decade. Was stimmt daran nicht?

Das mit der Startmarke auf dem Syncausgang ist tätsächlich ein Feature, das unverzichtbar für Standalone ist, sonst nützt einem die ganze Wobbelfunktion nichts.

Zu den Modulationen stimme ich Dir zu, das dürfte problematisch werden. ASK und FSK zusätzlich zum Burst dürfte wohl das Ende der Fahnenstange sein. Außerdem ist der Programmspeicher schon zu 90% voll, da ist nicht mehr viel Luft.

Viele Grüße
Paul
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 »

Hallo,

zum Thema DIV: Hier war meine Idee, die kalibrierten DDS und DCG als Spannungs-/Stromerzeuger zu benutzen. Die müssen halt in der Kette nach DIV kommen und können von diesem ferngesteuert werden. Natürlich kann man auch Widerstände schön direkt mit dem DCG messen, wenn man das in die Firmware packt, aber ein Multimeter mit Widerstandsmessung hat ja auch jeder ct-labler.

DDS:
Modulation hatte ich damals angeregt, weil mein Grosser das gerade in der Schule hatte und ich ihm die Effekte mal zeigen wollte. Die Nutzfrequenzen wären natürlich nur gering, aber immerhin hörbar. PWM könnte man sogar laut Thoralt mit den AVRs in Hardware machen, aber das habe ich noch nicht durchblickt.
Die Sweep-Marker sind ja eigentlich schon genehmigt ;-) nur nie begonnen, wobei mir auch die Idee mit dem doppelten Peak gut gefällt, da so die Standardfrontplattennutzer auch was davon haben. Für die (Lehr-)zwecke und zum Verstärkerreparieren hatte es mir auch ohne gereicht.
XOR und die ADC-Kanalkorrektur hören sich gut an. Und ja, amd-65 hatte in der DCG aufgrund Pauls Feedback schon Änderungen vorgenommen, die wir nicht eingecheckt hatten. Der Abgleich steht noch aus. Ich hatte nach Deiner Heurekamail (baumelndes Kabel) gedacht, dass Dein Kommunikationsproblem gelöst sei.
Die augenblickliche Speicherauslastung heisst nicht, das nicht noch ne Menge geht. Etliches ausprogrammiertes kann noch in Funktionen geschoben werden, was auch die Wartungsfreundlichkeit erhöht.
Also Paul: Tob Dich ruhig aus. Ich biete mich gerne zum CodeReview und einchecken an. Mir hats damals richtig Spass gemacht und den wünsche ich Dir natürlich auch. Wir können ja auch direkt in Kontakt bleiben, antworten kann ich aber wahrscheinlich nur abends, da ich die Entwicklungsumgebung nicht mehr auf dem Firmenrechner habe.
Benutzeravatar
thoralt
Site Admin
Site Admin
Beiträge: 262
Registriert: 10.04.2006, 08:48
Wohnort: Chemnitz
Kontaktdaten:

Beitrag von thoralt »

Hallo Leute,

ich finde es klasse, dass jemand das Projekt wieder ausgegraben hat :) OK, sooo tief war es noch nicht in der Versenkung verschwunden, aber wie Jörg weiter oben schon geschrieben hat, haben wir beide momentan kaum Zeit übrig und nutzen das bisschen Zeit lieber für die Familie.
'Ne Frage zum Sweep: ich hab mir den noch nicht genau angesehen, aber im Panel-Menü gibt es ihn, in linear, octave und decade. Was stimmt daran nicht?
Das waren nur die vorbereitenden Maßnahmen. Die Sweep-Arten wurden ja schonmal vor längerer Zeit gewünscht, deswegen habe ich die Menüpunkte bereits integriert. Die Implementierung ist alllerdings auf halber Strecke steckengeblieben. Ich erinnere mich noch, ne Menge Zettel mit Formeln wegen der Frequenzänderungen und Timings vollgekritzelt zu haben. Aber ich hatte noch irgendeinen Denkfehler drin, denn es hat schlussendlich noch nicht funktioniert. Das sollte nochmal jemand von Euch neu programmieren.
PWM könnte man sogar laut Thoralt mit den AVRs in Hardware machen, aber das habe ich noch nicht durchblickt.
Richtig. Der ATmega kann PWM in Hardware. Die Ausgänge dafür wären OC0/PB3 (STROBE für die zwei 4094), OC2/PD7 (Jumper-Eingang für Moduladresse), OC1A/PD5 (Jumper-Eingang für Moduladresse), OC1B/PD4 (frei!). Wenn man die PWM-Hardware des AVR benutzt, könnte man diesen freien Pin an den externen Eingang legen und somit den Pegel steuern. Ich nutze den externen Eingang nicht, daher wäre mir der Verlust desselben egal. Es müsste also Timer1 (16 Bit) im PWM-Modus programmiert werden. Der ist zum Glück noch unbenutzt (derzeit ist nur Timer2 in Betrieb). Es sollte ein vernünftiger Kompromiss aus Genauigkeit und Geschwindigkeit gefunden werden (oder dynamisch nachlassende Genauigkeit bei hoher Geschwindigkeit muss implementiert werden).
Das mit der Startmarke auf dem Syncausgang ist tätsächlich ein Feature, das unverzichtbar für Standalone ist, sonst nützt einem die ganze Wobbelfunktion nichts.
Das steht in der Tat noch aus, ich würde mir das auch wünschen. Außerdem sind die vorgeschlagenen "Eichmarken" eine tolle Sache, die Idee hatten wir noch nicht (obwohl wir als Quelle für Ideen die User-Manuals von einigen Rohde&Schwarz-Geräten gewälzt haben).

Wenn Ihr direkt im CVS Änderungen machen wollt, müsst Ihr bei Hartmut nachfragen, er nimmt Euch sicher gerne in die Entwicklerliste bei Sourceforge auf. Ansonsten können wir für Euch die Änderungen einbauen.

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

Beitrag von psclab38 »

Hallo Thoralt,
hallo Patrick,
hi Jörg,

also, wenn ich mir die Sweepfunktion mal so durchdenke, dann ist eigentlich dekadisch f=f0*10^(t/td10) mit octave f=f0*2^(t/td2) identisch, außer einem Skalierungsfaktor.
Wenn man sich mal Start- und Endfrequenz und Zeitspanne fest eingestellt denkt, dann unterscheiden sich die Sweeps nicht.
Nur wenn man Marker auf dem Syncausgang ausgibt, dann sind die oktav 3.32 (=1/log2) mal so oft wie dekadisch: td10 = 3.32*td2.

Der Code in der DDS bezgl. des Sweeps ist noch ein wenig BlackBox für mich, momentan ist der Sweep wohl linear (siehe g_dSweepFrequencyIncrement f = f0 + finc). Für die anderen beiden dürfte das dann ein g_dSweepFrequencyFactor werden: f = f0 * factor. Die Timings im Interrupt blicke ich aber noch nicht. Sieht mir irgendwie zeitkritisch aus.

Mal sehen, man ist ja noch lernfähig. Hoff ich jedenfalls.

Mit meinen Protokollfehlern bin ich eigentlich durch. Ich weiß nicht, ob meine Lösung mehrheitsfähig ist, aber eine strikte Kontrolle auf Kommandobeginn mit Adresse z.B. "2:" oder als Antwort "#2:" behebt die falsch eingestellten Werte bei Modulen hinten in der Kette, wenn ein Pufferüberlauf aufgetreten ist. Damit werden halt einige Befehle weggeschmissen, aber jedenfalls kein falscher ausgeführt. Das ist noch der beste Schutz vor einer Katastrophe.

LabView und JLab kommen jedenfalls beide prächtig damit klar, nur wenn man manuell im Terminal eintippt, dann muß man halt immer eine Adresse dazutippen.

Jetzt erst mal viele Grüße
Paul
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 »

Hallo Freunde,

jetzt muß ich mir dann doch fast selbst antworten:

Ich hab' heut abend mal ein wenig mit der Sweep-Funktion der DDS-C Firmware rumgespielt, und behutsam auf dekadisch (implizit ja auch octav) aufgebohrt. Sieht recht nett aus, auch wenn bislang nur Up + Down geht.
UpDown geht nach ein paar Minuten die Luft aus, weil die Rundungsfehler zuschlagen. Ich hab das so eingefädelt, daß in der Interruptroutine nur einmal double multipliziert wird, weil ich befürchte, daß eine Multiplikation und ein 10^x dann doch zulange dauert.

Und übrigens, ich habe einen schönen SyncOut-Impuls auf PL5 (PC4, auf dem Anschluß der TRMSC, den kann man aber auch vom DDS-Mainboard am TRMSC-Anschluß abzweigen). Kann man prima drauf triggern, wobei sich mein schönes altes HM103 leider weigert. Das Speicherscope spielt da aber brav mit und zeigt auch die richtigen Start-, Mitte- und Endefrequenzen an.

Und überhaupt, wenn ich das richtig sehe, sind beispielsweise PC5-PC7 noch unbenutzt, da läßt sich dann sicher noch ein Ausgang mit Eichmarken anflicken. Ein gemeinsamer mit dem SyncOut wird wieder schwierig zum Triggern.

Das ging jetzt eigentlich fast zu leicht, aber Standalone ist es scheinbar vollkommen ok. Weiter will ich jetzt nicht testen, sonst komm ich noch auf Fehler und sitz' die ganze Nacht dran und den Lötkolben für die Eichmarken schmeiß ich jetzt auch nicht mehr an.

Einen Nachteil der Sync-ausgänge darf man aber nicht verschweigen: die liegen auf Massepotential der DDS (!) Wenn man nun den Offset des Ausgangs einschaltet, dann gibt's einen schönen Kurzschluß für die Offset-Treiberstufe. CM hat da aber mitgedacht und so 'ne PolyswitchSicherung eingedesignt. Die hat mir die Treiber schon mehrfach gerettet.

Jetzt erst mal gute Nacht.
Paul
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 Paul,
UpDown geht nach ein paar Minuten die Luft aus, weil die Rundungsfehler zuschlagen.
Das ist aber merkwürdig. Mein Ansatz war folgender: Eine Laufvariable (Zeit) bestimmt, welche Frequenz (unabhängig von der Formel) berechnet wird. Die Formel soll nur von der Zeit abhängig sein. Am Beginn jedes Durchlaufes wird alles zurückgesetzt. In diesem Fall sollten Rundungsfehler nur innerhalb eines Durchlaufes auftreten (und auch hier nur für einzelne Werte, die Frequenz sollte deswegen nicht weglaufen).
Und überhaupt, wenn ich das richtig sehe, sind beispielsweise PC5-PC7 noch unbenutzt, da läßt sich dann sicher noch ein Ausgang mit Eichmarken anflicken. Ein gemeinsamer mit dem SyncOut wird wieder schwierig zum Triggern.
Wie meinst Du das? Ich dachte, die Eichmarken würde man in Software realisieren. Wenn dort für eine kurze Zeit der Pegel verdoppelt wird, dann müsste das den gewünschten Effekt haben.
Einen Nachteil der Sync-ausgänge darf man aber nicht verschweigen: die liegen auf Massepotential der DDS (!) Wenn man nun den Offset des Ausgangs einschaltet, dann gibt's einen schönen Kurzschluß für die Offset-Treiberstufe.
Wie wäre es mit einer Schaltung für den Triggerausgang, welche das Potential auf die Offsetspannung bezieht (siehe Anhang)? Das sollte auf nem minimalen Stück Lochraster Platz finden.

Viele Grüße

Thoralt
Dateianhänge
triggeroffset.png
triggeroffset.png (4.26 KiB) 6128 mal betrachtet
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

Beitrag von ompf »

UpDown...
Was macht man denn damit? Soundeffekte? Zur Darstellung auf dem Scope brauche ich ja eher den klassischen Sägezahn.
Wie wäre es mit einer Schaltung für den Triggerausgang, welche das Potential auf die Offsetspannung bezieht (siehe Anhang)? Das sollte auf nem minimalen Stück Lochraster Platz finden.
Gute Idee. Jetzt bleiben noch TRMSC und AUX. Beide sind ac-gekoppelt, die sollte man also auch relativ schmerzfrei auf dem Offset abstützen können. Dann gibt's nach außen hin nur noch eine Masse.


Gruß
Patrick
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 »

Hi Thoralt,

[quote]
Zitat:
UpDown geht nach ein paar Minuten die Luft aus, weil die Rundungsfehler zuschlagen.


Das ist aber merkwürdig. Mein Ansatz war folgender: Eine Laufvariable (Zeit) bestimmt, welche Frequenz (unabhängig von der Formel) berechnet wird. Die Formel soll nur von der Zeit abhängig sein. Am Beginn jedes Durchlaufes wird alles zurückgesetzt. In diesem Fall sollten Rundungsfehler nur innerhalb eines Durchlaufes auftreten (und auch hier nur für einzelne Werte, die Frequenz sollte deswegen nicht weglaufen).
[/quote]

Ja, ich hab auch nicht Deinen, sondern meinen Code gemeint, und da ist beim UpDown das Rücksetzen beim Richtungswechsel für den dekadischen Sweep (noch) nicht eingebaut gewesen. War schon spät und ich war zu müd' um das noch zu beheben. Jetzt gehts.

Sync hab ich für UpDown so eingebaut, daß der Pegel für Up auf High ist und Down auf Low. Für die einfachen Modes Up oder Down gibts beim Start einen Puls mit der Minimallänge (5ms)

Damit Ihr Euch mal vorstellen könnt, wie das ausieht, hab ich mal zwei Screenshots angehängt.

[quote]
Ich dachte, die Eichmarken würde man in Software realisieren. Wenn dort für eine kurze Zeit der Pegel verdoppelt wird, dann müsste das den gewünschten Effekt haben.
[/quote]

Ah, 'ne gute Idee, hatte ich gar nicht drangedacht. Für ganz niedrige Frequenzen, die in die 5ms Pulszeit keine kompletten Schwingungen reinkriegen, ist es wohl nicht sichtbar, aber prinzipiell echt elegant. Aber Faktor 2 beim Pegel finde ich recht gewagt. So +10% oder +20% reicht nicht? Dann geht das auch nicht so schnell in die Aussteuerungsgrenze.

Aber genau mit den Markern hab ich ne Frage: wo sollen die sichtbar werden?
Beim Dekadischen Mode bei 10, 100, 1000, 10000Hz? Oder relativ zur jeweils 10-fachen Startfrequenz?

Beim oktavischen Mode bei 27.5, 55, 110, 220, 440, 880, 1760, 3520, 7040, 14080Hz? Oder relativ zur jeweils doppelten Startfrequenz?

Jetzt sagt bloß nicht, beides und umschaltbar :) !

Die Schaltung mit dem Triggerausgang ist wohl als Dauerlösung die beste Idee, da geb' ich Dir recht. Fehlt eigentlich in der Originalschaltung, ist nicht ganz bis zuende durchdacht.

Paul
Dateianhänge
SweepUp
SweepUp
TEK0007-SweepUp.JPG (27.45 KiB) 6105 mal betrachtet
SweepUpDown
SweepUpDown
TEK0008-SweepUpDown.JPG (28.1 KiB) 6105 mal betrachtet
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 Paul, hallo Patrick,
psclab38 hat geschrieben:Ja, ich hab auch nicht Deinen, sondern meinen Code gemeint, und da ist beim UpDown das Rücksetzen beim Richtungswechsel für den dekadischen Sweep (noch) nicht eingebaut gewesen. War schon spät und ich war zu müd' um das noch zu beheben. Jetzt gehts.
sehr schön :)
psclab38 hat geschrieben:Sync hab ich für UpDown so eingebaut, daß der Pegel für Up auf High ist und Down auf Low. Für die einfachen Modes Up oder Down gibts beim Start einen Puls mit der Minimallänge (5ms)
ACK.
psclab38 hat geschrieben:
Ich dachte, die Eichmarken würde man in Software realisieren. Wenn dort für eine kurze Zeit der Pegel verdoppelt wird, dann müsste das den gewünschten Effekt haben.
Ah, 'ne gute Idee, hatte ich gar nicht drangedacht. Für ganz niedrige Frequenzen, die in die 5ms Pulszeit keine kompletten Schwingungen reinkriegen, ist es wohl nicht sichtbar, aber prinzipiell echt elegant. Aber Faktor 2 beim Pegel finde ich recht gewagt. So +10% oder +20% reicht nicht? Dann geht das auch nicht so schnell in die Aussteuerungsgrenze.
Ich denke, es müsste noch genügend Platz im Flash für einen eigenen Menüpunkt sein, wo man die Eichmarkenüberhöhung in Prozent selber einstellen kann. Das hat bestimmt Vorteile. Man könnte das gleich mit dem Ein- und Ausschalter für das Feature verbinden. Wenn Eichmarke = 0%, dann "aus", ansonsten in 10-Prozent-Schritten einstellbar. Falls Dir das Menü-Monster noch zu unübersichtlich ist (ich habe mir große Mühe gegeben, es flexibel zu gestalten), dann würde ich das übernehmen.
psclab38 hat geschrieben:Aber genau mit den Markern hab ich ne Frage: wo sollen die sichtbar werden?
Beim Dekadischen Mode bei 10, 100, 1000, 10000Hz? Oder relativ zur jeweils 10-fachen Startfrequenz?

Beim oktavischen Mode bei 27.5, 55, 110, 220, 440, 880, 1760, 3520, 7040, 14080Hz? Oder relativ zur jeweils doppelten Startfrequenz?

Jetzt sagt bloß nicht, beides und umschaltbar!
Nun... Beide Varianten haben ihre Vorzüge. Bei längerem Nachdenken gefällt mir die Variante mit festen Frequenzen 10, 100, 1000, ... Hz besser, weil allgemeiner. Es wird sich sicherlich einmal jemand die andere Variante wünschen. Wenn das wirklich der Fall ist, dann werden wir wohl beide Varianten umschaltbar bauen. Aber das lieber später.
ompf hat geschrieben:
UpDown...
Was macht man denn damit? Soundeffekte? Zur Darstellung auf dem Scope brauche ich ja eher den klassischen Sägezahn.
Nun, da muss ich Dir Recht geben. Wir waren da ein bißchen im Feature-Wahn und haben versucht, "alles was geht" umzusetzen. Vielleicht hat es ja irgendeinen didaktischen Wert. Aber für Messtechnik ist zweifelsohne ein unidirektionaler Sweep besser. Falls wir uns einig werden, können wir dieses Feature ja auch wieder rausschmeißen. Das spart ein paar Zeilen Code (allerdings nicht viel).

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

Beitrag von psclab38 »

Hallo DDS-Freunde,

es ist noch früh am Morgen, aber ich konnte irgendwie nicht schlafen. (werde ich im Büro nachholen 8) )

Ich will auch nicht viele Worte machen, aber ists so recht ? (siehe Bilder)
Das Ergebnis gefällt mir jedenfalls schon mal ganz gut.

Die Marker (+20% überhöhung) werden automatisch bei den Hz-Zehnerpotenzen bzw. bei den Zweierpotenzen von Kammerton A (440Hz) eingeblendet. Der Sweep auf den Bildern reicht von 2Hz bis 22kHz. Momentan gibt's die Marker nur für den UP-Mode und ich weiß nicht, ob ich's für die anderen Modes auch noch nachziehen soll. Programm Memory ist inzwischen bei 94.2%, und das Menü für dieses Feature fehlt auch noch. Mal sehen.

Viele Grüße
Paul
Dateianhänge
Decade Sweep w/ Marker
Decade Sweep w/ Marker
TEK0009SweepDecMarker.JPG (27.48 KiB) 6064 mal betrachtet
Octave Sweep w/ Marker
Octave Sweep w/ Marker
TEK0010SweepOctMarker.JPG (28.09 KiB) 6062 mal betrachtet
Viele Grüße
Antworten