Hallo werte W20xxA Besitzer und Interessierte!
Diesen Thread habe ich als Ersatz für den mittlerweile überfüllten
Thread
>Wittig(welec) Oszilloskop firmware problem<
eröffnet.
Für Hardwarethemen wird es einen eigenen Thread geben:
>Wittig(welec) DSO W20xxA Hardware>
Gruß Hayo
So hier noch eine kleine Wortliste damit der Thread auch von Google
gefunden wird:
DSO Oszilloskop oscilloscope WELEC WITTIG W2000 W2012A W2014A W2022A
W2024A
Gruß Hayo
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
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
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
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
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
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
branadic wrote:
> Dazu hätt ich nun mal eine Frage, besteht die Möglichkeit in dieser> Einstellung die Lineare Interpolation zwischen den Messwerten> abzustellen und nur die reinen Messwerte darzustellen?
Hallo Branadic, danke für die prompte Reaktion. Bin leider erst heute
dazu gekommen mir das anzusehen. Wenn ich Dich richtig verstanden habe
meinst Du die Umschaltung zwischen Vektordarstellung und reine
Punktdarstellung? Die Umschaltung erfolgt wie beim normalen Zeitsignal
über das "Display" Menü mit der Taste Vectors.
> Dann ist mir aufgefallen, dass ich immer einen einzelnen Messwerte habe,> der um die Nulllage herum liegt und das Bild verfälscht. Die ist so wie> es ausschaut auch gleich der allererste dargestellte Messpunkt.
Das konnte ich leider bei mir nicht nachvollziehen. Mach doch mal ein
Bild, damit ich mir was darunter vorstellen kann.
> Leider werden die Messdaten noch nicht korrekt wiedergegeben. Will> heißen: Ich würde erwarten, wenn ich an zwei Tastköpfen ein und dasselbe> Sinussignal anlege, dass die beiden Signale auf dem Display exakt> übereinander liegen. Das tun sie leider nicht, weswegen dann in der> x-y-Darstellung auch keine 45°-Schräge sondern eine Ellipse angezeigt> wird.> Liegt die Ursache hierfür im FPGA-Design oder in der FW?
Kann es sein, dass Du nicht mit einem 50 Ohm abgeschlossenen Kabel
gemessen hast? Offenbar hast Du Dir da irgendwo eine Phasenverschiebung
eingefangen. Bei mir gibt es eine Diagonale (siehe Bild).
> zur Mathe-Funktion:> Mir ist aufgefallen, dass bei den Einstellungen von Amplitude und Offset> nicht die LED am Verstell-Encoder leuchtet :)
Ja, das ist mir auch schon aufgefallen, allerdings tritt das nicht immer
auf und war auch schon vorher so bei der originalen FW. Da ist wohl ein
Fehler in der Menüführung.
> Dann ist mir aufgefallen, dass unter den Setting von CH1*CH2 bei Scale> irgendwie Hieroglyphen im Scale-Button angezeigt werden.
Muß ich mal checken.
> Der Offset steht in allen Funktionen aus irgendeinem Grund nicht von> Haus aus auf 0V, das wäre sicherlich auch noch erstrebenswert.
Das liegt an den Konfigdaten die beim Start geladen werden (Bei Dir sind
noch die Konfigbereiche noch original). Das ist bei Welec die
Originaleinstellung. Bei mir ist das längst anders eingestellt. Ich hab
meine neuen Parameter noch nicht im Konfigbereich untergebracht, muß ich
demnächst mal machen.
> Soweit an dieser Stelle die Kritik.> Ansonsten schon ein paar schöne Fortschritte in deiner FW.
Danke und Gruß
Hayo
branadic wrote:
> Hallo Hayo,>> was mir gerade so beim Herumspielen mit deiner FW ins Auge gestochen> ist:>> Für jeden Kanal gibt es ja den Kanalauswahlbutton, der Knopf mit der> Kanal-Zahl drauf.> Von dem Tek mit dem ich beinah täglich arbeite bin ich es gewohnt, wenn> ich diesen Kanalauswahlbutton drücke erscheint das Signal dieses Kanales> auf dem Display im Vordergrund, eine wie ich finde wirklich unglaublich> praktische Funktion.> Ist zum Beispiel wichtig, wenn ich mir ein moduliertes Signal anschauen> möchte und anschließend dessen passive Demodulation auf dem nächsten> Kanal. Aufgrund des zwangsläufigen Spannungsabfalls verschwindet das> demodulierte Signal nun hinter dem Signal des ersten Kanals bei gleichen> Scale-Einstellungen und gleichem Offset. Mit dem Kanalauswahlbutton hol> ich es mir einfach in den Vordergrund bzw. bestimme die Reihenfolge in> derer die einzelnen Kanäle angezeigt werden.>> Ließe sich sowas in deiner FW integrieren?
Um sicher zu gehen dass ich Dich richtig verstanden habe (kenne diese
Funktion bislang nicht): Mit Vordergrund/Hintergrund meinst Du bei
Signalen die direkt übereinander liegen, welches beim Zeichnen "oben"
und welches "unten" liegt bzw. welches Signal von welchem verdeckt wird?
Falls ich das so richtig verstanden habe, -> ja das sollte sich umsetzen
lassen. Hört sich ganz nützlich an.
Gruß Hayo
Hallo Hayo,
jetz habe ich mich auch mal an deine Beta rangetraut. Folgendes ist mir
aufgefallen:
Das Signal wird nicht bis zum unteren Bildschirmrand gezeichnet. Schön
zu sehen an einem "übersteuerten" Sinus.
Die Quick-Measures funktionieren nicht richtig.
Wenn man die Eingangskopplung der Kanäle auf GND schaltet, kleben die
Nulllinien am oberen Bildschirmrand.
Die Multiplikation sieht komisch aus und scheint einen großen negativen
Offset zu haben. Man muss einen positiven Offset einstellen, um das
Signal überhaupt auf den Schirm zu kriegen.
Die Eingangskopplung stand natürlich auf AC.
Beim Versuch die Daten auf den PC zu übertragen, bleibt der
Fortschrittsbalken in der Welec Software am Ende stehen und es passiert
garnichts mehr.
Beim XY ist auch auf beiden Kanälen ein negativer Offset. Vieleicht der
selbe den branadic meint.
Das symmetrische Raster ist wunderschön ;-)
Mfg,
Kurt
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
Kurt Bohnen wrote:
> Das Signal wird nicht bis zum unteren Bildschirmrand gezeichnet. Schön> zu sehen an einem "übersteuerten" Sinus.
Ja, Fehler ist bekannt -> hab ich in der readme beschrieben, nach der
Ursache suche ich noch, passiert irgendwo beim Zusammenmischen der
Grafiklayer.
> Die Quick-Measures funktionieren nicht richtig.
Hab ich befürchtet, da hier die Zerolinie völlig verschoben ist durch
meine Änderungen -> muß ich noch machen
> Wenn man die Eingangskopplung der Kanäle auf GND schaltet, kleben die> Nulllinien am oberen Bildschirmrand.
Oh, hatte ich ich noch garnicht bemerkt, ist das gleiche Problem wie bei
Quickmeasure, werd ich bis zur nächsten Beta beseitigen.
> Die Multiplikation sieht komisch aus und scheint einen großen negativen> Offset zu haben. Man muss einen positiven Offset einstellen, um das> Signal überhaupt auf den Schirm zu kriegen.
Hier wirkt sich die Multiplikation sehr stark auf kleinste Abweichungen
aus. Bei meinen bisherigen Testsignalen ist mir das nicht so extrem
aufgefallen. Hab mal Dein Testsignal nachgestellt und muß Dir recht
geben. Da muß ich mir nochmal was überlegen -> eine Idee hab ich schon.
> Beim Versuch die Daten auf den PC zu übertragen, bleibt der> Fortschrittsbalken in der Welec Software am Ende stehen und es passiert> garnichts mehr.
Die übertragung zum PC hab ich zur Zeit noch überhaupt nicht auf dem
Radar, da ich davon ausgegangen bin, dass Falk hier dran ist. Allerdings
hab ich da schon länger nichts mehr gehört. Muß ich aber erstmal hinten
an stellen, da mir die anderen Funktionen erstmal wichtiger sind.
Trotzdem Danke für den Hinweis.
> Beim XY ist auch auf beiden Kanälen ein negativer Offset. Vieleicht der> selbe den branadic meint.
Konnte ich leider nicht nachvollziehen. Wie man an meinem Testsignal
weiter oben sehen kann geht die Diagonale ziemlich genau durch den
Nullpunkt. Wie groß ist denn Dein Offset und wie hast Du gemessen?
> Das symmetrische Raster ist wunderschön ;-)
Höre ich gerne...
Gruß Hayo
branadic wrote:
> Ich messe übrigens nicht mit 50-Ohm-Kabeln sondern mit den Tastköpfen.> Abgeschlossen ist das DDS-Board aber dennoch mit 50 Ohm.
Ich vermute, dass die Tastköpfe die Phasenverschiebung verursachen.
> Daher nun auch das Bild. Zum Einen siehst du wie die beiden Signale> schön voneinander phasenverschoben liegen, zum Anderen gleich noch den> Ausreißer.
Schicke Liss-Figur, hab ich bei mir leider nicht hingekriegt, da ich
keine so schöne Phasenverschiebung produzieren konnte - muß ich mal mit
den Tastköpfen probieren.
> Auf dem Bild von Kurt kannst du übrigens die Hieroglyphe sehen, die> zieht sich dann (siehe mein Bild) in andere Menü's mit und wird nicht> überschrieben.
Ist keine Hieroglyphe, sondern ein kleines Bild. Dachte das wäre so
original. Keine Ahnung wo das herkommt, an der Stelle hab ich auch
nichts verändert. Scheint noch ne Macke aus der 1.2 FW zu sein.
>> Ansonsten hast du mich genau richtig verstanden, was die Signalpriorität> auf dem Bildschirm angeht. Ich denke das ist eine nette Bereicherung auf> auf dem Welec.
Kümmere ich mich drum
> Ist dein 4-Strahler heute eigentlich eingetroffen? Hin und wieder hab> ich die Vermutung, dass einige vermeintliche Fehler in deiner FW auf die> Tatsache zurückzuführen sind, dass ich hier noch den 2. FPGA drin habe.
Nein, Schande auch! Christian (hat im anderen Thread gepostet) hat seins
schon - ich nicht, hmmm...
-> morgen bestimmt.
Dann werd ich da mal ein paar Vergleiche anstellen.
Gruß Hayo
Das mit dem Offset in der XY Darstellung nehme ich zurück. Das lag nur
am falschen Nullabgleich der Kanäle.
Jedoch funktionieren die Cursor hier nicht richtig.
Und in der normalen Betriebsart stimmen die Anzeigen der Y-Cursor nicht
mit dem Raster überein.
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
Kurt Bohnen wrote:
> Das mit dem Offset in der XY Darstellung nehme ich zurück. Das lag nur> am falschen Nullabgleich der Kanäle.> Jedoch funktionieren die Cursor hier nicht richtig.>> Und in der normalen Betriebsart stimmen die Anzeigen der Y-Cursor nicht> mit dem Raster überein.
Cursor hab ich noch überhaupt nicht probiert, die müssen noch angepasst
werden. Hatte erstmal mit der XY-Funktion und der Optimierung der line()
Funktion alle hände voll zu tun. Wollte erstmal das Feedback zur reinen
XY-Funktion abwarten bevor ich weitermache.
Das Gleiche gilt für die Cursor in der normalen Betriebsart.
Das Dumme ist, dass ich hier Korrekturen an Coding durchführe für die
WELEC mehrere Jahre Entwicklungszeit hatte - dafür dass ich das nur
nebenbei mache bin ich also recht schnell finde ich.
Nichtsdestotrotz bin ich guter Dinge, in erster Linie versuche mal die
grundlegenden Funktionen benutzbar zu machen.
Gruß Hayo
Guido wrote:
> So alle,>> habe auch mal mit XY-Modus probiert. Bin ich eigentlich der Einzige, der> den mit einem SA o.ä. verwenden möchte?
Was ist SA?
> Lissajous ist ja ein schönes> Spielzeug aber dafür sind DSOs doch nicht wirklich gut geeignet.
Geht besser als mit meinem analogen 50MHz Oszi, das ist XY-Betrieb nur
bis 100KHz spezifiziert, danach ist die interne Phasenverschiebung zu
groß.
> @ Hayo: Die Darstellung im XY-Modus ist an der Mittelsenkrechten> gespiegelt (Fotos mach ich später noch). Welche Y-Signale stellst du> denn> dar, alle passen ja wohl nicht auf den Schirm. Ich vermute, dass da> ziemlich ausgefuchste Algorithmen nötig sind.
Wie meinst Du das mit den Y-Signalen?
> [Mecker:] Schönes Raster, aber mir fehlen echt die 2 Divisions in der> Horizontalen. [/Mecker:]
Welche Division möchtest Du denn noch haben? Habe zum Vergleich nur mein
analoges Oszi und da sieht es genauso aus. Ansonsten läßt sich das Grid
über Terminal auch in die alte gepunktete Darstellung umschalten ->
siehe readme
> @ branadic: Hast du vllt. den 2. Kanaleingang auf AC stehen? Bei> niedrigen Frequenzen verursacht der Koppelkondensator so eine> Phasenverschiebung.
Das stimmt, das könnte sein...
Gruß Hayo
@Guido
Ich habe mal die Sache mit dem spiegelverkehrten Signal um die vertikale
Achse geprüft -> Du hast Recht, es ist verkehrt rum.
Muß also noch korrigiert werden. Ist in Arbeit...
Gruß Hayo
Hallo 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
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
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
Guido wrote:
> Mit SA meine ich einen Spektrumanalyzer, hier mein Stolz, ein> TEK 1401A, bestimmt älter als die meisten Teilnehmer dieses> Forums.
-> Cool! Dann ist das Gerät also schon so um die 50 Jahre alt?
Wußte garnicht das es damals schon sowas gab ;-)
> Zum Vergleich links die Aufnahme am TDS210, viel besser geht es> mit einem analogen Oszi auch nicht. Die "Nachleuchtfunktion" ist> bei dieser langen Aufzeichnungsdauer sehr hilfreich, könnte aber> schwierig zu implementieren sein.
Sowas ähnliches wie die Nachleuchtfunktion gibt es am W20xx auch, nennt
sich "Persist" im Display-Menü.
> Auf dem Welec ist das Bild seitenverkehrt, das Hayo ja schon im Griff.
Jupp, ist schon erledigt.
> @ Hayo: Denke einfach an die FFT: 100 MHZ bzw. 200 MHz mit 8 div wird> ziemlich ungerade. Mir geht es mit 500 MHz genauso, deswegen wären> horizontal 10 div (wie bei jedem Oszi) besser, Symmetrie hin oder> her. Dass es dann mit den Spannungen ungerade wird ist kein Problem,> da sich dieses mit einem Spannungsteiler lösen lässt.
Nicht nötig, da ich gerade dabei bin eine Spectralanalyse (FFT) zu
implementieren die auch nicht schlechter sein wird als beim TEK.
Allerdings bin ich ebenso wie Bruno neugierig wie Du die Darstellung im
XY-Modus hingekriegt hast -> sieht irgendwie cool aus
> Die Y-Signale: bei der Speichertiefe des Gerätes kann ich mir nicht> vorstellen, dass du alle Werte zeichnest. Wie triffst du die Auswahl?
Korrekt, ich hatte die Auswahl zwischen wenigen Werten (schnell) und
vielen Werten (langsam). Da die reale Speichertiefe je nach Timebase
Zwischen 655 und 16K variiert, habe ich mich für die Darstellung der im
Zeitbereich angezeigten 600 Punkte entschieden. Dann weiß man, dass man
im XY-Betrieb genau das sieht was man vorher im Normalbetrieb
eingestellt hat.
> Lissajous: Die einzige mir bekannte Nutzung dieser liegt im Abgleich> von Oszillatoren. Mit einem DSO, das mir 1 bis 2 Bilder pro Sekunde> darstellt wird das aber sinnlos. Da kann man einfacher einen> Frequenzzähler einsetzen.
-> die Antwort hat Bruno schon gegeben...
> Was ich noch überhaupt nicht kapiere: kann das Gerät sich Einstellungen> merken? Kann ich mir eigentlich nicht vorstellen (im FPGA). Aber mir> kommt es bei der vertikalen Abschwächung so vor, die Offseteinstellung> ist aber immer nach dem Ausschalten weg.
-> definitiv ja! Bei bestimmten Eingaben (z.B. Verstellung der Timebase)
werden alle aktuellen Parameter ins Flash in den Konfigurationsbereich
geschrieben (kann man bei meiner FW sehen wenn ein Terminalprogramm
läuft). Allerdings muß ich zugeben, dass einige meiner neuen Parameter
noch nicht gesichert werden, ist aber auch schon in Arbeit.
Gruß Hayo
Eben habe ich mal diesen Phasenschieber zusammengelötet. Bei f0 macht er
-90°. Aber durch ändern der Eingangsfrequenz ändert sich auch die
Phasenverschiebung.
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
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
Ok, an die 500 MHz komme ich natürlich nicht heran, was ich aber meinte
war die Darstellung des Signals. Da werd ich mich mal ins Zeug legen,
dass das mal etwas geschmeidiger aussieht als ursprünglich bei den alten
Welecs. Bin da auch schon vorbelastet, da ich sowas mal als Diplomarbeit
gemacht habe.
-> Das mit dem Sägezahn werde ich auch mal ausprobieren, den Trick
kannte ich noch garnicht, man lernt nie aus...
Gruß und guats Nächtle wie der Schwabe sagen würde
Hayo
Ein Sägezahn als x-Signal- also eine gleichmäßig ansteigende Spannung.
Warum erinnert mich das nur so an das Zeitbasis- Signal? Das würde doch
bedeuten du kannst gleich den normalen Betriebsmodus wählen, wenn du
eine entsprechende Zeitbasis- Einstellung findest?
Hallo 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
Hallo Guido,
siehst du...
>Das 1401A hat übrigens keine eigene>Anzeige, war also zum Gebrauch mit einem Oszilloskop vorgesehen...
das war die entscheidende Info- Das Tek stellt also auch direkt das
passende Sägezahnsignal zur Verfügung. Das selbe kannst du mit einer
variabel einstellbaren Zeitbasis, so wie es viele Oszi's besitzen, auch
erreichen.
(Ein Referenzsignal vorausgesetzt)
Aber mit der Info:
1) Das Tek hat keine eigene Anzeige und
2.) Es stellt dafür ein Sägezahnsignal für die xy Ablenkung zu
Verfügung,
hätten wir uns die letzten 10 Posts sparen können.
Gruß
Hallo,
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.
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
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
Hallo Michael,
danke für die Hinweise, leider hab ich meinen Vierkanaler immer noch
nicht... grummel, Welec läßt sich verdammt viel Zeit, vielleich heute.
Daher bin ich auf den Kanälen 3 + 4 "blind" und kann da momentan nichts
dran machen. An einem neuen Nullabgleich bin ich aber ohnehin dran, da
ich auch noch nicht zufrieden war.
@Guido
Ich habe die XY-Funktion noch mal komplett überarbeitet und erweitert.
Du hast recht, in der 0.48 dreht das Ding noch ein paar Ehrenrunden,
deswegen sieht das auch etwas zugemüllt aus. Die neue Version ist
schneller, hat einen komplett von der Zeitdarstellung getrennten Offset
und - kleines Schmankerl für alle 4-Kanaler - eine zusätzliche
XY-Darstellung für Kanal 3 + 4 die auch gleichzeitig mit Kanal 1 + 2
dargestellt werden kann.
Nebenbei hab ich etliche Fehler beseitigt. Die neue Version gibt es
heute oder morgen.
Gruß Hayo
Hallo Hayo,
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
Hallo Hayo,
mir ist aufgefallen das in deiner FW- genauso wie im Original, im
"Vector off- Mode" nicht nur die Messwerte dargestellt werden. Falls ich
mich nicht verzählt habe werden in 10ns/Div 40Px gezeichnet, obwohl ja
nur Jede Nanosekunde ein Messwert vorliegt. D.h. es wird schon irgendwie
interpoliert...
Ich fände es, speziell für die Entwicklungsphase, weitaus besser wenn
wirklich nur die reinen Messwerte dargestellt werden. Man könnte so
wesentl. leichter etwaige ADC Nichtlinearitäten zuordnen (und
beseitigen).
Slog hat das in seinem FPGA Design wunderschön vorgemacht, indem jeder
ADC seine eigene Zeichenfarbe erhalten hat. Ich möchte jetzt keine
Grundsatzdiskussion über Sinn und Unsinn des Vector -off Mode
lostreten... dennoch würde dieses Feature gerade auch bei der Lösung der
HW Probleme imens helfen.
Gruß Brunowe
@Guido
Ja das mit dem eingefrorenen Signal konnte ich auch nachvollziehen, war
mir nur nie aufgefallen da ich in diesen Zeitbereichen nicht so häufig
teste. Meine Vermutung ist, dass es mit dem Trigger zusammenhängt, denn
die Zeichenroutine wird durchlaufen, es kommt nur kein neues Signal. Ich
hatte aber für das übernächste Betarelease ohnehin vor größere
Änderungen durchzuführen, unter anderem wollte ich den Zeroshift wieder
einbauen und dann einen neuen Zero-Offsetabgleich programmieren.
Vermutlich erledigt sich das Problem dann gleich mit.
@Bruno
Ja natürlich hast Du recht, denn die Signalgewinnung und
Signalverarbeitung sind komplett getrennt von der Zeichroutine. D.h.
wenn umgeschaltet wird zwischen Vector und Nonvector dann betrifft das
nur die Zeichenroutine. Die bekommt aber nur einen Wertebuffer übergeben
der die zu zeichnenden Werte enthält - in den Bereichen > 50ns sind das
halt die interpolierten Signalwerte. Die Interpolation findet also nicht
in der Zeichenroutine statt sondern vorher, daher wäre es etwas
schwierig die interpolierten Werte hinterher wieder auszublenden.
Weglassen kann man sie aber auch nicht, da sonst die Zeitachse nicht
mehr korrekt wäre(wäre sonst wie 50 ns).
Die Features der experimentellen FPGA-Version von Slog lassen sich hier
nur schwer einbauen (der derzeitige Stand ist dafür schon zu komplex),
auch wenn ich Dir recht geben muß, dass es für einige Tests ganz
hilfreich wäre.
Gruß Hayo
p.s. die neue FW kommt doch erst morgen, mein Oszi hoffentlich auch...
Hayo W. wrote:
> der die zu zeichnenden Werte enthält - in den Bereichen > 50ns sind das
sollte natürlich heißen < 50 ns - interpoliert werden 20ns und 10 ns
(und in Kürze auch die neue Zeitbasis 5ns)
Hayo
Hallo Hayo,
ja das habe ich mir schon fast gedacht :-( Wäre zu schön gewesen!
Dann muss ich mich wohl bei meiner "Messerei" anders behelfen...
Eine 5ns Zeitbasis ist ein guter Einfall, setzt aber eine gute
Interpolation (sinx/x) voraus.
Gruß
brunowe
Ob die Interpolation gut genug ist kannst Du Dir ja mal ansehen, es gibt
den 5ns Bereich nämlich schon - nur noch nicht im Main-Mode. Wenn Du bei
10ns in den Delayed-Mode schaltest hast Du Ihn!
Gruß Hayo
So hier wie angekündigt die aktuelle beta version 0.50 - es sind einige
Änderungen erfolgt insbesondere im XY-Betrieb.
Wundert Euch nicht beim Neustart, wenn es erstmal komisch aussieht. Da
ich die Ablage der Parameter im Config-Bereich geändert habe werden
erstmal unpassende Parameterwerte gezogen. Durch Betätigung des
Defaultsetups ist das dann aber erledigt. Bei der nächsten Verstellung
der Timebase werden dann aktuelle Werte weggeschrieben. Einen Flashdump
habt Ihr ja vorsichtshalber gemacht oder?
In der Defaultzeichenroutine werkelt jetzt die neue beschleunigte line()
Funktion, da diese das Signal an den Spitzen feiner auflöst als die alte
Zeichenroutine. Kann man gut sehen wenn man via Terminalprogramm mit den
Tasten shift + s die Darstellung umschaltet. Die Geschwindigkeit ist so
ziemlich gleich.
Die XY-Funktion hat jetzt eine eigene Zeroverstellung, deren Werte auch
getrennt im Configbereich abgelegt werden, so daß nach dem
Wiedereinschalten des Gerätes das Sinal noch an der gleichen Stelle ist
wie vorher.
Die Leute mit einem Vierkanalgerät könnten ja mal die XY-Funktion für
die Kanäle 3 + 4 testen die ich zwar implementiert habe, aber selber
noch nicht zu Gesicht bekommen habe (schneuz).
Die nächste Version wird wohl etwas dauern, da erstmal Ostern anliegt
und ich dann größere Umbaumaßnahmen vor habe, mit denen dann hoffentlich
auch etliche aktuelle Bugs verschwinden.
Also laßt mal hören was Ihr dazu meint.
So zum Schluß muß ich nochmal meinen Frust loswerden....mein Oszi ist
immer noch nicht da, obwohl WELEC das für den 4. April als spätesten
Termin angekündigt hatte. Die Gutschreibung des Betrages war sogar schon
am 27.3. . Da bin ich doch schon etwas geknickt muß ich sagen.
So langsam könnte das mal an Land kommen oder?
Gruß Hayo
Hallo Hayo,
das schalten der Kanäle auf GND funktioniert wieder. Allerdings behällt
Kanal 2 einen winzigen positiven Offset.
Ein verstellen der Volt/Div Knöpfe sorgt dafür dass sich der
entsprechende Kanal leicht verschiebt. Jedoch Komplett: Nullmarkierung,
Nulline, Triggermarkierung.
Noch schlimmer ist es bei Kanal 1: Wenn ich den Volt/Div Knopf beliebig
weit nach rechts drehe, also in Bereiche von 5mV,2mV,1mV... (wenn es die
geben würde) verschiebt sich der Kanal immer weiter nach oben.
Mfg,
Kurt
PS: Hoffentlich verzögert Welec den Versand nicht absichtlich. In den
Bewertungen heißt es immer "schnelle Lieferung".
Kurt Bohnen wrote:
> Hallo Hayo,> das schalten der Kanäle auf GND funktioniert wieder. Allerdings behällt> Kanal 2 einen winzigen positiven Offset.>> Ein verstellen der Volt/Div Knöpfe sorgt dafür dass sich der> entsprechende Kanal leicht verschiebt. Jedoch Komplett: Nullmarkierung,> Nulline, Triggermarkierung.>> Noch schlimmer ist es bei Kanal 1: Wenn ich den Volt/Div Knopf beliebig> weit nach rechts drehe, also in Bereiche von 5mV,2mV,1mV... (wenn es die> geben würde) verschiebt sich der Kanal immer weiter nach oben.
Hmm, muß ich mir mal angucken, ich hab die Nullinie jetzt geändert, in
der originalen FW wird einfach stumpf eine Linie beim Zerolevel
gezeichnet, während ich das jetzt so geändert habe, dass in der
Ausleseroutine des ADC statt der ADC-Werte Null (bzw. 127) in den
Speicher geschrieben wird. Ansonsten würde nämlich auch das Math-Signal
falsch berechnet werden, da ja im Hintergrund immer noch das
ursprüngliche Signal ausgelesen und berechnet würde.
> PS: Hoffentlich verzögert Welec den Versand nicht absichtlich. In den> Bewertungen heißt es immer "schnelle Lieferung".
Da wären sie ja schön blöd, denn breiter als hier könnten sie es wohl
kaum irgendwo trampeln! Wenn man bei Google die entsprechenden Begriffe
eingibt landet man zwangsläüfig in diesem Forum - Allerdings
interessanterweise nicht in diesem Thread sondern im Alten. Anscheinend
ist der Suchcache noch nicht aktualisiert worden.
Gruß Hayo
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!
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
Prima,
unsere kleine Gemeinde wächst von Woche zu Woche. Da macht das
weiterentwickeln so richtig Spass...
Ich denke übrigens nicht, dass da Absicht hintersteckt. Allerdings hab
ich heute mal eine Anfrage abgeschickt aber noch keine Antwort gekriegt.
Gruß Hayo
Oh, das sollte eigentlich eine Antwort an Egberto sein, aber ich sehe
gerade dass da schon wieder zwei Beiträge dazwischen stehen :-)
Danke übrigens wieder für die schnellen ersten Reaktionen. Heute hab ich
allerdings keine Lust mehr die Kiste anzuschmeißen. Werd mir das mal
später ansehen
@ Guido
Hast Du mal den XY-Modus auf Kanal 3 + 4 gecheckt? Würd mich mal
interessieren, ich kann das ja (noch) nicht sehen...
Gruß Hayo
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
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
Danke für die Hinweise.
>wenn man im x-y-Modus zwischen Vektor- und Punkt-Anzeige umschaltet,>dann wird das Signal an der y-Achse gespiegelt!
Da hab ich doch tatsächlich nur den Vektorbetrieb korrigiert und den
Punktbetrieb vergessen -> wird gemacht.
Gruß Hayo
@Hayo
ich habe mir erlaubt die FW1.2.BF.0.50_beta.zip in die Google Groups zu
stellen, hier im Mikrocontroller Forum findet die keiner aus dem
internationalen Umfeld :-)
-lässt sich irgendwie ein ADC Abgleich durch den User verwirklichen?
Praktisch wäre sowas natürlich via Menü und Encoder... aber wohl zu
komplex und eher wieder was fürs VHDL Projekt?
Bei meinen Messungen (die schon schwer im Gange sind) ist mir
aufgefallen das wohl viele Probleme (z.B. das Rauschen) durch den
schlechten ADC Abgleich zumindest begünstigt werden.
Gruß
brunowe
P.S.: Anbei noch ein kleines "Stimmungsbild"
Hi Community,
hab die FW mal angetestet, die bisher beschriebenen Phänomene konnte ich
z.T. auch schon beobachten, aber was mir arg zusetzt ist der Trigger. Da
dies die erste FW ist, die ich installiere, weiß ich nicht obs an der FW
oder an der Hardware liegt.
Ich hab jetzt keine Ahnung ob der durch die FPGA- oder die
Softcore-Firmware beeinflusst wird, jedenfalls konnte ich auf eine
sporadisch auftretende Flanke (ein Taster, der an der Mittelabzapfung
eines Spannungsteilers einen Spannungssprung erzeugt) beim besten Willen
nicht triggern, während es bei periodischen Signalen problemlos klappt.
Ansonsten, danke für die FW :-)
Das mit dem Trigger ist mir auch schon aufgefallen. Jedoch meine ich das
es nur bei CH1 extrem war und die anderen funktionierten. Werde das aber
heute Abend nochmal ausprobieren.
Bei mir klappt das angegebene Experiment auf keinem der Kanäle. Auch
nicht mit Puls-Trigger, welcher ja eigentlich noch besser geeignet wäre
für so was. Und auch bei keiner Timebase-Einstellung.
Okay, ich habe dem Projekt bereits meine Hilfe angekündigt, da weiß ich
ja jetzt wo was zu tun ist :-)
Hi,
bin aus dem Osterurlaub zurück und - Überaschung - das W2014 ist da.
Also, alles wird gut. Übrigens steht auch nur W2014 (ohne A) auf dem
Gehäuse, ich vermute mal das da alte Restbestände an Gehäusen oder
Labels verwendet werden. Die Hardware scheint aber aktuell zu sein.
Hab erstmal das komplette Flash gesichert, wer also seins zerschossen
hat kann gerne anfragen.
@Andreas
Mach mal erstmal noch nichts wegen des Triggers. Wie ich schon im readme
beschrieben habe hängt das unter Umständen mit der Deaktivierung des
Zeroshifts zusammen, den ich wegen des Nullabgleichs vorgenommen hatte.
Zur nächsten Beta werde ich das wieder aktivieren, ab da wird es dann
wirklich interessant wegen Nullabgleich, Trigger und Cursor. Der
derzeitige Stand ist nur ein Zwischenstand. In der nächsten Version
werde ich ebenfalls mal die Funktionen von Kanal 3 + 4 prüfen und
überarbeiten.
Gruß Hayo
@Hayo,
nochmal zum Trigger: wenn ich den Trigger auf AC stelle, klappts.
Seltsam, da ich überzeugt bin, dass der Trigger auch bei DC-Coupling
auslösen müsste, wenn ich den Triggerpegel zwischen H- und L-Level des
Signals lege.
Och egberto...
wie oft hatten wir das denn schon?
Lese doch einfach mal die alten Posts.
Tipp: Welec Updater... (wenn du "nur" mit Hayo's FW spielen willst...)
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
Bruno We wrote:
> wie oft hatten wir das denn schon?> Lese doch einfach mal die alten Posts.
Macht doch mal einen Artikel draus. Schliesslich breiten sich die Geräte
hier ja nun doch etwas aus, und jedem neuen Nutzer nahezulegen, 100e
Posts in mehreren Threads zu lesen... hust ;)
/Hannes
Liest eigentlich keiner das readme das ich dem FW-Update beigelegt habe?
Da steht doch alles drin und der Updater ist doch auch schon dabei.
Also hier noch mal zum Mitschreiben im Detail.
Backup erstellen:
- DSO und PC mit dem seriellen Kabel verbinden - beide anschalten!
- den Welecupdater starten, in der Parameterauswal (Pfeiltaste neben dem
grünen IC-Symbol) den Adressbereich einstellen.
- Komplettdump 00040000 bis 007FFFFF davor steht nichts drin und danach
fängt das RAM an.
- FW-Dump 00040000 bis 000DFFFF
- Config, protected Config und Signalspeicher 000E0000 bis 007FFFFF
- Am DSO die linken beiden Funktionstasten unter dem Bildschirm drücken,
es wird erst weiß dann schwarz - der Germs-Monitor ist aktiv
- Beim Welec-Updater den Download starten
- Nach dem Download mit dem Speichernbutton (Diskettensymbol) den Dump
in eine Datei speichern
Dump wieder zurückspielen:
- Am DSO die linken beiden Funktionstasten unter dem Bildschirm drücken,
es wird erst weiß dann schwarz - der Germs-Monitor ist aktiv.
- Beim Welec-Updater den Upload starten, die Flashdumpdatei auswählen
und den Upload bestätigen.
- wenn der Upload fertig ist kommt entweder eine Timeoutmeldung
(Übertragungsfehler) oder die Meldung "Fertig". Beides ist gut.
- danach DSO auschalten und dann wieder einschalten - das war es
Gruß Hayo
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
@Hayo,
der WelecUpdater hat bei mir erst funktioniert nachdem ich den Pfad auf
die .flash-Datei in der .ini-Datei angepasst hatte, erst dann wurde der
Download-Button grün (war davor disabled). Hat mich ne ganze weile
gekostet das herauszufinden, da der Pfad absolutcodiert auf das
Verzeichnis C:\Temp zeigt. Evtl. sollte in einem Future-Release ein
relativer Pfad (z.B. ".\tomcat.flash") angegeben werden.
Hi,
der Welecupdater ist von Markus geschrieben worden, daher
Änderungsvorschläge direkt an Ihn richten. Ansonsten kann ich aber in
zukünftigen Betareleases auf diese Eigenheiten hinweisen.
Ach ja, eine Frage - ich habe gerade eine Zwischenversiomn fertig, bei
der ich die XY-Funktion bzw. die Menüsteuerung angepasst habe und auch
sonst noch einige Kleinigkeiten in Bezug auf die Vierkanalfunktion
geändert habe. Soll ich die hier einstellen, oder lieber bis zum
nächsten größeren Release warten?
Gruß Hayo
Hi @Hayo,
also angesichts der Tatsache dass jede FW, insbesondere die originale,
mit einigen Bugs behaftet ist, nehme ich jedes Release gerne an, solange
es keine anderen Funktionen außer Kraft setzt. Außerdem ist das W2024A
mein einziges Oszi, über jede Verbesserung an meinem
oszillographierenden Messknecht bin ich froh :-) Gerade die
Menügeschichten klingen nützlich.
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
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
So, hab die FW grade mal draufgeflasht (ist ja in Verbindung mit dem
Backup ein abendfüllendes Programm :D) und werd dann mal bissi
rumspielen.
Was mir grade wieder auffällt: wäre es nicht sinnvoll, wenn durch Wählen
des aktiven Kanals auch gleich diese Triggerlevelmarke mit zum aktiven
Channel wechseln würde? Wenn ich Kanal 2 auswähle und dann am
Triggerlevel rumdrehe, ändert sich nach wie vor der Triggerlevel von
Kanal 1. Find ich irgendwie umständlich.
/Hannes
Gerade habe ich die neue Firmware geflasht - gibt's eigentlich keine
Möglichkeit, das über USB zu erledigen? Junge, Junge...
Die Kallibrierung:
beim vierten Kanal ist das Rauschen sehr gering gewesen, nach oben
hin(3,2,1) immer stärker...
Ich muss mich erstmal intensiver mit dem Teil beschäftigen (Spruts USB
PIC Brenner z.B. der hat bei mir eine zu hohe Brennspannung...). Die
Anzeige scheint mir aber immer noch sehr langsam. Slog soll ja bis zu
70(!) Frames/s mit dem neuen FPGA-Design hinbekommen...
Heute (gestern) hatte ich auf der Hannovermesse ein LeCroy in Action
gesehen - huuuh, ganz andere Liga, 15k€...
Michel
Hey,
@Slackman: warum das über USB nicht geht, frag ich mich auch jedes
mal...
Hat schon einmal jemand versucht, die neue FW einfach in die Original
Flash reinzukopieren (nach den Bootlader) und dann via original
W2000-update hoch zu laden? Ja ich weiß- original sind S2 Code- Zeilen
mit anderem Adress- Aufbau... war ja nur so ein Gedanke.
Wüsstest du das Lecroy derzeit eine Oszi- Abwrackprämie anbietet (ich
glaub 3000€- für Oszis ab 12k€) da kannst du dir jetzt direkt ein
Schnäppchen holen.
Gruß, brunowe
Johannes Studt wrote:
> Was mir grade wieder auffällt: wäre es nicht sinnvoll, wenn durch Wählen> des aktiven Kanals auch gleich diese Triggerlevelmarke mit zum aktiven> Channel wechseln würde? Wenn ich Kanal 2 auswähle und dann am> Triggerlevel rumdrehe, ändert sich nach wie vor der Triggerlevel von> Kanal 1. Find ich irgendwie umständlich.
Der aktive Kanal muß aber nicht unbedingt der Triggereingang sein! Daher
wäre es ja nicht sinnvoll die Triggersource einfach zu wechseln. Es
kommt ja auch vor, dass auf dem einen Signal getriggert und das andere
begutachtet wird.
Was man natürlich machen könnte, wäre beim Abschalten eines Kanals
gegebenenfalls die Triggersource automatisch auf den nächsten aktiven
Eingang zu legen.
Michael Werner wrote:
> Gerade habe ich die neue Firmware geflasht - gibt's eigentlich keine> Möglichkeit, das über USB zu erledigen? Junge, Junge...
Klar ginge das. War auch schon mal angedacht. Falk und Markus hatten
sich hierzu schon Gedanken gemacht. Da scheint aber noch nichts passiert
zu sein. Ich selbst bin mit USB nicht so gut vertraut und habe mich
daher erstmal auf die Firmware konzentriert.
> Die Kallibrierung:> beim vierten Kanal ist das Rauschen sehr gering gewesen, nach oben> hin(3,2,1) immer stärker...
Ja das sieht bei mir auch so aus. Das fällt einem bei der originalen FW
nur nicht so auf.
> Die Anzeige scheint mir aber immer noch sehr langsam. Slog soll ja bis zu> 70(!) Frames/s mit dem neuen FPGA-Design hinbekommen...
Stimmt, das liegt daran, dass im WELEC (Referenz) NIOS-Design keine
extra Multiplikationseinheit vorgesehen ist (es gibt auch ein Design mit
extra Multiplikator). Nun muß ich aber um die Anzeige genau zu machen
pro Meßwert eine Floating Point Multiplikation durchführen - das kostet
Zeit.
Die original WELEC-Firmware erkauft sich die Geschwindigkeit mit hoher
Messungenauigkeit! Meßt mal die genauen Pegel mit einem geeichten
Multimeter nach, dann wißt Ihr was ich meine. Besonders hoch sind die
Abweichungen in den 2er und 1er Bereichen.
Hier bin ich aber trotzdem dabei noch weiter zu optimieren.
Bruno We wrote:
> Hat schon einmal jemand versucht, die neue FW einfach in die Original> Flash reinzukopieren (nach den Bootlader) und dann via original> W2000-update hoch zu laden? Ja ich weiß- original sind S2 Code- Zeilen> mit anderem Adress- Aufbau... war ja nur so ein Gedanke.
Klar hab ich da schon rumexperimentiert. Leider erwies sich die
WELEC-Software als ziemlich zäh und widerborstig. Alle Möglichkeiten
habe ich hier sicher noch nicht ausgelotet - es besteht also noch
Experimentierpotential. Wenn jemand das hinkriegt, liefere ich die
Flashs auch gerne im WELEC-kompatiblen Format. An den Adressen liegt es
aber glaube ich nicht. Die kann man beim Updater von Markus vor dem
Download in der INI-Datei einstellen und damit eine entsprechende
Testdatei erzeugen.
Falls es nur daran liegen sollte, ist es wohl kein Problem einen
entsprechenden Kommandozeilenkonverter schnell zusammenzuklöppeln.
Gruß Hayo
Hayo W. wrote:
> Der aktive Kanal muß aber nicht unbedingt der Triggereingang sein! Daher> wäre es ja nicht sinnvoll die Triggersource einfach zu wechseln. Es> kommt ja auch vor, dass auf dem einen Signal getriggert und das andere> begutachtet wird.
Hm, da hatte ich einen Denkfehler drin. Ich war irgendwie der Meinung,
dass jeder Kanal unabhängig voneinander getriggert wird, aber das ist ja
Unfug.
> Was man natürlich machen könnte, wäre beim Abschalten eines Kanals> gegebenenfalls die Triggersource automatisch auf den nächsten aktiven> Eingang zu legen.
Das passiert immerhin zwischen Kanal 1 und 2 schon jetzt.
/Hannes
Hi,
erstmal danke für die neue FW - funktioniert soweit gut, vor allem das
mit der Nulllinie freut mich.
Aber eine kleine Frage zum Updater: ist es normal, dass der Flashvorgang
mit Schreibfehlern endet? Das war jetzt mein 2. Updatevorgang, und am
Schluss gabs jedes mal Fehler und Retries. Das Oszi tut allerdings
trotzdem.
Wenn das nur bei mir auftritt werd ich mir die genaue Meldung beim
nächsten mal aufschreiben.
Hallo Hayo,
so, hab mich etwas mit der ADC Kalibrierung gespielt.
Interessant was zu erreichen wäre wenn...
Aber so ganz perfekt ist das Ganze nicht- entweder ist Ch1 ODER Ch2 gut
kalibriert!
Bruno We wrote:
> Hallo Hayo,>> so, hab mich etwas mit der ADC Kalibrierung gespielt.> Interessant was zu erreichen wäre wenn...> Aber so ganz perfekt ist das Ganze nicht- entweder ist Ch1 ODER Ch2 gut> kalibriert!
Ja die Kalibrierung bringt nicht immer die gleichen Ergebnisse. Nach
drei Durchläufen ist sie aber meistens konstant. Die automatische
ADC-Kalibrierung wird übrigens für alle Kanäle durchlaufen wenn die
"Search Zeros" Funktion benutzt wird (und zwar direkt vorher).
Bei der manuellen Kalibrierung läßt sich das für jeden Kanal einzeln
einstellen. In den ersten 15 Schritten (jedes Mal beim Drücken von
shift + Q wird ein Schritt weitergeschaltet) werden verschiedene
Kombinationen durchlaufen - dann kommt als letzter Schritt ein
automatischer Abgleich für den Kanal. Mit shift + Z kann man zum
nächsten Kanal schalten und das Spiel neu beginnen. Wenn man alles durch
hat, kann man das Ergebnis mit shift + O in den protected Bereich
schreiben - dann wird es beim nächsten Start wieder geladen.
Gruß Hayo
..und so lange verwendet wird, bis durch ein Aufruf der "Calibrate Zero
lines" alles wieder überschrieben wird?! ÄCHZ
Mit den möglichen 15 Kombinationen des manuellen Abgleich bekomme ich
den Abgleich des Kanal 1 übrigens nicht so gut hin, wie mit der autom.
Kalibrierung. Es scheint mir als ob die Anpassung mindestens eines ADC
nicht mit den 15 Kombinationen abgedeckt wird- d.h. der max Bereich der
Anpassung reicht für diesen ADC nicht aus.
Schade das die autom. Kalibrierung (auch bei mehrmaligen Versuchen)
nicht für beide Kanäle gleichzeitig zufriedenstellend arbeitet!
Aber die Darstellungen auf meinen obigen Fotos finde ich schon ok...
Wenn jetzt das Optimum des Ch1 mit dem Optimum des Ch2 kombiniert
wäre...
Auf jeden Fall kann ich jetzt gut weitermachen, danke!
Gruß, brunowe
Bruno We wrote:
> ..und so lange verwendet wird, bis durch ein Aufruf der "Calibrate Zero> lines" alles wieder überschrieben wird?! ÄCHZ
Nein, der protected Bereich wird definitiv nur mit shift + O
überschrieben. Dieser Bereich ist eigentlich nur für Factory Settings
vorgesehen - hier steht unter anderem auch die Seriennummer. Wenn ein
Zero-Abgleich durchgeführt wird, dann ist das nur temporär. Beim
nächsten Start werden wieder die Werte aus dem protected Bereich
geladen.
> Mit den möglichen 15 Kombinationen des manuellen Abgleich bekomme ich> den Abgleich des Kanal 1 übrigens nicht so gut hin, wie mit der autom.> Kalibrierung. Es scheint mir als ob die Anpassung mindestens eines ADC> nicht mit den 15 Kombinationen abgedeckt wird- d.h. der max Bereich der> Anpassung reicht für diesen ADC nicht aus.
Sorry, mir waren das einfach zu viele Kombinationen, da hab ich dann die
genommen, die bei meinen beiden Oszis am besten funktioniert haben.
Bei den Einserkombinationen hab ich noch alle sinnvollen genommen, bei
den 2ern hab ich dann nur eine Auswahl verwendet. 3er hab ich garnicht
berücksichtigt, obwohl diese natürlich auch nicht ausgeschlossen sind -
bei mir allerdings nicht auftreten (Bei mir 2110 und 1001).
Nenne mir doch mal die Werte die die automatische Kalibrierung ergibt,
dann kann ich die Kombination mit einbauen.
> Schade das die autom. Kalibrierung (auch bei mehrmaligen Versuchen)> nicht für beide Kanäle gleichzeitig zufriedenstellend arbeitet!
Da ich diese in den Standardablauf mit eingebaut habe sind meine
Möglichkeiten hier erstmal beschränkt - alles Weitere ist in Arbeit...
> Aber die Darstellungen auf meinen obigen Fotos finde ich schon ok...> Wenn jetzt das Optimum des Ch1 mit dem Optimum des Ch2 kombiniert> wäre...> Auf jeden Fall kann ich jetzt gut weitermachen, danke!
Es zeigt auf jeden Fall, dass man hier noch Einiges herausholen kann.
Gruß Hayo
Hallo 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
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
@Guido
In hardware_t.cpp Zeile 3258 - das ist der Buttonhandler
(Suchbegriff Test Funktion 0 Q)
@Bruno
2340 ist aber echt heftig! Da kann ich mir gut vorstellen wie das Signal
unkalibriert aussieht...
Wenn Du in das oben genannte Coding gehst, kannst Du Dir eigene
Kombinationen dazubasteln. Ansonsten werde ich Deine mal mit aufnehmen
für die nächste Version.
Ich habe übrigens gerade festgestellt, dass es nicht 15 Kombinationen
sind, sondern 26 (ich war noch in Gedanken auf dem alten Stand) - die
27igste ist dann Autokalibrierung.
Gruß Hayo
Hallo,
es ist (zum Glück) nicht notwendig das ich im Code herum operiere. Ich
habe via auto calibration den optimalen Abgleich für Ch1 erstellt, dann
manuell den Abgleich für Ch2 durchgeführt und das Ganze mit Shift O
abgespeichert- scheint zu funktionieren. Eine sehr gute Basis fürs
weitere Vorgehen!
Gruß brunowe
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
Genau, am besten ist es immer in den "5er" Messbereichen, also 5V,
500mV, 50mV, am schlechtesten sieht es in den "1er" Messbereichen aus.
Ich bekomme es auch manuell nicht so hin wie Bruno.
Wie ist da eigtl die Vorgehensweise? Aus den Zeilen, die da im Terminal
erscheinen, einen Mittelwert je DAC bilden und dann den Ausgleich
errechnen? Ich hab jetzt nur der Reihe nach alle Kombinationenn
durchgedrückt und geschaut, wo es am hübschesten aussieht.
Irgendwie kommt es mir so vor, als wenn ich da irgendwas noch nicht
begriffen habe. :D
/Hannes
hallo 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
Hallo sunny,
na dann erstmal herzlich willkommen. Vielleicht hast du ja Lust etwas
mit an der HW rumzubasteln? Momentan bin ich anscheinend der Einzigste,
dessen Oszi schon seit Tagen auseinandergebaut am Arbeitsplatz liegt und
für Messungen an Herz und Leber herhalten muss?! Für Unterstützung und
evtl. für Vergleichsmessungen wäre ich durchaus dankbar!
Evtl. meldest dich ja mal via Skype bei mir? Skype- Name: brunowe1
Hallo 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
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
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
Bruno We wrote:
> Ist doch alles in der Liesmich von Hayo's FW, (evtl. in meinen> Messprotokollen- wg. 250MHz Schwingung) und in diversen anderen,> öffentl. verfügbaren Dokumentationen nachzulesen.
Hm, ich hab zu diesem Punkt nix gefunden. Liegt vllt auch daran, dass
ich nicht ein Werkzeug entwickeln, sondern nur Verbesserungen, welche
andere daran vornehmen, verwenden möchte (s.u.) und dementsprechend nur
das Liesmich gelesen und nicht irgendwo im Netz in vielen Dokumenten
dazu nachgeforscht habe.
> Wir haben uns viel Arbeit gemacht alle Info's über die W2000 Oszis in> unserem SF-Wiki abzulegen- nutzt sie.
Versteh mich bitte nicht falsch: ich finde das absolut bemerkenswert,
was ihr hier macht, aber für mich ist das Gerät nicht Selbstzweck,
sondern Werkzeug. Ich helfe gern im Rahmen meiner beschränkten
Möglichkeiten, indem ich zum Beispiel nach einer vorgegebenen
Verfahrensanleitung eine OS-Firmware flashe, ein Paar Testpunkte
abarbeite und dann ein Ergebnis poste, aber mitentwickeln oder auch
nur mich in die Funktionsweise hineindenken möchte ich eigtl nicht.
Darum kann ich die Nachfrage von egberto uneingeschränkt nachvollziehen.
> Noch ne Anmerkung: der etwas kompliziertere Weg des ADC- Abgleich wie> ich ihn oben durchgeführt habe, ist eh nur notwendig wenn mind. ein ADC> soweit aus dem Bereich raus ist, das er mittels Hayo's manuellen> Abgleich nicht korrigiert werden kann.
Ich hab gerade ein paar Fotos gemacht vom Zustand nach dem Einschalten
und vom Zustand nach dem mehrfachen Ausführen von "Calibrate Zero
Lines". Ich finde, das bringt nicht nur nix, sondern verschlechtert
das Rauschen (von den unverändert abweichenden Zerolines mal ganz
abgesehen). Also mache ich entweder etwas grundlegend verkehrt, oder
dort ist ein Wurm drin.
/Hannes
P.S: Fotos poste ich gleich, muss sie nur noch zusammenfügen.
So,
jeweils ein Bild vom Zustand direkt nach dem Einschalten (erstes und
drittes Bild) und vom Zustand nach dreimaligem "Calibrate Zero Lines"
(zweites und viertes Bild) bei unterschiedlicher zeitlicher Auflösung.
/Hannes
Hallo,
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
Hallo
@Guido, ja es sind die selben Wandler. So wie ich das momentan sehe,
werden die ADC nicht extern mit einer Referenzspg. versorgt, sondern
nehmen als Referenz einfach die Hälfte der angebotenen Versorgungsspg.
Wahrsch. kommt diese Abweichung dann einfach durch Bauteilunterschiede
zustande.
@Johannes: Inwieweit die "Calibrate Zero Lines" für die 4 Kanäler gut
arbeitet kann ich nicht beurteilen. Das muss Hayo beantworten. Wenn du
dein erstes Foto mit meinem Foto von oben vergleichst, dann liegt beim
Einschalten dein Rauschniveau in etwa so wie bei mir auf Ch2. Mein Ch1
ist das Optimum (vom analogen Standpunkt aus betrachtet- ohne
nachträgliche digitale Bearbeitung)- da will ich meinen Ch2 in etwa
hinbekommen. Noch mal für alle (die die obigen Post's nicht gelesen
haben) bei meinem Ch1 wurde die Verbindung zum analog- Part der
Schaltung abgelötet- das ±1 Digit an Fehler wird also vom ADC bzw. von
der anschl. digitalen Verarbeitung erzeugt (eher unwahrscheinlich).
Man muss auch nochmal erwähnen das Hayo's aktuelle FW etwas überstürzt
heraus gegeben wurde, um genau diesen Punkt des ADC- Abgleich wenigstens
schon einmal experimentell durchführen zu können. D.h.man muss halt noch
ggf. gewisse Einschränkungen in der Bedienung hinnehmen. Irgendwann wird
dieser manuelle Abgleich der einzelnen ADC bestimmt nicht mehr notwendig
sein- weil ich überzeugt bin Hayo bekommt den autom. Calibrate Zero Line
gut hin!
Gruß, brunowe
Ja, dass du den analogen Teil der Eingangsschaltung abgetrennt hast,
hatte ich zwar gelesen, aber gleich wieder "verdrängt". Sorry. ;-)
Wie kann man sich erklären, dass Nulllage und auch Rauschen in den 5er
und 2er Messbereichen jeweils deutlich besser sind als in den 1er
Messbereichen? Im 1V/div-Bereich habe ich auf Channel 4 aller paar
Sekunden Rauschen im Bereich einer Div-Teilung, m.a.W. 1Vpp, und wenn
ich auf 500mV runterschalte, wird es verglichen damit recht glatt (genau
wie in der anderen Richtung, also bei 2V/div und 5V/div).
Die Nulllage ist bei 5er und 2er MB fast korrekt, bei 1er MB dagegen
ziemlich daneben, und ich kann sie auch mit ShiftW/E nicht verschieben.
/Hannes
Hallo Bruno,
wie hast du eigentlich Slog's Design ins Oszi gekriegt?
Habe ich das so richtig Verstanden?
USB Blaster installieren
Quartus Programmer installieren
Hello_W2000_v0_1_4.sof ins Oszi Programmieren
Jetzt sieht es so aus wie
http://www.mikrocontroller.net/attachment/49782/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
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 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
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
Danke branadic!
Slog's Design verbessert wohl hauptsächlich die Geschwindigkeit weil es
Hardwaremultiplikationen ermöglicht und auch die Abfrage der
Bedienelemente in Harware realisiert. Dadurch wird die CPU stark
entlastet.
http://www.kurts-werkstatt.de/wittig/slog.avi (3,21MB)
Das Video ist in Echtzeit! Man beachte die flüssige Verstellung von
Zeitbasis, Vertikalauflösung und Signallage. Viel mehr kann man
allerdings noch nicht machen, da sich Slog auf das FPGA Design
konzentriert und die Software entsprechend mager ausgerüstet ist
(Messungen sind nicht möglich).
Hier noch ein Foto.
Wieso habe ich nicht die bunten Sample Punkte der ADCs?
Probiert hatte ich
Slog_Project_with_Nios_v0.1.3.zip und
Hello_W2000_v0_1_4.zip
Hallo,
oje, ich weiß gar nicht wo ich mit den Richtigstellungen und Erklärungen
anfangen soll...
Vielleicht vorab noch ein Hinweis: Leute die sich nicht in die
Funktionsweise des Oszi's hineindenken wollen- s.h. Zitat weiter oben-
sollten am besten nicht weiterlesen! ;-)
Also erstmal, nehmt euch doch mal meinen Schaltplan des Oszi's zur Hand:
http://welecw2000a.sourceforge.net/docs/schematics/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
Bruno We wrote:
> Vielleicht vorab noch ein Hinweis: Leute die sich nicht in die> Funktionsweise des Oszi's hineindenken wollen- s.h. Zitat weiter oben-> sollten am besten nicht weiterlesen! ;-)
Ich les trotzdem weiter. Nicht hauen bitte. :D
> Das Umschalten zwischen den Bereichen 5V-2V-1V etc. ist kein SW Trick.> [...]> Anfang ist relativ problemlos und muss nicht weiter beachtet werden.
Klar.
> So, wie geschieht nun die Umschaltung zwischen 50mV, 20mV und 10mV? Auch> [...]> Soweit findet in diesem Bereich also (abhängig vom Messbereich) ein 1:1;> 1:2 oder 1:4 Verstärkung statt-
Also wird das Rauschen hauptsächlich von diesen OPV und vllt noch den
elektronischen Schaltern bestimmt?
> ob jetzt durch einen weiteren Kniff das wieder zu 1:2:5 hingebügelt wird> wollte ich noch prüfen, glaub es aber eigentl. nicht.
D.h. dort wird dann das 1:4-Rauschen in Software auf 1:5 erhöht,
deswegen sieht das auch unverhältnismässig größer aus als bei 1:2?
Es ist übrigens schön, wenn einem das mal ein Berufener so erklärt, dann
versteht man auch gleich was (oder man beginnt wenigstens damit). In die
Schaltung allein habe ich geguckt wie die sprichwörtliche Sau ins
Uhrwerk.
Jetzt muss ich nur noch irgendwie die Trennlinie bzw. das Zusammenspiel
von dem, was Hayo macht mit dem, was Slog da bearbeitet, begreifen.
/Hannes
Hallo 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
Hallo Guido,
das mit dem Verstärkung des OPA656 war mir noch nicht ganz klar- (das
mit der Frequenzgangkompensation schon). Wie kommst du auf 1:1,25?
Klär uns doch mal über die Fkt. des OPA656 auf...
Alter Schwede hier ist ja was los...
Ich dachte ich hätte in diversen älteren Beiträgen schon mal auf den
Grund des unterschiedlichen Rauschens hingewiesen. Allerdings gebe ich
zu, dass es auch etwas nervig ist alle alten Beiträge durchzuforsten.
Daher möchte ich hier ergänzend zu Brunos Ausführungen mit wenigen
Worten die Problematik erklären:
- die einzelnen Stufen haben durchaus jede Ihre eigene
Spannungsvorteilung (wie Bruno ja auch schon anmerkte - kein Fake also)
- die Übersetzung ist jedoch so (unglücklich) gewählt, dass in den
unterschiedlichen Stufen bei der Grafikausgabe unterschiedliche
Skalierungsfaktoren nötig sind.
- bei den 5er Bereichen ist der Skalierungsfaktor ca. 2, bei den 2er und
1er Bereichen ist er ca. 3,3
D.h. wenn die Offsetabweichung eines ADC 3 ist (z.B. 3012 oder 0321),
dann stellt sich das in den 5er Bereichen mit eine Peak von 6 Pixeln
dar, wärend sich das in den anderen Bereichen mit einem Peak von 10
Pixeln darstellt.
Das ist schon ein deutlicher Unterschied.
Gruß Hayo
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
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
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
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
@Guido
ja das hatte ich ohnehin vor, aber da Bruno gerne schnell testen wollte
hab ich die Version etwas unfertig rausgehauen...
Wie ich sehe hast Du auch schon schön nach einzelnen Spannungsstufen
getrennt, kann ich dann ja so 1:1 übernehmen - spart Zeit ;-)
Danke und Gruß Hayo
Hallo,
habe mal eine Frage zur PC Software. Wie kann ich die gespeicherten
Messwerte bzw. Kurven mit der PC Software übertragen. Ich kann nur die
aktuelle Kurve in den PC laden.
Werde dann auch mal die FW1.2.BF.0.50 nach Flashsicherung aufspielen.
Aber das kann ja bekanntlich dauern...
Gruß
Ronny
Die Version FW1.2.BF.0.50 läuft auf meinem W2024A sehr gut. Habe dann
mal die FW1.2.BF.0.54 aufgespielt und das Nullinien-Rauschen war nach
einem "Calibrate Zero Lines" erheblich stärker auf Kanal 1-3, Kanal 4
war besser. Werde jetzt erstmal die vorige Version aufspielen und das
nochmal versuchen. Mauellen Abgleich der ADCs habe ich nicht
vorgenommen.
Gruß
Ronny
Nach Aufspielen der FW1.2.BF.0.50 und "calibrate zero line" ist das
Nullinien-Rauschen bedeutend geringer als mit FW1.2.BF.0.54, Kanal 3 ist
am Besten.
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
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
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
Guido schrieb:
> @ Johannes: Nö, ne knappe halbe Stunde brauche ich noch zum> Flashen, habe als Linuxer aber extra (naja, nicht ganz ernst> nehmen) ein Laptop mit XP gekauft.
Hm, ich hab bisher mit dem fwupload.pl rumprobiert (bekomme ich nicht
ans Rennen) und dann in einer Virtualbox mit USB->RS232-Adapter. Das
funktioniert, dauert aber ca. 1,5h.
Auch auf die Gefahr hin, dass ich wieder darauf hingewiesen werde, dass
das alles schon mal schön übersichtlich irgendwo beschrieben steht: wie
muss das Oszilloskop auf das Schreiben der Zeilen der Firmwaredatei
antworten? Bei mir sagt das irgendwie keinen Mucks, deswegen bleibt
offenbar auch das fwupload.pl stehen und wartet bis zum
St.-Nimmerleins-Tag.
/Hannes
Johannes Studt schrieb:
> muss das Oszilloskop auf das Schreiben der Zeilen der Firmwaredatei> antworten? Bei mir sagt das irgendwie keinen Mucks, deswegen bleibt> offenbar auch das fwupload.pl stehen und wartet bis zum> St.-Nimmerleins-Tag.
Kaum sucht man nochmal, findet man plötzlich was: ein + sollte da
auftauchen, das ist wohl der Prompt des GERMS-Monitors. Eben schreibe
ich deine Flash-Datei mit Minicom ins Oszi, mal sehen, wie lange das
dauert.
/Hannes
Na juchhu aber auch. Eben hab ich bemerkt, dass der Welec-Updater von
Markus ja auch für Linux verfügbar ist. Nachdem ich jetzt bissi mit
Lazarus und Freepascal rumgezappelt habe, läuft das Ding hier
einwandfrei.
Das Leben ist schön. :D
/Hannes
P.S: ich liebe Monologe.
Johannes Studt schrieb:
> Guido schrieb:>> Lust zum Testen hat ist eine Rückmeldung erwünscht. Ich habe nach>> ca. 30 Flashvorgängen kein Gefühl mehr dafür wie es vorher war.>> 30? Dauert das nur bei mir so lange, oder hast du jetzt echt ca. 40> Stunden dem Flashen zugeschaut?
Hab jetzt über 100 Flashvorgänge hinter mir. Dauert ca. 21 Minuten pro
Durchlauf - allerdings mit echtem RS232 (auch an langsamen Rechnern).
Ich hatte unter Linux einen Kommandozeilenuploader entwickelt, der hat
es in 2 bis 3 Minuten geschafft, allerdings nicht zuverlässig genug. Da
hab ich dann irgendwann aufgehört und den WELEC-Updater genutzt, der ist
wenigstens zuverlässig.
Gruß Hayo
Johannes Studt schrieb:
> Na juchhu aber auch. Eben hab ich bemerkt, dass der Welec-Updater von> Markus ja auch für Linux verfügbar ist. Nachdem ich jetzt bissi mit> Lazarus und Freepascal rumgezappelt habe, läuft das Ding hier> einwandfrei.>> Das Leben ist schön. :D>> /Hannes>> P.S: ich liebe Monologe.
Ich mach das jetzt mal zum Dialog:
Die Linux-Version läuft bei mir mindestens zehnmal länger als die
Windowsversion. Wie ist das bei Dir?
Gruß Hayo
Da hab ich keinen echten Vergleich, weil ich die Windowsversion
ebenfalls unter Linux in einer XP-VM (und das zu allem Überfluss auch
noch mit dem USB->RS232-Adapter) laufen hatte. In dieser Konstellation
haben sie beide ca. gleich lange gebraucht.
Ich hatte bisher angenommen, dass das DSO der Part ist, der bremst, weil
ja der Welecuploader nix anderes macht, als auf das '+' zu warten und
dann sofort die nexte Zeile abzuwerfen.
Jetzt werd ich mal das Notebook meiner Frau zünden und mit der dort noch
anwesenden echten RS232-Schnittstelle Vergleiche anstellen.
/Hannes
Ja, das kannste vergessen. Am Notebook meiner Frau benimmt sich das DSO
bockig. Nach ca. 15% bricht die Datenübertragung ab und der Welecupdater
wartet, bis die Elbe austrocknet. Bis kurz vor den Hänger meint er, er
würde ca. 52 Minuten brauchen wollen (Windowsversion).
Ich werd's jetzt nochmal mit einer Linux-LiveCd versuchen.
Ja, ich habe ähnliche Erfahrungen gemacht. Ich habe unter Windows keinen
kompletten Download zustande gebracht(auf zwei verschiedenen Laptops
getestet). Unter Linux hat es dann geklappt, wenn auch etwas langsamer.
Der Upload klappte problemlos auch unter Windows.
Uwe
@Guido
Ich bin gerade dabei die Erkenntnisse der letzten Tage in die aktuelle
Version einfließen zu lassen. Deine Erweiterung der Testfunktion 1 + 2
hab ich unverändert übernommen. Die Änderung der Flashroutine hab ich
nicht übernommen, da die Zero-offsetwerte schon im normalen
Configbereich des Flash gespeichert werden. Eine weitere Speicherung im
Protected-Bereich ist also nicht nötig.
Insbesondere implementiere ich gerade die neue Integerscalierung - der
Upload läuft noch - ich bin gespannt was rauskommt.
Ansonsten beisse ich mir zur Zeit die Zähne daran aus diesen blöden
Freeze-Fehler zu finden der das Signal bei Zeitbasen größer 5ms
einfrieren läßt. Immerhin hab ich das Problem schon soweit eingekreist,
dass ich weiß, das ich mir den Bug zwischen version 0.32 und 0.33
eingebaut habe. Es kommt einfach vom ADC kein Data-Available-Signal mehr
an. Die berühmte Nadel im Heuhaufen...
Ich halte Euch über die Fortschritte auf dem Laufenden.
Gruß Hayo
Upload ist fertig,
erstes Ergebnis: Super! Genauigkeit ist genau wie bei der Floating-Point
Skalierung, aber die Geschwindigkeit ist im Einkanalbetrieb so schnell,
dass ich die Anzahl der Bildwiederholungen nicht mitzählen kann für
einen Vergleich.
Gefühlt würde ich sagen 2 - 3 Mal schneller.
Gruß Hayo
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 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
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
Nach meinen Vorankündigungen hier die aktuelle Beta. Neu ist die rein
integerbasierte Grafik, die entsprechend schnell geworden ist. Angepasst
ist die normale Siganlausgabe, der delayed Modus und die XY-Darstellung.
Die erweiterte Testfunktion 1 + 2 für den manuellen Nullabgleich von
Guido ist auch schon drin (ungetestet).
Morgen (bzw. heute) werde ich mich mal weiter dran machen und den blöden
Freeze-Bug suchen, damit ich mal endlich dazu komme die FFT weiter zu
machen.
guats Nächtle
Hayo
Hallo Hayo,
die Geschwindigkeit ist schonmal super. Vor allem im XY-Modus!
Wenn ich da jedoch die Vektordarstellung abschalte, verschwindet der
Nullpunkt.
Kurt Bohnen schrieb:
> Wenn ich da jedoch die Vektordarstellung abschalte, verschwindet der> Nullpunkt.
Danke für die schnelle Rückmeldung. Fehler ist schon lokalisiert, da ist
mir doch wieder so ein typischer copy and paste Fehler durchgegangen.
Ist in der nächsten Version beseitigt.
Gruß Hayo
Hallo,
ich bin seit einiger Zeit Besitzer eines W2014a und verfolge die
Entwicklung hier aufmerksam.
Ich habe gerade die Beta V0.55 ausprobiert. Der Unterschied in der
Darstellungsgeschwindigkeit ist echt beeindruckend.
Bezüglich des Flashens will ich mal meine Erfahrungen darstellen. Das
Flashen dauert bei mir ca. 15-20 min auf einem System mit Win XP und
einem USB-RS232-Adapter der Firma systec-electronic. Mit der "normalen"
RS232-Schnittstelle habe ich keine Verbindung mit dem Oszi bekommen.
Viele Grüße
Kristian
Hallo,
Kristian da kannst du dich glücklich schätzen- ich bin froh wenn ich's
so in 4-5 Std. hin bekomme- ist jedes mal ne Nacht füllende Aktion.
(Mit Delock Adapter USB to seriell)
Noch ein paar Fragen an die Programm-Kundigen:
Ich spiel mich gerade mit dem DAC Abgleich.
1.) Was bedeuten den die Zeilen:
CH1 Zero Sign Offs 1 = 2<\n>
CH1 Zero Sign Offs 2 = 0<\n>
CH1 Zero Sign Offs 3 = -1<\n>
(sind das die abgelegten DAC Werte für die Messbereiche 1:2:5 ?)
Irgendwie kann ich bei Shift +W bzw. auch bei Shift +E keine Änderung am
Welec Display erkennen (wohl aber an der Terminal Ausgabe)- schade- ich
hab da einen echt groben Offset.
Schön wäre es, die "Zero Level Werte" direkt eingeben zu können - für
jeden der Messbereiche 1:2:5er extra.
Sobald ich Cal. Zero lines durchführe, ist der offset zwar korrigiert,
aber leider auch meine Optimierung der ADC's futsch.
2.) Was hat den der Enable Debug mode für einen praktischen Nutzen?
3.)Was bedeuten den die Zeilen beim Start des Oszi, die auf dem
seriellen Terminal ausgegeben werden, speziell folgende:
...
Volt_Correct_float = 1.625<\n>
Scale Factor = 3.250<\n>
CH1_DAC_Offset = 8194<\n>
multi_active = 1<\n>
Auf dem Hardware Sektor gibts auch Neuigkeiten- werde ich später im HW
Thread posten.
Gruß, brunowe
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
He Folks,
erst mal abwarten. Ich hab mich in den letzten Tagen ordentlich
reingekniet um die Jungs an der Hardwarefront zu supporten. Nachdem ich
den ADC-Abgleich etwas nachlässig implementiert hatte, hab ich jetzt
Nägel mit Köpfen gemacht und einen Abgleich gemacht der für alle vier
Kanäle zuverlässig arbeitet. Weiterhin bin ich noch am DAC-Abgleich
zugange. Die Graphikausgabe hab ich nochmal optimiert, so dass die
Skalierung jetzt ganz ohne Multiplikation auskommt (merkt man im delayed
Modus).
Als Schmankerl hab ich die bisherigen Testschalter ins Utility-Menü
gelegt, so dass man sie bequem betätigen kann auch ohne Terminal
(ADC-Abgleich, DAC-Abgleich, Gridumschaltung, Graphikmodusumschaltung).
Die neue Version gibt heute Abend - mal sehen wie weit ich noch komme.
Gruß Hayo
@Hayo- das hört sich ja Spitze an!
@Guido: ich glaube du verwechselst da ADC Abgleich mit dem DAC Offset-
Abgleich!
Wie gesagt, den ADC Abgleich der einzelnen ADC pro Kanal hab ich jetzt
soweit im Griff, nur der generelle Offset stimmt eben nicht.
CH1 Zero Sign Offs 1 = 2<\n>
CH1 Zero Sign Offs 2 = 0<\n>
CH1 Zero Sign Offs 3 = -1<\n>
Diese 3 Werte können nicht die ADC Kalibrierungswerte der 4! ADC 's
sein, schon eher die DAC Offset Werte wie ichs vermute.
Gruß, brunowe
Bruno We schrieb:
> Wie gesagt, den ADC Abgleich der einzelnen ADC pro Kanal hab ich jetzt> soweit im Griff, nur der generelle Offset stimmt eben nicht.> CH1 Zero Sign Offs 1 = 2<\n>> CH1 Zero Sign Offs 2 = 0<\n>> CH1 Zero Sign Offs 3 = -1<\n>> Diese 3 Werte können nicht die ADC Kalibrierungswerte der 4! ADC 's> sein, schon eher die DAC Offset Werte wie ichs vermute.
Diese Werte sind die Offsetkorrekturwerte für die DACs, die den
Nullpunkt der Eingangs-OPVs steuern. Pro Kanal gibt es drei Werte, und
zwar immer für alle 5er Bereiche (Nr. 3) für aller 2er (Nr 2) und die
1er (Nr. 1).
Der DAC wird von 0 bis 16384 ausgesteuert, die Mitte des Grids liegt bei
8192 (idealerweise). Der Offset korrigiert mit einem entsprechenden
Faktor diese Nulllage.
Bin mit dem DAC-Abgleich schon recht weit, teste nur noch kleinere
Änderungen.
Die 0.56 gibts dann nachher...
Gruß Hayo
So hier ist sie, bin mit dem DAC-Abgleich nicht ganz fertiggeworden.
Aber seht selbst - geht nach dem flashen einfach mal ins Utility Menü
und probiert es aus. Wenn Ihr die ADC-Werte sehen wollt die der
Abgleichermittelt, dann müßt Ihr ein Terminalprogramm laufen lassen, da
werden dann die ermittelten Werte ausgegeben.
Ansonsten wie gesagt habe ich die Grafikroutine nochmal beschleunigt -
sieht man im Normalbetrieb nicht so deutlich, aber im Delayed-Mode wo ja
doppelt so viele Signale geschrieben werden merkt man es schon.
Viel Spaß
Hayo
Bin immer noch am DAC-Abgleich. Leider ist das ziemlich Zeitaufwändig,
da man nach jeder Kleinigkeit die man testweise ändert warten muß bis
die Firmware wieder geladen ist bevor man weitermachen kann. Bin aber
schon recht weit.
Übrigens geht der DAC-Abgleich schon so ein bißchen wenn man vorher die
Nulllage des entsprechenden Kanals auf die Mitte des Grids stellt.
Hat es schon jemand ausprobiert?
Gruß Hayo
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
Guido schrieb:
> Hallo Hayo,>> ich habe letzte Nacht noch schnell probiert, aber ohne Erfolg.> Ich hatte übersehen, dass die Linien in Schirmmitte sein> müssen und so hat jeder Tastendruck den Offset um 1 div nach> unten verschoben. Geht das momentan nur für Kanal 1 oder wie> kann man umschalten?
Nein, geht für alle Kanäle gleichzeitig.
> Aufgefallen ist mit, dass dieser Abgleich> jetzt eh nur noch für die 1er Bereiche nötig sind die 2er> stimmen nach AutoZero im 5er Bereich auch. Zufall?
Nein, hab an der ursprünglichen Zero-Routine auch ein paar Kleinigkeiten
geändert.
Die Search Zero und die Calibrate DAC Funktion haben zwar das gleiche
Ziel, arbeiten aber völlig unterschiedlich. Ich bin mir noch nicht ganz
sicher, ob Calibrate DAC die alte Funktion komplett ersetzen wird oder
nur für's Feintuning als Zusatzfunktion bleibt. Mal sehen.
Gruß Hayo
Hallo Hayo,
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
Hallo Hayo,
Neue FW- Spitzenarbeit!!!
Super, mit dem erweiterten Menü- so stell ich mir das vor!
Jetzt noch den DAC Offset hinbügeln und dann "Beta" aus der Bezeichnung
streichen.
Also auch mein Rauschen ist, bedingt durch den tollen ADC- Abgleich,
wesentl. besser. (Seltsamerweise Kanal 1 jetzt viel besser als Ch2-
liegt auch tw. an meiner kleinen HW Modifizierung- lass mich bitte in
dem Glauben!)
Soweit ich's bisher testen konnte, echt erstklassige Arbeit von dir!
Gruß, brunowe
Hm,
bei mir wird das Rauschen immer nur schlimmer. Sobald ich die "Search
Zero Lines"-Funktion verwende, bekomme ich Rauschen im Bereich von einem
halben bis zu einem ganzen Div, je nach Messbereich und
Erwärmungszustand. Schlimm sind v.a. die Kanäle 3 und 4.
"Calibrate ADC" verändert an der Intensität des Rauschens im Grunde nix,
es verändert nur ein wenig die Form.
"Calibrate DAC" lässt die Nulllage je nach Messbereich mit jedem
Tastendruck um bis zu ein Div nach unten wandern, auch wenn ich vorher
die Nulllage aller Kanäle auf die Mitte drehe. "Search Zero Lines" fängt
das wieder ein, allerdings habe ich trotzdem auf den Kanälen 3 und 4
immer ein negatives Offset.
Mit dem Offset könnt ich leben, aber das Rauschen macht das Gerät in
meinen Augen ziemlich unbenutzbar.
Hallo,
frei nach dem Motto: "ein Bild sagt mehr als tausend Worte"
Meine aktuellen Rauschpegel mit der neuen FW nach ADC Calibration.
Probe- Klemme auf Gnd.
Hallo,
vielen Dank für die neue Firmware.
Bei meinem 2014A liegen die Kanäle 3 und 4 auch immer im negativen
Bereich (Kanal 3 ca. 500mV, Kanal 4 ca. 1V).
"Calibrate DAC" führt bei mir auch zu einer Verschiebung der Signale in
den negativen Bereich. Dies scheint aber stark vom jeweilig
eingestellten Spannungsbereich abzuhängen.
Das Rauschen erscheint bei mir (zumindest für Kanal 1 und 2) deutlich
verringert.
Bei mir fehlt die blau 3 neben der Anzeige der V/Div für Kanal 3. Die
Beschriftungen der anderen Kanäle sind vorhanden.
Gruß
Kristian
Ich krieg hier noch die Krise...
Muß erstmal etwas Frust ablassen, Hrmpf. Da tut die positive Rückmeldung
von Euch ganz gut. Bin immer noch an dem besch... DAC-Abgleich. Um die
Situatuion kurz zu schildern:
Vor dem Abgleich wird per Coding alles auf die Nulllinie (Gridmitte)
gefahren, dann der Abgleich durchgeführt. Trotzdem bleibt ein
Restoffset. Wenn ich die Nulllinien manuell auf die Gridmitte einstelle
klappt alles ordentlich. Ich hab alles dazwischen gecheckt und auch
schon eine Verzögerung eingebaut weil ich mir dachte dass die DACs
eventuell nicht schnell genug regeln - hilft nix.
Morgen hab ich leider nicht viel Zeit dafür, daher hier erstmal die
inoffizielle beta 0.57 nur als Flash zum ausprobieren.
Wie gesagt, wenn die Nulllinien auf Gridmitte sind reichen 2 - 3mal
Drücken und die die Lage stimmt. Bitte zu beachten:
- es wird zur Zeit nur der aktuell eingestellte Bereich
(1er, 2er oder 5er) calibriert.
- das Ergebnis wird zur Zeit noch nicht ins Flash geschrieben.
Gruß Hayo
Kristian Trenkel schrieb:
> Bei mir fehlt die blau 3 neben der Anzeige der V/Div für Kanal 3. Die> Beschriftungen der anderen Kanäle sind vorhanden.
Ja das passiert bei mir aber auch mit der aktuellen 1.4 FW von Welec. Da
das allerdings erstmal von der Prio her weit hinten rangiert werde ich
das noch nicht in Angriff nehmen (es sei denn ich stolpere zufällig
darüber.
Zur Zeit gibt es folgende Prio:
1. DAC-Abgleich
2. Den Freeze-Bug finden den ich mir in Version 0.33 eingebaut habe
(Signal friert ein bei Zeitbasen > 5ms)
3. FFT einbauen -> damit hat eigentlich vor einem halben Jahr alles
angefangen, aber bei all den Ungereimtheiten bin ich immer noch nicht
dazu gekommen...
Gruß Hayo
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
Darum habe ich auch jetzt meinen W2024 innerhalb des 14Tage
Rückgaberecht wieder zurückgeschickt. Bei mir war das Gleiche, das
Rauschen nahm nur zu. Hoffe für Euch, das Ihr das in den Griff bekommt.
Ich bin raus...
Ronny Schmiedel schrieb:
> Darum habe ich auch jetzt meinen W2024 innerhalb des 14Tage> Rückgaberecht wieder zurückgeschickt. Bei mir war das Gleiche, das> Rauschen nahm nur zu. Hoffe für Euch, das Ihr das in den Griff bekommt.> Ich bin raus...
Na sowas, das muß man sportlich sehen. Da ist halt recht viel
Optimierungspotential ;-)
Gebe allerdings zu, dass für professionelle oder semiprofessionelle
Anwendungen die WELECs nicht die erste Wahl wären. Aber für Hobbybastler
und Optimierer super bei dem Preis. Wenn ich jetzt auch noch Geld dafür
kriegte müßte ich mich nicht mehr "nebenbei" für SAP krumm machen.
@Hannes
warum macht Ihr eigentlich immer Bilder vom 10ns Bereich? Da muß man in
Gedanken immer die interpolierten Werte rausrechnen um sich ein Bild des
Werteverlaufs zu machen. Der 50ns Bereich ist da ideal, weil er die
Werte 1:1 wiedergibt bei voller Samplerate.
Gruß Hayo
Weil Bruno das so macht und ich keinen Plan habe, was für wen warum auch
immer am besten ist.
Sprich: hier einfach der Vergleichbarkeit der Bilder wegen.
Normalerweise[TM] mache ich auch andere Bilder.
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
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
@ 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
Hallo,
der Grund warum ich Fotos im 10ns Bereich mache ist eigentl. ganz
simpel: ich hatte lange Zeit (und habe tw. immer noch) massive Probleme
mit HF Schwingungen, eben auch mit dem ADC Abgleich und mit einer NF
Überlagerung bei offenen Eingängen. Bei 50ns ist es sehr schwer eine
eine HF Frequenz auszuzählen und eine Regelmäßigkeit zu erkennen. Das
mit den interpolierten Werten stellt kein Problem bei 10ns dar, erstmal
geht es ja um die Minimas und Maximas der Anzeige- und die sind auf
keinen Fall interpoliert. Darüber hinaus fällt es bei 10 ns leichter die
Anzahl der wirklichen Sprünge abzuschätzen, also um wieviele Bit des ADC
die Anzeige des Display sich wirklich ändert. Als letztes möchte ich
auch das Verstärkerrauschen mit untersuchen, das ist nach bisherigen
Erkenntnissen in den 1er Messbereichen am grössten.
@Guido:
Ich antworte dir im HW Thread.
Gruß, brunowe
Ich bin echt beeindruckt!
Es ist schon genial, was hier die Entwickler und Tester auf die Beine
stellen. Mich juckt es ja so sehr, ebenfalls einen Welec zu ersteigern.
Aber ich habe für mein Hobby bereits einen Agilent 54622D und ich
vermisse bei dem Welec einfach die 16 digitalen Kanäle, ohne die ich
nicht leben könnte :)
Trotzdem mal ein paar Ideen für die ganze Offset/Zeroing Problematik,
gerade weil ich diesen Abgleich vom Agilent her ein wenig kenne.
Allerdings habe ich für dieses Gerät, trotz Vorzugspreis und so weiter,
einen aus Hobby-Sicht stolzen Preis bezahlt und es daher noch nicht
geöffnet.
Der Agilent fährt bei einer User-Calibration ein recht aufwändiges
Muster an Kurven durch, dem man auch zuschauen kann. Wenn Euch das
hilft, versuche ich mal davon ein Video zu machen. Es sind wohl einige
unter Euch, die aus den dargestellten Mustern rückschließen können, was
da eingemessen wird.
Was ich bei dem Welec bislang vermisse, ist ein Referenz-DAC, der zur
Kalibration aller anderen verwendet werden kann. Ist der noch irgendwo
verborgen, oder wurde der tatsächlich eingespart? Oder gibt es bei den
verschiedenen Multiplexern eventuell eine Stellung in der sie auf 0 und
eine, in der sie auf eine Vref geschaltet werden können? Dann kann man
eventuell den Gain-DAC dazu verwenden, die OVs auszumessen.
Es wundert mich doch sehr, dass es notwendig ist, die Strahlen auf Mitte
zu bringen, bevor man eine ZeroCal durchführen kann.
Eine softwaretechnische Frage wäre dann noch, ob der Welec seine
Software aus dem FLASH laufen lässt, oder ins RAM bootet und dort dann
arbeitet. Für die Entwickler wäre die Idee, einen weiteren Bootloader zu
schreiben sicherlich sehr hilfreich, der originiale scheint, ehrlich
gesagt, Murks zu sein. Das Flashen von 8MB dürfte nicht länger als max.
4min dauern.
Sollte sich jemand daran wagen, dann wäre es wohl sinnvoll, den
Bootloader ins RAM zu kopieren, große Blöcke ins RAM zu laden und von
dort aus zu flashen. Bitte beachtet dabei, dass die Toggle-Bits einiger
AMD/Spansion und Kompatibler erst nach ein paar ms gültig sind. Ist eine
Falle, die das Flashen enorm verlangsamen kann, wenn man diese zu früh
abfragt und dann in eine Fehlerbehandlung rennt, die nicht nötig ist.
Ich meine MX gehört zu den Spansion kompatiblen. Wenn das ganze ins RAM
kopiert wird, dann sollte der Bootloader das auch unterstützen, damit
man eine Software auch ohne Flashen mal schnell ausprobieren kann.
Hat jemand eine Info, in wie weit diese Scopes noch nachgefertigt
werden? Wenn Welec/Wittig nur noch Restbestände abverkaufen, und alles
deutet darauf hin, dass nur noch die Retouren aufgearbeitet und
abverkauft werden, was dann? Die Arbeit ist auf keinen Fall vergebens,
aber es wäre sicherlich besser, wenn man länger was davon hätte, auch
wenn ich nicht weiß, ob sich ein OpenSource Oscar auf dem Markt
durchsetzt.
Allerdings wäre das doch sicherlich ein interessantes Geschäftsmodell
für Wittig um seinen Laden zu retten. Ich hatte eigentlich gehofft, dass
er sich mehr für das Projekt einsetzen würde. Nun, auf der Sourceforge
Seite angekündigte Bereitstellung von Mustern an die Maßgeblichen
Entwickler ist ein Schritt in die richtige Richtung.
Ich verfolge das auf jeden Fall mal weiter, vielleicht kann ich mein
Hobby-Budget mal wieder aufstocken :)
Gruß, Ulrich
@Guido
wg. des Freeze-Problems bräuchtest Du die Sourcen der 0.32 und 0.33, da
läßt sich das am einfachsten herausfinden da ein direkter
Sourcenvergleich möglich ist. Guckst Du im Anhang...
Der Fehler ist mit Sicherheit in der Hardwareroutine zu finden, denn die
Grafikausgabe wird, wie ich schon rausgefunden habe, korrekt durchlaufen
- die Drehgeberroutinen übrigens auch. Der Grund warum keine neuen Daten
gelesen werden ist sekundär, dass das ADC_Data_Available Flag nicht
gesetzt wird und dann auch der ADC nicht ausgelesen wird (Handle_ADC()
Zeile 19418). Warum es aber nicht mehr gesetzt wird, das versuche ich
rauszukriegen. Müßte eigentlich eine Änderung sein die ich mit BF
gekennzeichnet habe.
@Bruno
ok, das kann ich einsehen. Für meine Zwecke benutze ich meistens die
50ns Einstellung da ich hier immer alle realen Punkte ohne Zommfaktor
zur Verfügung habe (deswegen hab ich auch das Freeze-Problem nicht
bemerkt).
@Ulrich
Mußte Deinen Beitrag noch ein zweites Mal lesen, da er so lang war, dass
ich am Ende nicht mehr wußte was am Anfang stand (Altersbedingt).
Also zum Bootloader: Das Programm läuft natürlich im RAM. Beim
Anschalten des DSO wird ein kleines Bootloaderprogramm aus dem Flash
geladen (steht an Adresse 0x00040000) dieses kopiert dann den Rest der
Firmware ins RAM (Adresse 0x00800000), von wo es dann gestartet wird.
Zur Flashgeschwindigkeit: Klar, ich hab es mit einem selbstgeschriebenen
Linux-Kommandozeilenprogramm in 3 Minuten geschafft. Leider war mir das
Programm nicht zuverlässig genug, da hab ich dann lieber das von Markus
genommen. Anscheinend ist es nicht so einfach ein RS232
Übertragungsprogramm zu schreiben, das auf allen Rechnern gleich gut
funktioniert (liegt wohl auch am Hardware Abstraction Layer). Bin aber
ganz froh, dass es überhaupt so gut funktioniert.
Zudem hatte ich anfangs auch nicht vermutet dass es sooo viel zu tun
gibt und ich innerhalb kürzester Zeit auf weit über 100 Uploads komme.
Zu den Abgleichkurven: Ja, immer her damit. Ich laß mich gerne von
Profilösungen inspirieren.
Gruß Hayo
@Ulrich
Ach ja, eins hatte ich noch vergessen, der Trend geht zum Zweitwelec ;-)
Da kann man schön vergleichen und kann auch mal eins zerlegen.
Gruß Hayo
Ok, kürzer :)
Hoffe ich kann das Video mit meiner kleinen WebCam ordentlich hin
bekommen und irgendwo hin uploaden.
Ich denke, dass es nötig ist, den Bootloader so zu erweitern, dass man
auch direkt ins RAM schreiben kann, falls das nicht ohnehin schon
unterstützt wird, damit man eine neue Software direkt testen kann (
Flashloader überspringen). Wegen der fehlenden FlashErase und
Schreibzyklen sollte das weit unkritischer sein und damit auch
unkritischer für die serielle Kommunikation. Wurde auf Seite des Wittig
eventuell das RTS/CTS Handling übersehen, oder hat der diese Leitungen
nicht angeschlossen?
Gruß, Ulrich
Ulrich P. schrieb:
> Es wundert mich doch sehr, dass es notwendig ist, die Strahlen auf Mitte> zu bringen, bevor man eine ZeroCal durchführen kann.
Das liegt daran, das ich einen anderen Ansatz verfolge als die Routine
von WELEC. Ist eigentlich ganz simpel. Ich prüfe einfach bei offenen
Eingängen die ADC-Werte. Diese müssen bei GND 127 betragen (oder 128 je
nachdem wo man die Nullinie hinlegt). Ich ermittle also nur die
Differenz zu den 127 und korrigiere dann den DAC-Wert um die Differenz
und einen Faktor. Da aber nur bei DAC-Nulllage auch 127 rauskommt, muß
ich vorher die DACs in die Nulllage fahren. Übrigens wird kein absoluter
Korrekturwert ermittelt, sondern der von der Search Zero Routine
ermittelte Wert wird nach oben oder unten korrigiert - ein Feintuning
sozusagen.
Gruß Hayo
egberto schrieb:
> Anfängerfrage (nicht hauen!) - womit commpiliert ihr das eigentlich?>> Was muß ich mir dafür installieren?
Du brauchst ein Linux-System dafür. Kann man ganz easy zusätzlich zum
Windows installieren. Bei mir hat es mit Open SUSE prima hingehauen (War
auch Linux-Anfänger). Ich hatte auch schon mal ein how to geschrieben,
ich hänge das hier nochmal an.
Viel Erfolg
Hayo
Ok, ich hatte jetzt noch nicht die Zeit die Datenblätter der DACs und
ADCs durch zu arbeiten. Aber normalerweise ist doch ein signed bei
0..127 positiv und bei 128..255 negativ, wobei 128 der -1 entspricht.
Allerdings nur, wenn man die Wandler ensprechend einstellt. Ich habe die
ganzen Threads innerhalb eines Tages durchgelesen, und meine mich
erinnern zu können, dass die Eingangsstufen die Messpannung auf
Wandlermitte anheben, also wird nur positiv gemessen.
Die Zero-Linie bei offenem Eingang zu messen halte ich für kritisch, da
die OVs der Eingangsstufe dann frei laufen. Gibt es keine Option, die
Stufe auf GND zu schalten? Das wäre schon mal ein Anfang. Optimaler wäre
es sicherlich, die Gesamtaussteuerung zu durchlaufen und dann die Daten
zu mitteln. Dazu müssten aber wenigstens die DACs für das GAIN halbwegs
kalibriert sein. Gibt es denn in dem ganzen Scope keine einzige
brauchbare Referenz aller Kanäle gemeinsam?
Nochwas zum HP. Er führt die User-Calibration offenbar unter
Berücksichtigung der eigenen Temperatur durch, diese vermerkt er
jedenfalls in den Logdaten zur Cal. Viel mir nur gerade ein, weil einige
ja darüber klagten, dass der Welec nur bei bestimmten Temperaturen
sauber funktioniert. Vermutlich fehlt der Sensor im Welec-Design, oder
er wurde noch nicht gefunden. Andernfalls müsste man für eine schnelle
Aufbereitung der Daten für jeden Wandler eine Korrekturtabelle von 256
Werten anlegen. Diese wird beim HP vermutlich durch die User-Calib
extrapolieert.
Wo kann ich denn das Video ggf. ablegen. Die User-Calib dauert ein paar
Minuten... Werde ich dann heute Abend aufnehmen.
Gruß, Ulrich
Was mich extrem wundert, sind die Ähnlichkeiten zwischen Welec und
Agilent Geräten.
Z.B. sind die Bedienelemente 100% identisch. Abgesehen von zwei
fehlenden Tasten beim Welec und anderen Softkeys.
Auch das Bildschirmdesign ist zu 99% identisch. Auch die 4 SubDiv/Div in
Y-Richtung.
Siehe Bedienungsanleitung:
http://cp.literature.agilent.com/litweb/pdf/54622-97036.pdf
Verwendet Welec wirklich leicht abgeänderte Orginaldesigns von Agilent?
Aber warum sind dann Hard-und Software so buggy?
Kurt Bohnen schrieb:
> Was mich extrem wundert, sind die Ähnlichkeiten zwischen Welec und> Agilent Geräten.
Das wundert mich nicht. Wenn ich ein neues Gerät auf den Markt bringen
wollte, würde ich mich auch an Bewährtem orientieren
> Z.B. sind die Bedienelemente 100% identisch. Abgesehen von zwei> fehlenden Tasten beim Welec und anderen Softkeys.> Auch das Bildschirmdesign ist zu 99% identisch. Auch die 4 SubDiv/Div in> Y-Richtung.
Das hätten sie allerdings nicht abkupfern müssen. Da halte ich es eher
wie die Japaner: Gut abkupfern und dann verbessern!
> Siehe Bedienungsanleitung:> http://cp.literature.agilent.com/litweb/pdf/54622-97036.pdf
Die hätte WELEC man auch abkupfern sollen, denn die taugt wenigstens
was. Die werd ich mal als Anhaltspunkt für weitere Entwicklungen nehmen
und evtl. auf dieser Basis mal eine richtige Anleitung für das WELEC
stricken.
> Verwendet Welec wirklich leicht abgeänderte Orginaldesigns von Agilent?
Wohl nur das Äußere würde ich sagen. Genaueres kann uns da nur ein
Agilent-Besitzer sagen.
> Aber warum sind dann Hard-und Software so buggy?
Weil sie halt nicht von Agilent sind (schade)
Gruß Hayo
p.s. vielleicht kann man ja eine Platine von Agilent kriegen und ins
WELEC einbauen ;-)
Ulrich P. schrieb:
> Aber normalerweise ist doch ein signed bei> 0..127 positiv und bei 128..255 negativ, wobei 128 der -1 entspricht.
Und 127 die Null. Soweit korrekt.
> Die Zero-Linie bei offenem Eingang zu messen halte ich für kritisch, da> die OVs der Eingangsstufe dann frei laufen.
Da gebe ich Dir recht.
> Gibt es keine Option, die> Stufe auf GND zu schalten? Das wäre schon mal ein Anfang.
Mir ist keine bekannt, aber wenn es da andere Erkenntnisse gibt macht
mich schlau. Ich wollte mich erstmal an vorhandener Hardware
orientieren, damit alle was davon haben.
> Optimaler wäre> es sicherlich, die Gesamtaussteuerung zu durchlaufen und dann die Daten> zu mitteln. Dazu müssten aber wenigstens die DACs für das GAIN halbwegs> kalibriert sein. Gibt es denn in dem ganzen Scope keine einzige> brauchbare Referenz aller Kanäle gemeinsam?
Nicht das ich wüßte. Allerdings hab ich die Hardwareseite noch nicht so
intensiv unter die Lupe genommen. Tja da war ich wohl vor 15 Jahren
schon weiter als ich für die Diplomarbeit mein externes Oszi für den
Parallelport konstruiert habe. Da gab es nämlich Abgleichreferenzen und
auch eine schicke Spektralanalyse auf dem PC. Da lief aber die komplette
Software auf dem PC und man mußte nicht so mit Resourcen geizen wie
hier.
Unter anderem gab es auch eine Korrektur der ADC-Kennlinie, die hatte
ich beim WELEC auch schon probeweise eingebaut (Y = beta*X + alpha) aber
wegen der massiven Performanceeinbrüche bei der Graphikausgabe wieder
ausgebaut.
> Nochwas zum HP. Er führt die User-Calibration offenbar unter> Berücksichtigung der eigenen Temperatur durch, diese vermerkt er> jedenfalls in den Logdaten
...
> Vermutlich fehlt der Sensor im Welec-Design, oder> er wurde noch nicht gefunden.>
Temperatursensor? Was ist das möchte man fragen. Sowas gibt es hier
nicht. Da hilft nur nachkalibrieren, und damit das gut klappt legen wir
uns hier ja ins Zeug.
Gruß Hayo
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
Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.
Wichtige Regeln - erst lesen, dann posten!
Groß- und Kleinschreibung verwenden
Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang