Hallo werte W20xxA Besitzer und Interessierte!

Diesen Thread habe ich als Ersatz für den mittlerweile überfüllten
Thread

>Wittig(welec) Oszilloskop firmware problem<

eröffnet.

Für Hardwarethemen wird es einen eigenen Thread geben:

>Wittig(welec) DSO W20xxA Hardware>



Gruß Hayo

So hier noch eine kleine Wortliste damit der Thread auch von Google
gefunden wird:

DSO Oszilloskop oscilloscope WELEC WITTIG W2000 W2012A W2014A W2022A
W2024A

Gruß Hayo

Guido wrote:
> Hallo Hayo,
>
> nur um sicher zu gehen: Du benutzt den Bresenham nur im Notfall? Da
> lohnt
> meist eien Fallunterscheidung: horizontal, vertikal und diagonal direkt,
> nur sonst Bresenham.
>
> Gruß, Guido

Hi Guido,

ja genauso hab ich es implementiert. Läuft ca. 10 mal schneller als die
alte Implementierung von WELEC. Zur Zeit teste ich noch ob auch alles
fehlerfrei gezeichnet wird, aber bislang sieht alles gut aus.

Gruß Hayo

Broma.es wrote:
> Sorry about this- i don't know why no funciona..
> correct Link:
> http://apps.sourceforge.net/phpbb/welecw2000a/view...

na, bei dem Datum ;-))

So hab mich nochmal aufgerafft und alles heute fertiggemacht. Die
Liesmich gibts jetzt auch in Englisch und der Updater ist auch mit
dabei. Wie immer die Liesmich beachten. Wesentliche Neuerung ist die
XY-Funktion.

Das File wird es auch auf Google Groups und SFN geben.

Viel Spaß

Hayo

branadic wrote:

> Dazu hätt ich nun mal eine Frage, besteht die Möglichkeit in dieser
> Einstellung die Lineare Interpolation zwischen den Messwerten
> abzustellen und nur die reinen Messwerte darzustellen?

Hallo Branadic, danke für die prompte Reaktion. Bin leider erst heute
dazu gekommen mir das anzusehen. Wenn ich Dich richtig verstanden habe
meinst Du die Umschaltung zwischen Vektordarstellung und reine
Punktdarstellung? Die Umschaltung erfolgt wie beim normalen Zeitsignal
über das "Display" Menü mit der Taste Vectors.


> Dann ist mir aufgefallen, dass ich immer einen einzelnen Messwerte habe,
> der um die Nulllage herum liegt und das Bild verfälscht. Die ist so wie
> es ausschaut auch gleich der allererste dargestellte Messpunkt.

Das konnte ich leider bei mir nicht nachvollziehen. Mach doch mal ein
Bild, damit ich mir was darunter vorstellen kann.

> Leider werden die Messdaten noch nicht korrekt wiedergegeben. Will
> heißen: Ich würde erwarten, wenn ich an zwei Tastköpfen ein und dasselbe
> Sinussignal anlege, dass die beiden Signale auf dem Display exakt
> übereinander liegen. Das tun sie leider nicht, weswegen dann in der
> x-y-Darstellung auch keine 45°-Schräge sondern eine Ellipse angezeigt
> wird.
> Liegt die Ursache hierfür im FPGA-Design oder in der FW?

Kann es sein, dass Du nicht mit einem 50 Ohm abgeschlossenen Kabel
gemessen hast? Offenbar hast Du Dir da irgendwo eine Phasenverschiebung
eingefangen. Bei mir gibt es eine Diagonale (siehe Bild).

> zur Mathe-Funktion:
> Mir ist aufgefallen, dass bei den Einstellungen von Amplitude und Offset
> nicht die LED am Verstell-Encoder leuchtet :)

Ja, das ist mir auch schon aufgefallen, allerdings tritt das nicht immer
auf und war auch schon vorher so bei der originalen FW. Da ist wohl ein
Fehler in der Menüführung.

> Dann ist mir aufgefallen, dass unter den Setting von CH1*CH2 bei Scale
> irgendwie Hieroglyphen im Scale-Button angezeigt werden.

Muß ich mal checken.

> Der Offset steht in allen Funktionen aus irgendeinem Grund nicht von
> Haus aus auf 0V, das wäre sicherlich auch noch erstrebenswert.

Das liegt an den Konfigdaten die beim Start geladen werden (Bei Dir sind
noch die Konfigbereiche noch original). Das ist bei Welec die
Originaleinstellung. Bei mir ist das längst anders eingestellt. Ich hab
meine neuen Parameter noch nicht im Konfigbereich untergebracht, muß ich
demnächst mal machen.


> Soweit an dieser Stelle die Kritik.
> Ansonsten schon ein paar schöne Fortschritte in deiner FW.

Danke und Gruß

Hayo

branadic wrote:
> Hallo Hayo,
>
> was mir gerade so beim Herumspielen mit deiner FW ins Auge gestochen
> ist:
>
> Für jeden Kanal gibt es ja den Kanalauswahlbutton, der Knopf mit der
> Kanal-Zahl drauf.
> Von dem Tek mit dem ich beinah täglich arbeite bin ich es gewohnt, wenn
> ich diesen Kanalauswahlbutton drücke erscheint das Signal dieses Kanales
> auf dem Display im Vordergrund, eine wie ich finde wirklich unglaublich
> praktische Funktion.
> Ist zum Beispiel wichtig, wenn ich mir ein moduliertes Signal anschauen
> möchte und anschließend dessen passive Demodulation auf dem nächsten
> Kanal. Aufgrund des zwangsläufigen Spannungsabfalls verschwindet das
> demodulierte Signal nun hinter dem Signal des ersten Kanals bei gleichen
> Scale-Einstellungen und gleichem Offset. Mit dem Kanalauswahlbutton hol
> ich es mir einfach in den Vordergrund bzw. bestimme die Reihenfolge in
> derer die einzelnen Kanäle angezeigt werden.
>
> Ließe sich sowas in deiner FW integrieren?

Um sicher zu gehen dass ich Dich richtig verstanden habe (kenne diese
Funktion bislang nicht): Mit Vordergrund/Hintergrund meinst Du bei
Signalen die direkt übereinander liegen, welches beim Zeichnen "oben"
und welches "unten" liegt bzw. welches Signal von welchem verdeckt wird?

Falls ich das so richtig verstanden habe, -> ja das sollte sich umsetzen
lassen. Hört sich ganz nützlich an.

Gruß Hayo

Hallo Hayo,
jetz habe ich mich auch mal an deine Beta rangetraut. Folgendes ist mir
aufgefallen:

Das Signal wird nicht bis zum unteren Bildschirmrand gezeichnet. Schön
zu sehen an einem "übersteuerten" Sinus.

Die Quick-Measures funktionieren nicht richtig.

Wenn man die Eingangskopplung der Kanäle auf GND schaltet, kleben die
Nulllinien am oberen Bildschirmrand.

Die Multiplikation sieht komisch aus und scheint einen großen negativen
Offset zu haben. Man muss einen positiven Offset einstellen, um das
Signal überhaupt auf den Schirm zu kriegen.
Die Eingangskopplung stand natürlich auf AC.

Beim Versuch die Daten auf den PC zu übertragen, bleibt der
Fortschrittsbalken in der Welec Software am Ende stehen und es passiert
garnichts mehr.

Beim XY ist auch auf beiden Kanälen ein negativer Offset. Vieleicht der
selbe den branadic meint.

Das symmetrische Raster ist wunderschön ;-)

Mfg,
Kurt

Kurt Bohnen wrote:

> Das Signal wird nicht bis zum unteren Bildschirmrand gezeichnet. Schön
> zu sehen an einem "übersteuerten" Sinus.

Ja, Fehler ist bekannt  -> hab ich in der readme beschrieben, nach der
Ursache suche ich noch, passiert irgendwo beim Zusammenmischen der
Grafiklayer.

> Die Quick-Measures funktionieren nicht richtig.

Hab ich befürchtet, da hier die Zerolinie völlig verschoben ist durch
meine Änderungen -> muß ich noch machen

> Wenn man die Eingangskopplung der Kanäle auf GND schaltet, kleben die
> Nulllinien am oberen Bildschirmrand.

Oh, hatte ich ich noch garnicht bemerkt, ist das gleiche Problem wie bei
Quickmeasure, werd ich bis zur nächsten Beta beseitigen.

> Die Multiplikation sieht komisch aus und scheint einen großen negativen
> Offset zu haben. Man muss einen positiven Offset einstellen, um das
> Signal überhaupt auf den Schirm zu kriegen.

Hier wirkt sich die Multiplikation sehr stark auf kleinste Abweichungen
aus. Bei meinen bisherigen Testsignalen ist mir das nicht so extrem
aufgefallen. Hab mal Dein Testsignal nachgestellt und muß Dir recht
geben. Da muß ich mir nochmal was überlegen -> eine Idee hab ich schon.

> Beim Versuch die Daten auf den PC zu übertragen, bleibt der
> Fortschrittsbalken in der Welec Software am Ende stehen und es passiert
> garnichts mehr.

Die übertragung zum PC hab ich zur Zeit noch überhaupt nicht auf dem
Radar, da ich davon ausgegangen bin, dass Falk hier dran ist. Allerdings
hab ich da schon länger nichts mehr gehört. Muß ich aber erstmal hinten
an stellen, da mir die anderen Funktionen erstmal wichtiger sind.
Trotzdem Danke für den Hinweis.

> Beim XY ist auch auf beiden Kanälen ein negativer Offset. Vieleicht der
> selbe den branadic meint.

Konnte ich leider nicht nachvollziehen. Wie man an meinem Testsignal
weiter oben sehen kann geht die Diagonale ziemlich genau durch den
Nullpunkt. Wie groß ist denn Dein Offset und wie hast Du gemessen?

> Das symmetrische Raster ist wunderschön ;-)

Höre ich gerne...

Gruß Hayo

branadic wrote:

> Ich messe übrigens nicht mit 50-Ohm-Kabeln sondern mit den Tastköpfen.
> Abgeschlossen ist das DDS-Board aber dennoch mit 50 Ohm.

Ich vermute, dass die Tastköpfe die Phasenverschiebung verursachen.

> Daher nun auch das Bild. Zum Einen siehst du wie die beiden Signale
> schön voneinander phasenverschoben liegen, zum Anderen gleich noch den
> Ausreißer.

Schicke Liss-Figur, hab ich bei mir leider nicht hingekriegt, da ich
keine so schöne Phasenverschiebung produzieren konnte - muß ich mal mit
den Tastköpfen probieren.

> Auf dem Bild von Kurt kannst du übrigens die Hieroglyphe sehen, die
> zieht sich dann (siehe mein Bild) in andere Menü's mit und wird nicht
> überschrieben.

Ist keine Hieroglyphe, sondern ein kleines Bild. Dachte das wäre so
original. Keine Ahnung wo das herkommt, an der Stelle hab ich auch
nichts verändert. Scheint noch ne Macke aus der 1.2 FW zu sein.
>
> Ansonsten hast du mich genau richtig verstanden, was die Signalpriorität
> auf dem Bildschirm angeht. Ich denke das ist eine nette Bereicherung auf
> auf dem Welec.

Kümmere ich mich drum

> Ist dein 4-Strahler heute eigentlich eingetroffen? Hin und wieder hab
> ich die Vermutung, dass einige vermeintliche Fehler in deiner FW auf die
> Tatsache zurückzuführen sind, dass ich hier noch den 2. FPGA drin habe.

Nein, Schande auch! Christian (hat im anderen Thread gepostet) hat seins
schon - ich nicht, hmmm...
-> morgen bestimmt.

Dann werd ich da mal ein paar Vergleiche anstellen.

Gruß Hayo

Das mit dem Offset in der XY Darstellung nehme ich zurück. Das lag nur
am falschen Nullabgleich der Kanäle.
Jedoch funktionieren die Cursor hier nicht richtig.

Und in der normalen Betriebsart stimmen die Anzeigen der Y-Cursor nicht
mit dem Raster überein.

Kurt Bohnen wrote:
> Das mit dem Offset in der XY Darstellung nehme ich zurück. Das lag nur
> am falschen Nullabgleich der Kanäle.
> Jedoch funktionieren die Cursor hier nicht richtig.
>
> Und in der normalen Betriebsart stimmen die Anzeigen der Y-Cursor nicht
> mit dem Raster überein.

Cursor hab ich noch überhaupt nicht probiert, die müssen noch angepasst
werden. Hatte erstmal mit der XY-Funktion und der Optimierung der line()
Funktion alle hände voll zu tun. Wollte erstmal das Feedback zur reinen
XY-Funktion abwarten bevor ich weitermache.

Das Gleiche gilt für die Cursor in der normalen Betriebsart.

Das Dumme ist, dass ich hier Korrekturen an Coding durchführe für die
WELEC mehrere Jahre Entwicklungszeit hatte - dafür dass ich das nur
nebenbei mache bin ich also recht schnell finde ich.

Nichtsdestotrotz bin ich guter Dinge, in erster Linie versuche mal die
grundlegenden Funktionen benutzbar zu machen.

Gruß Hayo

Guido wrote:
> So alle,
>
> habe auch mal mit XY-Modus probiert. Bin ich eigentlich der Einzige, der
> den mit einem SA o.ä. verwenden möchte?

Was ist SA?

> Lissajous ist ja ein schönes
> Spielzeug aber dafür sind DSOs doch nicht wirklich gut geeignet.

Geht besser als mit meinem analogen 50MHz Oszi, das ist XY-Betrieb nur
bis 100KHz spezifiziert, danach ist die interne Phasenverschiebung zu
groß.

> @ Hayo: Die Darstellung im XY-Modus ist an der Mittelsenkrechten
> gespiegelt (Fotos mach ich später noch). Welche Y-Signale stellst du
> denn
> dar, alle passen ja wohl nicht auf den Schirm. Ich vermute, dass da
> ziemlich ausgefuchste Algorithmen nötig sind.

Wie meinst Du das mit den Y-Signalen?

> [Mecker:] Schönes Raster, aber mir fehlen echt die 2 Divisions in der
> Horizontalen. [/Mecker:]

Welche Division möchtest Du denn noch haben? Habe zum Vergleich nur mein
analoges Oszi und da sieht es genauso aus. Ansonsten läßt sich das Grid
über Terminal auch in die alte gepunktete Darstellung umschalten ->
siehe readme

> @ branadic: Hast du vllt. den 2. Kanaleingang auf AC stehen? Bei
> niedrigen Frequenzen verursacht der Koppelkondensator so eine
> Phasenverschiebung.

 Das stimmt, das könnte sein...

Gruß Hayo

@Guido

Ich habe mal die Sache mit dem spiegelverkehrten Signal um die vertikale
Achse geprüft -> Du hast Recht, es ist verkehrt rum.

Muß also noch korrigiert werden. Ist in Arbeit...

Gruß Hayo

Hallo Guido,
so, jetzt lass mich bitte nicht unwissend sterben...
Wozu brauchst du den XY Betrieb? Zur Spektralanalyse? Hmmm also das
interessiert mich dann schon wie du das machst. Wenn ich das richtig
verstanden habe führt dein TEK diese SA durch und du missbrauchst das
Welec nur zur Anzeige des Ergebnisses- weil du dir davon eine bessere
Darstellung versprichst?
Mal sehen wozu die eingebaute FFT im Stande ist, wenn diese einmal in HW
implementiert ist... vielleicht verkaufst du dein TEK dann ja? Das TEK
hat aber bestimmt eine wesentl. höhere Grenzfrequenz?

Meine Hauptanwendungen des XY -Betrieb sind:
Bestimmen von Frequenzbeziehungen- vor allem geringste Phasenjitter
lassen sich so absolut präzise feststellen. Bei analogen Oszi's ist das
allerdings  meist nur bis Frequenzen von ca. 1MHz möglich, da darüber
die geräteinternen Phasenjitter zu groß werden.
Aber die wichtigste Anwendung ist die Aufnahme von Kennlinienfelder.
Dioden, Transistoren u.v.m. lassen sich somit schnell und exakt in ihren
elektr. Kenngrössen miteinander vergleichen.... Der XY-Betrieb ist damit
weit mehr als nur eine Spielerei!

Gruß
brunowe

Guido wrote:

> Mit SA meine ich einen Spektrumanalyzer, hier mein Stolz, ein
> TEK 1401A, bestimmt älter als die meisten Teilnehmer dieses
> Forums.
-> Cool! Dann ist das Gerät also schon so um die 50 Jahre alt?
Wußte garnicht das es damals schon sowas gab ;-)

> Zum Vergleich links die Aufnahme am TDS210, viel besser geht es
> mit einem analogen Oszi auch nicht. Die "Nachleuchtfunktion" ist
> bei dieser langen Aufzeichnungsdauer sehr hilfreich, könnte aber
> schwierig zu implementieren sein.

Sowas ähnliches wie die Nachleuchtfunktion gibt es am W20xx auch, nennt
sich "Persist" im Display-Menü.

> Auf dem Welec ist das Bild seitenverkehrt, das Hayo ja schon im Griff.

Jupp, ist schon erledigt.

> @ Hayo: Denke einfach an die FFT: 100 MHZ bzw. 200 MHz mit 8 div wird
> ziemlich ungerade. Mir geht es mit 500 MHz genauso, deswegen wären
> horizontal 10 div (wie bei jedem Oszi) besser, Symmetrie hin oder
> her. Dass es dann mit den Spannungen ungerade wird ist kein Problem,
> da sich dieses mit einem Spannungsteiler lösen lässt.

Nicht nötig, da ich gerade dabei bin eine Spectralanalyse (FFT) zu
implementieren die auch nicht schlechter sein wird als beim TEK.
Allerdings bin ich ebenso wie Bruno neugierig wie Du die Darstellung im
XY-Modus hingekriegt hast -> sieht irgendwie cool aus

> Die Y-Signale: bei der Speichertiefe des Gerätes kann ich mir nicht
> vorstellen, dass du alle Werte zeichnest. Wie triffst du die Auswahl?

Korrekt, ich hatte die Auswahl zwischen wenigen Werten (schnell) und
vielen Werten (langsam). Da die reale Speichertiefe je nach Timebase
Zwischen 655 und 16K variiert, habe ich mich für die Darstellung der im
Zeitbereich angezeigten 600 Punkte entschieden. Dann weiß man, dass man
im XY-Betrieb genau das sieht was man vorher im Normalbetrieb
eingestellt hat.

> Lissajous: Die einzige mir bekannte Nutzung dieser liegt im Abgleich
> von Oszillatoren. Mit einem DSO, das mir 1 bis 2 Bilder pro Sekunde
> darstellt wird das aber sinnlos. Da kann man einfacher einen
> Frequenzzähler einsetzen.

-> die Antwort hat Bruno schon gegeben...

> Was ich noch überhaupt nicht kapiere: kann das Gerät sich Einstellungen
> merken? Kann ich mir eigentlich nicht vorstellen (im FPGA). Aber mir
> kommt es bei der vertikalen Abschwächung so vor, die Offseteinstellung
> ist aber immer nach dem Ausschalten weg.

-> definitiv ja! Bei bestimmten Eingaben (z.B. Verstellung der Timebase)
werden alle aktuellen Parameter ins Flash in den Konfigurationsbereich
geschrieben (kann man bei meiner FW sehen wenn ein Terminalprogramm
läuft). Allerdings muß ich zugeben, dass einige meiner neuen Parameter
noch nicht gesichert werden, ist aber auch schon in Arbeit.

Gruß Hayo

Eben habe ich mal diesen Phasenschieber zusammengelötet. Bei f0 macht er
-90°. Aber durch ändern der Eingangsfrequenz ändert sich auch die
Phasenverschiebung.

So sieht es dann auf dem Oszi aus bei 33kHz, 66kHz und 16kHz.

Hey, sehr schön, sowas hat mir als Bestätigung für die Funktion noch
gefehlt. Mußte mich immer mit einer Mischung aus Sinus (Funkt.
Generator) und Rechteck (Quarzoszillator) begnügen. Das entstehende
Signal ist aber für Testzwecke eigentlich zu kompliziert. Daher ist das
Bild sehr willkommen!

Gruß Hayo

Oder wer's einfacher haben will:
Passive Phasenschieberbrücke s.h. Bild

Kleiner Fehler im Bild: es existiert kein R2 ;) nur R4 :P

Und es gibt leider keine Möglichkeit U2 zu messen wenn man gleichzeitig
U1 messen möchte und/oder einen geerdeten Funktionsgenerator verwendet.

Ok, an die 500 MHz komme ich natürlich nicht heran, was ich aber meinte
war die Darstellung des Signals. Da werd ich mich mal ins Zeug legen,
dass das mal etwas geschmeidiger aussieht als ursprünglich bei den alten
Welecs. Bin da auch schon vorbelastet, da ich sowas mal als Diplomarbeit
gemacht habe.

-> Das mit dem Sägezahn werde ich auch mal ausprobieren, den Trick
kannte ich noch garnicht, man lernt nie aus...

Gruß und guats Nächtle wie der Schwabe sagen würde

Hayo

Ein Sägezahn als x-Signal- also eine gleichmäßig ansteigende Spannung.
Warum erinnert mich das nur so an das Zeitbasis- Signal? Das würde doch
bedeuten du kannst gleich den normalen Betriebsmodus wählen, wenn du
eine entsprechende Zeitbasis- Einstellung findest?

Hallo Guido,
siehst du...
>Das 1401A hat übrigens keine eigene
>Anzeige, war also zum Gebrauch mit einem Oszilloskop vorgesehen...

das war die entscheidende Info- Das Tek stellt also auch direkt das
passende Sägezahnsignal zur Verfügung. Das selbe kannst du mit einer
variabel einstellbaren Zeitbasis, so wie es viele Oszi's besitzen, auch
erreichen.
(Ein Referenzsignal vorausgesetzt)

Aber mit der Info:
1) Das Tek hat keine eigene Anzeige und
2.) Es stellt dafür ein Sägezahnsignal für die xy Ablenkung zu
Verfügung,
hätten wir uns die letzten 10 Posts sparen können.

Gruß

Hallo Michael,

danke für die Hinweise, leider hab ich meinen Vierkanaler immer noch
nicht... grummel, Welec läßt sich verdammt viel Zeit, vielleich heute.

Daher bin ich auf den Kanälen 3 + 4 "blind" und kann da momentan nichts
dran machen. An einem neuen Nullabgleich bin ich aber ohnehin dran, da
ich auch noch nicht zufrieden war.


@Guido

Ich habe die XY-Funktion noch mal komplett überarbeitet und erweitert.
Du hast recht, in der 0.48 dreht das Ding noch ein paar Ehrenrunden,
deswegen sieht das auch etwas zugemüllt aus. Die neue Version ist
schneller, hat einen komplett von der Zeitdarstellung getrennten Offset
und - kleines Schmankerl für alle 4-Kanaler - eine zusätzliche
XY-Darstellung für Kanal 3 + 4 die auch gleichzeitig mit Kanal 1 + 2
dargestellt werden kann.

Nebenbei hab ich etliche Fehler beseitigt. Die neue Version gibt es
heute oder morgen.

Gruß Hayo

Hallo Hayo,

mir ist aufgefallen das in deiner FW- genauso wie im Original, im
"Vector off- Mode" nicht nur die Messwerte dargestellt werden. Falls ich
mich nicht verzählt habe werden in 10ns/Div 40Px gezeichnet, obwohl ja
nur Jede Nanosekunde ein Messwert vorliegt. D.h. es wird schon irgendwie
interpoliert...

Ich fände es, speziell für die Entwicklungsphase, weitaus besser wenn
wirklich nur die reinen Messwerte dargestellt werden. Man könnte so
wesentl. leichter etwaige ADC Nichtlinearitäten zuordnen (und
beseitigen).
Slog hat das in seinem FPGA Design wunderschön vorgemacht, indem jeder
ADC seine eigene Zeichenfarbe erhalten hat. Ich möchte jetzt keine
Grundsatzdiskussion über Sinn und Unsinn des Vector -off Mode
lostreten... dennoch würde dieses Feature gerade auch bei der Lösung der
HW Probleme imens helfen.

Gruß Brunowe

@Guido

Ja das mit dem eingefrorenen Signal konnte ich auch nachvollziehen, war
mir nur nie aufgefallen da ich in diesen Zeitbereichen nicht so häufig
teste. Meine Vermutung ist, dass es mit dem Trigger zusammenhängt, denn
die Zeichenroutine wird durchlaufen, es kommt nur kein neues Signal. Ich
hatte aber für das übernächste Betarelease ohnehin vor größere
Änderungen durchzuführen, unter anderem wollte ich den Zeroshift wieder
einbauen und dann einen neuen Zero-Offsetabgleich programmieren.
Vermutlich erledigt sich das Problem dann gleich mit.


@Bruno

Ja natürlich hast Du recht, denn die Signalgewinnung und
Signalverarbeitung sind komplett getrennt von der Zeichroutine. D.h.
wenn umgeschaltet wird zwischen Vector und Nonvector dann betrifft das
nur die Zeichenroutine. Die bekommt aber nur einen Wertebuffer übergeben
der die zu zeichnenden Werte enthält - in den Bereichen > 50ns sind das
halt die interpolierten Signalwerte. Die Interpolation findet also nicht
in der Zeichenroutine statt sondern vorher, daher wäre es etwas
schwierig die interpolierten Werte hinterher wieder auszublenden.
Weglassen kann man sie aber auch nicht, da sonst die Zeitachse nicht
mehr korrekt wäre(wäre sonst wie 50 ns).

Die Features der experimentellen FPGA-Version von Slog lassen sich hier
nur schwer einbauen (der derzeitige Stand ist dafür schon zu komplex),
auch wenn ich Dir recht geben muß, dass es für einige Tests ganz
hilfreich wäre.

Gruß Hayo

p.s. die neue FW kommt doch erst morgen, mein Oszi hoffentlich auch...

Hayo W. wrote:

> der die zu zeichnenden Werte enthält - in den Bereichen > 50ns sind das

sollte natürlich heißen < 50 ns - interpoliert werden 20ns und 10 ns
(und in Kürze auch die neue Zeitbasis 5ns)


Hayo

Hallo Hayo,

ja das habe ich mir schon fast gedacht :-(     Wäre zu schön gewesen!
Dann muss ich mich wohl bei meiner "Messerei" anders behelfen...
Eine 5ns Zeitbasis ist ein guter Einfall, setzt aber eine gute
Interpolation (sinx/x) voraus.

Gruß
brunowe

Ob die Interpolation gut genug ist kannst Du Dir ja mal ansehen, es gibt
den 5ns Bereich nämlich schon - nur noch nicht im Main-Mode. Wenn Du bei
10ns in den Delayed-Mode schaltest hast Du Ihn!

Gruß Hayo

So hier wie angekündigt die aktuelle beta version 0.50 - es sind einige
Änderungen erfolgt insbesondere im XY-Betrieb.

Wundert Euch nicht beim Neustart, wenn es erstmal komisch aussieht. Da
ich die Ablage der Parameter im Config-Bereich geändert habe werden
erstmal unpassende Parameterwerte gezogen. Durch Betätigung des
Defaultsetups ist das dann aber erledigt. Bei der nächsten Verstellung
der Timebase werden dann aktuelle Werte weggeschrieben. Einen Flashdump
habt Ihr ja vorsichtshalber gemacht oder?

In der Defaultzeichenroutine werkelt jetzt die neue beschleunigte line()
Funktion, da diese das Signal an den Spitzen feiner auflöst als die alte
Zeichenroutine. Kann man gut sehen wenn man via Terminalprogramm mit den
Tasten shift + s die Darstellung umschaltet. Die Geschwindigkeit ist so
ziemlich gleich.

Die XY-Funktion hat jetzt eine eigene Zeroverstellung, deren Werte auch
getrennt im Configbereich abgelegt werden, so daß nach dem
Wiedereinschalten des Gerätes das Sinal noch an der gleichen Stelle ist
wie vorher.

Die Leute mit einem Vierkanalgerät könnten ja mal die XY-Funktion für
die Kanäle 3 + 4 testen die ich zwar implementiert habe, aber selber
noch nicht zu Gesicht bekommen habe (schneuz).

Die nächste Version wird wohl etwas dauern, da erstmal Ostern anliegt
und ich dann größere Umbaumaßnahmen vor habe, mit denen dann hoffentlich
auch etliche aktuelle Bugs verschwinden.

Also laßt mal hören was Ihr dazu meint.

So zum Schluß muß ich nochmal meinen Frust loswerden....mein Oszi ist
immer noch nicht da, obwohl WELEC das für den 4. April als spätesten
Termin angekündigt hatte. Die Gutschreibung des Betrages war sogar schon
am 27.3. . Da bin ich doch schon etwas geknickt muß ich sagen.

So langsam könnte das mal an Land kommen oder?

Gruß Hayo

Hallo Hayo,
das schalten der Kanäle auf GND funktioniert wieder. Allerdings behällt
Kanal 2 einen winzigen positiven Offset.

Ein verstellen der Volt/Div Knöpfe sorgt dafür dass sich der
entsprechende Kanal leicht verschiebt. Jedoch Komplett: Nullmarkierung,
Nulline, Triggermarkierung.

Noch schlimmer ist es bei Kanal 1: Wenn ich den Volt/Div Knopf beliebig
weit nach rechts drehe, also in Bereiche von 5mV,2mV,1mV... (wenn es die
geben würde) verschiebt sich der Kanal immer weiter nach oben.

Mfg,
Kurt

PS: Hoffentlich verzögert Welec den Versand nicht absichtlich. In den
Bewertungen heißt es immer "schnelle Lieferung".

Kurt Bohnen wrote:
> Hallo Hayo,
> das schalten der Kanäle auf GND funktioniert wieder. Allerdings behällt
> Kanal 2 einen winzigen positiven Offset.
>
> Ein verstellen der Volt/Div Knöpfe sorgt dafür dass sich der
> entsprechende Kanal leicht verschiebt. Jedoch Komplett: Nullmarkierung,
> Nulline, Triggermarkierung.
>
> Noch schlimmer ist es bei Kanal 1: Wenn ich den Volt/Div Knopf beliebig
> weit nach rechts drehe, also in Bereiche von 5mV,2mV,1mV... (wenn es die
> geben würde) verschiebt sich der Kanal immer weiter nach oben.

Hmm, muß ich mir mal angucken, ich hab die Nullinie jetzt geändert, in
der originalen FW wird einfach stumpf eine Linie beim Zerolevel
gezeichnet, während ich das jetzt so geändert habe, dass in der
Ausleseroutine des ADC statt der ADC-Werte Null (bzw. 127) in den
Speicher geschrieben wird. Ansonsten würde nämlich auch das Math-Signal
falsch berechnet werden, da ja im Hintergrund immer noch das
ursprüngliche Signal ausgelesen und berechnet würde.

> PS: Hoffentlich verzögert Welec den Versand nicht absichtlich. In den
> Bewertungen heißt es immer "schnelle Lieferung".

Da wären sie ja schön blöd, denn breiter als hier könnten sie es wohl
kaum irgendwo trampeln! Wenn man bei Google die entsprechenden Begriffe
eingibt landet man zwangsläüfig in diesem Forum - Allerdings
interessanterweise nicht in diesem Thread sondern im Alten. Anscheinend
ist der Suchcache noch nicht aktualisiert worden.

Gruß Hayo

Keine Ahnung was die sich denken. Wittig/Welec ist nicht gerade für
seine logische Handlungsweise bekannt...

Prima,

unsere kleine Gemeinde wächst von Woche zu Woche. Da macht das
weiterentwickeln so richtig Spass...

Ich denke übrigens nicht, dass da Absicht hintersteckt. Allerdings hab
ich heute mal eine Anfrage abgeschickt aber noch keine Antwort gekriegt.

Gruß Hayo

Oh, das sollte eigentlich eine Antwort an Egberto sein, aber ich sehe
gerade dass da schon wieder zwei Beiträge dazwischen stehen :-)

Danke übrigens wieder für die schnellen ersten Reaktionen. Heute hab ich
allerdings keine Lust mehr die Kiste anzuschmeißen. Werd mir das mal
später ansehen


@ Guido

Hast Du mal den XY-Modus auf Kanal 3 + 4 gecheckt? Würd mich mal
interessieren, ich kann das ja (noch) nicht sehen...

Gruß Hayo

So, jetzt hab ich mich hier auch mal angemeldet ;-)

Der X-Y-Modus funktioniert auch auf 3+4. Jedoch kann man nicht in den
X-Y-Modus, wenn Kanal 1 und/oder 2 deaktiviert ist. Auch funktioniert
hier der Offset noch nicht. Man muss beide Kanäle auf die Mitte regeln,
bevor man in den X-Y-Modus geht. Das klappt automatisch nur bei 1+2.

Fotos mach ich evtl. nachher noch und stelle sie rein.

MfG, Michael

was mir gerade aufgefallen ist:
wenn man im x-y-Modus zwischen Vektor- und Punkt-Anzeige umschaltet,
dann wird das Signal an der y-Achse gespiegelt!

@Michael

Danke für die Hinweise.

>wenn man im x-y-Modus zwischen Vektor- und Punkt-Anzeige umschaltet,
>dann wird das Signal an der y-Achse gespiegelt!

Da hab ich doch tatsächlich nur den Vektorbetrieb korrigiert und den
Punktbetrieb vergessen -> wird gemacht.

Gruß Hayo

@Hayo
ich habe mir erlaubt die FW1.2.BF.0.50_beta.zip in die Google Groups zu
stellen, hier im Mikrocontroller Forum findet die keiner aus dem
internationalen Umfeld :-)

-lässt sich irgendwie ein ADC Abgleich durch den User verwirklichen?
Praktisch wäre sowas natürlich via Menü und Encoder... aber wohl zu
komplex und eher wieder was fürs VHDL Projekt?
Bei meinen Messungen (die schon schwer im Gange sind) ist mir
aufgefallen das wohl viele Probleme (z.B. das Rauschen) durch den
schlechten ADC Abgleich zumindest begünstigt werden.

Gruß
brunowe

P.S.: Anbei noch ein kleines "Stimmungsbild"

Hi Community,

hab die FW mal angetestet, die bisher beschriebenen Phänomene konnte ich
z.T. auch schon beobachten, aber was mir arg zusetzt ist der Trigger. Da
dies die erste FW ist, die ich installiere, weiß ich nicht obs an der FW
oder an der Hardware liegt.

Ich hab jetzt keine Ahnung ob der durch die FPGA- oder die
Softcore-Firmware beeinflusst wird, jedenfalls konnte ich auf eine
sporadisch auftretende Flanke (ein Taster, der an der Mittelabzapfung
eines Spannungsteilers einen Spannungssprung erzeugt) beim besten Willen
nicht triggern, während es bei periodischen Signalen problemlos klappt.

Ansonsten, danke für die FW :-)

Das mit dem Trigger ist mir auch schon aufgefallen. Jedoch meine ich das
es nur bei CH1 extrem war und die anderen funktionierten. Werde das aber
heute Abend nochmal ausprobieren.

Bei mir klappt das angegebene Experiment auf keinem der Kanäle. Auch
nicht mit Puls-Trigger, welcher ja eigentlich noch besser geeignet wäre
für so was. Und auch bei keiner Timebase-Einstellung.

Okay, ich habe dem Projekt bereits meine Hilfe angekündigt, da weiß ich
ja jetzt wo was zu tun ist :-)

Hi,

bin aus dem Osterurlaub zurück und - Überaschung - das W2014 ist da.
Also, alles wird gut. Übrigens steht auch nur W2014 (ohne A) auf dem
Gehäuse, ich vermute mal das da alte Restbestände an Gehäusen oder
Labels verwendet werden. Die Hardware scheint aber aktuell zu sein.

Hab erstmal das komplette Flash gesichert, wer also seins zerschossen
hat kann gerne anfragen.

@Andreas

Mach mal erstmal noch nichts wegen des Triggers. Wie ich schon im readme
beschrieben habe hängt das unter Umständen mit der Deaktivierung des
Zeroshifts zusammen, den ich wegen des Nullabgleichs vorgenommen hatte.
Zur nächsten Beta werde ich das wieder aktivieren, ab da wird es dann
wirklich interessant wegen Nullabgleich, Trigger und Cursor. Der
derzeitige Stand ist nur ein Zwischenstand. In der nächsten Version
werde ich ebenfalls mal die Funktionen von Kanal 3 + 4 prüfen und
überarbeiten.

Gruß Hayo

@Hayo,

nochmal zum Trigger: wenn ich den Trigger auf AC stelle, klappts.
Seltsam, da ich überzeugt bin, dass der Trigger auch bei DC-Coupling
auslösen müsste, wenn ich den Triggerpegel zwischen H- und L-Level des
Signals lege.

Och egberto...
wie oft hatten wir das denn schon?
Lese doch einfach mal die alten Posts.
Tipp: Welec Updater... (wenn du "nur" mit Hayo's FW spielen willst...)

Bruno We wrote:
> wie oft hatten wir das denn schon?
> Lese doch einfach mal die alten Posts.

Macht doch mal einen Artikel draus. Schliesslich breiten sich die Geräte
hier ja nun doch etwas aus, und jedem neuen Nutzer nahezulegen, 100e
Posts in mehreren Threads zu lesen... hust ;)

/Hannes

Liest eigentlich keiner das readme das ich dem FW-Update beigelegt habe?
Da steht doch alles drin und der Updater ist doch auch schon dabei.

Also hier noch mal zum Mitschreiben im Detail.

Backup erstellen:

- DSO und PC mit dem seriellen Kabel verbinden - beide anschalten!
- den Welecupdater starten, in der Parameterauswal (Pfeiltaste neben dem
grünen IC-Symbol) den Adressbereich einstellen.
- Komplettdump 00040000 bis 007FFFFF davor steht nichts drin und danach
fängt das RAM an.
- FW-Dump 00040000 bis 000DFFFF
- Config, protected Config und Signalspeicher 000E0000 bis 007FFFFF

- Am DSO die linken beiden Funktionstasten unter dem Bildschirm drücken,
es wird erst weiß dann schwarz - der Germs-Monitor ist aktiv
- Beim Welec-Updater den Download starten
- Nach dem Download mit dem Speichernbutton (Diskettensymbol) den Dump
in eine Datei speichern

Dump wieder zurückspielen:

- Am DSO die linken beiden Funktionstasten unter dem Bildschirm drücken,
es wird erst weiß dann schwarz - der Germs-Monitor ist aktiv.
- Beim Welec-Updater den Upload starten, die Flashdumpdatei auswählen
und den Upload bestätigen.
- wenn der Upload fertig ist kommt entweder eine Timeoutmeldung
(Übertragungsfehler) oder die Meldung "Fertig". Beides ist gut.
- danach DSO auschalten und dann wieder einschalten - das war es

Gruß Hayo

@Hayo,

der WelecUpdater hat bei mir erst funktioniert nachdem ich den Pfad auf
die .flash-Datei in der .ini-Datei angepasst hatte, erst dann wurde der
Download-Button grün (war davor disabled). Hat mich ne ganze weile
gekostet das herauszufinden, da der Pfad absolutcodiert auf das
Verzeichnis C:\Temp zeigt. Evtl. sollte in einem Future-Release ein
relativer Pfad (z.B. ".\tomcat.flash") angegeben werden.

Hi,

der Welecupdater ist von Markus geschrieben worden, daher
Änderungsvorschläge direkt an Ihn richten. Ansonsten kann ich aber in
zukünftigen Betareleases auf diese Eigenheiten hinweisen.

Ach ja, eine Frage - ich habe gerade eine Zwischenversiomn fertig, bei
der ich die XY-Funktion bzw. die Menüsteuerung angepasst habe und auch
sonst noch einige Kleinigkeiten in Bezug auf die Vierkanalfunktion
geändert habe. Soll ich die hier einstellen, oder lieber bis zum
nächsten größeren Release warten?

Gruß Hayo

Hi @Hayo,

also angesichts der Tatsache dass jede FW, insbesondere die originale,
mit einigen Bugs behaftet ist, nehme ich jedes Release gerne an, solange
es keine anderen Funktionen außer Kraft setzt. Außerdem ist das W2024A
mein einziges Oszi, über jede Verbesserung an meinem
oszillographierenden Messknecht bin ich froh :-) Gerade die
Menügeschichten klingen nützlich.

So, hier wie angekündigt die vorgezogene beta 0.54.

Highlights sind:

- neue Timebase 5ns -> Trigger stimmt hier noch nicht
- manuelle Abgleichfunktionen für DAC und ADC
- neu implementierter Zeroshift
- diverse Bugs die Ihr mir gemeldet habt sind behoben
  (Invers-Bug, Triggeroffset etc.)

einige Sachen sind leider noch offen, da ich wegen der etwas
überhasteten Veröffentlichung keine Zeit mehr zum Testen und korrigieren
hatte.

Dem Paket habe ich auch eine aktualisierte Anleitung für das Erstellen
eines Backups und die Handhabung des Updaters beigefügt.

Die Kurzanleitung für den manuellen Abgleich findet Ihr am Ende des
Readme. Für diese Funktionen braucht Ihr auf jeden Fall ein
Terminalprogramm. Wenn es dazu noch Fragen gibt immer raus damit.

Gruß Hayo

Na das ist doch mal Klasse, danke!

 Gruß, brunowe

So, hab die FW grade mal draufgeflasht (ist ja in Verbindung mit dem
Backup ein abendfüllendes Programm :D) und werd dann mal bissi
rumspielen.

Was mir grade wieder auffällt: wäre es nicht sinnvoll, wenn durch Wählen
des aktiven Kanals auch gleich diese Triggerlevelmarke mit zum aktiven
Channel wechseln würde? Wenn ich Kanal 2 auswähle und dann am
Triggerlevel rumdrehe, ändert sich nach wie vor der Triggerlevel von
Kanal 1. Find ich irgendwie umständlich.

/Hannes

Gerade habe ich die neue Firmware geflasht - gibt's eigentlich keine
Möglichkeit, das über USB zu erledigen? Junge, Junge...

Die Kallibrierung:
beim vierten Kanal ist das Rauschen sehr gering gewesen, nach oben
hin(3,2,1) immer stärker...

Ich muss mich erstmal intensiver mit dem Teil beschäftigen (Spruts USB
PIC Brenner z.B. der hat bei mir eine zu hohe Brennspannung...). Die
Anzeige scheint mir aber immer noch sehr langsam. Slog soll ja bis zu
70(!) Frames/s mit dem neuen FPGA-Design hinbekommen...
Heute (gestern) hatte ich auf der Hannovermesse ein LeCroy in Action
gesehen - huuuh, ganz andere Liga, 15k€...

Michel

Hey,

@Slackman: warum das über USB nicht geht, frag ich mich auch jedes
mal...
Hat schon einmal jemand versucht, die neue FW einfach in die Original
Flash reinzukopieren (nach den Bootlader) und dann via original
W2000-update hoch zu laden? Ja ich weiß- original sind S2 Code- Zeilen
mit anderem Adress- Aufbau... war ja nur so ein Gedanke.
Wüsstest du das Lecroy derzeit eine Oszi- Abwrackprämie anbietet (ich
glaub 3000€- für Oszis ab 12k€) da kannst du dir jetzt direkt ein
Schnäppchen holen.

Gruß, brunowe

Johannes Studt wrote:

> Was mir grade wieder auffällt: wäre es nicht sinnvoll, wenn durch Wählen
> des aktiven Kanals auch gleich diese Triggerlevelmarke mit zum aktiven
> Channel wechseln würde? Wenn ich Kanal 2 auswähle und dann am
> Triggerlevel rumdrehe, ändert sich nach wie vor der Triggerlevel von
> Kanal 1. Find ich irgendwie umständlich.

Der aktive Kanal muß aber nicht unbedingt der Triggereingang sein! Daher
wäre es ja nicht sinnvoll die Triggersource einfach zu wechseln. Es
kommt ja auch vor, dass auf dem einen Signal getriggert und das andere
begutachtet wird.

Was man natürlich machen könnte, wäre beim Abschalten eines Kanals
gegebenenfalls die Triggersource automatisch auf den nächsten aktiven
Eingang zu legen.


Michael Werner wrote:
> Gerade habe ich die neue Firmware geflasht - gibt's eigentlich keine
> Möglichkeit, das über USB zu erledigen? Junge, Junge...

Klar ginge das. War auch schon mal angedacht. Falk und Markus hatten
sich hierzu schon Gedanken gemacht. Da scheint aber noch nichts passiert
zu sein. Ich selbst bin mit USB nicht so gut vertraut und habe mich
daher erstmal auf die Firmware konzentriert.

> Die Kallibrierung:
> beim vierten Kanal ist das Rauschen sehr gering gewesen, nach oben
> hin(3,2,1) immer stärker...

Ja das sieht bei mir auch so aus. Das fällt einem bei der originalen FW
nur nicht so auf.


> Die Anzeige scheint mir aber immer noch sehr langsam. Slog soll ja bis zu
> 70(!) Frames/s mit dem neuen FPGA-Design hinbekommen...

Stimmt, das liegt daran, dass im WELEC (Referenz) NIOS-Design keine
extra Multiplikationseinheit vorgesehen ist (es gibt auch ein Design mit
extra Multiplikator). Nun muß ich aber um die Anzeige genau zu machen
pro Meßwert eine Floating Point Multiplikation durchführen - das kostet
Zeit.
Die original WELEC-Firmware erkauft sich die Geschwindigkeit mit hoher
Messungenauigkeit! Meßt mal die genauen Pegel mit einem geeichten
Multimeter nach, dann wißt Ihr was ich meine. Besonders hoch sind die
Abweichungen in den 2er und 1er Bereichen.

Hier bin ich aber trotzdem dabei noch weiter zu optimieren.


Bruno We wrote:

> Hat schon einmal jemand versucht, die neue FW einfach in die Original
> Flash reinzukopieren (nach den Bootlader) und dann via original
> W2000-update hoch zu laden? Ja ich weiß- original sind S2 Code- Zeilen
> mit anderem Adress- Aufbau... war ja nur so ein Gedanke.

Klar hab ich da schon rumexperimentiert. Leider erwies sich die
WELEC-Software als ziemlich zäh und widerborstig. Alle Möglichkeiten
habe ich hier sicher noch nicht ausgelotet - es besteht also noch
Experimentierpotential. Wenn jemand das hinkriegt, liefere ich die
Flashs auch gerne im WELEC-kompatiblen Format. An den Adressen liegt es
aber glaube ich nicht. Die kann man beim Updater von Markus vor dem
Download in der INI-Datei einstellen und damit eine entsprechende
Testdatei erzeugen.
Falls es nur daran liegen sollte, ist es wohl kein Problem einen
entsprechenden Kommandozeilenkonverter schnell  zusammenzuklöppeln.

Gruß Hayo

Hayo W. wrote:
> Der aktive Kanal muß aber nicht unbedingt der Triggereingang sein! Daher
> wäre es ja nicht sinnvoll die Triggersource einfach zu wechseln. Es
> kommt ja auch vor, dass auf dem einen Signal getriggert und das andere
> begutachtet wird.

Hm, da hatte ich einen Denkfehler drin. Ich war irgendwie der Meinung,
dass jeder Kanal unabhängig voneinander getriggert wird, aber das ist ja
Unfug.

> Was man natürlich machen könnte, wäre beim Abschalten eines Kanals
> gegebenenfalls die Triggersource automatisch auf den nächsten aktiven
> Eingang zu legen.

Das passiert immerhin zwischen Kanal 1 und 2 schon jetzt.

/Hannes

Hi,

erstmal danke für die neue FW - funktioniert soweit gut, vor allem das
mit der Nulllinie freut mich.

Aber eine kleine Frage zum Updater: ist es normal, dass der Flashvorgang
mit Schreibfehlern endet? Das war jetzt mein 2. Updatevorgang, und am
Schluss gabs jedes mal Fehler und Retries. Das Oszi tut allerdings
trotzdem.

Wenn das nur bei mir auftritt werd ich mir die genaue Meldung beim
nächsten mal aufschreiben.

Siehe beiliegende Dokumentation ;)

Ooops... hab die Backup Howto übersehen, die war bisher nicht dabei.
Sorry.

Hallo Hayo,

so, hab mich etwas mit der ADC Kalibrierung gespielt.
Interessant was zu erreichen wäre wenn...
Aber so ganz perfekt ist das Ganze nicht- entweder ist Ch1 ODER Ch2 gut
kalibriert!

Bruno We wrote:
> Hallo Hayo,
>
> so, hab mich etwas mit der ADC Kalibrierung gespielt.
> Interessant was zu erreichen wäre wenn...
> Aber so ganz perfekt ist das Ganze nicht- entweder ist Ch1 ODER Ch2 gut
> kalibriert!

Ja die Kalibrierung bringt nicht immer die gleichen Ergebnisse. Nach
drei Durchläufen ist sie aber meistens konstant. Die automatische
ADC-Kalibrierung wird übrigens für alle Kanäle durchlaufen wenn die
"Search Zeros" Funktion benutzt wird (und zwar direkt vorher).

Bei der manuellen Kalibrierung läßt sich das für jeden Kanal einzeln
einstellen. In den ersten 15 Schritten (jedes Mal beim Drücken von
shift + Q wird ein Schritt weitergeschaltet) werden verschiedene
Kombinationen durchlaufen - dann kommt als letzter Schritt ein
automatischer Abgleich für den Kanal. Mit shift + Z kann man zum
nächsten Kanal schalten und das Spiel neu beginnen. Wenn man alles durch
hat, kann man das Ergebnis mit shift + O in den protected Bereich
schreiben - dann wird es beim nächsten Start wieder geladen.

Gruß Hayo

..und so lange verwendet wird, bis durch ein Aufruf der "Calibrate Zero
lines" alles wieder überschrieben wird?! ÄCHZ
Mit den möglichen 15 Kombinationen des manuellen Abgleich bekomme ich
den Abgleich des Kanal 1 übrigens nicht so gut hin, wie mit der autom.
Kalibrierung. Es scheint mir als ob die Anpassung mindestens eines ADC
nicht mit den 15 Kombinationen abgedeckt wird- d.h. der max Bereich der
Anpassung reicht für diesen ADC nicht aus.
Schade das die autom. Kalibrierung (auch bei mehrmaligen Versuchen)
nicht für beide Kanäle gleichzeitig zufriedenstellend arbeitet!

Aber die Darstellungen auf meinen obigen Fotos finde ich schon ok...
Wenn jetzt das Optimum des Ch1 mit dem Optimum des Ch2 kombiniert
wäre...
Auf jeden Fall kann ich jetzt gut weitermachen, danke!

Gruß, brunowe

Das sieht auf jeden Fall schon mal sehr "mögig" aus. :)

Bruno We wrote:
> ..und so lange verwendet wird, bis durch ein Aufruf der "Calibrate Zero
> lines" alles wieder überschrieben wird?! ÄCHZ

Nein, der protected Bereich wird definitiv nur mit shift + O
überschrieben. Dieser Bereich ist eigentlich nur für Factory Settings
vorgesehen - hier steht unter anderem auch die Seriennummer. Wenn ein
Zero-Abgleich durchgeführt wird, dann ist das nur temporär. Beim
nächsten Start werden wieder die Werte aus dem protected Bereich
geladen.

> Mit den möglichen 15 Kombinationen des manuellen Abgleich bekomme ich
> den Abgleich des Kanal 1 übrigens nicht so gut hin, wie mit der autom.
> Kalibrierung. Es scheint mir als ob die Anpassung mindestens eines ADC
> nicht mit den 15 Kombinationen abgedeckt wird- d.h. der max Bereich der
> Anpassung reicht für diesen ADC nicht aus.

Sorry, mir waren das einfach zu viele Kombinationen, da hab ich dann die
genommen, die bei meinen beiden Oszis am besten funktioniert haben.
Bei den Einserkombinationen hab ich noch alle sinnvollen genommen, bei
den 2ern hab ich dann nur eine Auswahl verwendet. 3er hab ich garnicht
berücksichtigt, obwohl diese natürlich auch nicht ausgeschlossen sind -
bei mir allerdings nicht auftreten (Bei mir 2110 und 1001).
Nenne mir doch mal die Werte die die automatische Kalibrierung ergibt,
dann kann ich die Kombination mit einbauen.

> Schade das die autom. Kalibrierung (auch bei mehrmaligen Versuchen)
> nicht für beide Kanäle gleichzeitig zufriedenstellend arbeitet!

Da ich diese in den Standardablauf mit eingebaut habe sind meine
Möglichkeiten hier erstmal beschränkt - alles Weitere ist in Arbeit...

> Aber die Darstellungen auf meinen obigen Fotos finde ich schon ok...
> Wenn jetzt das Optimum des Ch1 mit dem Optimum des Ch2 kombiniert
> wäre...
> Auf jeden Fall kann ich jetzt gut weitermachen, danke!

Es zeigt auf jeden Fall, dass man hier noch Einiges herausholen kann.

Gruß Hayo

Hallo,

ok, der protected Bereich wird mit "Zero Calibration Line" nicht
überschrieben- ist mir gestern nur so vorgekommen.
Meine optimale Kalibrierung für Ch1 ist 2340 (bzw. 3450 sieht auch recht
gut aus), für Ch2 0112. Ich hab die Einstellung für beide Kanäle jetzt
recht gut hinbekommen. Als nächstes will ich mal checken ob mein Kanal 2
auch auf ein Rauschen von ±1Digit zu bekommen ist. Das ist, glaub ich,
ein durchaus akzeptabler Wert.
Mein Kanal 1 sieht jetzt echt gut aus... nur schade das da noch keine
Analog-Stufen dranhängen!!!

Gruß, brunowe

Das heißt natürlich: "Calibrate Zero Lines"

@Guido

In hardware_t.cpp Zeile 3258 - das ist der Buttonhandler

(Suchbegriff Test Funktion 0 Q)


@Bruno

2340 ist aber echt heftig! Da kann ich mir gut vorstellen wie das Signal
unkalibriert aussieht...

Wenn Du in das oben genannte Coding gehst, kannst Du Dir eigene
Kombinationen dazubasteln. Ansonsten werde ich Deine mal mit aufnehmen
für die nächste Version.

Ich habe übrigens gerade festgestellt, dass es nicht 15 Kombinationen
sind, sondern 26 (ich war noch in Gedanken auf dem alten Stand) - die
27igste ist dann Autokalibrierung.

Gruß Hayo

Hallo,

es ist (zum Glück) nicht notwendig das ich im Code herum operiere. Ich
habe via auto calibration den optimalen Abgleich für Ch1 erstellt, dann
manuell den Abgleich für Ch2 durchgeführt und das Ganze mit Shift O
abgespeichert- scheint zu funktionieren. Eine sehr gute Basis fürs
weitere Vorgehen!

Gruß brunowe

Genau, am besten ist es immer in den "5er" Messbereichen, also 5V,
500mV, 50mV, am schlechtesten sieht es in den "1er" Messbereichen aus.
Ich bekomme es auch manuell nicht so hin wie Bruno.

Wie ist da eigtl die Vorgehensweise? Aus den Zeilen, die da im Terminal
erscheinen, einen Mittelwert je DAC bilden und dann den Ausgleich
errechnen? Ich hab jetzt nur der Reihe nach alle Kombinationenn
durchgedrückt und geschaut, wo es am hübschesten aussieht.

Irgendwie kommt es mir so vor, als wenn ich da irgendwas noch nicht
begriffen habe. :D

/Hannes

Hallo sunny,

na dann erstmal herzlich willkommen. Vielleicht hast du ja Lust etwas
mit an der HW rumzubasteln? Momentan bin ich anscheinend der Einzigste,
dessen Oszi schon seit Tagen auseinandergebaut am Arbeitsplatz liegt und
für Messungen an Herz und Leber herhalten muss?! Für Unterstützung und
evtl. für Vergleichsmessungen wäre ich durchaus dankbar!
Evtl. meldest dich ja mal via Skype bei mir? Skype- Name: brunowe1

Hallo egberto,

mir ist leider nicht ganz klar was du mit Abgleichanleitung meinst.
Wie ich meine ADC abgeglichen habe? Eigentlich ist das da nicht viel
dabei...
Ist doch alles in der Liesmich von Hayo's FW, (evtl. in meinen
Messprotokollen- wg. 250MHz Schwingung) und in diversen anderen,
öffentl. verfügbaren Dokumentationen nachzulesen.
Ich denk mir, wer sich ernsthaft mit der Materie auseinandersetzen will,
sollte sich vlt. erstmal die HW Beschreibung auf SF ansehen.
http://apps.sourceforge.net/trac/welecw2000a/
Wir haben uns viel Arbeit gemacht alle Info's über die W2000 Oszis in
unserem SF-Wiki abzulegen- nutzt sie.
Ich bin überzeugt, das dir dann sofort klar wird wie es zu den 250MHz
kommt.
Nur so nebenbei... auch mit der Niederschrift meiner Messergebnisse hab
ich versucht etwas Klarheit in die Funktion des Oszi's zu bringen.

Noch ne Anmerkung: der etwas kompliziertere Weg des ADC- Abgleich wie
ich ihn oben durchgeführt habe, ist eh nur notwendig wenn mind. ein ADC
soweit aus dem Bereich raus ist, das er mittels Hayo's manuellen
Abgleich nicht korrigiert werden kann.

Gruß brunowe

Bruno We wrote:
> Ist doch alles in der Liesmich von Hayo's FW, (evtl. in meinen
> Messprotokollen- wg. 250MHz Schwingung) und in diversen anderen,
> öffentl. verfügbaren Dokumentationen nachzulesen.

Hm, ich hab zu diesem Punkt nix gefunden. Liegt vllt auch daran, dass
ich nicht ein Werkzeug entwickeln, sondern nur Verbesserungen, welche
andere daran vornehmen, verwenden möchte (s.u.) und dementsprechend nur
das Liesmich gelesen und nicht irgendwo im Netz in vielen Dokumenten
dazu nachgeforscht habe.

> Wir haben uns viel Arbeit gemacht alle Info's über die W2000 Oszis in
> unserem SF-Wiki abzulegen- nutzt sie.

Versteh mich bitte nicht falsch: ich finde das absolut bemerkenswert,
was ihr hier macht, aber für mich ist das Gerät nicht Selbstzweck,
sondern Werkzeug. Ich helfe gern im Rahmen meiner beschränkten
Möglichkeiten, indem ich zum Beispiel nach einer vorgegebenen
Verfahrensanleitung eine OS-Firmware flashe, ein Paar Testpunkte
abarbeite und dann ein Ergebnis poste, aber mitentwickeln oder auch
nur mich in die Funktionsweise hineindenken möchte ich eigtl nicht.
Darum kann ich die Nachfrage von egberto uneingeschränkt nachvollziehen.

> Noch ne Anmerkung: der etwas kompliziertere Weg des ADC- Abgleich wie
> ich ihn oben durchgeführt habe, ist eh nur notwendig wenn mind. ein ADC
> soweit aus dem Bereich raus ist, das er mittels Hayo's manuellen
> Abgleich nicht korrigiert werden kann.

Ich hab gerade ein paar Fotos gemacht vom Zustand nach dem Einschalten
und vom Zustand nach dem mehrfachen Ausführen von "Calibrate Zero
Lines". Ich finde, das bringt nicht nur nix, sondern verschlechtert
das Rauschen (von den unverändert abweichenden Zerolines mal ganz
abgesehen). Also mache ich entweder etwas grundlegend verkehrt, oder
dort ist ein Wurm drin.

/Hannes

P.S: Fotos poste ich gleich, muss sie nur noch zusammenfügen.

So,

jeweils ein Bild vom Zustand direkt nach dem Einschalten (erstes und
drittes Bild) und vom Zustand nach dreimaligem "Calibrate Zero Lines"
(zweites und viertes Bild) bei unterschiedlicher zeitlicher Auflösung.

/Hannes

Hallo

@Guido, ja es sind die selben Wandler. So wie ich das momentan sehe,
werden die ADC nicht extern mit einer Referenzspg. versorgt, sondern
nehmen als Referenz einfach die Hälfte der angebotenen Versorgungsspg.
Wahrsch. kommt diese Abweichung dann einfach durch Bauteilunterschiede
zustande.

@Johannes: Inwieweit die "Calibrate Zero Lines" für die 4 Kanäler gut
arbeitet kann ich nicht beurteilen. Das muss Hayo beantworten. Wenn du
dein erstes Foto mit meinem Foto von oben vergleichst, dann liegt beim
Einschalten dein Rauschniveau in etwa so wie bei mir auf Ch2. Mein Ch1
ist das Optimum (vom analogen Standpunkt aus betrachtet- ohne
nachträgliche digitale Bearbeitung)- da will ich meinen Ch2 in etwa
hinbekommen. Noch mal für alle (die die obigen Post's nicht gelesen
haben) bei meinem Ch1 wurde die Verbindung zum analog- Part der
Schaltung abgelötet- das ±1 Digit an Fehler wird also vom ADC bzw. von
der anschl. digitalen Verarbeitung erzeugt (eher unwahrscheinlich).

Man muss auch nochmal erwähnen das Hayo's aktuelle FW etwas überstürzt
heraus gegeben wurde, um genau diesen Punkt des ADC- Abgleich wenigstens
schon einmal experimentell durchführen zu können. D.h.man muss halt noch
ggf. gewisse Einschränkungen in der Bedienung hinnehmen. Irgendwann wird
dieser manuelle Abgleich der einzelnen ADC bestimmt nicht mehr notwendig
sein- weil ich überzeugt bin Hayo bekommt den autom. Calibrate Zero Line
gut hin!


Gruß, brunowe

Ja, dass du den analogen Teil der Eingangsschaltung abgetrennt hast,
hatte ich zwar gelesen, aber gleich wieder "verdrängt". Sorry. ;-)

Wie kann man sich erklären, dass Nulllage und auch Rauschen in den 5er
und 2er Messbereichen jeweils deutlich besser sind als in den 1er
Messbereichen? Im 1V/div-Bereich habe ich auf Channel 4 aller paar
Sekunden Rauschen im Bereich einer Div-Teilung, m.a.W. 1Vpp, und wenn
ich auf 500mV runterschalte, wird es verglichen damit recht glatt (genau
wie in der anderen Richtung, also bei 2V/div und 5V/div).

Die Nulllage ist bei 5er und 2er MB fast korrekt, bei 1er MB dagegen
ziemlich daneben, und ich kann sie auch mit ShiftW/E nicht verschieben.

/Hannes

Hallo Bruno,
wie hast du eigentlich Slog's Design ins Oszi gekriegt?
Habe ich das so richtig Verstanden?

USB Blaster installieren
Quartus Programmer installieren
Hello_W2000_v0_1_4.sof ins Oszi Programmieren
Jetzt sieht es so aus wie
http://www.mikrocontroller.net/attachment/49782/Ch...
Nach Neustart des Gerätes ist der Zauber wieder vorbei
USB Blaster deinstallieren, damit sich das Oszi wieder als HID meldet
Backup des 24C64 ist nicht nötig

Mfg,
Kurt

branadic wrote:
> wie ich sehe hast du dich noch nicht wirklich mit der Materie und auch
> noch nicht mit deinem Gerät beschäftigt.

Du wirst lachen, nein. Ich mach das hier nur nebenher mit, während ich
ein Layout zu Papier bringe. :)

> Dir wäre dann nämlich aufgefallen, dass das Gerät nur über drei
> Messbereiche verfügt. Man hört wie beim Umstellen des Messbereiches ein
> Relais schaltet.

Doch, das ist mir aufgefallen. Ich hab nur nicht tiefschürfend darüber
nachgedacht, an welcher Stelle da etwas umschaltet.

> Dir hätte auch auffallen können, dass Wittig/Welec die optimale
> Darstellung der Signale in ihrer Produktbeschreibung bei 5V/500mV/50mV
> angibt.

Ist wirklich an mir vorbeigegangen, stimmt.

> Die Summe der so gesammelten Informationen führt dann zu der
> unglaublichen Erkenntnis, dass die 2V/1V Darstellung nur eine
> Vergrößerung der 5V-Messung sind

Das dachte ich mir schon, aber 1V/div sieht eben nicht aus wie eine
Vergrößerung der 2V/div-Darstellung, weil sich auch die Nullage gewaltig
verschiebt und das Rauschen nicht nur doppelt so groß, sondern
unverhältnismässig größer wird. Daher frug ich. :)

> 200mV/100mV der 500mV-Messung und wer hätte das gedacht, die 20mV/10mV
> die der 50mV-Messung. ;)

Das wiederum wird dann selbst mir klar.

Bin zwar kein Elektroniker, aber auch kein Depp. :D

/Hannes

Danke branadic!

Slog's Design verbessert wohl hauptsächlich die Geschwindigkeit weil es
Hardwaremultiplikationen ermöglicht und auch die Abfrage der
Bedienelemente in Harware realisiert. Dadurch wird die CPU stark
entlastet.

http://www.kurts-werkstatt.de/wittig/slog.avi (3,21MB)

Das Video ist in Echtzeit! Man beachte die flüssige Verstellung von
Zeitbasis, Vertikalauflösung und Signallage. Viel mehr kann man
allerdings noch nicht machen, da sich Slog auf das FPGA Design
konzentriert und die Software entsprechend mager ausgerüstet ist
(Messungen sind nicht möglich).

Hier noch ein Foto.

Wieso habe ich nicht die bunten Sample Punkte der ADCs?

Probiert hatte ich
Slog_Project_with_Nios_v0.1.3.zip und
Hello_W2000_v0_1_4.zip

Hallo,

oje, ich weiß gar nicht wo ich mit den Richtigstellungen und Erklärungen
anfangen soll...

Vielleicht vorab noch ein Hinweis: Leute die sich nicht in die
Funktionsweise des Oszi's hineindenken wollen- s.h. Zitat weiter oben-
sollten am besten nicht weiterlesen! ;-)

Also erstmal, nehmt euch doch mal meinen Schaltplan des Oszi's zur Hand:
http://welecw2000a.sourceforge.net/docs/schematics...
Das Umschalten zwischen den Bereichen 5V-2V-1V etc. ist kein SW Trick.
Links oben im Schaltplan seht ihr die beiden Relais die dieses
Umschalten erledigen- das Klack ist ja auch deutlich zu hören. Je
nachdem in welchem Messbereich ihr euch befindet wird das Eingangssignal
unterschiedl. stark gedämpft. Wenn ihr euch in 5V; 2V; oder auch 1V
befindet wird das Eingangssignal durch das Widerstandsnetzwerk von
Relais 1 bedämpft(geteilt) und zusätzlich durch das Netzwerk unter
Relais 2.
Befindet ihr euch in einem der Messbereiche 500mV, 200mV, 100mV, so ist
nur das Relais 2 in off- Position und teilt das verkleinert das
Eingangssignal ca. um den Faktor 10 (genaueres dazu steht recht
ausführlich in meinem Messprotokoll Nr.1)
Das bedeutet also, das jegliche folgende Signalverarbeitung auf die 3
Fälle 10mV, 20mV und 50mV Messbereich zurückzuführen ist. Die Teilung am
Anfang ist relativ problemlos und muss nicht weiter beachtet werden.

So, wie geschieht nun die Umschaltung zwischen 50mV, 20mV und 10mV? Auch
das ist kein SW- sondern ein Schaltungstrick. Ihr habt den Schaltplan
noch zur Hand? Unten in der Mitte befinden sich 3 Op's (AD8131) und
zwischen dem 1ten und 2ten, bzw. dem 2ten und 3ten unterhalb jeweils
elektronische Schalter (U7AD) (deshalb kein Klack!). Nur wenn der
Schalter geschlossen ist wird der nachfolgende AD mit einem
differentiellen Eingangssignal
versorgt und das Signal um den Faktor 2 verstärkt, ist der Schalter
offen liegt nur am positiven Input des AD das Eingangssignal an- seine
Verstärkung beträgt in diesem Fall 1.
Soweit findet in diesem Bereich also (abhängig vom Messbereich) ein 1:1;
1:2 oder 1:4 Verstärkung statt- ob jetzt durch einen weiteren Kniff das
wieder zu 1:2:5 hingebügelt wird wollte ich noch prüfen, glaub es aber
eigentl. nicht.

Zur Vollansteuerung der ADC ist an beiden (diff) Eingängen ein Signal
von ±0,3125V nötig- d.h. das Signal am positiven Ausgang des letzten AD
kann/ soll sich um ±0,3125V um den Mittelwert von +1,4V ändern, am
negativen Ausgang des AD ebenso, nur eben um π Phasenverschoben. Auch da
wollte ich nochmal checken inwieweit das passt.

Zu Slog's VHDL Design:
Prinzipiell muss man sagen das es mehrere funktionierende VHDL Designs
gibt, nicht nur die von dir oben erwähnten. Die VHDL Arbeit basiert
allerdings immer auf der großartigen Vorarbeit von Slog- er hat sich nun
mal als erstes mit Oszi intensiv auseinandergesetzt und es als VHDL-
Entwicklungsboard missbraucht.
D.h. den einzelnen VHDL Designs liegen ganz unterschiedl. Zielsetzungen
zu Grunde. Während der Eine über spezielle Aspekte der internen
Datenverarbeitung seine Masterarbeit schreibt- will der Andere "nur"
sein VHDL verbessern... aber das Gute daran ist, das man all diese
Arbeiten durchaus zusammenführen kann.
Alle VHDL Designs sind bislang nur temporär ausgelegt , d.h. nach dem
Ausschalten des Oszi's ist alles wieder weg (nicht weiter tragisch, das
aufspielen dauert ca. 10s!)- es werden keine Daten intern überschrieben
und man kann nichts kaputt machen. Das liegt einfach daran weil derzeit
von jedem Design nur spezielle Aspekte getestet/ entwickelt werden.
Und ja- man kann mit Slog die einzelnen ADC Werte farbig darstellen
lassen, so wie in meinem Foto im Messprotokoll 2. spiele dich einfach
mal mit den Tasten- wie gesagt du kannst dabei nichts kaputt machen-
maximal haben sie keine Auswirkung da sie halt via VHDL-Code nicht
verarbeitet werden. Das aktuelle Slog Design hat übrigens genau die ADC
Kalibrierung und vor allem das Timing der einzelnen ADC zum Thema-
deshalb diese schöne farbige Darstellmöglichkeit. Die Zeitbasis lässt
sich nicht verändern, ist glaub ich fix auf 50ns/Div eingestellt. (damit
müsste jeder gemessene ADC-Wert einem Pixel auf der zeitl. Achse des
Displays entsprechen.

so, jetzt ist aber erstmal genug-
Gruß, brunowe

Bruno We wrote:
> Vielleicht vorab noch ein Hinweis: Leute die sich nicht in die
> Funktionsweise des Oszi's hineindenken wollen- s.h. Zitat weiter oben-
> sollten am besten nicht weiterlesen! ;-)

Ich les trotzdem weiter. Nicht hauen bitte. :D

> Das Umschalten zwischen den Bereichen 5V-2V-1V etc. ist kein SW Trick.
> [...]
> Anfang ist relativ problemlos und muss nicht weiter beachtet werden.

Klar.

> So, wie geschieht nun die Umschaltung zwischen 50mV, 20mV und 10mV? Auch
> [...]
> Soweit findet in diesem Bereich also (abhängig vom Messbereich) ein 1:1;
> 1:2 oder 1:4 Verstärkung statt-

Also wird das Rauschen hauptsächlich von diesen OPV und vllt noch den
elektronischen Schaltern bestimmt?

> ob jetzt durch einen weiteren Kniff das wieder zu 1:2:5 hingebügelt wird
> wollte ich noch prüfen, glaub es aber eigentl. nicht.

D.h. dort wird dann das 1:4-Rauschen in Software auf 1:5 erhöht,
deswegen sieht das auch unverhältnismässig größer aus als bei 1:2?


Es ist übrigens schön, wenn einem das mal ein Berufener so erklärt, dann
versteht man auch gleich was (oder man beginnt wenigstens damit). In die
Schaltung allein habe ich geguckt wie die sprichwörtliche Sau ins
Uhrwerk.

Jetzt muss ich nur noch irgendwie die Trennlinie bzw. das Zusammenspiel
von dem, was Hayo macht mit dem, was Slog da bearbeitet, begreifen.

/Hannes

Hallo Guido,

das mit dem Verstärkung des OPA656 war mir noch nicht ganz klar- (das
mit der Frequenzgangkompensation schon). Wie kommst du auf 1:1,25?
Klär uns doch mal über die Fkt. des OPA656 auf...

Alter Schwede hier ist ja was los...

Ich dachte ich hätte in diversen älteren Beiträgen schon mal auf den
Grund des unterschiedlichen Rauschens hingewiesen. Allerdings gebe ich
zu, dass es auch etwas nervig ist alle alten Beiträge durchzuforsten.
Daher möchte ich hier ergänzend zu Brunos Ausführungen mit wenigen
Worten die Problematik erklären:

- die einzelnen Stufen haben durchaus jede Ihre eigene
Spannungsvorteilung (wie Bruno ja auch schon anmerkte - kein Fake also)
- die Übersetzung ist jedoch so (unglücklich) gewählt, dass in den
unterschiedlichen Stufen bei der Grafikausgabe unterschiedliche
Skalierungsfaktoren nötig sind.
- bei den 5er Bereichen ist der Skalierungsfaktor ca. 2, bei den 2er und
1er Bereichen ist er ca. 3,3

D.h. wenn die Offsetabweichung eines ADC 3 ist (z.B. 3012 oder 0321),
dann stellt sich das in den 5er Bereichen mit eine Peak von 6 Pixeln
dar, wärend sich das in den anderen Bereichen mit einem Peak von 10
Pixeln darstellt.

Das ist schon ein deutlicher Unterschied.

Gruß Hayo

Guido wrote:
> Hallo Hayo,
>
> wo findet denn die Skalierung der ADC-Werte statt? Ich finde es
> nicht. Heute abend möchte ich mal mit den Verstärkungen spielen,
> da müsste ich die Skalierung für die 1er und 2er Bereiche
> ändern.
>
> Danke, Guido

In der Datei tc_vars.cpp Zeile 1437 (float scale_factor[16])

Gruß Hayo

@Guido

ja das hatte ich ohnehin vor, aber da Bruno gerne schnell testen wollte
hab ich die Version etwas unfertig rausgehauen...

Wie ich sehe hast Du auch schon schön nach einzelnen Spannungsstufen
getrennt, kann ich dann ja so 1:1 übernehmen - spart Zeit ;-)

Danke und Gruß Hayo

Hallo,

habe mal eine Frage zur PC Software. Wie kann ich die gespeicherten
Messwerte bzw. Kurven mit der PC Software übertragen. Ich kann nur die
aktuelle Kurve in den PC laden.
Werde dann auch mal die FW1.2.BF.0.50 nach Flashsicherung aufspielen.
Aber das kann ja bekanntlich dauern...
Gruß
Ronny

Die Version FW1.2.BF.0.50 läuft auf meinem W2024A sehr gut. Habe dann
mal die FW1.2.BF.0.54 aufgespielt und das Nullinien-Rauschen war nach
einem "Calibrate Zero Lines" erheblich stärker auf Kanal 1-3, Kanal 4
war besser. Werde jetzt erstmal die vorige Version aufspielen und das
nochmal versuchen. Mauellen Abgleich der ADCs habe ich nicht
vorgenommen.
Gruß
Ronny

Nach Aufspielen der FW1.2.BF.0.50 und "calibrate zero line" ist das
Nullinien-Rauschen bedeutend geringer als mit FW1.2.BF.0.54, Kanal 3 ist
am Besten.

Eine Datenübertragung zum PC geht auch nicht mehr, habe jetzt erstmal
das Original wieder aufgespielt. Schade...

Guido schrieb:
> Lust zum Testen hat ist eine Rückmeldung erwünscht. Ich habe nach
> ca. 30 Flashvorgängen kein Gefühl mehr dafür wie es vorher war.

30? Dauert das nur bei mir so lange, oder hast du jetzt echt ca. 40
Stunden dem Flashen zugeschaut?

/Hannes

Direkt über eine serielle Schnittstelle geht es recht fix, nur mit einem
USB-RS232 Adapter dauerte es bei mir ewig (ca. 10h).

Guido schrieb:
> @ Johannes: Nö, ne knappe halbe Stunde brauche ich noch zum
> Flashen, habe als Linuxer aber extra (naja, nicht ganz ernst
> nehmen) ein Laptop mit XP gekauft.

Hm, ich hab bisher mit dem fwupload.pl rumprobiert (bekomme ich nicht
ans Rennen) und dann in einer Virtualbox mit USB->RS232-Adapter. Das
funktioniert, dauert aber ca. 1,5h.

Auch auf die Gefahr hin, dass ich wieder darauf hingewiesen werde, dass
das alles schon mal schön übersichtlich irgendwo beschrieben steht: wie
muss das Oszilloskop auf das Schreiben der Zeilen der Firmwaredatei
antworten? Bei mir sagt das irgendwie keinen Mucks, deswegen bleibt
offenbar auch das fwupload.pl stehen und wartet bis zum
St.-Nimmerleins-Tag.

/Hannes

Johannes Studt schrieb:
> muss das Oszilloskop auf das Schreiben der Zeilen der Firmwaredatei
> antworten? Bei mir sagt das irgendwie keinen Mucks, deswegen bleibt
> offenbar auch das fwupload.pl stehen und wartet bis zum
> St.-Nimmerleins-Tag.

Kaum sucht man nochmal, findet man plötzlich was: ein + sollte da
auftauchen, das ist wohl der Prompt des GERMS-Monitors. Eben schreibe
ich deine Flash-Datei mit Minicom ins Oszi, mal sehen, wie lange das
dauert.

/Hannes

Na juchhu aber auch. Eben hab ich bemerkt, dass der Welec-Updater von
Markus ja auch für Linux verfügbar ist. Nachdem ich jetzt bissi mit
Lazarus und Freepascal rumgezappelt habe, läuft das Ding hier
einwandfrei.

Das Leben ist schön. :D

/Hannes

P.S: ich liebe Monologe.

Johannes Studt schrieb:
> Guido schrieb:
>> Lust zum Testen hat ist eine Rückmeldung erwünscht. Ich habe nach
>> ca. 30 Flashvorgängen kein Gefühl mehr dafür wie es vorher war.
>
> 30? Dauert das nur bei mir so lange, oder hast du jetzt echt ca. 40
> Stunden dem Flashen zugeschaut?

Hab jetzt über 100 Flashvorgänge hinter mir. Dauert ca. 21 Minuten pro
Durchlauf - allerdings mit echtem RS232 (auch an langsamen Rechnern).
Ich hatte unter Linux einen Kommandozeilenuploader entwickelt, der hat
es in 2 bis 3 Minuten geschafft, allerdings nicht zuverlässig genug. Da
hab ich dann irgendwann aufgehört und den WELEC-Updater genutzt, der ist
wenigstens zuverlässig.

Gruß Hayo

Johannes Studt schrieb:
> Na juchhu aber auch. Eben hab ich bemerkt, dass der Welec-Updater von
> Markus ja auch für Linux verfügbar ist. Nachdem ich jetzt bissi mit
> Lazarus und Freepascal rumgezappelt habe, läuft das Ding hier
> einwandfrei.
>
> Das Leben ist schön. :D
>
> /Hannes
>
> P.S: ich liebe Monologe.

Ich mach das jetzt mal zum Dialog:

Die Linux-Version läuft bei mir mindestens zehnmal länger als die
Windowsversion. Wie ist das bei Dir?

Gruß Hayo

Da hab ich keinen echten Vergleich, weil ich die Windowsversion
ebenfalls unter Linux in einer XP-VM (und das zu allem Überfluss auch
noch mit dem USB->RS232-Adapter) laufen hatte. In dieser Konstellation
haben sie beide ca. gleich lange gebraucht.

Ich hatte bisher angenommen, dass das DSO der Part ist, der bremst, weil
ja der Welecuploader nix anderes macht, als auf das '+' zu warten und
dann sofort die nexte Zeile abzuwerfen.

Jetzt werd ich mal das Notebook meiner Frau zünden und mit der dort noch
anwesenden echten RS232-Schnittstelle Vergleiche anstellen.

/Hannes

Ja, das kannste vergessen. Am Notebook meiner Frau benimmt sich das DSO
bockig. Nach ca. 15% bricht die Datenübertragung ab und der Welecupdater
wartet, bis die Elbe austrocknet. Bis kurz vor den Hänger meint er, er
würde ca. 52 Minuten brauchen wollen (Windowsversion).

Ich werd's jetzt nochmal mit einer Linux-LiveCd versuchen.

So, das hat jetzt 1:50 gedauert, also deutlich langsamer als unter
Windows, dafür isses aber durchgelaufen.

Ja, ich habe ähnliche Erfahrungen gemacht. Ich habe unter Windows keinen
kompletten Download zustande gebracht(auf zwei verschiedenen Laptops
getestet). Unter Linux hat es dann geklappt, wenn auch etwas langsamer.
Der Upload klappte problemlos auch unter Windows.

Uwe

@Guido

Ich bin gerade dabei die Erkenntnisse der letzten Tage in die aktuelle
Version einfließen zu lassen. Deine Erweiterung der Testfunktion 1 + 2
hab ich unverändert übernommen. Die Änderung der Flashroutine hab ich
nicht übernommen, da die Zero-offsetwerte schon im normalen
Configbereich des Flash gespeichert werden. Eine weitere Speicherung im
Protected-Bereich ist also nicht nötig.

Insbesondere implementiere ich gerade die neue Integerscalierung - der
Upload läuft noch - ich bin gespannt was rauskommt.

Ansonsten beisse ich mir zur Zeit die Zähne daran aus diesen blöden
Freeze-Fehler zu finden der das Signal bei Zeitbasen größer 5ms
einfrieren läßt. Immerhin hab ich das Problem schon soweit eingekreist,
dass ich weiß, das ich mir den Bug zwischen version 0.32 und 0.33
eingebaut habe. Es kommt einfach vom ADC kein Data-Available-Signal mehr
an. Die berühmte Nadel im Heuhaufen...

Ich halte Euch über die Fortschritte auf dem Laufenden.


Gruß Hayo

Upload ist fertig,

erstes Ergebnis: Super! Genauigkeit ist genau wie bei der Floating-Point
Skalierung, aber die Geschwindigkeit ist im Einkanalbetrieb so schnell,
dass ich die Anzahl der Bildwiederholungen nicht mitzählen kann für
einen Vergleich.

Gefühlt würde ich sagen 2 - 3 Mal schneller.

Gruß Hayo

Guido schrieb:

> Mit dem Freeze: ich habe den Eindruck, dass eine Variable überläuft.
> Wenn man ein paar mal rauf- und runterschaltet, werden immerhin
> noch Teile des Bildschirms aktualisiert (in manchen Zeitbereichen).

Das liegt daran, das bei Änderung der Zeitbasis der ADC-Durchlauf neu
gestartet wird, dadurch wird dann zumindist ein Signaldurchlauf gelesen
- das wars dann aber auch.

> Ich hänge noch mal die Erläuterung zu den Drehgebern an, ist zwar
> suboptimal aber damit bekomme ich die Pfeile synchron zur
> Drehung auf dem LCD aktualisiert. Ev. wäre das ja noch was für
> die nächste Version.

Hast Du gesehen, dass ich einen ähnlichen etwas einfacheren Ansatz auch
schon implementiert habe? Bei irgendeiner User-Interface-Eingabe werden
alle weiteren Berechnungen und Ausgaben abgebrochen und erstmal der
Drehgeber ausgewertet. Dann erst wird weiter auf dem Schirm ausgegeben.
Das hab ich einfach mit einem Flag realisiert (UI_request), das in den
entsprechenden Interrupt-Serviceroutinen gesetzt und am Ende des
Hauptschleifendurchlaufs wieder gelöscht wird.

Gruß hayo

Nach meinen Vorankündigungen hier die aktuelle Beta. Neu ist die rein
integerbasierte Grafik, die entsprechend schnell geworden ist. Angepasst
ist die normale Siganlausgabe, der delayed Modus und die XY-Darstellung.

Die erweiterte Testfunktion 1 + 2 für den manuellen Nullabgleich von
Guido ist auch schon drin (ungetestet).

Morgen (bzw. heute) werde ich mich mal weiter dran machen und den blöden
Freeze-Bug suchen, damit ich mal endlich dazu komme die FFT weiter zu
machen.

guats Nächtle

Hayo

Hallo Hayo,
die Geschwindigkeit ist schonmal super. Vor allem im XY-Modus!

Wenn ich da jedoch die Vektordarstellung abschalte, verschwindet der
Nullpunkt.

Kurt Bohnen schrieb:

> Wenn ich da jedoch die Vektordarstellung abschalte, verschwindet der
> Nullpunkt.

Danke für die schnelle Rückmeldung. Fehler ist schon lokalisiert, da ist
mir doch wieder so ein typischer copy and paste Fehler durchgegangen.

Ist in der nächsten Version beseitigt.

Gruß Hayo

Hallo,

ich bin seit einiger Zeit Besitzer eines W2014a und verfolge die
Entwicklung hier aufmerksam.

Ich habe gerade die Beta V0.55 ausprobiert. Der Unterschied in der
Darstellungsgeschwindigkeit ist echt beeindruckend.

Bezüglich des Flashens will ich mal meine Erfahrungen darstellen. Das
Flashen dauert bei mir ca. 15-20 min auf einem System mit Win XP und
einem USB-RS232-Adapter der Firma systec-electronic. Mit der "normalen"
RS232-Schnittstelle habe ich keine Verbindung mit dem Oszi bekommen.


Viele Grüße

Kristian

Hallo,

Kristian da kannst du dich glücklich schätzen- ich bin froh wenn ich's
so in 4-5 Std. hin bekomme- ist jedes mal ne Nacht füllende Aktion.
(Mit Delock Adapter USB to seriell)

Noch ein paar Fragen an die Programm-Kundigen:
Ich spiel mich gerade mit dem DAC Abgleich.
1.) Was bedeuten den die Zeilen:
CH1 Zero Sign Offs 1   = 2<\n>
CH1 Zero Sign Offs 2   = 0<\n>
CH1 Zero Sign Offs 3   = -1<\n>
(sind das die abgelegten DAC Werte für die Messbereiche 1:2:5 ?)
Irgendwie kann ich bei Shift +W bzw. auch bei Shift +E keine Änderung am
Welec Display erkennen (wohl aber an der Terminal Ausgabe)- schade- ich
hab da einen echt groben Offset.

Schön wäre es, die "Zero Level Werte" direkt eingeben zu können - für
jeden der Messbereiche 1:2:5er extra.

Sobald ich Cal. Zero lines durchführe, ist der offset zwar korrigiert,
aber leider auch meine Optimierung der ADC's futsch.

2.) Was hat den der Enable Debug mode für einen praktischen Nutzen?

3.)Was bedeuten den die Zeilen beim Start des Oszi, die auf dem
seriellen Terminal ausgegeben werden, speziell folgende:
...
Volt_Correct_float   = 1.625<\n>
Scale Factor         = 3.250<\n>
CH1_DAC_Offset       = 8194<\n>
multi_active         = 1<\n>

Auf dem Hardware Sektor gibts auch Neuigkeiten- werde ich später im HW
Thread posten.

Gruß, brunowe

He Folks,

erst mal abwarten. Ich hab mich in den letzten Tagen ordentlich
reingekniet um die Jungs an der Hardwarefront zu supporten. Nachdem ich
den ADC-Abgleich etwas nachlässig implementiert hatte, hab ich jetzt
Nägel mit Köpfen gemacht und einen Abgleich gemacht der für alle vier
Kanäle zuverlässig arbeitet. Weiterhin bin ich noch am DAC-Abgleich
zugange. Die Graphikausgabe hab ich nochmal optimiert, so dass die
Skalierung jetzt ganz ohne Multiplikation auskommt (merkt man im delayed
Modus).

Als Schmankerl hab ich die bisherigen Testschalter ins Utility-Menü
gelegt, so dass man sie bequem betätigen kann auch ohne Terminal
(ADC-Abgleich, DAC-Abgleich, Gridumschaltung, Graphikmodusumschaltung).
Die neue Version gibt heute Abend - mal sehen wie weit ich noch komme.


Gruß Hayo

@Hayo- das hört sich ja Spitze an!

@Guido: ich glaube du verwechselst da ADC Abgleich mit dem DAC Offset-
Abgleich!

Wie gesagt, den ADC Abgleich der einzelnen ADC pro Kanal hab ich jetzt
soweit im Griff, nur der generelle Offset stimmt eben nicht.
CH1 Zero Sign Offs 1   = 2<\n>
CH1 Zero Sign Offs 2   = 0<\n>
CH1 Zero Sign Offs 3   = -1<\n>
Diese 3 Werte können nicht die ADC Kalibrierungswerte der 4! ADC 's
sein, schon eher die DAC Offset Werte wie ichs vermute.

Gruß, brunowe

Bruno We schrieb:

> Wie gesagt, den ADC Abgleich der einzelnen ADC pro Kanal hab ich jetzt
> soweit im Griff, nur der generelle Offset stimmt eben nicht.
> CH1 Zero Sign Offs 1   = 2<\n>
> CH1 Zero Sign Offs 2   = 0<\n>
> CH1 Zero Sign Offs 3   = -1<\n>
> Diese 3 Werte können nicht die ADC Kalibrierungswerte der 4! ADC 's
> sein, schon eher die DAC Offset Werte wie ichs vermute.

Diese Werte sind die Offsetkorrekturwerte für die DACs, die den
Nullpunkt der Eingangs-OPVs steuern. Pro Kanal gibt es drei Werte, und
zwar immer für alle 5er Bereiche (Nr. 3) für aller 2er (Nr 2) und die
1er (Nr. 1).

Der DAC wird von 0 bis 16384 ausgesteuert, die Mitte des Grids liegt bei
8192 (idealerweise). Der Offset korrigiert mit einem entsprechenden
Faktor diese Nulllage.

Bin mit dem DAC-Abgleich schon recht weit, teste nur noch kleinere
Änderungen.

Die 0.56 gibts dann nachher...

Gruß Hayo

@Hayo...
so macht das Sinn, Danke.

So hier ist sie, bin mit dem DAC-Abgleich nicht ganz fertiggeworden.
Aber seht selbst - geht nach dem flashen einfach mal ins Utility Menü
und probiert es aus. Wenn Ihr die ADC-Werte sehen wollt die der
Abgleichermittelt, dann müßt Ihr ein Terminalprogramm laufen lassen, da
werden dann die ermittelten Werte ausgegeben.

Ansonsten wie gesagt habe ich die Grafikroutine nochmal beschleunigt -
sieht man im Normalbetrieb nicht so deutlich, aber im Delayed-Mode wo ja
doppelt so viele Signale geschrieben werden merkt man es schon.

Viel Spaß

Hayo

Bin immer noch am DAC-Abgleich. Leider ist das ziemlich Zeitaufwändig,
da man nach jeder Kleinigkeit die man testweise ändert warten muß bis
die Firmware wieder geladen ist bevor man weitermachen kann. Bin aber
schon recht weit.

Übrigens geht der DAC-Abgleich schon so ein bißchen wenn man vorher die
Nulllage des entsprechenden Kanals auf die Mitte des Grids stellt.

Hat es schon jemand ausprobiert?

Gruß Hayo

Guido schrieb:
> Hallo Hayo,
>
> ich habe letzte Nacht noch schnell probiert, aber ohne Erfolg.
> Ich hatte übersehen, dass die Linien in Schirmmitte sein
> müssen und so hat jeder Tastendruck den Offset um 1 div nach
> unten verschoben. Geht das momentan nur für Kanal 1 oder wie
> kann man umschalten?

Nein, geht für alle Kanäle gleichzeitig.

> Aufgefallen ist mit, dass dieser Abgleich
> jetzt eh nur noch für die 1er Bereiche nötig sind die 2er
> stimmen nach AutoZero im 5er Bereich auch. Zufall?

Nein, hab an der ursprünglichen Zero-Routine auch ein paar Kleinigkeiten
geändert.

Die Search Zero und die Calibrate DAC Funktion haben zwar das gleiche
Ziel, arbeiten aber völlig unterschiedlich. Ich bin mir noch nicht ganz
sicher, ob Calibrate DAC die alte Funktion komplett ersetzen wird oder
nur für's Feintuning als Zusatzfunktion bleibt. Mal sehen.

Gruß Hayo

Hallo Hayo,

Neue FW- Spitzenarbeit!!!
Super, mit dem erweiterten Menü- so stell ich mir das vor!
Jetzt noch den DAC Offset hinbügeln und dann "Beta" aus der Bezeichnung
streichen.

Also auch mein Rauschen ist, bedingt durch den tollen ADC- Abgleich,
wesentl. besser. (Seltsamerweise Kanal 1 jetzt viel besser als Ch2-
liegt auch tw. an meiner kleinen HW Modifizierung- lass mich bitte in
dem Glauben!)

Soweit ich's bisher testen konnte, echt erstklassige Arbeit von dir!

Gruß, brunowe

Hm,

bei mir wird das Rauschen immer nur schlimmer. Sobald ich die "Search
Zero Lines"-Funktion verwende, bekomme ich Rauschen im Bereich von einem
halben bis zu einem ganzen Div, je nach Messbereich und
Erwärmungszustand. Schlimm sind v.a. die Kanäle 3 und 4.

"Calibrate ADC" verändert an der Intensität des Rauschens im Grunde nix,
es verändert nur ein wenig die Form.

"Calibrate DAC" lässt die Nulllage je nach Messbereich mit jedem
Tastendruck um bis zu ein Div nach unten wandern, auch wenn ich vorher
die Nulllage aller Kanäle auf die Mitte drehe. "Search Zero Lines" fängt
das wieder ein, allerdings habe ich trotzdem auf den Kanälen 3 und 4
immer ein negatives Offset.

Mit dem Offset könnt ich leben, aber das Rauschen macht das Gerät in
meinen Augen ziemlich unbenutzbar.

Hallo,

frei nach dem Motto: "ein Bild sagt mehr als tausend Worte"
Meine aktuellen Rauschpegel mit der neuen FW nach ADC Calibration.
Probe- Klemme auf Gnd.

Hallo,

vielen Dank für die neue Firmware.

Bei meinem 2014A liegen die Kanäle 3 und 4 auch immer im negativen
Bereich (Kanal 3 ca. 500mV, Kanal 4 ca. 1V).

"Calibrate DAC" führt bei mir auch zu einer Verschiebung der Signale in
den negativen Bereich. Dies scheint aber stark vom jeweilig
eingestellten Spannungsbereich abzuhängen.

Das Rauschen erscheint bei mir (zumindest für Kanal 1 und 2) deutlich
verringert.

Bei mir fehlt die blau 3 neben der Anzeige der V/Div für Kanal 3. Die
Beschriftungen der anderen Kanäle sind vorhanden.

Gruß

Kristian

Ich krieg hier noch die Krise...

Muß erstmal etwas Frust ablassen, Hrmpf. Da tut die positive Rückmeldung
von Euch ganz gut. Bin immer noch an dem besch... DAC-Abgleich. Um die
Situatuion kurz zu schildern:

Vor dem Abgleich wird per Coding alles auf die Nulllinie (Gridmitte)
gefahren, dann der Abgleich durchgeführt. Trotzdem bleibt ein
Restoffset. Wenn ich die Nulllinien manuell auf die Gridmitte einstelle
klappt alles ordentlich. Ich hab alles dazwischen gecheckt und auch
schon eine Verzögerung eingebaut weil ich mir dachte dass die DACs
eventuell nicht schnell genug regeln - hilft nix.

Morgen hab ich leider nicht viel Zeit dafür, daher hier erstmal die
inoffizielle beta 0.57 nur als Flash zum ausprobieren.

Wie gesagt, wenn die Nulllinien auf Gridmitte sind reichen 2 - 3mal
Drücken und die die Lage stimmt. Bitte zu beachten:

- es wird zur Zeit nur der aktuell eingestellte Bereich
 (1er, 2er oder 5er) calibriert.
- das Ergebnis wird zur Zeit noch nicht ins Flash geschrieben.

Gruß Hayo

Kristian Trenkel schrieb:

> Bei mir fehlt die blau 3 neben der Anzeige der V/Div für Kanal 3. Die
> Beschriftungen der anderen Kanäle sind vorhanden.

Ja das passiert bei mir aber auch mit der aktuellen 1.4 FW von Welec. Da
das allerdings erstmal von der Prio her weit hinten rangiert werde ich
das noch nicht in Angriff nehmen (es sei denn ich stolpere zufällig
darüber.

Zur Zeit gibt es folgende Prio:

1. DAC-Abgleich
2. Den Freeze-Bug finden den ich mir in Version 0.33 eingebaut habe
   (Signal friert ein bei Zeitbasen > 5ms)
3. FFT einbauen -> damit hat eigentlich vor einem halben Jahr alles
angefangen, aber bei all den Ungereimtheiten bin ich immer noch nicht
dazu gekommen...

Gruß Hayo

Bruno We schrieb:
> frei nach dem Motto: "ein Bild sagt mehr als tausend Worte"

So denn, das ist Kanal 4.

/Hannes

Johannes Studt schrieb:

> So denn, das ist Kanal 4.

Tja, da muß ich leider sagen, es ist nicht der ADC-Abgleich der hier
nicht hinhaut sondern hier dürften Störungen oder Eigenresonanzen
verantwortlich sein. Mein Kanal 4 sieht zeitweise noch viel schlimmer
aus. Die Bilder kennt Ihr ja schon. Da hilftnatürlich auch kein
ADC-Abgleich. Hinzu kommt, dass der ADC-Abgleich natürlich auch dadurch
gestört wird. Wie sieht denn Dein Kanal 3 aus? Der ist bei mir nämlich
glatt wie ein Babypopo.

Gruß Hayo

Bittesärrrrr. ;)

/Hannes

Darum habe ich auch jetzt meinen W2024 innerhalb des 14Tage
Rückgaberecht wieder zurückgeschickt. Bei mir war das Gleiche, das
Rauschen nahm nur zu. Hoffe für Euch, das Ihr das in den Griff bekommt.
Ich bin raus...

Ronny Schmiedel schrieb:
> Darum habe ich auch jetzt meinen W2024 innerhalb des 14Tage
> Rückgaberecht wieder zurückgeschickt. Bei mir war das Gleiche, das
> Rauschen nahm nur zu. Hoffe für Euch, das Ihr das in den Griff bekommt.
> Ich bin raus...

Na sowas, das muß man sportlich sehen. Da ist halt recht viel
Optimierungspotential ;-)

Gebe allerdings zu, dass für professionelle oder semiprofessionelle
Anwendungen die WELECs nicht die erste Wahl wären. Aber für Hobbybastler
und Optimierer super bei dem Preis. Wenn ich jetzt auch noch Geld dafür
kriegte müßte ich mich nicht mehr "nebenbei" für SAP krumm machen.

@Hannes

warum macht Ihr eigentlich immer Bilder vom 10ns Bereich? Da muß man in
Gedanken immer die interpolierten Werte rausrechnen um sich ein Bild des
Werteverlaufs zu machen. Der 50ns Bereich ist da ideal, weil er die
Werte 1:1 wiedergibt bei voller Samplerate.

Gruß Hayo

Weil Bruno das so macht und ich keinen Plan habe, was für wen warum auch
immer am besten ist.

Sprich: hier einfach der Vergleichbarkeit der Bilder wegen.
Normalerweise[TM] mache ich auch andere Bilder.

Guido schrieb:
> woanders her kommen. Kanal 3 kannst du besser einstellen. Da sieht
> man noch die Abweichungen zwischen den ADCs (periodisch). Probier
> mal mit einem Terminalprogramm (sofern nicht schon getestet).

Ändert nix, damit habe ich schon rumgespielt. ;)

/Hannes

Hallo,
der Grund warum ich Fotos im 10ns Bereich mache ist eigentl. ganz
simpel: ich hatte lange Zeit (und habe tw. immer noch) massive Probleme
mit HF Schwingungen, eben auch mit dem ADC Abgleich und mit einer NF
Überlagerung bei offenen Eingängen. Bei 50ns ist es sehr schwer eine
eine HF Frequenz auszuzählen und eine Regelmäßigkeit zu erkennen. Das
mit den interpolierten Werten stellt kein Problem bei 10ns dar, erstmal
geht es ja um die Minimas und Maximas der Anzeige- und die sind auf
keinen Fall interpoliert. Darüber hinaus fällt es bei 10 ns leichter die
Anzahl der wirklichen Sprünge abzuschätzen, also um wieviele Bit des ADC
die Anzeige des Display sich wirklich ändert. Als letztes möchte ich
auch das Verstärkerrauschen mit untersuchen, das ist nach bisherigen
Erkenntnissen in den 1er Messbereichen am grössten.

@Guido:
Ich antworte dir im HW Thread.

Gruß, brunowe

Ich bin echt beeindruckt!

Es ist schon genial, was hier die Entwickler und Tester auf die Beine
stellen. Mich juckt es ja so sehr, ebenfalls einen Welec zu ersteigern.
Aber ich habe für mein Hobby bereits einen Agilent 54622D und ich
vermisse bei dem Welec einfach die 16 digitalen Kanäle, ohne die ich
nicht leben könnte :)

Trotzdem mal ein paar Ideen für die ganze Offset/Zeroing Problematik,
gerade weil ich diesen Abgleich vom Agilent her ein wenig kenne.
Allerdings habe ich für dieses Gerät, trotz Vorzugspreis und so weiter,
einen aus Hobby-Sicht stolzen Preis bezahlt und es daher noch nicht
geöffnet.

Der Agilent fährt bei einer User-Calibration ein recht aufwändiges
Muster an Kurven durch, dem man auch zuschauen kann. Wenn Euch das
hilft, versuche ich mal davon ein Video zu machen. Es sind wohl einige
unter Euch, die aus den dargestellten Mustern rückschließen können, was
da eingemessen wird.
Was ich bei dem Welec bislang vermisse, ist ein Referenz-DAC, der zur
Kalibration aller anderen verwendet werden kann. Ist der noch irgendwo
verborgen, oder wurde der tatsächlich eingespart? Oder gibt es bei den
verschiedenen Multiplexern eventuell eine Stellung in der sie auf 0 und
eine, in der sie auf eine Vref geschaltet werden können? Dann kann man
eventuell den Gain-DAC dazu verwenden, die OVs auszumessen.
Es wundert mich doch sehr, dass es notwendig ist, die Strahlen auf Mitte
zu bringen, bevor man eine ZeroCal durchführen kann.

Eine softwaretechnische Frage wäre dann noch, ob der Welec seine
Software aus dem FLASH laufen lässt, oder ins RAM bootet und dort dann
arbeitet. Für die Entwickler wäre die Idee, einen weiteren Bootloader zu
schreiben sicherlich sehr hilfreich, der originiale scheint, ehrlich
gesagt, Murks zu sein. Das Flashen von 8MB dürfte nicht länger als max.
4min dauern.
Sollte sich jemand daran wagen, dann wäre es wohl sinnvoll, den
Bootloader ins RAM zu kopieren, große Blöcke ins RAM zu laden und von
dort aus zu flashen. Bitte beachtet dabei, dass die Toggle-Bits einiger
AMD/Spansion und Kompatibler erst nach ein paar ms gültig sind. Ist eine
Falle, die das Flashen enorm verlangsamen kann, wenn man diese zu früh
abfragt und dann in eine Fehlerbehandlung rennt, die nicht nötig ist.
Ich meine MX gehört zu den Spansion kompatiblen. Wenn das ganze ins RAM
kopiert wird, dann sollte der Bootloader das auch unterstützen, damit
man eine Software auch ohne Flashen mal schnell ausprobieren kann.

Hat jemand eine Info, in wie weit diese Scopes noch nachgefertigt
werden? Wenn Welec/Wittig nur noch Restbestände abverkaufen, und alles
deutet darauf hin, dass nur noch die Retouren aufgearbeitet und
abverkauft werden, was dann? Die Arbeit ist auf keinen Fall vergebens,
aber es wäre sicherlich besser, wenn man länger was davon hätte, auch
wenn ich nicht weiß, ob sich ein OpenSource Oscar auf dem Markt
durchsetzt.
Allerdings wäre das doch sicherlich ein interessantes Geschäftsmodell
für Wittig um seinen Laden zu retten. Ich hatte eigentlich gehofft, dass
er sich mehr für das Projekt einsetzen würde. Nun, auf der Sourceforge
Seite angekündigte Bereitstellung von Mustern an die Maßgeblichen
Entwickler ist ein Schritt in die richtige Richtung.

Ich verfolge das auf jeden Fall mal weiter, vielleicht kann ich mein
Hobby-Budget mal wieder aufstocken :)

Gruß, Ulrich

@Guido

wg. des Freeze-Problems bräuchtest Du die Sourcen der 0.32 und 0.33, da
läßt sich das am einfachsten herausfinden da ein direkter
Sourcenvergleich möglich ist. Guckst Du im Anhang...

Der Fehler ist mit Sicherheit in der Hardwareroutine zu finden, denn die
Grafikausgabe wird, wie ich schon rausgefunden habe, korrekt durchlaufen
- die Drehgeberroutinen übrigens auch. Der Grund warum keine neuen Daten
gelesen werden ist sekundär, dass das ADC_Data_Available Flag nicht
gesetzt wird und dann auch der ADC nicht ausgelesen wird (Handle_ADC()
Zeile 19418). Warum es aber nicht mehr gesetzt wird, das versuche ich
rauszukriegen. Müßte eigentlich eine Änderung sein die ich mit BF
gekennzeichnet habe.


@Bruno

ok, das kann ich einsehen. Für meine Zwecke benutze ich meistens die
50ns Einstellung da ich hier immer alle realen Punkte ohne Zommfaktor
zur Verfügung habe (deswegen hab ich auch das Freeze-Problem nicht
bemerkt).


@Ulrich

Mußte Deinen Beitrag noch ein zweites Mal lesen, da er so lang war, dass
ich am Ende nicht mehr wußte was am Anfang stand (Altersbedingt).

Also zum Bootloader: Das Programm läuft natürlich im RAM. Beim
Anschalten des DSO wird ein kleines Bootloaderprogramm aus dem Flash
geladen (steht an Adresse 0x00040000) dieses kopiert dann den Rest der
Firmware ins RAM (Adresse 0x00800000), von wo es dann gestartet wird.

Zur Flashgeschwindigkeit: Klar, ich hab es mit einem selbstgeschriebenen
Linux-Kommandozeilenprogramm in 3 Minuten geschafft. Leider war mir das
Programm nicht zuverlässig genug, da hab ich dann lieber das von Markus
genommen. Anscheinend ist es nicht so einfach ein RS232
Übertragungsprogramm zu schreiben, das auf allen Rechnern gleich gut
funktioniert (liegt wohl auch am Hardware Abstraction Layer). Bin aber
ganz froh, dass es überhaupt so gut funktioniert.
Zudem hatte ich anfangs auch nicht vermutet dass es sooo viel zu tun
gibt und ich innerhalb kürzester Zeit auf weit über 100 Uploads komme.

Zu den Abgleichkurven: Ja, immer her damit. Ich laß mich gerne von
Profilösungen inspirieren.


Gruß Hayo

@Ulrich

Ach ja, eins hatte ich noch vergessen, der Trend geht zum Zweitwelec ;-)


Da kann man schön vergleichen und kann auch mal eins zerlegen.

Gruß Hayo

Ok, kürzer :)
Hoffe ich kann das Video mit meiner kleinen WebCam ordentlich hin
bekommen und irgendwo hin uploaden.

Ich denke, dass es nötig ist, den Bootloader so zu erweitern, dass man
auch direkt ins RAM schreiben kann, falls das nicht ohnehin schon
unterstützt wird, damit man eine neue Software direkt testen kann (
Flashloader überspringen). Wegen der fehlenden FlashErase und
Schreibzyklen sollte das weit unkritischer sein und damit auch
unkritischer für die serielle Kommunikation. Wurde auf Seite des Wittig
eventuell das RTS/CTS Handling übersehen, oder hat der diese Leitungen
nicht angeschlossen?

Gruß, Ulrich

Ulrich P. schrieb:
> Es wundert mich doch sehr, dass es notwendig ist, die Strahlen auf Mitte
> zu bringen, bevor man eine ZeroCal durchführen kann.

Das liegt daran, das ich einen anderen Ansatz verfolge als die Routine
von WELEC. Ist eigentlich ganz simpel. Ich prüfe einfach bei offenen
Eingängen die ADC-Werte. Diese müssen bei GND 127 betragen (oder 128 je
nachdem wo man die Nullinie hinlegt). Ich ermittle also nur die
Differenz zu den 127 und korrigiere dann den DAC-Wert um die Differenz
und einen Faktor. Da aber nur bei DAC-Nulllage auch 127 rauskommt, muß
ich vorher die DACs in die Nulllage fahren. Übrigens wird kein absoluter
Korrekturwert ermittelt, sondern der von der Search Zero Routine
ermittelte Wert wird nach oben oder unten korrigiert - ein Feintuning
sozusagen.

Gruß Hayo

egberto schrieb:

> Anfängerfrage (nicht hauen!) - womit commpiliert ihr das eigentlich?
>
> Was muß ich mir dafür installieren?

Du brauchst ein Linux-System dafür. Kann man ganz easy zusätzlich zum
Windows installieren. Bei mir hat es mit Open SUSE prima hingehauen (War
auch Linux-Anfänger). Ich hatte auch schon mal ein how to geschrieben,
ich hänge das hier nochmal an.


Viel Erfolg

Hayo

Ok, ich hatte jetzt noch nicht die Zeit die Datenblätter der DACs und
ADCs durch zu arbeiten. Aber normalerweise ist doch ein signed bei
0..127 positiv und bei 128..255 negativ, wobei 128 der -1 entspricht.
Allerdings nur, wenn man die Wandler ensprechend einstellt. Ich habe die
ganzen Threads innerhalb eines Tages durchgelesen, und meine mich
erinnern zu können, dass die Eingangsstufen die Messpannung auf
Wandlermitte anheben, also wird nur positiv gemessen.

Die Zero-Linie bei offenem Eingang zu messen halte ich für kritisch, da
die OVs der Eingangsstufe dann frei laufen. Gibt es keine Option, die
Stufe auf GND zu schalten? Das wäre schon mal ein Anfang. Optimaler wäre
es sicherlich, die Gesamtaussteuerung zu durchlaufen und dann die Daten
zu mitteln. Dazu müssten aber wenigstens die DACs für das GAIN halbwegs
kalibriert sein. Gibt es denn in dem ganzen Scope keine einzige
brauchbare Referenz aller Kanäle gemeinsam?

Nochwas zum HP. Er führt die User-Calibration offenbar unter
Berücksichtigung der eigenen Temperatur durch, diese vermerkt er
jedenfalls in den Logdaten zur Cal. Viel mir nur gerade ein, weil einige
ja darüber klagten, dass der Welec nur bei bestimmten Temperaturen
sauber funktioniert. Vermutlich fehlt der Sensor im Welec-Design, oder
er wurde noch nicht gefunden. Andernfalls müsste man für eine schnelle
Aufbereitung der Daten für jeden Wandler eine Korrekturtabelle von 256
Werten anlegen. Diese wird beim HP vermutlich durch die User-Calib
extrapolieert.

Wo kann ich denn das Video ggf. ablegen. Die User-Calib dauert ein paar
Minuten... Werde ich dann heute Abend aufnehmen.

Gruß, Ulrich

Was mich extrem wundert, sind die Ähnlichkeiten zwischen Welec und
Agilent Geräten.
Z.B. sind die Bedienelemente 100% identisch. Abgesehen von zwei
fehlenden Tasten beim Welec und anderen Softkeys.
Auch das Bildschirmdesign ist zu 99% identisch. Auch die 4 SubDiv/Div in
Y-Richtung.
Siehe Bedienungsanleitung:
http://cp.literature.agilent.com/litweb/pdf/54622-97036.pdf

Verwendet Welec wirklich leicht abgeänderte Orginaldesigns von Agilent?
Aber warum sind dann Hard-und Software so buggy?

Kurt Bohnen schrieb:
> Was mich extrem wundert, sind die Ähnlichkeiten zwischen Welec und
> Agilent Geräten.

Das wundert mich nicht. Wenn ich ein neues Gerät auf den Markt bringen
wollte, würde ich mich auch an Bewährtem orientieren

> Z.B. sind die Bedienelemente 100% identisch. Abgesehen von zwei
> fehlenden Tasten beim Welec und anderen Softkeys.
> Auch das Bildschirmdesign ist zu 99% identisch. Auch die 4 SubDiv/Div in
> Y-Richtung.

Das hätten sie allerdings nicht abkupfern müssen. Da halte ich es eher
wie die Japaner: Gut abkupfern und dann verbessern!

> Siehe Bedienungsanleitung:
> http://cp.literature.agilent.com/litweb/pdf/54622-97036.pdf

Die hätte WELEC man auch abkupfern sollen, denn die taugt wenigstens
was. Die werd ich mal als Anhaltspunkt für weitere Entwicklungen nehmen
und evtl. auf dieser Basis mal eine richtige Anleitung für das WELEC
stricken.

> Verwendet Welec wirklich leicht abgeänderte Orginaldesigns von Agilent?

Wohl nur das Äußere würde ich sagen. Genaueres kann uns da nur ein
Agilent-Besitzer sagen.

> Aber warum sind dann Hard-und Software so buggy?

Weil sie halt nicht von Agilent sind (schade)

Gruß Hayo

p.s. vielleicht kann man ja eine Platine von Agilent kriegen und ins
WELEC einbauen ;-)

Ulrich P. schrieb:
> Aber normalerweise ist doch ein signed bei
> 0..127 positiv und bei 128..255 negativ, wobei 128 der -1 entspricht.

Und 127 die Null. Soweit korrekt.

> Die Zero-Linie bei offenem Eingang zu messen halte ich für kritisch, da
> die OVs der Eingangsstufe dann frei laufen.

Da gebe ich Dir recht.

> Gibt es keine Option, die
> Stufe auf GND zu schalten? Das wäre schon mal ein Anfang.

Mir ist keine bekannt, aber wenn es da andere Erkenntnisse gibt macht
mich schlau. Ich wollte mich erstmal an vorhandener Hardware
orientieren, damit alle was davon haben.

> Optimaler wäre
> es sicherlich, die Gesamtaussteuerung zu durchlaufen und dann die Daten
> zu mitteln. Dazu müssten aber wenigstens die DACs für das GAIN halbwegs
> kalibriert sein. Gibt es denn in dem ganzen Scope keine einzige
> brauchbare Referenz aller Kanäle gemeinsam?

Nicht das ich wüßte. Allerdings hab ich die Hardwareseite noch nicht so
intensiv unter die Lupe genommen. Tja da war ich wohl vor 15 Jahren
schon weiter als ich für die Diplomarbeit mein externes Oszi für den
Parallelport konstruiert habe. Da gab es nämlich Abgleichreferenzen und
auch eine schicke Spektralanalyse auf dem PC. Da lief aber die komplette
Software auf dem PC und man mußte nicht so mit Resourcen geizen wie
hier.
Unter anderem gab es auch eine Korrektur der ADC-Kennlinie, die hatte
ich beim WELEC auch schon probeweise eingebaut (Y = beta*X + alpha) aber
wegen der massiven Performanceeinbrüche bei der Graphikausgabe wieder
ausgebaut.

> Nochwas zum HP. Er führt die User-Calibration offenbar unter
> Berücksichtigung der eigenen Temperatur durch, diese vermerkt er
> jedenfalls in den Logdaten
...
> Vermutlich fehlt der Sensor im Welec-Design, oder
> er wurde noch nicht gefunden.>

Temperatursensor? Was ist das möchte man fragen. Sowas gibt es hier
nicht. Da hilft nur nachkalibrieren, und damit das gut klappt legen wir
uns hier ja ins Zeug.

Gruß Hayo

Hayo W. schrieb:
>> Die Zero-Linie bei offenem Eingang zu messen halte ich für kritisch, da
>> die OVs der Eingangsstufe dann frei laufen.
>
> Da gebe ich Dir recht.
>
>> Gibt es keine Option, die
>> Stufe auf GND zu schalten? Das wäre schon mal ein Anfang.
>
> Mir ist keine bekannt, aber wenn es da andere Erkenntnisse gibt macht
> mich schlau. Ich wollte mich erstmal an vorhandener Hardware
> orientieren, damit alle was davon haben.

Wenn ich mir den Schaltplan unter
http://welecw2000a.sourceforge.net/docs/pcb/Analog...
ansehe, dan gibt es dort wohl mehrere Möglichkeiten. Leider sind in der
letzten Version die IC-Nummern raus gefallen.
Der MAX4704 kann das Signal aus der Vorstufe über NO2 auf GND schalten.
Damit wäre die mittlere Stufe in die Kalibration einbezogen.
Er kann mit NO1 auch gegen einen Pin D8 vom FPGA geschaltet werden, was
das für einen Sinn hat weiß ich nicht, aber wenn der Pin ein Ausgang
ist, kann man damit zumindest einen Bezug zu Digital-Masse und Digital
Vcc herstellen. Allerdings scheint da 0V anzuliegen...

Die Vorstufe rund um die OPAs müsste über K1 und K2 ebenfalls zu
beruhigen sein, hier liegt leider ein 110K Widerstand im Weg zur Masse.
Immer noch besser, als zu floaten.

>
>> Optimaler wäre
>> es sicherlich, die Gesamtaussteuerung zu durchlaufen und dann die Daten
>> zu mitteln. Dazu müssten aber wenigstens die DACs für das GAIN halbwegs
>> kalibriert sein. Gibt es denn in dem ganzen Scope keine einzige
>> brauchbare Referenz aller Kanäle gemeinsam?
>
> Nicht das ich wüßte. Allerdings hab ich die Hardwareseite noch nicht so
> intensiv unter die Lupe genommen.

Ich auch gerade erst, aber weil ich halt nur mal so mitspiele, habe ich
auch keine Hektik :) Muss ja keinen Code ändern, weil hunderte Leute
nach jeder kleinen Verbesserung lechzen :)

> Unter anderem gab es auch eine Korrektur der ADC-Kennlinie, die hatte
> ich beim WELEC auch schon probeweise eingebaut (Y = beta*X + alpha) aber
> wegen der massiven Performanceeinbrüche bei der Graphikausgabe wieder
> ausgebaut.
>
Ich kenne die Software, wie gesagt, nicht. Ich spiele daher also nur mal
mit Gedanken. Wenn man die Werte als Byte einliest, aber in einem Word
oder Longint speichert und das gleich als 2. oder drittes Byte.
Dann baut man sich eine Kalibriertabelle, ebenfalls mit korrekt
verschobenen Faktoren und multipliziert dann nur ein einziges Mal und
das als int und nicht float. Klar, die Tabelle müsste dann natürlich für
die geraden und ungeraden Faktoren abgelegt werden, also mind. 2mal. Am
besten sogar für jeden Messbereich und jeden Kanal. Das braucht etwas
Platz, spart aber Zeit.

Gruß, Ulrich

@Guido

Ich bin mir relativ sicher, dass die 0.32 noch anständig läuft. Hier
sicherheitshalber die Flashdatei wenn Du das probieren möchtest.


@Ulrich

> weil ich halt nur mal so mitspiele, habe ich
> auch keine Hektik :) Muss ja keinen Code ändern, weil hunderte Leute
> nach jeder kleinen Verbesserung lechzen :)

Ich bin zum Glück seelisch stabil ;-) - sonst wär ich auch als
EDV-Fachmann völlig im verkehrten Beruf - Kunden können echt grausam
sein...

> Dann baut man sich eine Kalibriertabelle, ebenfalls mit korrekt
> verschobenen Faktoren und multipliziert dann nur ein einziges Mal und
> das als int und nicht float. Klar, die Tabelle müsste dann natürlich für
> die geraden und ungeraden Faktoren abgelegt werden, also mind. 2mal. Am
> besten sogar für jeden Messbereich und jeden Kanal. Das braucht etwas
> Platz, spart aber Zeit.

1. Platz ist rar. Brauche schon eine Menge für die trigonometrischen
Tabellen die ich bei der FFT einsetze.

2. Bei 8 Bit ist der Benefit des Abgleichs kombiniert mit der
Ablesegenauigkeit nicht so berauschend. Den Fehler kann man also wohl
verschmerzen.

3. Diese Tabellen müßten ja für jedes Gerät separat ermittelt und
gespeichert werden - was für ein Aufwand an Abgleichroutinen.

Ich denke die Anderen werden mir Recht geben dass es momentan andere
Baustellen gibt die mehr an nutzbarem Erfolg bringen wenn wir sie in den
Griff kriegen.

Nichts desto trotz immer her mit konstruktiven Vorschlägen, dann kann
man Für und Wider hier ausdiskutieren bevor ich (oder andere Berufene)
da was einbauen.

Gruß Hayo

Hallo,

@Ulrich- mit dem Problem des "Eingangstest" (Power on self Test) hab ich
mich auch schon beschäftigt... der FPGA1 PIN D8 scheint allerdings als
Input geschalten zu sein...(Wir- im VHDL Projekt- hatten schon mal
angedacht einen definierten Spannungsverlauf über diesen Pin auszugeben
und das Ergebnis an den ADC's mit dem abgespeicherten Sollzustand zu
vergleichen)

Über die jetzige Fkt. der dortigen Beschaltung gibt's meines Wissens
noch keine tieferen Erkenntnisse.

Evtl. könnte man auch über den DAC eine definierten Spannungsverlauf
ausgeben- da müsste man einmal sehen wie schnell der ist...

Also ich verbinde meinen BNC- Eingang für die Kalibrierung immer mit
GND- speziell da mein OPA gern schwingt.

Nehm doch bitte den Schaltplan in der Google Groups, der ist immer auf
dem neusten Stand (und wesentl. ausführlicher). Derzeit in Version 1.32
http://groups.google.com/group/welec-dso

Gruß, brunowe

Hi Bruno,

Ok, dann beziehe ich mich auf diesen Schaltplan, für den aber vorerst
das gleiche gilt. Mir ist die Funktion aller OVs darin noch nicht ganz
klar, aber das wird schon. In der Diskussion dieser drei Threads war die
Rede davon, dass der ADC Single-Ended angesprochen wird. Die Schaltung
ist aber eher differential ausgelegt. Aber ich bin halt nicht der
analoge Crack, bei mir fängt die Signalaufbereitung normalerweise auch
erst im DAC/ADC an.
Daher spinn ich jetzt mal was herum. Wenn der DAC eingesetzt wird, um
den negativen Bereich in den Positiven zu verschieben, dann ist keine
saubere 0-Linien Berechnung zu machen, weil die Verzerrungen und die
Offsetfehler der OVs hoch skaliert werden. Nutzt man den ADC als
Differential und den DAC nur zum Offsetabgleich und Gain, dann würde man
doch viel genauere Messwerte gerade bei kleinen Signalen erhalten?
Beschimpft mich nicht, erklärt es mir, ich lern gerne noch was dazu.

Gruß, Ulrich

Ist schon ok, ich klemm mich mal wieder raus und schau mal, ob ich eine
UserCalib vom Agilent aufzeichnen kann.

Gruß, Ulrich

@Guido

ja da bin ich auch gerade dabei. Ich muß Dir Recht geben, die
Hardwareroutinen geben keinen Hinweis. Ich hab danach mal die
Displayroutinen gescannt, aber auch nichts direktes gefunden außer einem
Verdächtigen in der DrawSignals(), den ich jetzt mal per
Terminaldebugging etwas unter die Lupe nehme - Upload läuft noch...

Hayo

Tja bei mir sieht es ähnlich aus. Der Diff-Vergleich bringt nur
unspektakuläres. Hab jetzt mal ein paar Debuggingausgaben eingebaut.

Folgende Details:

Timebase < 18 und >28 - ADC wird gestartet, ADC meldet per ISR Data
available, Daten werden vom ADC abgeholt, Zeichenroutine gibt Signal
aus, ADC wird gestartet....usw.


Timebase >= 18 und <= 28 - ADC wird gestartet, keine Rückmeldung vom
ADC, es werden keine Daten abgeholt (wegen der fehlenden Rückmeldung),
Zeichenroutine gibt das alte Signal aus das immer noch im Buffer steht,
ADC wird gestartet... usw.


Also ich kann mir da im Moment keinen Reim drauf machen. Werd mal als
nächstes die PIO-Register checken. Schaff ich aber heute und morgen
nicht.

Gruß Hayo

Guido schrieb:
> Es macht mich halt misstrauisch,
> dass der Fehler vom Timing abhängt.

Ich habe da einen weiteren Verdächtigen ausgemacht. Vielleicht schaffe
ich es nach der Arbeit noch schnell eine neue Testversion upzuloaden
bevor ich wieder los muß.

Gruß Hayo

Ich habe bei mir das loader file etwas geändert, das wird dann mit dem
Flashfile zusammengemerged. Hier noch mal alle wichtigen Ordner ohne den
src Ordner.

Das sollte es sein. Wenn nach dem Upload alles im Oszi läuft wie es soll
kann es nicht so verkehrt sein.

Gruß Hayo

Noch eine Frage: hattest Du überhaupt das Loader-File? Wenn nicht
funktioniert es nicht, da ist der Bootloader drin, der das Programm
nachher in den RAM-Speicher lädt. Deshalb muß das Loader-File mit dem
Tomcat.Flash kombiniert werden. Sieht man auch wenn man mit dem
Texteditor ins Flashfile geht. Das ist im Makefile schon alles
eingebaut.

Gruß Hayo

@egberto

prima, dann kannst Du ja auch gleich mit einsteigen...


@Guido
Der nächste Verdächtige scheidet auch aus. Hab mal alle UI_requests
rausgenommen, geht aber trotzdem nicht - die Suche geht weiter. Hab
schon die nächste Idee, komme aber erst morgen oder übermorgen dazu.

Gruß Hayo

@Guido

das Löschen der availability Abfrage bringt uns aber nicht näher an den
Fehler. Das Problem ist ja, dass der ADC gestartet wir, aber aus
irgendeinem Grund keinen Ready-Interupt mehr auslöst. Da muß ich wohl
die Register prüfen, allerdings hatte ich da eigentlich nichts geändert.
Zur Eingrenzung werde ich auch noch mal versuchen die 0.32er
Display-Routine mit der 0.33er Hardware-Rotine zu kombinieren und
umgekehrt. Dadurch läßt sich vielleicht der Fehler weiter eingrenzen.

Gruß Hayo

Oh, sorry - da fehlte wohl ein Zeilenumbruch in Deiner Datei. Ich hab
nur den ersten Teil gelesen. Hab eben nochmal die Zeilen umgebrochen und
den Rest gelesen. Ok, das ist schon mal ein Hinweis dem man nachgehen
kann. Die Copy und Transfer Planes Routinen sind leider spärlich
kommentiert, so dass die Suche etwas schwierig ist. Evtl. könnte man
nach StopRecord() suchen, denn damit kann man den ADC-Lauf abbrechen.

Gruß Hayo

muß heißen

Stop_Record()

Hayo

Hab ich mal gecheckt, Stop_Record() scheidet aus.

Hayo

Ok,

ich glaube ich hab es. Durch Deinen Workaround bin ich da auf einen
Gedanken gekommen. Es gab in der 032 eine Variable - DrawSignals_Needed
- die hab ich in der 033 rausgenommen (zumindest in der Graphikroutine)
weil mir die Funktion redundant erschien.

Wenn ich jetzt so darüber nachdenke sollte diese Variable wohl
verhindern, dass die Gaphikroutine zu früh aufgerufen wird und damit
natürlich auch das nächste Start_Record(). Denn in Start_Record() wird
erstmal der alte Aufruf gestoppt und dann wieder ein Neuer gestartet.
Das erklärt narürlich, warum dann bei langen Wandlerlaufzeiten keine
neuen Daten mehr gelesen werden. Ich werde das mal morgen reparieren und
schicke dann die nächste Beta raus. Da sieht man wieder, zu zweit sieht
man einfach mehr als ein Einzelner.

Gruß Hayo

Ich hab auch schon einen viel eleganteren Lösungsansatz.

In der Routine Start_Record() braucht man nämlich nur das Flag -
adc_started - abzufragen und bei gesetztem Flag die Routine zu verlassen
und schon sollte die Welt wieder in Ordnung sein und da die
Graphikroutine trotzdem noch durchlaufen wird, reagiert sie auch auf
User-Eingaben.

Das halte ich auch für nachlässig programmiert (von WELEC), denn es
macht ja keinen Sinn den ADC aufzurufen wenn er noch läuft.

Gruß Hayo

Bin gerade zuhause angekommen, schnell mal Linux gestartet und die
Änderungen programmiert und den Updater angeworfen - Upload läuft. Bin
gespannt was rauskommt.

Gruß Hayo

Jo ich habs!!!!!!!!!!!!

Details erzähl ich später. Muß jetzt los.

Hayo

@sunny

Die Marker repräsentieren nur die Nulllinie (Grid-Zerolevel), diese wird
nur als direkter gridproportionaler Integerwert im Zerolevel geführt.
Die FW unterscheidet den Grid-Zerolevel (0 - 400) und den virtuellen
Zerolevel (-8192 bis +8192) der den Aussteuerbereich des DAC
repräsentiert. Man kann den Zerolevel also bis in den Virtuellen Bereich
verstellen, nur das der Grid-Zerolevel dann auf 0 oder 400 stehen
bleibt.

Die Werte im float Volt_Correct_float array sind für die Skalierung des
DAC-Offsets (Zerolevels) verantwortlich, für die Signalskalierung haben
sie keine Auswirkungen. Die Mitte (Gridmitte) des DAC-Offsets liegt bei
8192. Hinzuaddiert wird der virtuelle Zerolevel skaliert durch diesen
Faktor und korrigiert durch die DAC-Korrektur, die ja bei SearchZero()
ermittelt wird.

Gruß Hayo

Ok hier nun einige Details.

Nachdem ich gestern mit Guidos Hilfe auf den (eigentlich sekundären)
Fehler gestoßen bin, hab ich erstmal einiges Ausprobiert und analysiert.
Ausglöst wurde der Fehler durch eine Variable die ich gelöscht hatte,
die aber eigentlich von hinten durch die Brust ins Auge die
Start/Stop-Logik steuern sollte (in der Graphikroutine!).

Ich hatte ja gestern die Idee in der Start_Record() den erneuten Aufruf
zu unterbinden. Vom Gedanken her auch korrekt, aber es läuft nicht, da
die Start/Stop-Logik des ADC so krude implementiert ist, dass es immer
wieder zu Hängern kommt. Also gleich wieder Nägel mit Köpfen gemacht und
die Logik vernünftig implementiert. Die Startsequenz hab ich also aus
der Graphikroutine rausgenommen - wo sie auch wirklich nichts zu suchen
hat -  und in den ADC-Handler verfrachtet - wo sie auch hingehört.
Zusätzlich hab ich noch eine Start/Stop-Sequenz in den
TimebaseWheel-handler eingebaut. Auf die komische Steuervariable die ich
ja ohnehin schon an diversen Stellen gelöscht hatte, kann man jetzt ganz
verzichten. Außerdem wird jetzt die Graphikroutine unabhängig vom
Abtastprozess des ADC durchlaufen was eine bessere Reaktion auf
Usereingaben bewirkt.

Zusätzlich bin ich bei der Gelegenheit auf eine weitere Baustelle
gestoßen, die auch die aktuelle FW 1.4 betrifft.
Und zwar laufen Zeitbasen > 20S im 50ns Modus, man kann also mit der
Zeitbasis 200s ein Signal mit einer Frequenz von z.B. 5 MHz sauber
darstellen.

Wie das mit dem Timebaseregister zusammenhängt kann man in der
aktualisierten Fassung meiner Programming Maps sehen die in der
Timebasetabelle die aktuellen Einstellungen zeigt (siehe Anhang).

Ursprünglich war wohl für Zeitbasen im Sekundenbereich der sogenannte
Rollmode vorgesehen, der nicht eine Zeitlinie nach der anderen
darstellt, sondern mit einem Zeitfenster durch die Zeitlinie fährt. Man
kann sich das so vorstellen wie die Anzeige auf einem Herzschlagmonitor.

Der Programmierer hat jedoch alle Stellen zum Rollmode in der FW
auskommentiert. War wohl noch unausgegoren. Ich werde das auch nicht
wieder aktivieren sondern lieber gleich richtig machen. Dauert aber
natürlich etwas.

Die aktuelle FW ohne Freeze-Bug gibt es heute abend.

Gruß Hayo

Guido schrieb:

> Die Zeitbasisprobleme kann man wohl nur in der Firmware erkennen,
> wer kommt schon auf die Idee über eine Stunde zu warten, bis das
> Sampling abgeschlossen ist.

Nein, schließ mal ein 5MHz Signal an und gehe auf 100s oder 200s, das
sieht genauso aus wie im 50ns Bereich. Bin drauf gekommen weil mich die
hohe Wiederholrate stutzig gemacht hat. Bei 10s und 20s geht es noch
(hab ich einfach ausgesessen).

> Rollmode, das ist der Begriff, der mir gestern gefehlt hat. Den
> müssen wir noch implementieren (hab schon eine Idee) sonst sind
> die langsamen Bereiche next to useless.

So ist es. Der rein physikalisch Vorgang ist eigentlich ganz einfach.
Man sampled immer nur ein kurzes Stück und scheibt es auf der einen
Seite in den Signalbuffer rein. Hinten läßt man das alte einfach
"rausfallen". Dann gibt man das Siganl aus. Dann Sampled man erneut und
schiebt dann wieder nach. Das sieht dann so aus, als würde das Signal
(ein Impuls z.B.) von links nach rechts über den Bildschirm wandern.
Dadurch hat man dann bei Sampleraten um 1Sa/s auch keine ewigen
Wartezeiten bevor man was sieht.

Ideen hab ich auch schon, aber ich muß mal meine Prioritätenliste
sortieren und sehen was mir wichtig erscheint.

Gruß Hayo

Guido schrieb:

> Ich hatte mir auch Gedanken gemacht
> und war zu dem Ergebnis gekommen, dass Start_ADC in Display_Signals
> schon seinen Grund hat. Wenn der ADC schon wieder sampled, während
> die Daten verarbeitet werden, gibt es keinen zusammenhängenden
> Kurvenzug mehr.

Nein, kein Problem, der ADC-Handler wartet ja mit dem Auslesen des
nächsten Samples bis die Graphikroutine fertig ist - es sei denn es
kommt ein UI-Interrupt.

> Auch bei der Triggerung könnte das zu Problemen
> führen. Soweit ich das bisher verstehe, haben wir ja keine echte
> Hardware-Triggerung, es wird nur das aktuelle Sample entsprechend
> durchsucht.

Der Trigger verschiebt im Prinzip nur den angezeigten Ausschnitt aus dem
Signalbuffer. Ich habe die Variable die den Startpunkt des Fensters
markiert irgendwann mal umbenannt in MemWinStart falls Du mal im Coding
suchen willst.

Gruß Hayo

Ok hier wie angekündigt die neue 0.59 beta.

Hab noch schnell einige Sachen geprüft, aber soweit scheint alles stabil
zu laufen (außer den bekannten Bugs). Wer mitgelesen hat der weiß schon,
dass der Freeze-Bug endlich gefunden und beseitigt ist. Der DAC-Abgleich
ist noch in Arbeit und funktioniert nur wenn man die Zerolevel vorher
auf Gridmitte gestellt hat.

Der neu gefundene Fehler in der Zeitbasis, der auch in der originalen FW
steckt kann nur durch die Implementierung des Rollmode beseitigt werden
- Fertigstellungstermin noch unklar.

Wie immer alles andere in der readme. Ich hab auch noch die How To für
die Linux und CDK Installation mit reingepackt.

Gruß Hayo

branadic schrieb:
> Kann es sein, dass die SearchZeroLines bei den Kanälen 3 und 4 noch
> nicht richtig funktioniert? Kanal 1 und 2 werden ziemlich gut auf Null
> gebracht, bei Kanal 3 und 4 liegen die Signale unterhalb der Nulllinie.

Bei mir ganz genauso.

/Hannes

Stefan schrieb:

> habe mich mal durch das Assembler-Listing durchgelesen, das du im
> anderen Thread veröffentlich hast. Ich antworte einfach mal hier, weil
> es ja zur Software gehört. Ich hoffe, dass stört keinen.

Das ist hier schon ganz richtig, hatte nur das Thema von Bruno im
Hardwarethread aufgegriffen, von daher überschneiden sich auch einige
Themen in den Threads was ja nicht schlimm ist.

> Alles habe ich noch nicht 100% verstanden, aber den Größtenteil. Es
> langt auf alle Fälle um zu erkennen, warum das Averaging so ganz komisch
> funktioniert. Der Durchschnitt wird nicht mit den benachtbarten
> Messwerten gebildet, sondern mit den Messwerten die noch im Speicher vom
> letzten Aufruf stehen. Wenn der Trigger etwas ungenau funktioniert,
> werden dadurch verschiedenste Werte gemittelt.

Das wäre allerding etwas merkwürdig. Wundern täte es mich allerdings
nicht, nach dem was ich bislang schon alles im Coding gefunden habe.
Aber schön, dass Du Dich da reinkniest, ich gebe zu ich hatte keine
Lust, Assembler ist immer so mühsam.

Da gut optimiertes C-Coding auch nicht langsamer ist war ich schon am
überlegen ob man das nicht in C umschreibt.

Gruß Hayo

Hallo,

erstmal vorallem Danke an Hayo und Bruno für die bisherige hervorragende
Arbeit.

Ich habe mich mal mit der Idee beschäftigt das Flash für die
Entwicklungsarbeit zu umgehen und die Firmware direkt ins RAM zu laden.
Das geht gut in dem man anstatt dem Loader einfach ein "r0" an den
Anfang schreibt um den Relocate zu umgehen.

Das angehängte Makefile erzeugt zusätzlich zum TomCat.flash ein
TomCat.ram welches man ohne lange Wartezeit sehr schnell ins RAM
laden kann.
Durch den S8 Record am Ende wird die Firmware dann auch gleich
gestartet.
Dieser "S8" Record ist vermutlich auch der Grund für den Timeout
wenn man das Flash beschreibt, da der GERMS Monitor dann die
Firmware starten will, aber ein einer falschen Stelle.
Im Flash File sollte man diesen Record entfernen (mach ich mich als
nächstes drüber).

Mit gtkTerm kann ich das Ram File in knapp 3 Minuten zuverlässig laden,
damit spart man viel Zeit beim Testen, und das Flash wird auch nicht so
oft neu beschrieben was der Haltbarkeit des selben zu gute kommt.

Gruß,
Günter

Könnte man eigentlich die Bootzeit verkürzen indem man den
Startbildschirm rausnimmt, der 5 Sekunden angezeigt wird?
Man kann ihn ja immer noch über Utility/About Oscilloscope anzeigen.

Außerdem: Nach dem verstellen der Zeitbasis, wenn der Scrollbalken
ausgeblendet wurde, bleibt die Anzeige kurz stehen. Ist das normal?

branadic schrieb:

> Kann es sein, dass die SearchZeroLines bei den Kanälen 3 und 4 noch
> nicht richtig funktioniert?

Ich hab die Search Zero Funktion bis auf ein paar kleine Reparaturen
wieder auf original gesetzt weil ich die Feinkorrektur in Calibrate DAC
machen will.

> Ansonsten sieht die FW bei mir momentan stabil aus, werd mal noch ein
> wenig herumprobieren.

Einen kleinen Bug hab ich eben noch gefunden und auch schon beseitigt,
nach Calibrate Zero läuft das Signal nicht wieder los. Man muß erst am
Timebase-Knopf drehen bevor es weitergeht.

Dass Dein einer Kanal bei 0000 liegt ist schon Glücksache, das Glück
haben nicht Viele (ich denke da z.B. an Bruno). Bei mir liegen auch alle
Offsets zwischen 0 und 3.

@Egberto

Ich hab das nicht mit ins Package reingetan, weil sonst der Umfang zu
sehr anschwillt und das Limit irgendwann erreicht ist. Ich kann aber mal
ein aktuelles Build auf Google Groups ablegen und die Links dahin
aktualisieren (mach ich morgen).

Gruß Hayo

Hi,
gerade habe ich mal die Firmware auf allen Kanälen durchgetestet und es
sah recht gut aus (interner Rechteckgenerator).

Später dann (30 Minuten) habe ich diese Tests nochmal duchgeführt und
gemerkt, dass die Kurven nur bei eingehendem Signal gezeichnet werden.
Sobald der Triger weg ist, bleiben die Kurven stehen - böse Sache. Wenn
ich den getriggerten Eingang auf Null gelegt habe, steht immer noch die
'alte' Kurve. Sobald das Signal wieder am getriggerten Eingang liegt,
wird das Bild wieder gemalt. Ist aber auch möglich, dass ich irgendwo
zwischendurch was verdreht habe (Level, protrigger)...

Allerdings habe ich die Tests immer nur mit einem geschalteten Eingang
durchgeführt. Wie es sich mit 2+ Signalen verhält, weiss ich nicht.

Im großen Ganzen ist der Rauschteppich aber merklich kleiner geworden -
Danke dafür.

Michel

Ok, danke für die Info,

ich schau es mir mal an.

Gruß Hayo

@Michel

Konnte ich nicht nachvollziehen. Kriegst Du das nochmal hin? Wenn ja
dann die genauen Einstellungen posten (evtl. Bild).

Gruß Hayo

Sorry,
hab an den EInstellungen gespielt...
Wenn ich von 'Edge' auf 'Pulse Width' gehe. Ein Redraw findet statt
(Marker rechts und links zucken, nur die Kurven werden nicht neu
gezeichnet. Allerdings denke ich mal, dass die Einstellungen nicht so
ganz passen: Delta T 115us bei 1kHz Signal... ?

Bild ist nur mit 'nem Handy aufgenommen, sorry dafür. Hatte keinen Bock
die Kamera zu suchen.

Michel

@Michel

Ok Problem erkannt. Allerdings habe ich festgestellt, dass es nicht an
meinen Änderungen liegt, denn die original FW 1.4 hat genau das gleiche
Problem.

Gruß Hayo

Hab noch mal ezwas rumgetestet, sobald die Triggereinstellungen zur
Pulsweite passen läuft er weiter. Mir fehlt jetzt etwas die Erfahrung
mit anderen DSOs, insofern weiß ich nicht ob dies als Fehler anzusehen
ist, oder ob es gewollt ist. Kann hier jemand weiterhelfen?

Gruß Hayo

Da ich in den letzten Jahren nur Hochsprachen gemacht habe, traue ich
mir eine solche hardwarenahe Programmierung nicht zu, würde aber gerne
helfen...

@Hayo:
vielleicht sollte ich mich mit dem USB beschäftigen? Die serielle
Schnittstelle geht mir auf den Zwirn. Vielleicht auch den Updater
(Option: In's RAM oder Flashen...)

Gibt es einen Teil im Code, der den USB behandelt? Ich bin leider
FPGA-mäßig nicht so fit (s.o.), ist die serielle Schnittstelle direkt in
den FPGA integriert? Die Aktivierung über die Funktionstasten läßt ja
sowas vermuten...

Kann ich die Entwicklung auch unter Windows machen oder ist es unter
Linux einfacher?

Werde mal auf Google Groups nach den entsprechenden Quellen fahnden...

Michel

Hallo,

Danke Crazor, gute Erklärung.
Was ich mich in diesem Zusammenhang schon öfter gefragt habe:
Warum muss ich beim Welec-Updater den Germs-Monitor zum Upload starten,
beim original W2000-updater von Welec nicht? Offensichtlich gibt es
einen grundsätzlichen Unterschied zwischen den beiden Update-
Verfahren?!
Hat Jemand tiefere Erkenntnisse diesbezüglich?

@werner: Für einen Updater per USB wäre ich seeeehr dankbar!
Mit diesen USB-seriell ist das echt ne Qual.

Gruß, brunowe

... ich hab' mal'n Bischen rumgesucht...

Leider bringt er es laut irgendeinem Schema auf Google Groups nur auf
57k zum FPGA, laut Datenblatt kann der Cypress bis zu 230k. Wie die
Anbindung an den FPGA funktioniert, muss ich erst rauskriegen.

Bleibt mir die Firmware wohl nicht erspart...
@Hayo
Ist es vielleicht möglich mir zwei weiteren Funktionstasten das Scope an
dem USB lauschen zu lassen?

Was macht eigentlich die Firmware für den Cypress im Originalzustand?
Nur Sampledaten ausgeben?

Michel

Hi, das sind jetzt aber viel Fragen,

- erstmal kann jemand bei der Sache mit dem stehenden Signal
weiterhelfen und mal kundtun ob das so sein muß oder nicht?

- es gibt USB-Routinen in der FW. Wenn jemand die Windows oder
Linux-Seite übernimmt, könnte ich die Verarbeitung auf der DSO-Seite
übernehmen.

- Der GERMS-Monitor ist normalerweise Bestandteil aller Developmentkits
(hatte ich auf meinem DSP56000 Board auch) und ist wegen Minimalcodings
nur auf RS232 ausgelegt. Die Schnittstelle ist eigentlich nicht für den
Normalbetrieb gedacht, aber freundlicherweise hat WELEC sie gewollt oder
evtl. sogar ungewollt zur Verfügung gestellt.

- Zur aktuellen Beta die bei mir gerade heranwächst: Der DAC-Abgleich
wird langsam rund. Ich mache gerade noch ein paar Tests, ich denke
morgen müßte ich soweit sein.

Gruß Hayo

@Karl

das heißt also das WELEC läuft im "Normal" Modus, und es fehlt
eigentlich nur der "Auto" Modus.

Es ist also kein Bug sondern ein fehlendes Feature - korrekt?

Hayo

michaelk schrieb:
> So, ich kann nun auch compilieren. Wenn es also eine Kleinigkeit gibt,
> die sich für den Einstieg eignet könnte ich mich daran versuchen. Werde
> in der nächsten Zeit mal versuchen mich in den Code einzuarbeiten...

Die Datenübertragung via USB für die PC-Software ist von mir weder
getestet noch komme ich dazu hier was zu bauen (evtl. Erweiterungen).
Hier wäre also Unterstützung notwendig.

Mein letzter Stand war, dass die FW1.2 einen Fehler in der
Datenübertragung hat, und die Open Source FW basiert ja auf einer frühen
Version der 1.2 FW (anscheinend aber nicht auf der offiziellen FW1.2).

> Uum Reinzoomen:
> in der Uni arbeite ich mit einem Agilent. Dort kann man im Menü auf
> "High Resolution" umstellen. Dann samplet das Osiz höher und man kann
> ohne Probleme reinzoomen. Das ist schon sehr praktisch.

Solche Sachen müssen erstmal auf die Wunschliste, es macht keinen Sinn
damit anzufangen solange so viele unerledigte Baustellen offen sind.
Deshalb bin ich mit der FFT ja auch noch nicht weiter, da ich einsehen
mußte, das es einfach keinen Sinn macht. So langsam kommt aber Struktur
in die Sache und ich denke wir können bald anfangen die Wunschliste
abzuarbeiten.

> Hat schon jemand das Makefile von Günter ausprobiert? Wenn das
> funktioniert wäre es ja super zum Testen. Werde mal heute Nachmittag
> probieren ob es bei mir klappt.

Ich werde heute ein komplettes Build zur neuen 0.62 beta zur Verfügung
stellen

Hayo

Was meint ihr zum weglassen des Startbildschirms?

Kurt Bohnen schrieb:
> Was meint ihr zum weglassen des Startbildschirms?

Meinst Du den ganzen Startbildschirm mit Versionsanzeige etc. oder nur
das Logo? Ich finde das immer ganz nützlich. Außerdem braucht die Kiste
die Zeit ohnehin um sich zu initialisieren.

Ich kann aber gerne mal eine logofreie Version machen wenn das der
konsenz ist.

Hayo

Ich meine den ganzen Bildschirm. Aber wenn während der Anzeige noch
weiter initialisiert wird, macht es keinen Sinn.