Wittig(welec) DSO W20xxA Open Source Firmware

[Blue F. (blueflash)]

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

[Blue F. (blueflash)]

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 (Gast)]

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

[Blue F. (blueflash)]

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 (Gast)]

Sorry wegen schlechtem deutsch, bin Spanier und beobachte Welec
Entwicklung.
Habe diesen LInk gefunden:
http://apps.sourceforge.net/phpbb/welecw2000a/view...
das ist gute Nachricht für alles Welec Oscilloscope Besitzer!
Hoffe mit euch auf gute Fortschritte bei Entwicklung-

Grusse
Broma

[Broma.es (Gast)]

Sorry about this- i don't know why no funciona..
correct Link:
http://apps.sourceforge.net/phpbb/welecw2000a/viewtopic.php?f=8&t=10

[Bernhard M. (boregard)]

Broma.es wrote:
> Sorry about this- i don't know why no funciona..
> correct Link:
> http://apps.sourceforge.net/phpbb/welecw2000a/viewtopic.php?f=8&t=10

na, bei dem Datum ;-))

[Blue F. (blueflash)]

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 (Gast)]

Hallo Hayo,

hab deine neue FW bereits in mein Oszi geladen und schaue mir gerade die 
XY-Funktion an.
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? Würde die Anzeige 
schon deutlich verbessern.
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.

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?

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

Dann ist mir aufgefallen, dass unter den Setting von CH1*CH2 bei Scale 
irgendwie Hieroglyphen im Scale-Button angezeigt werden.
Der Offset steht in allen Funktionen aus irgendeinem Grund nicht von 
Haus aus auf 0V, das wäre sicherlich auch noch erstrebenswert.

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

Gruß, branadic

[branadic (Gast)]

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?

Gruß, branadic

[Blue F. (blueflash)]

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

[Blue F. (blueflash)]

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

[Kurt B. (kurt)]

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

[branadic (Gast)]

Hallo Hayo,

das mit dem Umschalten der Vectordarstellung hatte ich irgendwie 
verdrängt :)

Ich messe übrigens nicht mit 50-Ohm-Kabeln sondern mit den Tastköpfen. 
Abgeschlossen ist das DDS-Board aber dennoch mit 50 Ohm.
Hab eine schöne Phasenverschiebung zwischen Kanal 1 und Kanal 2, obwohl 
sie beide am gleichen Ausgang vom DDS-Board hängen. Ich seh da jetzt 
ehrlich gesagt keinen Messfehler?
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.

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.

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.

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.

Gruß, branadic

[Blue F. (blueflash)]

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

[Blue F. (blueflash)]

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

[Kurt B. (kurt)]

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.

[Guido (Gast)]

So alle,

habe auch mal mit XY-Modus probiert. Bin ich eigentlich der Einzige, der
den mit einem SA o.ä. verwenden möchte? Lissajous ist ja ein schönes
Spielzeug aber dafür sind DSOs doch nicht wirklich gut geeignet.

@ 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.

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

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

Gruß, Guido

[Blue F. (blueflash)]

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

[Blue F. (blueflash)]

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

[Blue F. (blueflash)]

@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

[Guido (Gast)]

Hallo Hayo,

hat etwas gedauert, aber ein Bild sagt mehr.....

Mit SA meine ich einen Spektrumanalyzer, hier mein Stolz, ein
TEK 1401A, bestimmt älter als die meisten Teilnehmer dieses
Forums.

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.

Für alle, die mit solchen Bildern nicht so firm sind: ganz links
der erste Peak ist die Nulllinie, die zur Einstellung des hor.
Offsets benutzt werden kann. Nach rechts geht es mit 50 MHZ/div
weiter. der nächste Peak ist das Nutzsignal bei 80 MHz. Dann
folgen die Oberwellen, wobei ein div einer Abschwächung um 20 dB
entspricht. Das ist meine eines Testsignal für das Welec, einstellbar
von 52 MHz bis 125 MHz, fast reiner Sinus.

Auf dem Welec ist das Bild seitenverkehrt, das Hayo ja schon im Griff.
Woher der "Rahmen" kommt ist mir unklar.

@ 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.

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

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.

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.

Gruß, Guido

[Bruno W. (brunowe)]

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

[branadic (Gast)]

Hallo Hayo hallo Guido,

ich hatte beide Kanäle auf AC_Coupling. Witzigerweise habe ich diese 
Phasenverschiebung auch bei DC-Coupling.
Wäre zu prüfen, ob das durch die Tastköpfe selbst kommt oder noch eine 
andere Ursache hat.
Werd am Montag mal 50-Ohm-Kabel mitnehmen und den Versuch wiederholen.

Gruß, branadic

[Blue F. (blueflash)]

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

[Kurt B. (kurt)]

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

[Kurt B. (kurt)]

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

[Blue F. (blueflash)]

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

[Bruno W. (brunowe)]

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

[Hauke R. (lafkaschar)]

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

[Kurt B. (kurt)]

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

[Guido (Gast)]

Hallo alle,

>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.

Was aber am Analogteil liegt, der bei den Welecs sicher auch nicht
besser ist als bei einem analogen Oszi.

>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!

So sehe ich das auch, ein Wobbler oder SA verwendet den XY-Modus exakt
genauso.

>Nicht nötig, da ich gerade dabei bin eine Spectralanalyse (FFT) zu
>implementieren die auch nicht schlechter sein wird als beim TEK.

Vorsicht, da liegen Welten dazwischen. Die Grenzfrequenz des 1401A liegt
bei 500 MHz (sieht man ja auf dem Bild). Die Amplitudenauflösung bei 
über
70 dB. da kann das Welec niemals mithalten. Die Empfindlichkeit geht
soweit, dass ein Meter Draht am Eingang reichen um die UKW-Sender
sichtbar zu machen.

>-> Cool! Dann ist das Gerät also schon so um die 50 Jahre alt?
>Wußte garnicht das es damals schon sowas gab ;-)

Hallo hayo, dass das für dich nicht zutrifft habe ich mir schon gedacht.
Für mich übrigens auch nicht. Aber das Gerät ist rund 35 Jahre alt,
für die meisten Teilnehmer wird es also schon zutreffen.

>Allerdings bin ich ebenso wie Bruno neugierig wie Du die Darstellung im
>XY-Modus hingekriegt hast -> sieht irgendwie cool aus

Aber bitte, das Bild habe ich nicht gemacht, nur aufgenommen. Das war
schon das Welec. das X-Signal ist einfach ein Sägezahn und in Y-Richtung
sind die Peaks vorhanden, die man ja beim TDS210 auch sieht.

Gruß, Guido

[Blue F. (blueflash)]

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

[Bruno W. (brunowe)]

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?

[Guido (Gast)]

Hallo Bruno We,

das ist ja ein Messgerät. Mit mal so ungefähr die Zeitbasis halbwegs
brauchbar hinkriegen wird das nichts. Aber genau für solche Fälle ist
ja der XY-Modus vorgesehen. Das 1401A hat übrigens keine eigene
Anzeige, war also zum Gebrauch mit einem Oszilloskop vorgesehen.

Gruß, Guido

[Bruno W. (brunowe)]

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ß

[michael (Gast)]

Hallo,
ich hab am Wochenende mal die neue Firmware von Hayo getestet und noch 
ein paar Probleme entdeckt, die bei mir und einem Freund (wir haben 
beide das W2024) auftraten.
Anbei sind ein paar Bilder, die das Problem beschreiben. Es sieht für 
mich so aus, als wenn eine falsche Speicherposition ausgelesen und 
dargestellt würde (letztes Bild). Bei Timebase-Einstellungen von größer 
2ms bekomme stellt das Oszi nur noch eine Linie dar (kein Rauschen). 
Dies beginnt mit nur einem Kanal und setzt sich bei größerer Timebase 
fort. Ab 50ms und größer ist das Signal eingefrohren.
Das andere Problem ist die Kalibrierung bei Kanal 3 und 4. Wenn ich 
genau die Stufen treffe (im Bild 5V und 500mV) dann ist sie gut. Stelle 
ich aber 2V ein, so habe ich einen großen Offset.

[egberto (Gast)]

nur so am Rande - bei den ersten 3 Bildern ist das Gehäuse so ocker - 
hast du das umgespritzt oder rauchst du 3 Schachteln am Tag vor dem Teil 
;-)) ??

gut's Nächtle

egberto

[michael (Gast)]

Ne, ich bin Nichtraucher und umgespritzt habe ich es auch nicht ;-) Hab 
nur ohne Blitz fotografiert und das bei relativ wenig Licht...

[Guido (Gast)]

Hallo,

nö, vor dem XY-Modus kapituliere ich. Auch wenn ich die Vektoren
ausschalte bekomme ich nur ca. 1 Bild/s. Was macht das Ding in der
Zwischenzeit? Auch mit konstanten Signalen am Eingang springt die
Anzeige hin und her. Habe mal Lissajous bei 512 kHz probiert, sieht
aus wie Aliasing-Probleme, aber die zeitl. Abhängigkeit müsste doch
im XY-Betrieb weg sein.

Michaels Problem kann ich bestätigen, bei langsamer als 10 ms/div
friert bei mir der Bildschirm ein.

@ Bruno: das Welec hat keine variable Zeitbasis und Synchronität ist
mit sowas nicht zu schaffen.

Gruß, Guido

[Blue F. (blueflash)]

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

[Guido (Gast)]

Hallo Hayo,

freut mich zu hören, dann warte ich mal ab. Zum Zeitbasisproblem:
10 ms/div geht, 20 ms/div Bildschirm eingefroren, langsamer dito.
Aktivierter Mathemodus (z.B. 2-1): 20 ms/div geht noch, ab
50 ms/div eingefroren.

Kannst du das Abspeichern der Einstellungen noch mal anschauen?
Ich muss nach jedem Einschalten ein Autozero durchführen, weil er
mindestens einen Kanal wieder verstellt hat.

Gruß, Guido

[Bruno W. (brunowe)]

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

[Blue F. (blueflash)]

@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...

[Blue F. (blueflash)]

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

[Bruno W. (brunowe)]

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

[Blue F. (blueflash)]

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

[Guido (Gast)]

>Wenn Du bei 10ns in den Delayed-Mode schaltest hast Du Ihn!

Ha,

habe ich mir das also nicht blos eingebildet. Ich mag den
Delayed-Mode!

Gruß, Guido

[Blue F. (blueflash)]

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

[Kurt B. (kurt)]

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".

[Blue F. (blueflash)]

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

[egberto (Gast)]

Warum sollten die denn den Versand verzögern?

Viele Grüße,

egberto

PS: Habe heute auch so ein 4 Kanal Teil (200 MHz) geschossen - Nach 
Ostern (wenn nichts dazwischen kommt) bin ich dann (erst mal als Tester) 
hier dabei!

[Guido (Gast)]

Hallo Hayo,

das sieht wieder mal richtig gut aus. Der XY-Modus ist wirklich
deutlich schneller und einen Lissajous habe ich jetzt auch
hinbekommen.

Kurts Meldung kann ich bestätigen, ist bei mir in beiden Kanälen.
Sieht aus, als ob der Drehgeber für die Aschwächung/Verstärkung die
vert. Pos. verschiebt.

Mir scheint, dass in den langsamen Bereichen eine für die Grafik
zuständige Variable überläuft. Schalte ich auf 20 ms/div, friert
der Bildschirm ein. Zurück auf 10 ms/div gibt es einen Bruch in der
Darstellung bei der 3. div (Verschiebung im Signal). Weiter runter
auf 5 ms/div, der Bruch verschiebt sich in die Mitte des Schirms.

Jetzt stehen die Signale bei mir wie eine Eins auf dem Schirm, kein
Rumspringen mehr und dementsprechend auch kein hektischer Druck auf
Run/Stopp. Liegt das an der neuen Firmware, oder hatte ich vorher
was anderes verbockt?

Gruß, Guido

[Kurt B. (kurt)]

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

[Blue F. (blueflash)]

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

[Blue F. (blueflash)]

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

[Guido (Gast)]

Sorry Hayo,

ich hab ja auch nur ein zweikanaliges Gerät. Aber ich drück
die Daumen, dass dein 4-Kanaler morgen ankommt. Bei mir hatte
Herr Wittig gut eine Woche gebraucht.

Gruß, Guido

[Michael K. (michaelk)]

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

[Michael K. (michaelk)]

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!

[Blue F. (blueflash)]

@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

[Bruno W. (brunowe)]

@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"

[Andreas P. (andreaspfau)]

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 :-)

[Michael K. (michaelk)]

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.

[Andreas P. (andreaspfau)]

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 :-)

[Blue F. (blueflash)]

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

[Andreas P. (andreaspfau)]

@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.

[egberto (Gast)]

So, ich habe jetzt auch mein 2024A -> wie mache ich denn ein Backup von 
dem Teil (bevor ich mit der Beta experimentiere??)

Viele Grüße,

egberto

[Bruno W. (brunowe)]

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...)

[egberto (Gast)]

Ok, ich war zu faul.....wollte aber auch auf Nummer sicher gehen - ob 
ich dann auch alle Parameter etc. mitnehme.

Ich werd dann wohl mal lesen (müssen)

Schönes WE,

egberto

[Johannes S. (demofreak)]

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

[Blue F. (blueflash)]

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

[egberto (Gast)]

Danke!

Deine Beta wollte ich ja sonst erst auspacken, wenn ich das Backup 
habe.....
Mal sehen, ob ich heute noch dazu komme (ich muß mir ja auch die 
originale Firmware erst mal etwas anschauen!).

Viele Grüße,

egberto

[Andreas P. (andreaspfau)]

@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.

[egberto (Gast)]

Stimmt, war bei mir genauso.

Viele Grüße,

egberto

[Carlos (Gast)]

Dito

Viele Grüße,

Carlos

[Blue F. (blueflash)]

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

[Andreas P. (andreaspfau)]

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.

[egberto (Gast)]

Ich denke auch, so lange nicht neue Baustellen aufgerissen werden 
sondern Dinge korrigiert - nur raus damit.

Nebenfrage: Ich habe das Teil ja erst seit Freitag (bin also noch in der 
"Gewöhnungsphase), gibt es eine Möglichkeit die Samplerate runter zu 
setzen (zwecks Vergleich mit meinem OWON)? Dann müsste sich doch auch 
das (sichtbare) Rauschen verringern?

Viele Grüße,

egberto

[Blue F. (blueflash)]

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

[Bruno W. (brunowe)]

Na das ist doch mal Klasse, danke!

 Gruß, brunowe

[egberto (Gast)]

Vielen Dank!!

(heute teste ich aber nicht mehr - komme gerade aus dem Biergarten 
<=8-))

[Johannes S. (demofreak)]

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

[Michael W. (slackman)]

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

[Bruno W. (brunowe)]

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

[Blue F. (blueflash)]

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

[Johannes S. (demofreak)]

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

[Andreas P. (andreaspfau)]

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.

[Johannes S. (demofreak)]

Siehe beiliegende Dokumentation ;)

[Andreas P. (andreaspfau)]

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

[Bruno W. (brunowe)]

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!

[Blue F. (blueflash)]

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

[Bruno W. (brunowe)]

..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

[Johannes S. (demofreak)]

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

[Blue F. (blueflash)]

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

[Guido (Gast)]

Hallo Hayo,

nur zur akt. Diskussion: gib bitte noch mal einen Suchbegriff an, mit
dem diese Kalibrierung in hardware_t.cpp gefunden werden kann. Ich
hatte das schon mal angesehen, jetzt finde ich es nicht mehr.

Wenn Bruno eine Toolchain hat, kann er das leicht selbst probieren
(schien mir unproblematisch).

Ich danke mal für die neue Version und werde nächste Woche testen.

Gruß, Guido

[Bruno W. (brunowe)]

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

[Bruno W. (brunowe)]

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

[Blue F. (blueflash)]

@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

[Bruno W. (brunowe)]

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

[egberto (Gast)]

Ich bin mal Bruno We's Beispiel gefolgt und habe das mal an meinem 
A2024A durchgeführt...

Viele Grüße,

egberto

[egberto (Gast)]

Anmerkung:

bei 10mV Eingangsempfindlichkeit (wie bei Bruno We) sieht es bei mir 
nicht so gut aus - am Besten klappt es anscheinend bei 50 mV (bei 100 mV 
ist es schon wieder schlechter).

Viele Grüße,

egberto

[Johannes S. (demofreak)]

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

[sunny (Gast)]

hallo bastelfreunde

zu aller erst mal ein großes HUT AB und DANKESCHÖN an hayo, bruno und 
die anderen entwickler die so viel arbeit und zeit in dieses projekt 
investieren.
seit vorige woche bin ich auch besitzer eines w2024. die entwicklungen 
hier im forum verfolge ich nun schon seit ein paar tagen. mich erstaunt 
wieviel potential wittig bei dem gerät verschenkt hat. wenn es also was 
zu testen gibt stehe ich gern zur verfügung. ich schrecke auch vor 
hardwarebastellein am gerät nicht zurück. als vergleichsgerät steht ein 
lecroy 9400 zur verfügung. ein paar kenntnisse in C sind auch vorhanden.

grüße sunny

[Bruno W. (brunowe)]

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

[egberto (Gast)]

Hallo Bruno We,

auch wenn wir (die primär nicht an der Hardware arbeitenden) dich nicht 
direkt vorwärts bringen können- könntest du so etwas wie eine kurze 
Abgleichanleitung mit etwas Hintergrund (warum z.B. entsteht durch 
schlechten Nullinienabgleich eine Schwingung mit 250 Mhz?) hier rein 
stellen?

Neben Johannes und mir gibt es bestimmt noch mehr Einsteiger in die 
Thematik.

Viele Grüße,

egberto

[Bruno W. (brunowe)]

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

[egberto (Gast)]

Hallo Bruno We,

vielen Dank für die Antwort.

Es ist halt das alte Problem, man muss erst viele Dinge lesen (und 
ellenlange Threads abarbeiten) um eine Antwort auf eine sich stellende 
Frage zu erhalten.

Mir ist klar, das der Grat zwischen nerven der (kundigen) 
Forumsteilnehmer und Aufgabe wegen zu hohem Einarbeitungsaufwand schmal 
ist.

Darum die Bitte, auch mal eine doofe Frage wohlwollend zu beantworten - 
das macht den Einstieg wesentlich leichter.

Viele Grüße,

egberto

[Johannes S. (demofreak)]

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.

[Johannes S. (demofreak)]

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

[Guido (Gast)]

Hallo,

mal eine Schnellanleitung für den ADC-Abgleich: Ihr müsst ein
Terminalprogramm über die ser. Schnittstelle mit 115,3 kBaud/8N1
anschließen. Oszi lange warmlaufen lassen (1 h oder so).
Einstellung für alle Kanäle: 5 V/div, 50 ns/div.
Unter Utilities-> Auto-Calibrate mehrmals durchführen.

Falls die Linien für die Kanäle unterschiedlich dick sind (sieht
aus wie Rauschen) im Terminalprogramm mit Shift+Z den gestörten
Kanal wählen. Dann immer wieder Shift+Q drücken und die Anzeige
beobachten. Mit jedem Tastendruck wird eine von 22 Kombinationen
eingestellt und ihr könnt euch für die optimale Entscheiden. Die
letzte Kombination ist wieder ein Auto-Zero, jetzt aber spez. für
den eingestellten Kanal. Habt ihr die optimale Kombination für
alle Kanäle eingestellt, könnt ihr diese mit Shift+O dauerhaft
speichern.

@ Bruno We: Ich verstehe überhaupt nicht, warum diese Kalibrierung
für die Kanäle unterschiedlich ist. Es sind doch dieselben Wandler?

@ Hayo: Sollen wir mal eine Sammlung an Kalibrierwerten anlegen?

In den den 1er-Bereichen habe ich jetzt einen bleibenden Offset,
2er- und 5er-Bereiche stimmen optimal überein. Kann (muss) man das
auch individuell kalibrieren.

@ all: Viele Spaß beim Experimentieren,

Gruß, Guido

[Guido (Gast)]

Ahh, upps,

gerade gefunden Shifz+W/E, wird erst beim Umschalten übernommen.

Schon toll, wenn man sein Oszi so kalibrieren kann.

Gruß, Guido

[Bruno W. (brunowe)]

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

[Johannes S. (demofreak)]

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

[Kurt B. (kurt)]

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/Ch1_ohne_R31uR32-Slog_V1_3_.jpg
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 (Gast)]

Hallo Hannes,

wie ich sehe hast du dich noch nicht wirklich mit der Materie und auch 
noch nicht mit deinem Gerät beschäftigt.
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.
Dir hätte auch auffallen können, dass Wittig/Welec die optimale 
Darstellung der Signale in ihrer Produktbeschreibung bei 5V/500mV/50mV 
angibt.

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

Gruß, branadic

[branadic (Gast)]

Hallo Kurt,

genau so läuft das ab.

Gruß, branadic

[Johannes S. (demofreak)]

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

[egberto (Gast)]

Sehr interessant - das mit dem abgetrennten Kanal hatte ich auch 
verdrängt; über die 1V/2V/5V Thematik hatte ich noch nicht nachgedacht, 
allerdings wäre ich nie auf den Gedanken eines "Softwaretricks" 
gekommen.

Wieder eine Anfängerfrage: Was genau verbessert SLOGs FPGA Design? (ist 
wohl noch sehr beta, sonst hätten es ja alle fest installiert..) (bitte 
sagt jetzt nicht, ich soll das russische Forum durcharbeiten ;-)!)

Vielen Dank für die Infos....

egberto

[Kurt B. (kurt)]

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).

[Kurt B. (kurt)]

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

[Bruno W. (brunowe)]

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/Analog-Input-Part_assignment.pdf
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

[Johannes S. (demofreak)]

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

[Guido (Gast)]

Hallo Buno We,

zur Spannungsverstärkung noch folgendes: Der OPA656 ist in der
Verstärkung zwischen 1 und 1,25 umschaltbar. So entstehen die
Gesamtverstärkungen von 1, 2.5 und 5. Das ist auch nicht ganz
uninteressant, da bei 1,25-facher Verstärkung eine Frequenzkompensation
für den OPA zugeschaltet wird, die die hochfrequenten Störungen etwas
reduziert.

@ Kurt: Danke für das Video, wirklich beeindruckend.

Gruß, Guido

[Bruno W. (brunowe)]

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...

[Blue F. (blueflash)]

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 (Gast)]

Hallo Bruno We,

wir sollten uns in den Hardware-Thread verziehen. :-))

Ist U3 am OPA656 geöffnet, bilden R21 und R14 seine Gegnkopplung.
Rechnerische Spannungsverstärkung 1,244, wird in der Praxis wohl
1,25 sein. Schließt U3, ist der OPA ein Impedanzwandler, in beiden
Fällen wirkt R14 auch als Mindestlast.

Durch ide Wirkung der Kompensation bin ich auf die Idee gekommen
mit Kondensatoren zu experimentieren. Leider halt ohne großen
Erfolg.

Gruß, Guido

[Guido (Gast)]

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

[Blue F. (blueflash)]

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 (Gast)]

@ Hayo,

danke, Guido

[Guido (Gast)]

Hallo Hayo,

ich habe mal die Testfunktionen 1 und 2 so erweitert, dass sie
für den gewählten Test_Channel wirken. Die Einstellungen werden
im Protected_Flash angehängt.

Schau dir das bitte mal durch und pflege es ggf. in deine Quellen
ein. Bei meinem W2012A scheint es für beide Kanäle zu funktionieren,
ich habe 4 Kanäle vorgesehen, kann die aber nicht kontrollieren.

Über die Verstärkungseinstellungen berichte ich morgen, heute schaffe
ich wohl nicht mehr viele Tests.

Gruß, Guido

[Blue F. (blueflash)]

@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

[Ronny S. (ronnysc)]

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

[Ronny S. (ronnysc)]

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

[Ronny S. (ronnysc)]

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.

[Ronny S. (ronnysc)]

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

[Guido (Gast)]

Hallo alle,

ich habe mir mal Gedanken zum Userinterface gemacht. Wenn jemand
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.
Zufrieden bin ich eigentlich nur mit der Triggerposition, die
läuft in ihrem begrenzten Laufstall imho sehr schön.

@ Hayo: Was ich geändert habe steht im zip unter anders2.txt. Das
ist sicher nur ein Proof of Concept und lässt sich mit Sicherheit
noch verbessern. Bei meinem momentanen Codeverständnis kriege ich
es aber nicht besser hin. :-(

Gruß, Guido

[Johannes S. (demofreak)]

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

[Ronny S. (ronnysc)]

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

[Guido (Gast)]

Hallo Ronny Schmiedel,

was nutzt die USB-Übertragung, wenn das Gerät sonst nur sehr
eingeschränkt nutzbar ist? Ich habe mir das Welec eigentlich
auch deswegen gekauft, hilft aber nicht weiter. Also geh zum
Regal, nimm den K&R und lege los. :-)

@ 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. Da macht man sich aber
natürlich Gedanken: das USB-Interface würde um keinen Deut
weiterhelfen, auch über RS232 kann es höchstens 2 Minuten
dauern die Daten zu Übertragen. Teste mal!

Gruß, Guido

[Johannes S. (demofreak)]

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 S. (demofreak)]

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

[Johannes S. (demofreak)]

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.

[Blue F. (blueflash)]

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

[Blue F. (blueflash)]

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

[Johannes S. (demofreak)]

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

[Johannes S. (demofreak)]

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.

[Johannes S. (demofreak)]

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

[Uwe S. (us1)]

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

[Blue F. (blueflash)]

@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

[Blue F. (blueflash)]

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 (Gast)]

Hallo Hayo,

das hört sich ja gut an. Wegen dem Flash-Eingriff: Da habe ich
schlicht nicht kapiert was gespeichert wird und wollte sicher
gehen.

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).

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.

[Guido (Gast)]

Achso,

natürlich noch:

Gruß, Guido

[Blue F. (blueflash)]

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

[Guido (Gast)]

Hallo Hayo,

ja, das UI_request habe ich schon gesehen, aber es wirkt nicht
richtig. Deshalb meine Idee die Änderung in Tomcat anzusetzen.
Das wirkt dann auch und benötigt nur sehr wenige Änderungen.

Mit dem freeze: ich habe nicht den Eindruck, dass es voll
hängt (kann mich aber auch täuschen). Mir kommt es eher vor,
als ob die Grafikaufbereitung außerhalb des sichtbaren
Bereiches erfolgt (erst verschwindet 1/3 des Schirms, bei
größerer Zeitbasis dan 2/3 anschließend passiert garnichts
mehr).

Gruß, Guido

[Blue F. (blueflash)]

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

[Kurt B. (kurt)]

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

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

[Blue F. (blueflash)]

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

[Kristian T. (krissy1983)]

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

[Bruno W. (brunowe)]

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

[Guido (Gast)]

Hall0 Bruno We,

zu 1): Die Zeilen geben die Zahlenwerte für die Offsets der
einzelnen ADC an, sollten also dieselben sein wie die, die
beim Shift+W drücken in einer Zeile angezeigt werden. Die
Änderung auf dem Bildschirm macht sich erst bemerkbar, wenn
du den Eingangswahlschalter hin- und wieder zurückdrehst.

Ich gehe so vor: Cal. Zero-Lines, Offset stimmt für einen
Bereich (norm. nehme ich einen 5er Bereich). Umschalten in
nächsten Bereich (2er) und mit Shift W optimieren. Als letztes
noch den 1er Bereich und dann speichern.

Gruß, Guido

[Guido (Gast)]

Oops,

oben immer Shift+Q einsetzen (statt Shift+W).

Guido

[Blue F. (blueflash)]

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

[Bruno W. (brunowe)]

@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

[Blue F. (blueflash)]

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

[Bruno W. (brunowe)]

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

[Blue F. (blueflash)]

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

[Blue F. (blueflash)]

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 (Gast)]

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? 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?

Gruß, Guido

[Blue F. (blueflash)]

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

[Stefan (Gast)]

Hallo Hayo,

hast du von der Software aus zugriff auf den Programm-Speicher? Evtl. 
würde sich ein zweiter Bootloader rentieren, der den Speicher schneller 
vollbringt. Ich stelle mir das Entwickeln bei den Upload-Zeiten ziemlich 
langweilig vor ;-)

Wirklich ein super Projekt.

Gruß,
Stefan

[Bruno W. (brunowe)]

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

[Johannes S. (demofreak)]

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.

[Bruno W. (brunowe)]

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.

[Kristian T. (krissy1983)]

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

[Blue F. (blueflash)]

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

[Blue F. (blueflash)]

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

[Johannes S. (demofreak)]

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

So denn, das ist Kanal 4.

/Hannes

[Blue F. (blueflash)]

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

[Johannes S. (demofreak)]

Bittesärrrrr. ;)

/Hannes

[Ronny S. (ronnysc)]

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...

[Blue F. (blueflash)]

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

[Johannes S. (demofreak)]

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 (Gast)]

Hallo,

@ Hayo, mach mal Pause, dann fällt es einem oft wie Schuppen aus den
Haaren. Den Ansatzpunkt (manuell versus auto) hast du ja schon.

Wegen dem Freeze suche ich auch noch mal, das ist aber wohl was
fieses kleines.

@ Johannes: Kanal 4 sieht wirklich schlimm aus. Eigentlich ist der
doch am weitesten von Netzteil entfernt, das Rauschen muss also
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).

@ Bruno We: jo, so etwa bekomme ich den Abgleich auch hin. Für
mich verfestigt sich der Eindruck, dass da ein Schwingen im
Eingangskreis stattfindet. Das ist kein Rauschen der Bauteile,
dafür ist es um Größenordnungen zu stark. Normalerweise würde
ich zu Ferritperlen raten, aber das geht in dem SMD-Layout wohl
nicht?

Gruß, Guido

[Johannes S. (demofreak)]

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

[branadic (Gast)]

@ Guido,

wie wäre es statt Ferritperlen mit Ferrit Beads? Die gibt es für die 
unterschiedlichsten Frequenzbereiche und in unterschiedlichen Packages. 
Schau mal bei RS nach, da solltest du schnell fündig werden.

Gruß, branadic

[Bruno W. (brunowe)]

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

[Ulrich P. (uprinz)]

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

[egberto (Gast)]

Das der Beitrag bezüglich des Sponsorings vom 1. April ist, hast du 
gesehen?? ;-)

Viele Grüße,

egberto

[Blue F. (blueflash)]

@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

[Blue F. (blueflash)]

@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

[Ulrich P. (uprinz)]

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

[egberto (Gast)]

@Hayo / Guido

Anfängerfrage (nicht hauen!) - womit commpiliert ihr das eigentlich?

Was muß ich mir dafür installieren?

Viele Grüße,

egberto

[Blue F. (blueflash)]

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

[Blue F. (blueflash)]

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

[egberto (Gast)]

Danke, das ging ja schnell.

Und das kann man ja sogar "nebenbei" in der Firma machen ;-)......

Viele Grüße,

egberto

[Ulrich P. (uprinz)]

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

[Kurt B. (kurt)]

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?

[Blue F. (blueflash)]

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 ;-)

[Blue F. (blueflash)]

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

[Guido (Gast)]

Hallo Hayo,

wenn das Freeze-Problem wirklich zwischen 0.32 und 0.33 eingetreten
ist (h.h. in der 0.32 war es noch nicht), liegt es sicher nicht an
hardware. Da wurde fast nichtsgeändert, wie ein diff zeigt.
Es muss von display kommen, die meisten Änderungen betreffen wohl
den Delayed-Mode. Es kann eineWeile dauern, das durchzuschauen
aber das werden wir schon finden. 8-)

Gruß, Guido

[Ulrich P. (uprinz)]

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_+Inputs_updated2.png
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

[Blue F. (blueflash)]

@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

[Bruno W. (brunowe)]

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

[Ulrich P. (uprinz)]

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

[Guido (Gast)]

@ Ulrich: Der ADC wird differentiell angesteuert. Der DAC verschiebt
direkt den Offset des OPA-Eingangsverstärkers. Er könnte damit direkt
für Testsignale verwendet werden. Aber alles zu seiner Zeit. Solange
die Offseteinstellung noch hakt macht es wenig Sinn daran rumzuspielen.

@ Hayo. Jo, die 0.32 läuft noch. Ich gehe mal das diff durch.

Gruß, Guido

[Ulrich P. (uprinz)]

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

Gruß, Ulrich

[Blue F. (blueflash)]

@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

[Guido (Gast)]

@ Hayo: mit dem diff bin ich durch, da ist mir nichts
gravierendes aufgefallen. Ich bin schon am überlegen,
ob es nicht eine Race-Condition ist, aber das sieht
eigentlich auch sauber aus. Ich hab mal "Signal_Loaded"
rausgeworfen, wird eh nicht benutzt aber wohl auch keine
Besserung bringen.

Gruß, Guido

[Blue F. (blueflash)]

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 (Gast)]

Hallo Hayo,

heute blicke ich auch nicht mehr viel. Aber suche doch mal
in hardware nach "Start_Record", das wird selbst im
Timerinterrupt aufgerufen. Es macht mich halt misstrauisch,
dass der Fehler vom Timing abhängt.

Gruß, Guido

[Blue F. (blueflash)]

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

[egberto (Gast)]

Ich habe die 0.56er Sourcen jetzt compiliert bekommen, meine 
TomCat.flash ist allerdings 1307517 Byte groß, die von Hayo 1307650 
Byte.

Habe ich was falsch gemacht (die in der Anleitung beschriebenen 
"offical" Sourcen hatten kein Makefile, ich habe die "improved" genommen 
und dort das src Verzeichnis durch das von Hayo ersetzt)???

Viele Grüße,

egberto

[Blue F. (blueflash)]

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

[Blue F. (blueflash)]

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 (Gast)]

Hallo Hayo,

loader ist dabei gewesen(801 Bytes).

Mit deinen Build-Dateien bekomme nach "make clean all" nun auch deine 
Dateigröße.

Viele Grüße,

egberto

[Blue F. (blueflash)]

@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 (Gast)]

Hallo Hayo,

es ist mir gelungen den Fehler einzugrenzen und einen
Workaround zu implementieren. Der wird uns hoffentlich
helfen den Fehler zu finden. Näheres findest du im zip
als freeze.txt.

@ all: Im zip ist auch ein Tomcat.flash, das außer dem
Workaround Hayos letzter Beta entspricht. Vielleicht hat
jemand Lust zum Testen.

Gruß, Guido

[Blue F. (blueflash)]

@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

[Guido (Gast)]

Hallo Hayo,

die Availability-Prüfung habe ich längst wieder drin. Du musst
da keine weiteren Tests machen. Das Problem ist einfach, dass
der ADC in der Grafik gestoppt wird, so dass sein Interrupt
nicht ausgelöst wird. Ich vermute, dass das in Copy-Planes
erfolgt. Das können wir noch weiter untersuchen, im Moment
arbeitet das Welec mit dem Workaround aber wie gewünscht.

Gruß, Guido

[Blue F. (blueflash)]

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

[Blue F. (blueflash)]

muß heißen

Stop_Record()

Hayo

[Blue F. (blueflash)]

Hab ich mal gecheckt, Stop_Record() scheidet aus.

Hayo

[Guido (Gast)]

Hallo Hayo,

ich werde später erst mal versuchen den Workaround auf die
schuldige Funktion zu begrenzen (im Moment sind es ja noch
3). Wenn da irgendwo in dem Assemblerteil ein Bit getoggled
wird, könnte die Suche lang werden. :-(

Es könnte aber auch Absicht dahinterstecken, weil sonst ein
Konflikt beim Zugriff aufs RAM entsteht.

Wir werden es rausfinden, Guido

[Blue F. (blueflash)]

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

[Blue F. (blueflash)]

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

[Guido (Gast)]

Hallo Hayo,

das haben die sicher so gemacht, damit bei Änderung der
Einstellungen nur Start_Record aufgerufen wird. Sonst muss
man einen Messzyklus abwarten, bis die Signalanzeige
aktualisiert wird (das ist mir eh noch ein Dorn im Auge, jedes
andere Oszi kann das besser), oder erst Stop_Record und dann
noch Start_Record aufrufen.

So, TransferPlanes (allein) ist unschuldig. Werde gleich noch
mal flashen.

Gruß, Guido

[Blue F. (blueflash)]

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

[Guido (Gast)]

> Bin gespannt was rauskommt.

Wird schon klappen, ist sehr beruhigend, dass es nur das
Start_Record ist. Braucht man nicht im Assemblercode zu
wühlen.

Gruß, Guido

[Blue F. (blueflash)]

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

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

Hayo

[sunny (Gast)]

ich hab mal eine frage an die firmware coder. ich spiele gerade etwas 
mit dem schaltverhalten des switch U3 und den softwareskalierungen rum. 
wenn ich die ändere passt der offsetmarker nicht mehr zur nulllinie. 
gibt es für die markerposition auch korrekturfaktoren?

gruß sunny

[Guido (Gast)]

Hallo sunny,

das klingt ziemlich unsinnig. Die Nulllinie sollte ja da sein,
wo man sie mittels Marker hinsetzt. Die Kalibrierung des Offsets
stimmt aber nur für die in der Firmware vorgesehenen
Einstellungen der Verstärkung.

Gruß, Guido

[sunny (Gast)]

der sinn, das schaltverhalten des U3 zu ändern (zu invertieren), besteht 
darin die auflösung in den 1er und 2er messbereichen zu verbessern.
im original verstärkt der opa656 im 5er bereich mit 1,25 und in den 1er 
und 2er bereichen mit 1. das hat zur folge, dass in den 1er und 2er 
bereichen die aussteuerung des adc recht gering ist und eine 
softwareskalierung >3 notwendig ist, um den screen zu füllen. betreibt 
man den opa 656 jedoch genau umgekehrt, so dass er im 5er bereich mit 1 
und in den 1er und 2er bereichen mit 1,25 verstärkt, reduziert sich die 
nötige softwareskalierung auf einen faktor von etwa 2. das vermindert 
das sichtbare rauschen und verbessert die darstellungsqualität.
problem ist dass die ausgangsspannungen des offset dac nicht mehr zu den 
verstärkungen des opa656 passen. der offsetmarker erreicht das obere 
ende des screens ca 1,5div vor der nullinie.

die werte in dem float Volt_Correct_float array in der tc_vars.cpp 
müssten doch das sein was ich suche. richtig?

[Guido (Gast)]

Hallo sunny,

das hängt jetzt davon ab, welche Firmware du benutzt. In der neuesten
Beta hat Hayo die Umrechnung auf Int umgewandelt, so dass die
Tabelle obsolet ist.

Eigentlich sollte U3 immer geöffnet sein (meine Meinung). In den
5er Bereichen bringt das eine bessere Auflösung (Umrechnungsfaktor
auf die Grafik dann 2), in den 1er und 2er Bereichen ist die 1,25
fache Verstärkung sowieso nötig. Da müssen wir mal einheitlich
was festlegen. Dazu sind dann 3 Offsetwerte nötig, was bisher
schon vorgesehen ist.

Gruß, Guido

[sunny (Gast)]

ich nutz die .56
in der funktion ON_Zero_Channel_x wird das array noch genutzt. ich weiß 
nicht wann hayo das geändert hat.

ich hab den u3 im 5er bereich schlißen lassen, weil dann die 
softskalierung in allen 3 bereichen gleich ist. du hast allerdings 
recht. es macht eigendlich keinen sinn ihn im 5er bereich zu schließen. 
damit verschenkt man nur aussteuerbarkeit. man könnte wirklich mal 
versuchen ihn ständig ausgeschaltet zu lassen.

[Guido (Gast)]

Tja sunny,

da gibt es schon noch Unstimmigkeiten. Dein Hinweis ist
da schon hilfreich, damit das nach und nach geändert
werden kann.

Mal was anderes: Du hast ja rausgefunden wie U21 und U23
angesteuert werden (hab ich auch schon ;-)). Findest du
ev. wie und wo U24 angesteuert wird? Das wäre für den
Offsetabgleich super, dann könnte man mit dem MAX4704
hierfür die Eingänge auf GND legen.

Gruß, Guido

[egberto (Gast)]

Dafür, U3 rauszuschmeißen spricht auch die Simulation von Bruno im 
Hardwarethread -> man würde gleich 2 Fliegen mit einer Klappe 
erschlagen.

Mal sehen, was bei Brunos Lötaktion so raus kommt.

Viele Grüße,

egberto

[Blue F. (blueflash)]

@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

[Blue F. (blueflash)]

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 (Gast)]

Hallo Hayo,

da bin ich aber mal gespannt. 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. 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.

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.

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.

Gruß, Guido

[Blue F. (blueflash)]

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

[Blue F. (blueflash)]

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

[sunny (Gast)]

hi

@guido
>Findest du ev. wie und wo U24 angesteuert wird?
ja, ich denke schon.
der U24 hängt hardwaremäßig hinter dem U22 welcher für die ansteuerung 
des CH2 zuständig ist. du machst also

SwitchesCH2 &=0x00FF;
SwitchesCH2 |= 0x**00; // ** sind die daten die an U24 erscheinen sollen
SetSwitches(2, -1);

ich denke so müsste das gehen.

@hayo
die signalskalierung hatte ich schon gefunden.  mir ging es hier um die 
skalierung der dac ausgangsspannung in bezug auf die markerposition. ich 
hatte das etwas blöd beschrieben. auf jeden fall danke für die 
erklärung. ich werd mein glück noch mal versuchen.

gruß sunny

[Guido (Gast)]

Hallo sunny,

danke, damit werde ich mal spielen.

Gruß, Guido

[Blue F. (blueflash)]

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 (Gast)]

Hallo Hayo,

ich hab die neue FW mal aufgespielt und auch den ADC-Abgleich 
durchgeführt, soweit so gut.

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.
Oder hängt das noch mit dem DAC-Abgelich zusammen?

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

Gruß, branadic (W2014A)

[egberto (Gast)]

Hallo Hayo,

ich hatte das ja bei meinen Compilierversuchen schon angedeutet - die in 
deiner Anleitung angegebenen Sourcen stehen da nicht mehr, und die als 
"improved" zu findenden haben einen anderen loader als du.
Könntest du nicht diese build.zip in jede weitere Beta einschließen? 
Dann hat man ein Makefile und auch deinen loader. So könnte sich eine 
breitere "Masse" damit auseinandersetzen.

Leider geht z.Z. mein Hausumbau vor, aber deine "Programming_Maps" 
empfinde ich als sehr hilfreich zum Verständnis - bitte mehr in dieser 
Art bzw. umfangreiche Kommentare in den Sources.

Viele Grüße,

egberto

[Johannes S. (demofreak)]

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

[branadic (Gast)]

Hallo Hayo,

ich weiß nicht inwiefern dir das jetzt noch hilft, aber bei mir spuckt 
der automatische ADC-Abgleich folgende Werte aus:

CH1 ADC1 Voltage offset = 3
CH1 ADC2 Voltage offset = 0
CH1 ADC3 Voltage offset = 1
CH1 ADC4 Voltage offset = 0

CH2 ADC1 Voltage offset = 0
CH2 ADC2 Voltage offset = 0
CH2 ADC3 Voltage offset = 0
CH2 ADC4 Voltage offset = 0

CH1 Zero Sign Offs 1    = 113
CH1 Zero Sign Offs 2    = 134
CH1 Zero Sign Offs 3    = 91

CH2 Zero Sign Offs 1    = 115
CH2 Zero Sign Offs 2    = 140
CH2 Zero Sign Offs 3    = 104

Man merkt auch den Geschwindigkeitszuwachs durch deine Aufräumarbeiten 
:)
Wirklich schon schön anzuschauen.

Gruß, branadic

[Stefan (Gast)]

Hallo Hayo,

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.

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.

Mehr dazu dann Morgen, wenn ich es ganz verstanden habe.

Gruß,Stefan

[Blue F. (blueflash)]

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

[Guido (Gast)]

Hallo,

@ egberto: deine Probleme kann ich nachvollziehen, probier mal mit
dem angehängten loader.flash aus dem "Offical_Build", bei mir geht das.

@ Stefan: Probier mal, es sieht wirklich nicht so schlimm aus. Freue
mich auf Rückmeldungen! Wie du das mit dem Trigger meinst, verstehe ich
nicht. Der Mittelwert sollte ja schon aus aufeinanderfolgenden Messungen
berechnet werden.

Gruß, Guido

[Günter J. (gjung)]

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

[Kurt B. (kurt)]

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?

[Blue F. (blueflash)]

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

[Michael W. (slackman)]

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

[Blue F. (blueflash)]

Ok, danke für die Info,

ich schau es mir mal an.

Gruß Hayo

[Blue F. (blueflash)]

@Michel

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

Gruß Hayo

[Michael W. (slackman)]

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

[Blue F. (blueflash)]

@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

[Blue F. (blueflash)]

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

[Michael W. (slackman)]

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

[Crazor (Gast)]

Oszi-seitig hängt am USB ein Cypress FX1. Das ist ein USB-fähiger 
8051er. Der FX1 ist außer per JTAG nur per einer weiteren UART mit dem 
FPGA verbunden. Das heißt du gewinnst nicht viel.

Für die Anwender ist der FX1 nur ein teurer USB<->RS232 Wandler, aber 
für die FPGA-Bastler kann man auf den FX1 auch eine nette Firmware 
laden, die das Oszi dann zum Rechner hin wie einen Altera ByteBlaster 
aussehen lässt. Somit kann man direkt ohne das Gerät zu öffnen neue 
Configs in den FPGA übertragen.

Beide UARTs (die für den seriellen und die für den USB-Anschluss) werden 
im FPGA realisiert und sehen von der Software her deshalb vermutlich 
auch beim NIOS aus wie normale serielle Schnittstellen. Außerdem denke 
ich dass auch an der USB-UART bei 115200 Baud schluss ist. Aber das ist 
jetzt Spekulation.

[Bruno W. (brunowe)]

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

[Michael W. (slackman)]

... 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

[Blue F. (blueflash)]

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

[branadic (Gast)]

Hallo Hayo,

also ich kann nur von meinem täglichen Arbeitsgerät berichten:

Ist die Triggerquelle weg, dann wird die Anzeige auch weiterhin mit den 
digitalisierten Werten aktualisiert, allerdings aufgrund des fehlenden 
Triggers wandert das Signal wahllos durch den Bildschirm.
So kenn ich das jedenfalls und das macht auch irgendwo Sinn. 
Zugegebenermaßen arbeite ich mit einem DPO, nicht mit einem DSO.

Vielleicht weiß jemand anderes etwas anderes zu berichten.

Gruß, branadic

[branadic (Gast)]

Hallo Hayo,

mir ist noch eine Sache aufgefallen.
Angenommen ich habe eine Zeitbasis von 5ms, lasse mir ein Signal 
anzeigen und stoppe dann, dann sollte ich theoretisch bis 5ns herunter 
den Zeitbereich verstellen können und somit im aktuellen Ausschnitt 
näher an das Signal heran zoomen können. So kenn ich das zumindest von 
dem Tek mit dem ich arbeite.
Tatsächlich kann ich aber nur bis 1ms/div verstellen. Klar kann ich das 
Signal nur im Rahmen der aktuellen Samplerate auflösen, dennoch sollte 
das funktionieren.
Das dies notwendig sein kann weiß ich aus meiner aktuellen Arbeit. Mit 
einem einfachen Triggerereignis hätte mir da nicht geholfen, aber das 
Reinzoomen.

Man muss immer davon ausgehen, dass man am Anfang nicht weiß wonach man 
in einem Signal sucht. Erst wenn man weiß wonach man sucht (dazu sollte 
man das Ereignis mal wenigstens kurz über den Bildschirm gerauscht haben 
sehen) kann man den Trigger auf ein entsprechend Ereignis einstellen.
Daher auch mein oberer Beitrag nach Sinn oder Unsinn der 
Bildschirm-aktualisierung bei fehlendem Triggerereignis.

Beste Grüße, branadic

[Guido (Gast)]

Hallo alle,

da ja Einiges aufgelaufen ist, mal ein paar Anmerkungen.

@ branadic: Das eigentliche Problem ist ja, dass afaik es keine
Triggerung gibt. Es wird gesampled und anschließend das Sample
nach einem passenden Event durchsucht. Das mit dem Zoomen im
Stop-Modus schaue ich mal an. Ich fürchte nur, dass es mal wieder
kein Bug sondern ein Feature ist, weil es sonst garnicht geht (Hayo
kann da nix für).

@ Hayo: Mach dir keine Gedanken um den Quatsch mit PW-Triggerung. Das
ist was für Logicanalyzer und im Source wohl noch drin wie andere
LA-Fragmente.

@ Michael Werner: Ob USB oder RS232 spielt eigentlich keine große
Rolle. Ein USB-Zugang wäre halt für die Leute wertvoll, die keine
RS232-Schnittstelle mehr haben. Einfach wird das aber nicht, da
sich das Welec als HID anmeldet und damit ein entsprechender Treiber
benötigt wird. Eine verbesserte Version des Welec-Updaters wäre
schon schön. Die enorme Flashdauer hierin wird wohl hauptsächlich
durch den Einsatz einer Klasse für RS232 hervorgerufen, die sowohl
für Linux als auch Windows nutzbar ist. Uhhnd, blos nix gegen den
GERMS-Monitor, der hilft sogar, wenn man fast alles kaputt geflasht
hat.

Gruß, Guido

[Karl (Gast)]

Zum Trigger: Agilent bietet die 2 Einstellungen "Normal" und "Auto". 
Erstere zeichnet nur neu, wenn auch ein Trigger-Ereignis stattgefunden 
hat, letztere triggert immer mal wieder (0.3 s?) und zeichnet auch, was 
dann gemessen wurde. Beide sind nützlich.

Ein Oszi ohne Pulsweitentriggerung kommt mir nicht mehr ins Haus. Das 
ist mitnichten etwas für einen LA!

[Blue F. (blueflash)]

@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 (Gast)]

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...

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.
Ob man sonst eine Beschränkung in der Zeitbasis hat, kann ich aber 
gerade nicht sagen.

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.

MfG, Michael

[Blue F. (blueflash)]

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

[Kurt B. (kurt)]

Was meint ihr zum weglassen des Startbildschirms?

[Blue F. (blueflash)]

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

[Kurt B. (kurt)]

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

[Blue F. (blueflash)]

@Kurt

ja und es wird auch noch etwas länger dauern wenn ich die FFT 
implementiere, da ich die Zeit der Sartsequenz nutzen werde um die 
trigonometrischen Tabellen anzulegen (zumindest solange die nicht im 
Flash untergebracht sind). Diese Funktion ist zur Zeit nur deaktiviert 
weil ich mit dem Rest der FFT noch nich´t so weit bin.

@all

Zur Zeit bin ich beim Feintuning der DAC-Calibration Routine. Dabei bin 
ich auf einige Ungereimtheiten (mal wieder) beim Setzen der ADC-Register 
der Kanäle 3 + 4 gestoßen. Evtl. könnten hieraus einige der für Kanal 3 
+ 4 gemeldeten Effekte resultieren. Ich werde der Sache mal nachgehen.

Gruß Hayo

[Guido (Gast)]

Hallo,

nochmal zur Triggerung: mein Tek TDS210 verhält sich da exakt
genauso wie die Beta 0.59. Von Fehler kann also wohl keine Rede
sein, eher von Wunschliste.

Wenn sich jemand an der Firmware was vorknöpft, bitte hier
melden, damit nichr mehrere Leute am selben Problem arbeiten. Das
gibt sonst nur Frust und Probleme gibt es ja genug für alle.

Gruß, guido

[Michael W. (slackman)]

@ Guido:
kannst Du mir mal einen Tipp geben, wie Du die Entwicklungsumgebung auf 
Ubuntu eingerichtet hast? Das, was im Forum stand, war ein wenig kurz 
und unsortiert. Ich bin gerade dabei 'Mint' bei mir einzurichten, 
gefällt mir besser als normales Ubuntu.

@Hayo:
kann ich Dein komplettes Build so übernehmen oder muss ich Anpassungen 
machen? Sind Deine letzten FWs (oder die letzte) komplett oder muss ich 
die alten Source dazubauen?

Besten Dank im Voraus
Michel

[Guido (Gast)]

@ Michael W: Ich habe garnichts eingerichtet (wenn ich mich recht
erinnere). Nur das ndk4nios nach /usr/local kopiert (ausgepackt).
Im Makefile musste ich noch /usr/include in die Include-Liste
aufnehmen. Zum Kompilieren muss ich einmal/Tag den Pfad erweitern,
mit meiner Einrichtung mit:
"export PATH=$PATH:/usr/local/ndk4nios/bin".

Dann läuft make im "Official Build" durch. Für neue Betas mache ich
erst make clean und überschreibe dann das src-Verzeichnis im
Official Buil mit Hayos neuem src.

[michaelk (Gast)]

@ Michael W.:
die Einrichtung auf Ubuntu ist eigentlich sehr einfach. Du lädst dir die 
deb-Pakete von der Google-Groups-Seite runter und installierst sie 
(entweder per Doppelklick oder im Terminal mit dpkg -i ...). Danach 
musst du noch den Installationspfad (z.B. /opt/cdk4nios) in die 
PATH-Variable eintragen (z.B. export PATH=$PATH:/opt/cdk4nios/bin). Dann 
brauchst du noch unix2dos. Das kannst du über die Paketverwaltung 
installieren (tofrodos). Danach solltest du im Terminal per make-befehl 
compilieren können.

[Michael W. (slackman)]

Hi,
danke erstmal, nach dem zweiten Versuch habe ich Mint dann auch 
draufbekommen (Installerscript ist wohl buggy). Nachdem mir das Script 
den Windows Boot zerschossen hat, muss ich erstmal sehen, wie ich den 
wieder hinbekomme - shit, ist mir ewig nicht mehr passiert (hab seit 
Slackware 4.x in regelmäßigen Abständen mit diversen Linuxen gespielt). 
Ärgerlich, wahrscheinlich muss ich Alles platt machen und wieder neu 
installieren (Win & Linux) :-(.
WinXP Boot macht Bluescreen...

Michel

[Guido (Gast)]

>wahrscheinlich muss ich Alles platt machen und wieder neu
>installieren (Win & Linux) :-(.

Blos nicht! Eine Reparatur müsste doch einfach sein, erstmal
mit der Windows-CD. Weitere Möglichkeiten könnte ich noch
suchen.

Guido

[Blue F. (blueflash)]

Das komplette Build welches ich heute auf Google Groups zur Verfügung 
stelle muß man einfach nur in ein beliebiges Homeverzeichnis kopieren. 
Nach einem "make clean" und anschließendem "make all" (man muß natürlich 
ins Buildverzeichnis wechseln) sollte alles durchlaufen.

Hayo

[Blue F. (blueflash)]

So hier kommt sie die 0.62 beta.

Highlight: Die DAC-Kalibrierung funktioniert jetzt richtig gut. Ich habe 
eine How to für den Abgleich beigelegt.

Zusätzlich habe ich Registerwerte für den Kanal 3 + 4 verändert. Bei mir 
konnte ich keine Auswirkungen beobachten. Wer was feststellt bitte mit 
detailierter Beschreibung posten.

Die Beschreibnungen für die Linuxinstallation habe ich mit neuen Links 
versehen u.a. zum aktuellen Build 0.62. Die Sources und das komplette 
Build sind auf Google Groups verfügbar.

http://grou