Seid Ihr schnell :-) Mein 2024 zeigt keine Macke bzgl. Kanal2
@Hayo, bitteschön...und du bekommst das schon hin ;-) @Jürgen, du kompilierst selbst? Warum? Gruß Michael
Es ist eine Macke drin! Und ich hab sie auch schon... Wie schon oben erklärt eine Stelle an der der Kanalindex zurückgerechnet wird - Altlast eben - jetzt ist auch mein W2022 richtig kalibriert. Moment, ich pack das mal eben in die C3 zusammen, kommt gleich...
Ok, hoffe jetzt ist es ok. @Jürgen die stdint.h gehört ins inc Verzeichnis, dann sollte es gehen. Die kann man auch aus dem Internet runterladen. Ich hab sie jetzt mal dazugetan. Gruß Hayo
Ach ja, der Haken im Hardwaresetup... Den hatte ich auch, konnte die Ursache aber nicht feststellen. Vermutlich irgendwas aus dem Flash. Bei mir ist das nach zwei mal benutzen (an/aus/an/aus) weg gewesen. Hayo
Hayo, gibt es eine Möglichkeit, die Berechnung und Ablage der Trigonometrie Tabellen im Flash manuell erneut zu starten? Hintergrund: Nach dem Flachen der 6.4 Version heute morgen startete wie erwartet der Berechnungsprozess. Auf halbem Weg trat aber dann das allseits gefürchtete Pixelflimmern im Display auf (RAM Lötstellen). Blöderweise habe ich aber den Berechnungsvorgang nicht abgebrochen, sondern durchlaufen lassen. Die RAMs sind jetzt nachgelötet und das Skope scheint auch einwandfrei zu arbeiten. Dennoch habe ich die Befürchtung, dass evtl. während der Generierung der Tabellen durch den RAM-Fehler falsche Werte generiert und im Flash abgelegt wurden. Danke! Lothar
Hayo W. schrieb: > @Jürgen > > die stdint.h gehört ins inc Verzeichnis, dann sollte es gehen. Die kann > man auch aus dem Internet runterladen. Das war mir bekannt, das die als Standard im Internet zu finden sein sollte. Das Problem war, wie so oft bei Standards, es gab zu viele davon :-) >Ich hab sie jetzt mal dazugetan. Danke. Compiliert aber noch nicht. Es werden 'undefined references to 'Opsys::_ExecHdl' angemault. Ich dachte Du hattest das wieder heraus genommen? Ok, werde ich mir später mal ansehen. > > Gruß Hayo Michael D. schrieb: > @Jürgen, > du kompilierst selbst? Warum? > > Gruß Michael Die Frage lautet doch eher "Warum nicht?" bei einem open source project :-) Gruß Jürgen
Jürgen schrieb: > Compiliert aber noch nicht. Es werden 'undefined references to > 'Opsys::_ExecHdl' angemault. Ich dachte Du hattest das wieder heraus > genommen? Nein, die Sourcen sind noch drin. Es wird zwar nicht mehr die volle Execution Queue benutzt, aber noch ein einzelner Execution Handler der in die Hauptschleife integriert ist. Hintergrund ist der reaktivierte Vsync-Interrupt. Ich benutze das zum verzögerten Ausführen von Routinen. Man kann beim VSync eine Sprungaddresse hinterlegen (z.B. SetupTrigger()) und einen Timeout. Nach Ablauf des Timeout wird die Adresse in den Execution Handler geschrieben und beim nächsten Schleifendurchlauf ausgeführt. Damit kann man verhindern, dass beim Kurbeln am Triggerlevel ständig ein Hardwarezugriff durchgeführt wird. Erst wenn man aufhört zu kurbeln und der Timeout eintritt werden die Neuen Einstellungen übernommen. Benutze ich an einigen Stellen. Benutzt Du das neue Makefile das ich mit ausliefere? Übrigens checke ich neuerdings alles im SVN ein, da dank Andi jetzt auch ein BF-Verzeichnis eingerichtet ist. Hayo
Hayo W. schrieb: > Übrigens checke ich neuerdings alles im SVN ein, da dank Andi jetzt auch ein BF- > Verzeichnis eingerichtet ist. ... und alle Änderungen ab der Version 1.2.BF.5.0 (Jahr 2011) sind so für alle sichtbar! Gruß Andi
@Hayo > Ok, > hoffe jetzt ist es ok. Jaaa, jetzt ist alles schick! Die 50ns hatten noch ein wenig gezickt, des öfteren die Offset u. Cal.Standart betätigt, dann war es endlich ok. Ist das eigentlich wurscht, was ich zuerst drücke? Also zuerst den Offset dann Cal.Standart, oder besser umgekehrt? @Jürgen > Die Frage lautet doch eher "Warum nicht?" bei einem open source project > :-) Stimmt auch wieder... ;-) Gruß Michael
Michael D. schrieb: > Ist das eigentlich wurscht, was ich zuerst drücke? Also zuerst den > Offset dann Cal.Standart, oder besser umgekehrt? Da gibt es wohl ein kleines Mißverständnis, das Calibration Set brauchst Du eigentlich überhaupt nicht zu ändern, damit kannst Du nur einfach unterschiedliche Kalibrierungen für bestimmte Eingangsoffsets speichern. Das hatte ich (glaube ich) für Branadic und seine aktiven Tastköpfe eingebaut. Übrigens habe ich noch einen Bug gefunden, das Channel Delay für Kanal 4 und das Calibration Set wird nicht im Flash gespeichert, ich ermittle schon, aber die C4 wird es erst morgen geben. Vielleicht findet Ihr ja noch was, das kann ich dann gleich mit fixen. Gruß Hayo
Das Calibrationset ist mir schon klar, bleibt ja in meine Fall auf Standart stehen. Wenn ich es betätige, tut sich aber trotzdem was. Also nur den Offset benutzen? Der Lothar hat da ein Problem mit der Trigonometrie Tabelle. Die hattest du das erste Mal in der 5.8XE. Wenn ich auf eine Vorgängerversion z.B. 5.5 flashe(downgrade) und wieder zurück auch die 6.4, wird keine Tabelle mehr geladen, bleibt die jetzt für immer im Flash? Gruß Michael
Angehängte Dateien:
-
Browse.png
3,9 KB
jetzt fällt es mir wieder ein :-( früher mußten wir 2 Knöppe drücken, heute nur noch den Offset. Mir fällt gerade noch was zum OSS ein. Wenn ich die Browse-Leiste eingeblendet lasse, dann sieht man die OSS-Anzeige natürlich nicht mehr, wollen wir das so lassen, oder das OSS knapp unter die erste Gritlinie versetzen? Gruß Michael
Hi! Mir fällt gerade auf, dass die Save/Recall Funktion nicht mehr funktioniert. Zumindest bei meinem Skope. Bei "Recall" bekomme ich entweder eine Gleichspannung oder ein niederfrequents Rechtecksignal angezeigt. Egal was vorher gesaved wurde. Das passiert aber nur bei Zeitbasen ab 1ms/div oder langsamer. Bei schnelleren Zeitbasen ist alles OK. Lothar
Andreas W. schrieb: > > Hayo W. schrieb: >> Übrigens checke ich neuerdings alles im SVN ein, da dank Andi jetzt auch ein BF- >> Verzeichnis eingerichtet ist. > > ... und alle Änderungen ab der Version 1.2.BF.5.0 (Jahr 2011) sind so > für alle sichtbar! > > Gruß Andi Eben leider nicht! Es fehlen die Änderungen im /lib - Verzeichnis. Da wurde auch geändert und ich nehme doch an aus gutem Grund. Hajo, ich habe das geänderte Makefile übernommen und an meine Installation angepasst. Jetzt wird über nios_mul.s gemeckert. Gruß Jürgen
Angehängte Dateien:
-
save.jpg
33 KB -
restore.jpg
25 KB
Hier noch 2 Screenshots zur Verdeutlichung. Eingangssignal: Daumen auf dem Tastkopf ;-) save.jpg -> So sieht das Signal aus und wird gespeichert restore.jpg -> Das wird bei 'Recall' angezeigt Lothar
Ok, schnell noch geantwortet: @Lothar entweder Du spielst ein Backup ein, oder ich lade Dir hier morgen ein spezielles Flashfile hoch das Dein Trigo-Flash neu organisiert. Das Recall-Problem sehe ich mir morgen mal an. @Jürgen ich lade einfach mal das komplette Build hoch in SFN und poste hier den Link, dann sollte das gegessen sein. @Michael Ich würde das nur ungern tiefer setzen, dann habe ich das immer direkt im Signal. Hayo
Hallo Hayo, Danke für den Hinweis. Wenn es mit dem Einspielen der Originalsoftware getan ist, sollte ich das eigentlich hinbekommen. Wollte ich sowieso mal machen. Nur um zu sehen, wie unglaublich schlecht die Welec Firmware im Vergleich zur BF war. Lothar
Super! Hat geklappt. Momentan initialisiert mein Oszi die Trigonometrie Tabellen neu. Habe die Original Firmware 1.4 eingespielt. DAS GRAUEN!! Unglaublich, dass man DAMIT mal versucht hat, irgend etwas zu messen! Ich kann nur jedem empfehlen, das mal zu tun. Dann sieht man überdeutlich, welche Leistung hier mit der OpenFirmware erbracht wurde. Nochmal ausdrücklich 1000 Dank an alle, die das Projekt voran getrieben und ihre wertvolle Zeit geopfert haben! Lothar
Hallo Leute, auch von mir 1000 Dank für die Leistung die hier erbracht worden ist. Ich werde heute Abend auch mal die neue FW auf das Oszi spielen. Eine Frage habe ich aber noch. Wird beim Auspielen das FPGA auch gleich mit geflasht oder muß dies manuell über JTAG und USB-Blaster drauf? Ist die FPGA FW auch im Zip-File enthalten? Danke und Gruß, Georg.
Lothar Merl schrieb: > DAS GRAUEN!! > Unglaublich, dass man DAMIT mal versucht hat, irgend etwas zu messen! Ein ähnlicher Effekt stellt sich nochmal ein, wenn man vom jetzigen FPGA auf das neue Nios II wechselt... ;-) Georg X. schrieb: > Wird beim Auspielen das FPGA auch gleich mit geflasht oder muß dies > manuell über JTAG und USB-Blaster drauf? > Ist die FPGA FW auch im Zip-File enthalten? Die BF-Software enthielt noch nie ein FPGA-Update, sie arbeitet stets mit der Originalhardware. Die Software kann den FPGA-Konfigurationsflash nicht erreichen. Dafür wirst du demnächst einen USB-Blaster oder den Slog-Treiber brauchen. Wir sind noch nicht besonders gut mit Anleitung zu dem Thema aufgestellt. In die neue Hardware könnte ich theoretisch einen Zugang zum Konfigurationsflash einbauen. Dann könnte man aus der Software heraus die Hardware updaten, aber sich bei Unterbrechung oder Fehlfunktion auch aussperren. In dem Fall bräuchte man eh wieder einen Blaster, und für's erste Mal auch. Deshalb habe ich da wenig Ambitionen. Jörg
@Georg in dem "doc" Verzeichnis sind Anleitungen was Du installieren must und wie Du die Firmware dann ins DSO kriegst. Die original WELEC Update-Software (über USB) geht nicht! Bei Fragen einfach hier melden. @Jürgen + alle Das aktuelle SDK-Build hab ich hier hochgeladen: http://sourceforge.net/projects/welecw2000a/files/Development/SDK_BlueFlash_Build.zip/download Einfach draufklicken sollte genügen. @Lothar Ja gruselig nicht wahr? Ich geb mir das auch ab und zu um mal zu sehen wie es früher war, dann freue ich mich hinterher immer über den aktuellen Stand. :-) Gruß Hayo
Alle gestern gemeldeten Fehler sind bereinigt. Gruß Hayo
Wow! So schnell, wie Du die Fehler fixt, kann man die ja kaum finden! Danke!
Hayo W. schrieb: > @Jürgen + Andi > > Ich habe jetzt /bin /lib und /inc ins SVN mit eingecheckt > > Hayo Hi Hayo, danke, es compiliert jetzt ohne Fehler!
Oh, einen hatte ich vergessen, habe noch Single Shot für FFT eingebaut. Hayo
Hab noch einen gefunden: Beim Kalibrieren wird die Delay-Einstellung aus dem Flash gelöscht. Die C6 ist in Arbeit... Hayo
Angehängte Dateien:
-
FW1.2.BF.6.4C6.png
5,5 KB
habe sie gleich mal geflasht. Was macht denn das Häkchen unten rechts im HW-Menu? Und wieso hat mein "Screenshot" ein Turkisefarbenes Grid, obwohl Weiß eingestellt ist? War bei der vorherigen Version nicht, habe das gerade getestet. Gruß Michael
Das mit dem Häkchen hatten wir schon weiter oben, das geht nach einmal aus und wieder einschalten weg. Frag bloß nicht wo das her kommt. Hab mir schon nen Wolf gesucht. Die Farbe vom Grid ist im Screenshotprogramm fest vorgegeben. Mit gefiel das Grünliche besser, deswegen habe ich das geändert. Kann aber jeder selbst im Coding verändern. Das Compilieren müßte eigentlich funktionieren wenn man die Cygwin Umgebung bei sich laufen hat, auf USB-Stick oder Platte. Ansonsten nehme ich auch Bestellungen zu Wunschfarben an :-) Hayo
@Hayo > Das mit dem Häkchen hatten wir schon weiter oben, das geht nach einmal > aus und wieder einschalten weg. Frag bloß nicht wo das her kommt. Hab > mir schon nen Wolf gesucht. Das ist ja Quatsch damit wertvolle Zeit zu verschwenden! Mich stört es nicht, meinetwegen können noch 2 dazu, unwichtig... Mit dem Screenshot, dachte ich nur, das es wäre ein Bug wäre. Wem die Farbe nicht gefällt, kann ja die vorherige Screenshot-Version benutzen, also auch nicht lebenswichtig. ;-) Gruß Michael
Michael D. schrieb: > @Hayo > Mich stört es nicht, meinetwegen können noch 2 dazu, unwichtig... Mich stört es schon wenn ich nicht weiß warum... > Mit dem Screenshot, dachte ich nur, das es wäre ein Bug wäre. Nein ein Feature! > Wem die Farbe nicht gefällt, kann ja die vorherige Screenshot-Version > benutzen, also auch nicht lebenswichtig. ;-) Das stimmt, außer der Farbe sind die identisch. Habe auch keine neue Versionsnummer vergeben. Hayo
Und ich habe mir extra Mühe gegeben, am LCD-Stecker die genauen Bits pro Farbe gemessen, um für's neue FPGA und den Osoz-Screenshot die originalen Farben zu verwenden, und dann kommt ihr Künstlervolk daher! ;-) Jörg
Schande über mich, aber als einer der mit den alten Analog Oszis groß geworden ist hat das grüne Grid einfach was Vertrautes für mich... ;-) Hayo p.s. bin erstmal eine Woche Ski-fahren, hoffe aber dass ich da irgendwie Internetzugang habe.
> und dann kommt ihr Künstlervolk daher! > ;-) und das stimmt auch noch! ;-) fällt unter "Automotive-Design" oder "innovatives Design" :-) Jörg > Schande über mich, aber als einer der mit den alten Analog Oszis groß > geworden ist hat das grüne Grid einfach was Vertrautes für mich... > ;-) hm, im Displaymenu hast du diese Farbe "Teal" genannt. Ist eigendlich ein weiblicher Vorname, der aber auch die Farbe Patrol oder Blau-Grün definiert. Ich war mal ein Fan von dem Farbton. Wohin geht es denn zum Ski fahren? Gruß Michael
Nach Schladming, hoffe dass da noch Schnee liegt, sonst hab ich das Lappy dabei und programmiere ein wenig :-) Teal - die Farbe hab ich bei meiner Kiste eingestellt, das gefällt mir einfach am Besten. Soll ja auch dem Auge gefallen. Hayo
Angehängte Dateien:
-
1_25MHz-100ns-RT-0_0s.jpg
59 KB -
1_25MHz-200ns-RT-0_0s.jpg
68 KB
Ok, vom HW-Thread nach hier... > Hi Michael, > ich vermute Du hast für die Rise/Fall-Timemessung eine zu kleine > Zeitbasis eingestellt. Dann reichen ihm die Punkte zur Messung nicht > mehr aus. > Mach mal einen Screenshot - aber dann im Firmwarethread. Hier mal 2 Screenshots von der Rise/Fall-Anzeige Das Signal ist ein Rechteck 1,25 und mit einer Amplitude von 5V, Rise/Falltime 1-2ns, Jitter 25ps. Bei beiden Zeitbasen wird 0s angezeigt, oder es schwankt manchmal zwischen "s" und "ns". Dazwischen sollte doch "µs" liegen?! In höheren Zeitbasen, bzw. Frequenzen, wird die Rise/Falltime korrekt angezeigt. Gruß Michael EDIT. Achso, mußte leider fotografieren, da das ganze Geraffel zu weit vom PC hängt. Vielleicht stricke ich mir noch eine 8m RS232 Leitung... :-) >Gruß Hayo > p.s. zu Peak Detect sag ich noch was... ja, sag' was ;-)
Angehängte Dateien:
-
Rise_Time.jpeg
54 KB
Hi Michael, wie ich schon vermutet habe ist die Zeitbasis für die Messung zu langsam und die Pegelaussteuerung ist zu klein. Die Flanke auf Deinen Screenshots geht so steil hoch, dass auch bei einer manuellen Messung mit den Cursorn die Anstiegszeit Null wäre. Je schräger die "Rampe", desto genauer ist die Messung. Gemessen wird die Zeit von 10% bis 90% der Flanke. Das sind die beiden gepunkteten Linien im Grid. Die Signalamplitude sollte daher auf den jeweils letzten Gridlinien liegen. In etwa so wie auf dem Screenshot. Das ist die Anstiegszeit meines alten HP3310B Signalgenerators. Dein Signal scheint aber deutlich schneller zu sein. Evtl. ist auch einfach das Signal zu schnell für unser Oszi. Um das zu sehen müßtest Du aber auf 50 ns auflösen und einen Spannungsbereich wählen in dem Du die Amplitude weiter aussteuern kannst. Wenn dann immer noch nichts geht ist das WELEC einfach zu langsam... Ich denke eine Anstiegszeit von 5ns sollte es aber schaffen - und das ist schon ziemlich schnell. Gruß Hayo
Angehängte Dateien:
29ns das ist natürlich eine langsame Anstiegszeit.
Ich habe gestern noch ein paar Messungen mit dem schnellen Signal
gemacht, müßte so um die 2ns sein, angegeben ist der ICS511 mit
Rise/Fall-Time von 1nS bei 4pF load. Da kommt ja noch die Leitungslänge,
Stecker etc. dazu, da könnte es mit 2-3ns hinkommen.
Das Welec ist in der Lage picosekunden zu messen, ob das real ist, kann
ich nicht beurteilen.
Anbei ein paar Shots
Die 50MHz sehen noch einigermaßen gut aus, bis auf die viel zu hohe
Amplitude. Hier wird z.B. in ps gemessen.
bei 130MHz habe ich schon 12V
150MHz 14V :-(
183MHz 11,2V
200MHz 4,68V dieser Wert ist realistischer
Könnte es an den noch nicht ersetzten 24R und 150R bzw. 170R liegen?
Gruß Michael
Michael D. schrieb: > Das Welec ist in der Lage picosekunden zu messen, ob das real ist, kann > ich nicht beurteilen. Nein, kann es nicht. Das sind interpolierte Zeitbasen. da wird das Signal nur "gestretcht". Die schnellste reale Zeitbasis ist 50ns/Div. Da ist ein Pixel eine Nanosekunde. Bei einer Anstiegszeit von 2ns wird es tatsächlich etwas eng. Da ist das WELEC wohl einfach zu langsam. Das ist kein Firmwarefehler, sondern Du lotest gerade die Grenzen des Gerätes aus - auch nicht übel :-) Gruß Hayo
> Das ist kein Firmwarefehler...
Ja, das ist mir schon klar.
Wie kommt es, das so ab 100MHz die Amplitude extrem in die Höhe geht und
ab 200MHz wieder absackt auf einen einigermaßen realistischen Wert?
Übrigens habe ich ohne Tastkopf und direkt mit einem RG174 an BNC sowie
1:1 ohne Abschluss gemessen.
Da ich noch die originale Bestückung in der Eingangsstufe habe, frage
ich mich, ob da merkliche Besserung nach der Modifizierung eintritt.
Gibt es da nicht irgendwo eine Dokumentation für vorher u. nachher?
Ich könnte noch einen Vergleich zum Voltcraft 3062C posten, wenn
Interesse besteht. Da steigt zwar auch die Amplitude, nur nicht so
extrem hoch.
Gruß Michael
Michael D. schrieb: > Wie kommt es, das so ab 100MHz die Amplitude extrem in die Höhe geht und > ab 200MHz wieder absackt auf einen einigermaßen realistischen Wert? Das ist der Frequenzgang des original bestückten WELEC. Das hatten ja einer unserer Hardwarespezi mal vor längerer Zeit genau ausgemessen und als Diagramm hier dargestellt (gleich das Erste): http://sourceforge.net/apps/trac/welecw2000a/wiki/HardwareImprovement > Übrigens habe ich ohne Tastkopf und direkt mit einem RG174 an BNC sowie > 1:1 ohne Abschluss gemessen. Das ist allerdings Messtechnisch eine Vollkatastrophe. Da dürfte es auf der Leitung lustig klingeln... Du hast zwei Möglichkeiten: 1. Du schließt den Ausgang Deiner Schaltung mit einem 50 Ohm Widerstand ab und machst am anderen Ende (Oszi-Eingang) auch einen Abschluß dran, was natürlich die Amplitude verkleinert. Es ist zu prüfen, ob Dein Ausgangskreis genügend Ausgangsleistung liefert um die 100 Ohm zu befeuern. 2. Du mißt mit einem Tastkopf im 10x Modus, ist am einfachsten, erfordert aber bei deinem Signal einen guten Tastkopf mit großer Bandbreite. > Da ich noch die originale Bestückung in der Eingangsstufe habe, frage > ich mich, ob da merkliche Besserung nach der Modifizierung eintritt. > Gibt es da nicht irgendwo eine Dokumentation für vorher u. nachher? Ich habe dazu mal eine Testreihe mit Bildern gemacht, ist aber etwas her. In Kürze - bei Verwendung von 24,9/174 Ohm wird der Frequenzgang wieder linear und die Eingangsstufe neigt nicht mehr so sehr zum Schwingen. Ich habe mir gerade einen 100er Streifen 24.9 Ohm Widerstände für mein W2014A geordert. Wenn Bedarf besteht kann ich die Kombination 24,9/180 anbieten, einfach PIN mit Adresse schreiben, dann schicke ich ein Briefchen... Gruß Hayo > Ich könnte noch einen Vergleich zum Voltcraft 3062C posten, wenn > Interesse besteht. Dann aber mit korrektem Messaufbau. Gruß Hayo
Gute Sonntag Michael D., Hayo, Jörg H. und all jene, die an dem Projekt beteiligt sind Welec! Nach langer Abwesenheit bin ich wieder. :-) Ich verlor ein wenig 'Arbeit, aber ich werde versuchen, zu fragen, Informationen beheben. ;-) Bereiten Sie die übliche Dosis Geduld... ...Ich vertraue in deine Güte :-) @Michael D. Michael, you can't directly get a so little rise time on the screen of the Welec because what You want to misure exceeded the DSO's features. Infact 200MHz (W202xA) bandwidth version have to be 1,75ns as the better fast rise time who can view on the screen, while 100MHz (W201xA) version reach 3,5ns, pico seconds are to small to be wiev on the screen as impulse response. Coming close to the scope rise time it is necessary to subtract the scope’s (and if used the probe’s) rise times geometrically from the rise time as seen on the screen. The true signal rise time will become: Ta= SQR((Ttot*Ttot) – (Tosc*Tosc) – (Tt2*Tt2)) Ttot is the rise time seen, Tosc is the scope’s own rise time (2,3ns for 150MHz bandwidth oscilloscope), Tt is the rise time of the probe, e.g. 2ns and Ta is the true waveform rise time. If the signal’s rise time is > 22 ns (in this example the DSO is 150MHz bandwidth so we have 22ns, more generally that is the result of about 10 times its specific rise time who is 2,3ns, so 10 * 2,3ns = ~22ns), the rise times of scope and probe may be neglected. So, if for instance you measure 8ns as signal's rise time on the screen of the oscilloscope, then the true signal rise time will become: Ta= SQR((8*8) - (2.3*2,3 *2,3) - (2*2)) = 7,4 ns For most amplifiers, even if their pulse behaviour is far from ideal, the following relationship holds: Ta=350/B hence B=350/Ta Where B is the oscilloscope's bandwidth and Ta is again the true waveform rise time tr/ns = 350/Bandwidth/MHz Resulting by my tests, seems to me the W2022a is a real 200MHz bandwidth oscilloscope when I tested it with a fast rise time pulse and W2012a is at least a real 170MHz bandwidth DSO. I used the Jim Williams avalanche fast pulse generator who the author described on LT App Note 47, it is a 300ps pulse generator, so much faster than Welec's impulse response capability. It is also cheap and easy to build. When I built mine then I verified it using a 500MHz Tektronix DSO who is the better instrument I can have, poor bandwidth you can say but I get about 980ps on its screen and because it is a real 700ps risetime DSO hence my avalanche pulse generator is a true 300ps or less (280ps I viewed). Please take a look at this: Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil4)" Note: the pics and the post was wrote when my W2022A/W2012a has not yet been modified putting 24/150 ohm resistors. Michael D. schrieb: >Die 50MHz sehen noch einigermaßen gut aus, bis auf die viel zu hohe >Amplitude. Hier wird z.B. in ps gemessen. > >bei 130MHz habe ich schon 12V > 150MHz 14V :-( > 183MHz 11,2V > 200MHz 4,68V dieser Wert ist realistischer > >Könnte es an den noch nicht ersetzten 24R und 150R bzw. 170R liegen? Of course Michael, if your DSO yet have the original hardware's resistors it is normal the behaviour you described, otherwise I don't know why of that behaviour with the hardware's resistors changed to 24/150 or 24/174 ohm. What I can say for sure is that after I changed the resistors the my two units exhibit a flat response (flatness) from about 10Hz to 180MHz, I can't go over with my leveled signal generator who stop at 180MHz so I can't reach the W2022a's bandwidth that however I suppose to be real 200MHz. @Hayo. Good news from You even in the "hardware teil", very amazing, as always thank You Hayo! Much terrific the fine/coarse level setting for the inputs amplitude, as all You know I have always dreamed for that, even if as it is now it is better for servicing. Infact would have been better if it had been able to act independently on each channel, but also as it is now it is really usefull. I know it was very hard to obtain it, a miracle you can say, but just because You're the man of miracles, in the case You can reach the result to put fine/corse directly for each channel, it could be great. ;-) I warned all you about patience and kindly! ;-)) Thanks Hayo and RESPECT! Perhaps new Jörg design can aid... ;-) Very, very good even the hint for compensate/calibrate each input directly on the DSO's input circuitries, thank You very much Hayo: RESPECT! Interesting considerations about the performance achieved among different FPGA revisions, even if with the new FPGA development by Jörg all will be drammatically improved, also frame rate matter: as I wrote one time Jörg is the master of the time. Another dream who became true is the 'Peak Detect' function who is roughly what I demanded in an old post: Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil3)" Really awesome, thank You very much Hayo, no words, RESPETC! Now I go away, I have to verify something important in the new firmware, I cross my fingers because might be the right time! :-) Nochmals vielen Dank Hayo und Vielen Dank an alle Unterstützer des Projekts Welec! Mit freundlichen Grüßen, Luc
Gute Sonntag Michael D. und all jene, die an dem Projekt beteiligt sind Welec! One important thing that I forgot to write before about the report I wrote time ago and all you can see here: Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil4)" Fall time values in the pics are 0 (zero) because at that time Hayo's firmware wasn't yet able to show picoseconds in fal and rise time as it is now. Infact due to this I expressely demanded to Him to modify it, thing which He promptly did with His usual mastery that we all know. You can see the behaviour of other DSOs and analog oscilloscopes with different bandwidths. As visible up to 300MHz automeasures show true rise/fall time of the instrument, because 300ps are much less of its typical rise/fall time, so other factors may be neglected. Only the Tektronix DSO, who is a 500MHz bandwidth, begins to show the weight of 300ps because it is a 700ps instruments. I felt compelled to specify this things. Thanks. Nochmals vielen Dank Michael D. und Vielen Dank an alle Unterstützer des Projekts Welec! Mit freundlichen Grüßen, Luc
So Michael ich hoffe diese kleine Doku beantwortet Deine Fragen zum Peak Detect. Ich habe gerade die aktuelle Release fertig und bereite den Upload vor. Dann könnt ihr selbst probieren. Hayo
So, viel Spaß beim Ausprobieren. You will find the english version of the peak detect docu inside the doc directory. enjoy... Hayo
Wie mache ich einen (oder mehrere) Screenshots? Ich beschreibe mal die Prozedur unter Windows, aber unter Linux geht es fast genauso. Also im Verzeichnis screenshot findet man eine Batchdatei scrsh.bat - diese muß mit einem Editor auf die eigene Hardware angepasst werden. Der String "%~dp0\w2000a-screenshot.exe" -c 1 -b -a %* enthält als Argument den zu benutzenden COM-Port, hier COM1. Das muß man entsprechend anpassen und dann sichern. Dann das DSO einschalten und per Doppelklick die Batchdatei starten. Das Programm verbindet sich mit dem DSO, prüft die aktuelle Firmware auf dem DSO und wartet dann auf Screenshots, die man am DSO per Doppeldruck auf die Quick Printtaste oder im Printmenü selbst auslöst. Die Bildschirmausgabe sollte so aussehen: * Connecting to DSO and retrieving version information... done - found firmware version: 6.5 - found hardware version: 8C7.0.G - found model: W2022A * Waiting for screenshot, trace, or measurement... Man kann das Programm natürlich auch direkt mit den Argumenten starten. Der Screenshot kann auch umgekehrt vom Programm aus getriggert werden. Mit -h als Argument bekommt man einen Hilfetext angezeigt. Das Programm wartet und verarbeitet so lange Screenshots bis es beendet wird. @Martin Die von Dir beschriebene Meldung läßt mich vermuten, dass Du das DSO erst hinterher eingeschaltet hast. Gruß Hayo
Angehängte Dateien:
-
Rise_Time_W2022A.jpeg
50 KB
Nachdem ich mir bei meinem Neuzugang - einem 100 MHz Pulsgenerator, der leider defekt bei mir ankam - einen Wolf gesucht habe bis ich die Fehlerquellen lokalisiert hatte, läuft das Teil jetzt wie Schmitts Katze. Ich habe die Gelegenheit genutzt und passend zu unserem Thema weiter oben ein paar Messungen vorzunehmen (gehört ja eigentlich in den HW Thread). Ich war doch positiv überrascht, das WELEC ist gar nicht so übel. Die Fakten: Der Pulsgenerator ist spezifziert mit 2.5ns Anstiegszeit. Gemessen habe ich mit dem Tektronix 2465A (Bw ~400MHz, Tr ~0,8ns) eine Anstiegszeit von 2.4ns. Wie man auf dem Screenshot sehen kann schafft das W2022A diese Anstiegszeit ebenfalls, was ich nicht vermutet hätte. Das entspricht einer Bandbreite von 140 - 150 MHz. Das ist schon ganz anständig. Das W2014A schafft da - genau wie mein OWON SDS8102 - "nur" 3ns, was einer Bandbreite von etwas über 100MHz entspricht. Für diese Messungen muß man im Hardwaremenü unbedingt die Einstellung "High Frequency" wählen, da es sonst zu überlagerten Schwingungen kommt. Gruß Hayo
Hallo, ich habe ein Problem mit dem Logikmodus. Ich versuche ein zyklisches I2C-Signal (alle 2s 10Byte, 100kHz) im TTL-Modus zu betrachten. Irgendwie scheint die Zeitauflösung zu spinnen. Das ist so auffällig, dass ich mir gar nicht vorstellen kann, dass das noch nicht aufgefallen ist. Wenn ich von 2V Auflösung und 20µs auf Logic TTL5V umschalte wird wie erwartet getriggert, wenn ich den Triggermodus wieder auf Normal gestellt habe. Allerdings führt dann ein Ändern der Zeitauflösung incl. neuem Triggern zu keiner Veränderung in der Zeitachse. Soll heißen das Signal bleibt scheinbar in der vorherigen Zeitauflösung, die Anzeige der Auflösung oben rechts ändert sich. Bei manchen Änderungen wird auch das Signal gestaucht obwohl eine Streckung zu erwarten wäre. Hat das schon mal jemand gesehen? Gruß, Rainer
Hat Dein I2C Signal denn TTL-Pegel? Welche Probe-Einstellung hast Du eingestellt? Es wird nur 1:1 und 1:10 unterstützt. Das muß auch genau passend zur Prüfspitze eingestellt werden, da sonst die Pegel nicht stimmen. Gruß Hayo
Hallo Hayo, Wenn ich mit der neuen Firmware eine Offset Calibration mache dann bekomme ich schöne Streifen auf dem Display. Ist ein W2022A. Sonst habe ich noch kein merkwürdiges Verhalten feststellen können.
Hallo Stefan, das ist kein gutes Zeichen. Die Streifen tauchen eigentlich immer nur dann auf, wenn es Probleme mit dem RAM oder dem Display gibt. Meine beiden W2xxxA machen beide keine Streifen bei der Kalibrierung. Kannst Du mit einer Kamera evtl. ein Foto davon machen? Gruß Hayo
habe das Thema lange nicht verfolgt, aber wie weit wird die Huckepackplatine eigentlich mittlerweile unterstützt? Ist das in der Software nun implementiert?
Ja, ist es. Jörg hat dafür einen Treiber geschrieben, der auch in der aktuellen Firmware auswählbar ist. Wie die Erfahrungen damit sind mußt Du Jörg und Branadic selbst fragen. Wer das noch eingebaut hat weiß ich nicht. Gruß Hayo
Hallo, anbei drei Beweisfotos für das beschriebene Verhalten. Ich bin von 2V zu Logik TTL gegangen, habe dann die Zeitachse verstellt (50µs, 20µs, 10µs). Es wurde auch erneut getriggert. Beim Umstellen von 10µs Logik auf 2V (Logik aus) bleibt die falsche Zeitachse. Erst ein Drehen an der Zeitauflösung stellt die korrekten Zustände wieder her. Gruß, Rainer
Hayo W. schrieb: > Ja, ist es. Jörg hat dafür einen Treiber geschrieben, der auch in der > aktuellen Firmware auswählbar ist. Wie die Erfahrungen damit sind mußt > Du Jörg und Branadic selbst fragen. Wer das noch eingebaut hat weiß ich > nicht. Ist schon lange her, ich meine mich dunkel zu erinnern daß das in der BF-Firmware noch nicht recht hinhaut. Ich habe den Lowlevel-Support dafür gebaut, dann gab es etwas Schwierigkeiten mit der Integration, weil das (aus meiner Sicht) alles so vermurkst ist. Kann sein, daß ich mich da auf Hayo verlassen habe, das zuende zu stricken, aber er hat seine Platine nie eingebaut. Sorry daß wir jetzt beide im Kreis aufeinander zeigen... In Osoz funktioniert es "richtig". Es ist auch möglich, die Kanäle unterschiedlich zu bestücken. Jörg
Rainer, Du hast recht, merkwürdige Dinge gehen da vor. Muß ich mir mal genauer ansehen. Da ich über Ostern Besuch bekomme, wird das wohl erst was nächste Woche. Gruß Hayo
Sourceforge drängelt mit Erinnerungs-Emails, wir sollen unser Projekt endlich auf deren neue "Allura" Plattform umstellen. Nun kriegt man zusätzlich bei jedem Einchecken eine Erinnerung auf den Schirm. Ich habe mich noch nicht getraut das anzuschubsen. Im Netz liest man aber nichts schlechtes. Sicherheitshalber habe ich mir heute ein Backup des gesamten Repositories gezogen, das ist die Checkin-Historie. Also nicht das Wiki. Das gleiche habe ich bei einem anderen Sourceforge-Projekt von mir gemacht (OpenHC, da mache ich derzeit nichts), und gewissermaßen als Vorab-Test für uns das Update-Knöpfchen gedrückt. Damit ist das beantragt, wird irgendwann ausgeführt, man bekommt Nachricht. Keine Ahnung ob das ein automatisierter Prozeß ist oder da jemand werktags ran muß. Mal sehen wie lange das braucht. Das blöde ist, das die Commits zwische Beantragung und vollzogener Migration verloren gehen können. Wir müssen dann also ein Weilchen die Füße still halten. Jörg
Ok Rainer hab doch noch mal schnell versucht das Problem zu lösen. Hatte aber keine Zeit das jetzt tiefschürfend zu testen. Sieht aber für mich besser aus jetzt. Ich muß jetzt los zum Training und schaue dann gegen 23:00 noch mal rein. Gruß Hayo
Naaa, noch keine neuen Erkenntnisse? Morgen (heute) ist doch frei... Hayo
Guten Abend Hayo und all jene die an dem Projekt beteiligt sind Welec! Hayo W. schrieb: >Nachdem ich mir bei meinem Neuzugang - einem 100 MHz Pulsgenerator, der >leider defekt bei mir ankam - einen Wolf gesucht habe bis ich die >Fehlerquellen lokalisiert hatte, läuft das Teil jetzt wie Schmitts >Katze. Ich habe die Gelegenheit genutzt und passend zu unserem Thema >weiter oben ein paar Messungen vorzunehmen (gehört ja eigentlich in den >HW Thread). Ich würde nicht wie ein neugieriger schauen, genau das, was Modell ist Ihre neue Pulsgenerator? Vielleicht könnten Sie verwenden, um controlloare was passiert, indem die vertikale Größe (Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil5)") Ich weiß, dass ich langweilig bin, Entschuldigen Sie mich bitte. Interessant Screenhot! Vielen Dank Hayo und alle Unterstützer des Projekts Welec! Mit freundlichen Grüßen, Luc
Angehängte Dateien:
-
TR-0307.jpg
150 KB
Hi Luc, the pulse generator is an old device from the 80ies made in Hungary, type TR-0307 (EMG). It is completely analog controlled, no digital stuff in it. I like it because of the simple and uncomplicated handling. It is constructed very modular with high quality standard parts and is therefore good to repair if something is defect. It is working very fine now - and it was cheap! It has a rise time of 2.4ns and many possibilities of signal forming (variable rise and fall time), especially simulating fast glitches and spikes but also to produce a standard square wave up to 100MHz. Seems to be ideal for testing the W2000A models. > Vielleicht könnten Sie verwenden, um controlloare was passiert, indem > die vertikale Größe Unfortunately I did not understand, what you meant with this. Kind regards Hayo
Angehängte Dateien:
-
Lyons_PG_2B.jpg
130 KB
Guten Abend Hayo und all jene die an dem Projekt beteiligt sind Welec! Hayo W. schrieb: >the pulse generator is an old device from the 80ies made in Hungary, >type TR-0307 (EMG). Hi Hayo, thanks for your kind reply. Really a nice instrument, congratulation expecially for its repair: RESPECT! Me too I have a pulse generator, my equipment is an old Lyons Instruments PG-2B. It is maximum 10 MHz and its rise/fall time is 10ns minimum, so inadequate to test bandwidth in 100MHz DSO as Welec are claimed. Due this fact I built a 300ps pulse generator based on what Jim Williams described in LT App Note 47. By time I try to put my hands on some old oscilloscope calibrator but sadly to now yet I'm been not able to get one. Perhaps may be next time, we will see. Hayo W. schrieb: >Unfortunately I did not understand, what you meant with this. What I wanted to say is that perhaps your instrument could be capable to replicate my measure. I.E. set your pulse generator for a fast rise/fall time (about 300ps, otherwise surely less than 1ns) about 1ns duration 18Vpp amplitude pulse and see the waveform on your W2022a/W2014a changing Volt/Div setting in order to verify if the scale factor of the signal drawn on the screen remains correct, thing sadly do not succeed with both my W2022A and W2012A. But your instrument is only "2,4ns" as fast rise/fall time, so I think it is unable to do that test. That is why I asked for its identification. Of course, anyone else in possession of adequate instrumentation who wants try to repeat the measurements is welcome, thanks in advance! How I already wrote I'm interested about oscilloscopes' bandwidth verification, so I'd like to see a screenshot of the same pulse You posted in here (Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil5)") but this time catched by your Tektronix 2465A. So if You want and when You can easily get it, I'd like to take a look to a such kind of thing. Thanks in advance Hayo! I think the biggest difference, beyond the different pulse duration due to the different oscilloscopes performance as a rise and fall times, should be the waveform's amplitude, who it should be more great when it shown on the faster one instrument (better bandwidth). This is an important aspect of the matter, not only rise/fall time shape. By now a such kind of measure could be facilitated by the new "Peak to Peak detect" function. Of course, on the Welec side a such kind of measure must to be done using an hardware modified DSO, otherwise the lack in linearity bandwidth will hinder the achievement of the correct result. Hayo W. schrieb: Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil5)" Hayo, as always I thank You very much for your priceless work, RESPECT! Grüße und frohe Ostern an alle! Mit freundlichen Grüßen, Luc
Hi, today i upload 1.2.BF.6.5C2 firmware on my welec, and i set adc_change12_reg to 0x0 for Hifrequency mode (with this seting i dont have ringing), but whan i turn off oscilloscope and on, adc_change12 register is missing my value. I dont have this problem on 1.2.BF.6.1 and early version. Greating from Bosnia
Sorry for mistake, adc_change12 = 28000 is my best setting.
Hi Sladjan, > ...but whan i turn off oscilloscope and on, adc_change12 > register is missing my value. I changed the storage location of calibration and register values. They now have an own flash sector. > adc_change12 = 28000 is my best setting. I tested it and it seems to work ok on my W2014A, on the W2022A I got strong ringing on the signal. I added it in the hardware menu as "High Freq 2" Regards Hayo
Thanks a lot, setup work ok for me. I see one litle think. When I push "Center Channel1 OR Center Channel2" and restart oscilloscope (turn off and on), "center" setting is missing and line is back to default value.
May be I forgot the saving call for this function. I will check it and add it. You can use a work around - after centering you can switch your timebase one higher or lower and then back. This will trigger the saving routine. Hayo
Thanks, settings save after switch timebase.
Hallo Hayo, ich bin während der Arbeitszeit am Welec, daher erst jetzt die Rückmeldung, sorry. Die Logikerkennung mit richtiger Timebase scheint zu funktionieren. Super, danke. Jetzt noch ein Analyser für I2C, SPI, UART... oder eine schnelle USB online Datenübertagung zur PC-Analyse, dann wäre der (serielle) Logicanalyser da. Bitte nicht als (Auf-)Forderung verstehen, nur ein Wunschtraum. Viele Grüße, Rainer
Auch hier kurz der Hinweis auf den WELEC Einsteiger-Thread: Beitrag "Wittig(welec) DSO W20xxA Einsteiger" Hayo
Hallo, ich habe bei meinem W2022A die 1.2.BF.6.5C3 eingespielt. Seitdem stürzt das Oszi manchmal ab, wenn ein "Calibrate Offsets" durchgeführt wird. Dies ist abhängig von der Zeitbasis. Im ns-Bereich funktioniert alles normal bis 5us runter, bei 10us oder größer stürzt es ab. Bin testweise auf die 1.2.BF.6.4C6 zurück, da ist alles gut, das Problem fängt mit 1.2.BF.6.5 an. Gruß Ricardo
Hallo Ricardo, das weist normalerweise auf das übliche Problem mit dem RAM hin. Bei mir konnte ich noch keine Abstürze feststellen. Das heißt - Anschlüsse nachlöten. An Alle: Hat einer von Euch auch Abstürze? Gruß Hayo
Hey Hayo, ja ich kann mich dem Ricardo nur anschließen. Ich habe nur den Vergleich zwischen der 6.3, 6.5 und 6.5C3 ... ... die 6.5 und 6.5C3 zeigen einen Blue Screen (rosa Steifen) auf dem Display. Bei Tests mit Jörg war mir der direkte Vergleich vor Tagen aufgefallen (leider noch nicht zum posten gekommen). Grüße Andiiiiy
Ok, danke für den Hinweis! Dann muß Ricardo ja doch nicht an seinem RAM rumlöten. Ich schau mir das mal an ob ich das nachstellen kann, sonst frag ich noch mal nach. Gruß Hayo
Hi, habe's leider zu spät gesehen. Heute Abend gingen bei Ebay 4 LCDs weg: LQ104V1DF21. 10 Zoll, 640x480 und identische Stecker/Belegung. Vom Timing leichte Differenzen, z.B. ist die Gesamt- Zeilenlänge etwas länger. Da ich kein zweites Oszi habe, kann ich leider die Wittig-Zeilenlänge bzw. das Timing nicht messen. Wenn das mal einer machen könnte, dann kann man sich ja mal einen grösseren LCD zulegen (Nachteil: gleiche Auflösung). Das angebotene LCD habe ich auch schon als 12"-Version gesehen. Gruss
Der Fehler mit den Abstürzen beim Kalibrieren ist bestätigt. Da ist irgendwo ein übler Bug drin. Korrektur kommt so schnell wie möglich. Bis dahin bitte nur bei Zeitbasen >= 5µs kalibrieren. Hayo
Der Versuchsballon ist durch, ein Sourceforge-Projekt von mir ist jetzt umgestellt: Jörg H. schrieb: > Sourceforge drängelt mit Erinnerungs-Emails, wir sollen unser Projekt > endlich auf deren neue "Allura" Plattform umstellen. Nun kriegt man > zusätzlich bei jedem Einchecken eine Erinnerung auf den Schirm. ... > und gewissermaßen als > Vorab-Test für uns das Update-Knöpfchen gedrückt. Damit ist das > beantragt, wird irgendwann ausgeführt, man bekommt Nachricht. Keine > Ahnung ob das ein automatisierter Prozeß ist oder da jemand werktags ran > muß. Mal sehen wie lange das braucht. Heute bekam ich Nachricht, also nach knapp einem Monat. In der ersten stand, daß das Repository migriert wird, etwa eine Stunde später bekam ich Nachricht das es abgeschlossen ist und unter neuere Adresse auschecken soll. Habe ich ausprobiert, scheint zu funktionieren. Unser Welec-Projekt ist über das Warten auf diesen Test so spät dran, daß wir jetzt bereits mit Zwangsmigration bedroht werden: http://sourceforge.net/blog/upgrades-april22/ Wird also irgendwann passieren, nicht wundern. Jörg
Sorry, warum wusste ich schon immer, dass ich das nicht gut leiden kann? Auch die Spam von SF ist unerträglich. :-(
Hat wieder etwas gedauert, aber hier ist sie. Neu ist der Support für die Low Budget Mod. Ansonsten Bugfixes. Bitte nach dem Flashen im Hardwaremenü die Gain-Einstellung prüfen. Durch die LB-Mod haben sich die Einträge verschoben. Hayo
Not yet enough time to try but in the absence of other comments to this last work i say...THANKS!! :-)
Hallo Hayo, im Gain Menu steht standartmässig 1.000 ! Welche Gain Einstellung ist für die originale Bestückung relevant und welche für die modifizierte? Beim hochdrehen gehen die Nulllinien beider Kanäle auseinander (entgegengesetzt) dann gehen diese automatisch wieder in die ursprüngliche Position. Kannst du dazu etwas sagen? Gruß Michael
Bei 1.00 sind die Skalierungsfaktoren genau so wie sie im Programm vorgegeben sind bzw. wie Du sie im PreGain-Menu eingestellt hast. Für den Fall, dass bei Dir dann aufgrund von Bauteiltoleranzen oder Ähnliches die angezeigten Pegel nicht stimmen, kannst Du dann mit Werten die von 1.00 abweichen den Pegel korrigieren. Der eingestellte Skalierungsfaktor wird mit dem angezeigten Gain multipliziert. Beispiel: Wer die LB-Mod drin hat stellt im PreGain natürlich "LB-Mod" ein. Der Skalierungsfaktor ist dann 1.6 bei den 5er Bereichen (Bei Gain 1.00). Wenn Du z.B statt 330 Ohm Abschluß nur 300 Ohm verwendest, wirst Du einen größeren Skalierungsfaktor benötigen. Dann drehst Du den Gain langsam hoch z.B. auf 1.15) und kalibrierst das Gerät nochmal. Danach ist der Skalierungsfaktor 1.6 * 1.15 = 1.84 War das einigermaßen verständlich? Gruß Hayo p.s. Bin gerade dabei in meinem Zimmer neue Fenster einzubauen, daher bin ich etwas "offline".
Also bei meinem Scope scheint der Single Shot nicht mehr zu funktionieren. Man kann das Scope zwar noch für einen Single-Shot scharf schalten und er scheint auch zu Triggern (Run/Stop schaltet nach dem Trigger Event auf rot) aber auf dem Schirm wird immer noch das Signal angezeigt, das vor dem Single Shot schon da war. Verhalten war schon bei 1.2.BF.6.5 so und ist bei 6.6 immer noch so.
Jörg H. schrieb: > Unser Welec-Projekt ist über das Warten auf diesen Test so spät dran, > daß wir jetzt bereits mit Zwangsmigration bedroht werden: > http://sourceforge.net/blog/upgrades-april22/ > > Wird also irgendwann passieren, nicht wundern. Gestern ist es passiert, unser svn Repository ist umgezogen. Es ist ganz einfach, die Arbeitskopie auch drauf folgen zu lassen. Noch einfacher als die Email von Sourceforge beschreibt, man braucht nur im obersten Verzeichnis des eigenen Checkouts folgendes eingeben:
1 | svn relocate https://svn.code.sf.net/p/welecw2000a/code |
Beim nächsten Checkin wird man dann noch mal nach Username und Password gefragt. Zwei kleine Commits habe ich schon erfolgreich in das neue Repository gemacht. Wir sind jetzt übrigens bei svn Revision #999, der nächste Commit wird der "Jubiläumscommit" #1000. (Ziemlich genau die Hälfte der Checkins ist von mir.) Jörg
Herr Lehmann schrieb: > Also bei meinem Scope scheint der Single Shot nicht mehr zu > funktionieren. Ja es gibt einen Fehler, der indirekt durch die Umstellung der Ausleselänge zustande kommt. Das ist in der BF.6.7 bereits behoben, aber ich muß noch die Faktoren für die OPA653 Mod anpassen, dann kommt die neue Version. Gruß Hayo
Ah, schön zu hören, daß es tatsächlich an der Firmware liegt und nicht an meiner Unfähigkeit, das Gerät zu bedienen. Jetzt habe ich noch eine blöde Frage: wäre es möglich, den Drehsinn der Zeitbasis und der V/div Knöpfe umzukehren (Option im Setup)? Ich bin es gewohnt, daß Uhrzeigersinn größere Werte sind, bei unserem Scope ist es aber genau anders herum.
Oh wie peinlich, bitte vergißt die Geschichte mit dem Drehsinn ganz schnell. Ich habe gerade gesehen, daß dieses Thema schon länger durchgekaut wurde und jetzt komme ich schon wieder damit an. Entschuldigung, das tut mir leid.
Kein Problem, bei meinem Tek ist der Drehsinn übrigens auch im Uhrzeigersinn zu den kleineren Zeitbasen hin. Passt also gut wie es ist. Hier die neue Version mit Unterstüzung der OPA653 Mod und noch einigen Änderungen/Fixes. Gruß Hayo
Hey Hayo,
ich hatte ja schon Anfang des Jahres von meinen Spike Problemen auf
Kanal 2 berichtet. Schon damals hatte "sar" ähnliche Probleme geäußert.
Ich habe das Wittig mittlerweile ausgemustert, allerdings ist mir jetzt
ein Topic im Marktplatz aufgefallen wo auch wieder jemand ("sh0dan") von
vorher nicht vorhandenen Spikes auf Kanal 2 berichtet. Die Spikes traten
scheinbar nach einem Update auf und stehen eventuell wieder in
Zusammenhang mit der Temperatur.
Bei mir kann ich das zeitlich auf ca. die Version 5.8 eingrenzen,
möglicherweise auch etwas davor da ich nicht jede Version getestet habe.
Auf einmal waren jedenfalls dann die massiven Spikes da, die ich davor
nie! hatte.
Meine Frage:
Hat BF5.8 oder eine vorige Firmware Version einen Speicherbereich oder
sonstiges verändert, der beim löschen mit Welec Updater oder einem neuen
Flashen nicht mehr rückgesetzt werden kann?
Ich bekomme bei mir die Spikes in keiner Konfiguration mehr weg. Ich
denke da an die Funktionen, die ins Flash geschrieben wurden o.ä.
Einen alterungsbedingten Hardware-Defekt, der bei nun 3 Leuten innerhalb
von wenigen Monaten auftritt, halte ich mittlerweile für sehr
unwahrscheinlich. Diese "Hardcore-Spikes" (man beachte die Screenshots,
das ist mehr als "altbekannten" Spikes an der Flanke etc.) wurden
jedenfalls nach meiner Recherche noch nie vor Dezember 2012 berichtet.
Es ist mit Sicherheit ein Timingproblem das in Zusammenhang mit dem
FPGA-Design steht und die ADCs betrifft, nur wird dieses nach meinen
aktuellen Erkenntnissen durch eine Änderung der Firmware hervorgerufen
bzw. begünstigt.
Ich denke doch, dass das diese Sache mehr als ein Einzelproblem mit
manchen Scopes ist.
Wäre toll, wenn du dir das aus Firmware Sicht nochmal ansehen könntest.
Hallo Ben, nach zwei Tagen Sturm im Ionischen Meer in einer einsamen Bucht, bin ich heute mal wieder dank WLAN online. Ja das Thema Spikes ist ja kein Neues. Auch der Zusammenhang mit dem thermischen Zustand des Gerätes wurde mehrfach berichtet. Wobei aber interessanterweise bei einigen Geräten die Spikes mit warmem Gerät verschwinden, während bei anderen die Spikes erst bei warmem Gerät auftauchen. Wesentlich scheint hier die Hardwareversion (FPGA-Version) zu sein. Softwareseitig (Firmware) habe ich aber seit einiger Zeit nichts verändert. Bei meinen beiden Geräten kann ich auch keine Auffälligkeiten gegenüber vorher feststellen. Hast Du evtl. die Hardwareeinstellungen anders als vorher? Wenn man die "High Frequency" Einstellungen benutzt hat man teils deutlich mehr Spikes als in der "Factory" Einstellung - dafür aber keine Signalverzerrung bei hohen Frequenzen. Auch der Ausschnitt des Signals auf der Zeitachse (in denglisch "Pretrigger" und "Memory Browser") hat in Verbindung mit der Zeitbasis Einfluß darauf. Soll heißen, wenn man mit anderen Einstellungen arbeitet als vorher, kann es sein, dass es einem mehr auffällt. Als Gegentest kann man ein Komplettbackup mit der alten Originalfirmware einspielen um zu testen ob es da Unterschiede gibt. Das haben auch schon Einige getan um dann festzustellen, dass es vorher auch schon so war, aber irgendwie nicht so aufgefallen ist. Gruß vom Skipper Hayo
Hast du dir mal die Spike-Screenshots angesehen? Es rammelt die Spikes dauerhaft, das fällt jedem sofort auf. Natürlich sind nicht alle Geräte betroffen, genauere Untersuchungen welche HW Version es ist müssen wir noch anstellen. Bei mir sind die Spikes (wie berichtet) auch nie wieder verschwunden d.h. auch nicht nach einem Komplettbackup. Und dass hier mehrere auf einmal von Spikes berichten, die sie vorher nie hatten, ist schon merkwürdig, findest du nicht? Schau mal die Threads durch, es gab DIESE Spikes nicht vor Dez. 12. Unabhängig von der thermischen Abhängigkeit ist ja alleine schon das plötzliche auftreten der vorher_nie_vorhandenen Spikes merkwürdig! Achso, HW Einstellung ist Factory, sonst wird alles nur schlimmer.
Mit dem neuen FPGA-Design ist das Geschichte, da gibt es keine Spikes mehr. Kein Grund, Geräte dauerhaft auszumustern. Jörg
das stimmt, ich erwarte auch gespannt das finale FPGA Design. Aber als einziges Scopes war das Wittig schon immer sehr gewagt, und mit diesen Spikes ist es eben total unbrauchbar. Da kann ich also nicht warten... Obwohl dieses Projekt inkl. deiner sehr vielversprechenden Arbeit eigentlich der Hauptgrund ist, das Wittig noch im Regal stehen zu lassen :) Dennoch- es wurde halt zum Bastel- Scope degardiert und "gemessen" wird mit was anderem. Bleibt für mich auch unabhängig davon, dass der neue FPGA Entwurf besser ist ;) die Frage, warum das überhaupt passiert ist- das Original Design hatte diesen Fehler (starke Spikes Kanal 2) ja ursprünglich (bei mir und 2 anderen) nicht. Hat mir jemand vielleicht ein aktuelles Dump vom 2022A (kompletter Speicher) mit der BF-FW?
@Ben > Hat mir jemand vielleicht ein aktuelles Dump vom 2022A (kompletter > Speicher) mit der BF-FW? welche Version denn???
elecBlu schrieb: > Hast du dir mal die Spike-Screenshots angesehen? Es rammelt die Spikes > dauerhaft, das fällt jedem sofort auf. > Natürlich sind nicht alle Geräte betroffen, genauere Untersuchungen > welche HW Version es ist müssen wir noch anstellen. > Bei mir sind die Spikes (wie berichtet) auch nie wieder verschwunden > d.h. auch nicht nach einem Komplettbackup. > Und dass hier mehrere auf einmal von Spikes berichten, die sie vorher > nie hatten, ist schon merkwürdig, findest du nicht? Hi, habe wieder WLAN hier auf dem Boot und nutze die Gelegenheit mal um zu antworten. Also wenn Du nach dem Einspielen eines Komplettbackups immer noch grobe Spikes hast, gibt es nach meiner Logik nur zwei Möglichkeiten: 1. Es ist Dir vorher nicht so aufgefallen, weil Du andere Einstellungen verwendet hast. 2. Irgendetwas an Deiner Hardware hat sich geändert (thermisch, Alterung, lose Pins etc.) Jedenfalls ist das Gerät ja nach dem Einspielen des Backups wieder im Originalzustand, so dass die BF-Firmware nicht dafür verantwortlich sein kann. An der FPGA-Konfiguration kann die Firmware nichts verändern, das scheidet also aus. Gruß Hayo
eben deshalb war ja meine Frage oben ob über oder unter dem üblichen Dump- Speicherbereich was geändert wurde/ wird! Insbesondere das schreiben der Math- Funktionen ins Flash mit 5.7! Da es in einer folgenden Version (ich hatte nicht jedes Release geflasht) auftrat. Wenn das nicht der Fall ist, kann es das wohl nicht sein das ist mir auch klar. Und es wäre sofort aufgefallen, glaubs oder glaubs nicht, wenn die Spikes vorhanden waren, siehe Screens und damalige Beschreibung. Ich habe das Gerät 3 Jahre genutzt, genauso wie "sh0dan" mir fast identisches berichtet hat. @ Michael: Hardware 8C7.0, BF Version eigentlich egal. Also Obacht Leute, nach 3,5 - 4 Jahren verabschieden sich die Welecs bevorzugt, hardwarebedingt ;) Gabs nicht 3 Jahre Garantie? Höhö.
Ben L. schrieb: > eben deshalb war ja meine Frage oben ob über oder unter dem üblichen > Dump- Speicherbereich was geändert wurde/ wird! Insbesondere das > schreiben der Math- Funktionen ins Flash mit 5.7! Naja, wenn Du ein komplettes Backup wieder zurückspielst ist halt alles wieder original, also das komplette Flash. Da ist dann nix mehr oberhalb oder unterhalb was anders sein könnte. Das Einigen verstärkte Spikes aufgefallen sind glaube ich schon. Aber ich kann mir aus besagten Gründen nicht vorstellen, dass es einen Zusammenhang mit der BF-Firmware gibt. Beide Geräte die ich verwende arbeiten da genauso wie mit der originalen Firmware. Beide haben auch sehr unterschiedliches Spike-Verhalten. Aber wie Jörg schon anmerkte, ist das ja zum Glück bald Geschichte :-) Gruß vom Skipper
Morgen, ich hab jetzt das W2022A von sh0dan,von den Spikes merk ich nichts(ca. 20°C), aber das Oszilloskop hängt sich oft auf wenn ich Coupling oder Probe verstellen möchte, dann ignoriert es alle Eingaben abgesehen von den Drehgebern. Firmware ist 1.2.BF.6.7 MFG Henning
Angehängte Dateien:
-
25MSa-s-10us.png
4,4 KB -
250MSa-s-5us.png
4,6 KB
wo ich gerade mal dabei bin... 1kHz Rechteck, 25MSa/s 10µs, ist alles schön sauber. Eine Stufe weiter, also 250MSa/s 5µs, sind die Spikes extrem bis 20ns. Siehe Shots! Jetzt stellt sich mir die Frage, was wird ab 250MSa aktiv... EDIT: Die Screenshotsoftware kennt keinen COM10 ?
Michael D. schrieb: > Jetzt stellt sich mir die Frage, was wird ab 250MSa aktiv... Ich kann's grad nicht testen, aber bei meiner Hardware wird es (mit dem alten FPGA-Design, versteht sich) oberhalb von 250MSa ganz schlimm. Sogar das LCD ist dann gestört. Die Hardware geht dann in einen Modus der alle 4 ADCs verwendet. Das ist wohl irgendwie anstrengender. Wo wir gerade dabei sind: in der BF-Firmware gibt es immer noch diesen merkwürdig großen Sprung von 25 MSa auf 250 MSa. Das muß nicht sein, habe ich Hayo auch schon früher drauf hingewiesen, aber vielleicht nicht deutlich genug. Hayo, guck dir mal die Funktion CaptureSetTimebase() in osoz/platform/nios/src/capture.c an. Die alte Hardware teilt von 1 GSa abwärts, erstmal mit Halbierungen: /1: 1 GSa /2: 500 MSa /4: 250 Msa /8: 125 MSa /16: 62,5 MSa Dann geht es in 8er Schritten quasi unendlich weiter: /32: 31,25 MSa /40: 25 MSa /48: 20,833 MSa /56: 17,857 Msa ... usw Es sind also noch 2 Stufen zwischen 25 und 250 MSa. Zu den langsameren Teilern werden die Abstände immer feiner, ist halt reziprok. Der Teiler hat volle 32 Bit Auflösung, das geht also bis grotesk langsam. Jörg
@Jörg > Ich kann's grad nicht testen, aber bei meiner Hardware wird es (mit dem > alten FPGA-Design, versteht sich) oberhalb von 250MSa ganz schlimm. > Sogar das LCD ist dann gestört. Ja, wie man sieht... Was händelt dann das neue Design die ADC's, das diese Spikes nicht auftreten?
Michael D. schrieb: > @Jörg >> Ich kann's grad nicht testen, aber bei meiner Hardware wird es (mit dem >> alten FPGA-Design, versteht sich) oberhalb von 250MSa ganz schlimm. >> Sogar das LCD ist dann gestört. > Ja, wie man sieht... Nein, anders, bei mir ist dann ein Teil des LCD grisselig. Vermutlich gibt es dann Timing-Fehler beim Auslesen des Bildschirmspeichers. Das ist also noch ein anderes Problem. Die Spikes hingegen sind vermutlich Timingfehler bei der Signalverarbeitung. > Was händelt dann das neue Design die ADC's, das diese Spikes nicht > auftreten? Frag' mich lieber, was das alte Design falsch macht... Soweit wir wissen hat es keinerlei Timingchecks. Die Synthese weiß gar nicht wie schnell die Logik laufen wird und kann deshalb nicht prüfen, ob das noch paßt. Die Daten werden dort mit den vollen 250 MHz verarbeitet. Das ist zwar das Maximum, was die Einzelkomponenten des FPGAs leisten können (Speicher, Multiplizierer, Logikzellen, etc.), aber für eine ganze Baugruppe eines Designs viel zu schnell, das Routing und die Logik ist auch noch da. (Das ist ungefähr so, wie ein Auto für 250 km/h zu bauen, weil's grad auf den Reifen und dem Tacho draufsteht, ohne den Konstukteuren von Bremsen und Fahrwerk zu erzählen was es werden soll.) Die Sampleverarbeitung van Alex arbeitet mit dem halben Takt und verarbeitet pro Takt doppelt so viele Werte, parallel. Zugegeben wird auch viel mehr gerechnet, die Filterei gab es ja vorher gar nicht, schon von daher können wir nicht so schnell. Wir fahren also halb so schnell, aber mit 2 Autos, schaffen das gleiche rüber. Jörg
Ich habe mir in der Bucht ein "jungfräuliches" W2022A geschossen und habe festgestellt, dass der Update auf eine neueste Version über den WelecUpdater nicht funktioniert. Der Upload kommt anscheinend bis Zeile 5. Anschließend kommt nur noch die Meldung "Uebertragungsfehler: ? xxxx" Bis kurz vor BF.5.2 (5.1C?) ist ein Update noch möglich. Bei den darauf folgenden Versionen wurde anscheinend ein schnellerer Loader eingeführt, was möglicherweise den Fehler verursacht. Erst über Perl konnte ich mein Gerät auf BF.6.7 updaten. Das Testsignal auf Kanal 2 sieht bei BF.6.7 merkwürdig aus. Es sollte vermutlich ein Sinus sein, besteht jetzt aber aus einzelnen Sinusperioden, welche durch Nullinien miteinander verbunden sind. Getestet habe ich auf zwei verschiedenen PCs jeweils mit XP. Hardwareversion des Gerätes ist 8C7.0E. Natürlich will ich nicht nur meckern, ganz im Gegenteil, Hut ab vor Euren Programmierkünsten.
Meines Wissens ist nach dem erstem Update auf Hayos FW die Wellec SW nicht mehr für Updates zu gebrauchen. Wurde mehrmals hier im Forum so beschrieben, man soll es gar nicht probieren. Ist auch kein Schaden, der Update-Vorgang mit Wellec-Sw dauerte gute halbe Stunde.
Gute Nacht, Hayo und all jene, die an dem Projekt beteiligt sind WELEC. Having upgraded my W2012A with the OPA653 I installed the latest firmware 1.2.BF.6.7 by Hayo, so I noted some weird things. Maybe I'm wrong, however: 1) Coupling channels are labeled as [DC (ext)] and [AC (ext)], I can not find GND (yes, I know someone wanted it to be deleted because it is really just a dummy fiction, but it seemed to me that in the end it was decided to keep it). However, what means (ext)? 2) When the waveforms' amplitude exceeds some limit the upper and bottom become flat. I guess it is due the exceeded in the ADC range that now it is very different that before. It is not a real problem, but as it is now seems to me that the screen's area is not efficiently used. I hope to have been understandable. 3) Some fake labels and controls' icons when You play with the setting. I will more precise next time when I will test better this for me new firmware. As always all I wrote is not intended as criticisms but only for knowledge. And as always Hayo RESPECT for You and all your hard work! Thank You very much Hayo! Nochmals vielen Dank Hayo und Vielen Dank an alle Unterstützer des Projekts Welec! Mit freundlichen Grüßen, Luc
Luc schrieb: > Coupling channels are labeled as [DC (ext)] and [AC (ext)], I can not > find GND (yes, I know someone wanted it to be deleted because it is > really just a dummy fiction, but it seemed to me that in the end it was > decided to keep it). > However, what means (ext)? ext -> External Trigger This are the settings for the external trigger. Therefore you won't find a GND coupling. The coupling for the channels You will find in the channel menu of each channel. > When the waveforms' amplitude exceeds some limit the upper and bottom > become flat. Seems that there is something wrong with the gain or with the resistors in your mod. Could you provide us with a screenshot? Kind regards Hayo
kingcopper schrieb: > Bis kurz vor BF.5.2 (5.1C?) ist ein Update noch möglich. Bei den darauf > folgenden Versionen wurde anscheinend ein schnellerer Loader eingeführt, > was möglicherweise den Fehler verursacht. Hi, etwas späte Antwort - ab 5.2 (glaube ich) wurde der Loader mit komprimiertem Coding eingeführt (UCL). Vermutlich ist das der Grund. Gruß Hayo
Gute Nacht, Hayo und all jene, die an dem Projekt beteiligt sind WELEC. Thank You for the reply Hayo and happy to meet You again! :-) Hayo W. schrieb: >ext -> External Trigger > >This are the settings for the external trigger. Therefore you won't find >a GND coupling. The coupling for the channels You will find in the >channel menu of each channel. hhuummm... Hence I must to have a problem. Indeed I found [(ext)] and I am unable to find the correct ones. Maybe something has gone wrong performing the upgrade. I did firmware upgraded before the hardware modification, but I do not think it is the culprit. I will try to reprogram the DSO. Thank You for the hint Hayo! Hayo W. schrieb: >Seems that there is something wrong with the gain or with the resistors >in your mod. I am pretty sure components are correct and correctly placed and welded. I guess the culprit is somewhere else, I suspect bad tune in the compensation of the channels' input stages. I must to investigate about that. ;-) Hayo W. schrieb: Could you provide us with a screenshot? Sadly right now I am far from my DSOs, but stay tuned for the future: I warn You!... ;-) Again I thank You very much Hayo for all your contributions and hard work You share with us, RESPECT!!!!!!! Nochmals vielen Dank Hayo!!! Mit freundlichen Grüßen, Luc
Gute Nacht, Hayo und all jene, die an dem Projekt beteiligt sind WELEC. @Hayo Hayo, wie immer, Sie hatten recht. Ich folgte Ihren Vorschlag durch das Laden der Firmware wieder und alles geregelt ist: KLASSE! Leider ist die Frage der Bandbreite hat sich nicht geändert. Als Lösung habe ich versucht, die Eingangskanäle zu kalibrieren mit dem Rechteckgenerator, die ich gebaut. Ich habe entdeckt, dass es nicht in Ordnung für diesen Zweck, Berühren der Kompensatoren nichts passiert. Ich vermute, dass selbst bei 33 MHz ist der Generator zu schnell auch als Zeit des Auf-und Abstieg. Statt der Generator funktioniert perfekt für die Auswertung der Bandbreite. Ich habe die Instrumente mit Generator 500ps und mit Marconi 2019A überprüft und praktisch habe ich die gleichen Ergebnisse. Also für die Bewertung der Bandbreite funktioniert gut für mich und ist ein nützliches Werkzeug, es ist jedoch nicht geeignet, um die Kompensations-Eingangs einzustellen. Ich habe, um die Eingänge mit dem alten Lyons Instruments PG-2B einstellen. Ich werde hier zu stoppen,der Nächste! Vielen Dank an alle Unterstützer des Projekts Welec! Mit freundlichen Grüßen, Luc
Angehängte Dateien:
-
test_50_MHz.JPG
59 KB
Hello I tested the last firmware with input OPA amp. modification(datasheet states a Ft of 600MHz),great job as usual from Hayo,low noise in the 10 mv volt /div and improved frequency response. But just a little bug in the trigger,please see enclosed file,using for example a 50MHz sinewave,the sine around trigger point has a distortion,didn't noticed with old firmware. Happy 2014 and thank you to all the DSO team and Hayo for this last project. Sandro
Hi Sandro, thanks for reporting. I will check this and try to fix it as soon as possible. Greetings and a happy new year to all from Valle de Aosta in bella Italia Hayo
Happy new year Sandro, I see trigger position on the axis of time it's out of the video area it being far left. By chance have you saw the same problem putting it within the area of the video? Glad you wrote about the OPA amp. modification. Was your DSO the 100MHz or the 200MHz version? Pretty good shape for the waveform but filter is on, would be better to see it with filters switched off. Even if 50MHz is low frequency, would be better increase it a bit. You can say ~100MHz or more. Noise and gain should be much improved for sure. While Ft is for sure 600MHz in the datasheet, but the real one on the DSO? Did you do some measures? You can read different opinions on it. Victor
moinmoin Hayo & Co., ziemlich ruhig hier ;) habe eben versucht im single mode signale 'einzufangen', leider wird bei einer TB groesser 5µS in der Ver 6.7 nix mehr dargestellt ;(, habe mich bis zur 6.3 zureckgeschafft, da scheint es noch zu funktionieren, koenntest du bitte mal nachsehen und uns ein update hochladen, vielen Dank! vlG Charly ps. wenn 'Single' auf warten steht (rot) und an der TB gedreht wird sollte die Signale auf dem Schirm geloescht werden
:
Bearbeitet durch User
Hallo Charly, ich habe Deine Email bekommen, antworte aber trotzdem mal hier im Forum. Zur Zeit bin ich mal wieder im Ski-Urlaub :-). Daher auch eine etwas verzögerte Reaktion. Die Probleme mit dem Singletrigger waren mir kürzlich auch schon aufgefallen.Da sich bisher noch keiner darüber beschwert hat war ich mir nicht ganz sicher ob ich bei mir was falsch eingestellt hatte. Bisher bin ich noch nicht dazu gekommen der Sache auf den Grund zu gehen, aber ich werde mich mal dransetzen sobald ich wieder zuhause bin. Gruß Hayo
Hallo, ich wollte nur mal sagen, dass ich auch das Problem mit dem Single-Modus habe. Außerdem ist mir aufgefallen, dass es einen Darstellungsfehler im USTB-Modus gibt: Wenn man die TB auf 1s stellt und im Roll-Forward-Modus das Zeitfenster mit der Browse-Option anzeigen lässt, wandert der rechte Begrenzungsstrich oben in der Zeitleiste aus selbiger heraus. Irgendwann kommt er dann von links wieder ins Bild. Grüße Lukas
Moinmoin Hayo, wollte nur mal kurz 'nachtriggern' ob es schon was neues gibt :) vG Charly
Moin, die Sache ist nicht vergessen. Der Messplatz ist bereits aufgebaut, aber ich bin zur Zeit etwas eingespannt und komme daher nicht so richtig dazu mich dran zu setzen. Soll aber auf jeden Fall in Kürze weiter gehen. Gruß Hayo
moinmoin, super Hayo, dann handelt es sich ja nur noch um nS bis es losgeht ;) wenn du soweit bist schreib mir event. eine PN, i haette noch ein paar 'unschoenheiten' die event. mit ein paar Zeilen auch zu beseitigen sind vlG Charly
Dem Charly geht's mal wieder nicht schnell genug :-))) Eigentlich könntest du uns deine erwähnten "Unschönheiten" mitteilen, oder? Gruß Michael
jojo, so ist das........ ich habe das Oszilloguck sehr oft im einsatz daher ist es manchmal schon a bissel stoerend wenns nicht so will wie ich mir das vorstelle.... mit den 'unschoenheiten' will ich jetzt noch keinen verrueckt machen da ich ein Downgrate auf die 6.3 gemacht habe und event. die meisten davon schon beseitigt sind, ist also nix geheimes, wenns hier interessiert kann ich es natuerlich auch hier posten vlG Charly
Hi Charly, bin gerade vom Griechen zurück. Poste das mal ruhig hier, dann kann man auch drüber diskutieren in wieweit man da Änderungen einfließen lassen sollte. Muss mich auch erst mal wieder in die ganze Sache reinwursteln da ich mich in letzter Zeit mehr mit Langwellen, Mittelwellen und Kurzwellenempfang beschäftigt habe. Als krassen Gegensatz zu unserem SMD-gespickten DSO habe ich über Winter einen alten U-Bootempfänger aus dem 2. Weltkrieg renoviert - da bekommt man schon ein anderes Gefühl für die Dimensionen von Bauteilen und Betriebsspannnungen (300V!!!). Wenn man bedenkt, dass diese Technik mit den Röhren und Bauteilen in Kartoffelgröße damals aktueller Stand der Technik war... Immerhin kann ich da noch alles ohne Brille erkennen :-) Gruß Hayo
moinmoin Hayo, beim Griechen haett i dir helfen koennen ;) bei dem U-Boot RX haett i auch gerne mitgemacht, ist immer interessant wie die Jungs damals gebaut haben, i hab hier auch 'grobtechnik' mit der 3-500Z, GS31 / GS35 u. 4CX1500 in der Pipeline, komme aber im moment nicht dazu ;( hier so ein paar Punkte dir mir einfallen: 1. die Einstellung f. den Tastkopf wird nicht dauerhaft gespeichert (z.B. 10:1) 2. wenn ein Signal zb. mit 5V anliegt das kurze impulse nach 0V hat und man dreht an der TB,, schaltet mal in den Single & wieder zurueck, usw dann triggert er nicht mehr, man muss die Probe abklemmen und wieder drann dann laufts als waehre nix gewesen 3. ruft man Speicher auf, und ueberlappt signal mit memory dann vergisst er irgendwann die einstellung f. Y und schaltet dort auf 2V/Div. (meine ich mich zu errinern) vielleicht bin i auch zu verwoeht, hatte durch meinen vorherigen job ein 'grosses' Agilent da, das ist jetzt leider weg ;(( ps. bitte denk daran dass i mit der 6.3 arbeite weil in spaetern versionen der Single nicht mehr wollte vlG Charly
Moin Hayo, über deine Ausdrucksweise könnte ich mich immer wegschmeißen..."Kartoffelgröße" :-))) Hast du deine Restauration dokumentiert? Ich finde sowas immer hochinteressant und es wäre bestimmt einen eigenen Thread wert! Es ist schon sehr lange her, das bei Entrümpelungen die Röhrengeräte auf der Straße standen. Die habe ich mir immer geschnappt, Röhren ausgebaut und gesammelt(als Ersatz für defekte Geräte). Heute würde ich dafür bestimmt gutes Geld bekommen, leider hatte die Verwandschaft alles entsorgt... Gruß Michael
Oh! Hätte ich gar nicht gedacht, dass hier auch an sowas Interesse besteht. Ist natürlich alles dokumentiert. Ich mache gerne einen Thread dafür auf. Das Gerät steht übrigens auch im Horchraum des U995 in Laboe - ich poste den Link im neuen Thread. Hayo
So, wie versprochen hier der Link zum neuen Thread über Röhrenradios - bevor es hier zu offtopic wird :-) Beitrag "Restaurierung alter Röhrenempfänger - Telefunken Ela1012a/b" Hayo
Hallo Leute, heute habe ich mich nach der Arbeit mal durchgerungen und mich um die Firmware gekümmert. Das Triggerproblem ist nun gefixt. Bei den anderen gemeldeten Problemen konnte ich das nicht so recht nachstellen. - Die Probeeinstellungen werden bei mir einwandfrei gespeichert. - die Triggeraussetzer nach drehen der TB und Singleshot habe ich nicht hinbekommen -> vielleicht noch mal prüfen und dann genauer beschreiben wie man das nachstellen kann - die Einstellungen beim Overlay haben bei mir problemlos funktioniert - Im Ultra Slow-TB Modus gab es (leider) auch keine Auffälligkeiten Das Ganze getestet mit der aktuellen 6.8. Falls da doch noch Bugs sein sollten bitte mit genauer Anleitung wie ich das nachstellen kann. Gruß Hayo
Danke Hayo!!! wie beschrieben waren die Fehler bei mir mit der 6.3, i bekomme verm. am Fr. die neue Platine und dann bin ich wieder 'verstaerkt' in der HW u.SW entwicklung und da 'qualmt' das oszi wieder ;) vlG Charly
Hallo zusammen! Lieber Hayo, Danke und schön, daß Du wieder etwas Zeit für die Oszi Firmware hattest! Ich habe mit der Version BF6.8 mal alles was mir so seit BF5.10 aufgefallen war nochmal durchgespielt und getestet. Hauptproblem bei der Arbeit mit dem Oszi war/ist die Triggerauslösung bzw, des erneuten Startes der Signalaquise nach der Änderung der Einstellungen zur Signaltriggerung. Dazu gab es ja immer wieder Hinweise im FW-Thread. Grundsätzlich soll der NORMAL-Mode der funktionierende Modus sein! Ich versuche mal zu beschreiben: Wenn man z.B. den Triggerpegel im Edge-Modus langsam und schrittweise höher als das dargestellte Signal stellt, hört die Triggerung auch korrekt auf.Wenn danach der Triggerpegel wieder kleiner gemacht wird und in das Signal hinein dreht, funktioniert die Triggerung auch wieder, wenn der Pegel wieder auf Signalhöhe ist. Im Pulsewidth-Modus funktioniert dies nicht immer.Zusätzlich kommen noch die Zeitparameter für die Impulse ins Spiel. Auch wenn man diese verstellt, soll die Triggerung/Signalaquise wieder starten, wenn die Parameter wieder zum Signal passen. Z.B. kann man im Modus "><" den größeren Wert herunter drehen. Falls die Impulslänge nicht mehr passt bleibt das Signal stehen. Dreht man danach wieder auf die alten Werte zurück, startet die Triggerung nicht mehr. Sie läßt sich meist erst durch Verstellen der Timebase (Mainwheel) wieder starten. Grundsätzlich sollen nach einer Änderung aller für den Modus relevanten Triggerparameter alle für den Modus relevanten Parameter wieder zur Hardware geschrieben werden und die Signalaquise auch wieder gestartet werden. Ich kann leider im Moment nicht übersehen, ob es in der Firmware noch Situaionen gibt, die dies verhindern?? Es gibt sicher noch andere Einstellungen, nach deren Wechsel es sinngemäß auch funktionieren muss. Vielleicht geht da ja noch was :-) Viele Grüße Jürgen
Hi Jürgen, die Probleme beim Pulsweitentrigger die Du beschreibst sind mir bekannt. Leider kann ich da firmwareseitig nicht viel machen, da das Hauptproblem eine lausige Implementierung der Triggerfunktion im FPGA ist. Gruß Hayo
Angehängte Dateien:
-
USTB-Bug.png
2,8 KB
Hallo, ich habe mal einen Screenshot von dem USTB-Bug angehängt. Um ihn zu reproduzieren muss ich nur einmal in "Utility" auf "Default Setup" drücken und dann die Zeitskala bis auf 1s/ drehen. Wenn mann dann "Browse" einschaltet, wandert der rechte Strich in der Leiste wie auf dem Bild zu sehen aus selbiger heraus. Gibt es außer auf "Default Setup" zu drücken vielleicht noch ne andere Möglichkeit die Standardeinstellungen wieder herzustellen? Also, um wirklich alles wieder auf Null zu setzen? Mir ist noch die Kleinigkeit aufgefallen, dass oben links auch die ganze Zeit der Pfeil eingeblendet ist, der normalerweise anzeigt, dass der Trigger links außerhalb des Bildbereichs liegt. Der sollte in diesem Modus wahrscheinlich eigentlich nicht angezeigt werden, oder? Grüße Lukas
Aahh, danke Lukas. Damit kann ich gezielt auf Fehlersuche gehen. Gruß Hayo
Hi at Victor, yes is possible to improve the max. frequency adjusting the RC network input OPA but each DSO flatness should be individually calibrated and there isn`t enough memory to do it. And higher bandwith means higher noise,now is one of the lowers in its class. Let`s wait for next improvements about fast trigger point and ustb. Thank you to Hayo and all the Team and happy Easter from Italy. Sandro
Hallo, ich hab mal ein bisschen daran "herumgeschraubt" und die Triggerei verbessert. Auch die Pulsewidth Triggerung geht jetzt besser. Hayo W. schrieb: > Leider kann ich da firmwareseitig nicht viel machen, da das Hauptproblem > eine lausige Implementierung der Triggerfunktion im FPGA ist. Liegt nicht nur am FPGA :-) Wer mag, kann ja mal etwas testen und Rückmeldung geben. Noch einen schönen Feiertag! Gruß Jürgen
Hi Juergen, koenntest du bitte auch ein .flash hochladen, Danke! vlG Charly
Hallo Jürgen, ich bin leider noch nicht dazu gekommen Deine Triggermodifikation zu testen. Aber vielleicht könntest Du mir sagen was Du genau verändert hast, dann kann ich das gezielter testen und evtl. in das nächste Release einbauen. Gruß Hayo
Charly B. schrieb: > koenntest du bitte auch ein .flash hochladen, Danke! Hallo Charly, hier die .flash und .ram Gruß Jürgen
Hallo Hayo, bin eben erst zurück. Ich würde gern erst einige Rückmeldungen haben, bevor ich mich hier äussere. Einfach, damit das nicht nur eine "eingebildete" Verbesserung ist :-) Danach gerne. Viel Grüße in den Norden! Jürgen
danke, werde uebers WE mal testen vlG Charly
Hallo Jürgen, bin gerade am Testen, kann zum Triggerverhalten aber noch nichts näheres sagen, zumindest ist es nicht schlechter geworden ;) Eine Macke hat sich allerdings eingeschlichen: Die Einstellung für PreTrigger wird nicht gespeichert; nach Aus-/Einschalten triggert das Welec immer auf den linken Bildschirmrand. Grüße, Ulrich
auch kurze Rueckmeldung v. mir: war am WE auf einer anderen Baustelle, hoffe jetzt auf das verlaengerte WE vlG Charly
Hallo werte Gemeinde, ich stecke zur Zeit in baulichen Maßnahmen am Haus (Carport) und komme daher nur dazu den Thread kurz zu lesen. Sobald ich wieder etwas mehr Zeit habe bin ich wieder am Ball. Gruß Hayo
Hallo, ich habe schon länger mein DSO nicht mehr in Benutzung gehabt. Daher wollte ich ihn nun endlich mal wieder einsetzen und das neuste Firmware update aufspielen. Von 1.2.BF.4.8 auf 1.2.BF.6.8 Aber leider schlägt bei mir das Update immer fehl.
1 | Flashloader: |
2 | |
3 | GERMSloader.pl Ver 1.2.0 |
4 | |
5 | *** No Warranty |
6 | *** |
7 | *** This program is distributed in the hope that it will be useful, |
8 | *** but is provided AS IS with ABSOLUTELY NO WARRANTY; |
9 | *** The entire risk as to the quality and performance |
10 | *** of the program is with you. Should the program prove defective, |
11 | *** you assume the cost of all necessary servicing, repair or correction. |
12 | *** In no event will any of the developers, or any other party, |
13 | *** be liable to anyone for damages arising out of the use or inability |
14 | *** to use the program. |
15 | |
16 | Device : COM3 |
17 | Flash filename : TomCat.flash |
18 | |
19 | --- Writing GERMS firmware... |
20 | Writing line 000016 of 027361: ........... transferred. |
21 | Error: Timeout while reading response from DSO! |
22 | Response was: 'r0' |
23 | Firmware update was NOT successful! |
24 | Please fix the connection issue and retry! |
Ich habe auch versucht auf 1.2.BF.4.9 zu updaten aber dies schlägt genauso fehl. Ein Backup bzw. den Flash auslesen mit GERMSloader oder WelecUpdater schlägt auch fehl. Ich verwende einen Digitus Serial USB Converter (FTDI) mit Win8 x64. Habt ihr eine Idee warum das Update nicht funktioniert?
Tom schrieb: > Ich verwende einen Digitus Serial USB Converter (FTDI) mit Win8 x64. Sicher daran. Was ist an > Please fix the connection issue and retry! so rätselhaft? ;-) Gruß, Guido
Hallo Tom, Guido hat recht, das sieht ganz nach der seriellen Schnittstelle aus. Das Beste was Du machen kannst ist, Dir einen alten Rechner mit echter serieller Schnittstelle zu suchen (Freunde, Bekannte) und damit das Update zu machen. Ich benutze auch einen USB zu seriell Wandler, aber es funktionieren halt nicht alle. Da hatten wir schon öfter entsprechende Rückmeldungen. Bei dieser Diagnose gehe ich mal davon aus, dass Du die Initialisierung des Updatevorgangs mit den beiden Funktionstasten F1/F2 am DSO korrekt gemacht hast. Gruß Hayo
Hallo, vielen dank für eure Rückmeldungen und Hilfe. >> Ich verwende einen Digitus Serial USB Converter (FTDI) mit Win8 x64. > > Sicher daran. Habe ich auch gedacht, aber ich bin mir nicht ganz sicher wie ich es früher gemacht habe. Ich bin der Meinung das ich es auch damals mit dem Serial Converter gemacht habe. > Was ist an > >> Please fix the connection issue and retry! > > so rätselhaft? ;-) Nicht so viel :D aber es hätte ja sein können das Respone "r0" etwas "besonders" bedeutet. > Guido hat recht, das sieht ganz nach der seriellen Schnittstelle aus. > Das Beste was Du machen kannst ist, Dir einen alten Rechner mit echter > serieller Schnittstelle zu suchen (Freunde, Bekannte) und damit das > Update zu machen. Ich benutze auch einen USB zu seriell Wandler, aber es > funktionieren halt nicht alle. Da hatten wir schon öfter entsprechende > Rückmeldungen. Welchen Converter/Wandler nutz du denn? Bis jetzt hatte ich noch nie Probleme mit dem Digitus. > Bei dieser Diagnose gehe ich mal davon aus, dass Du die Initialisierung > des Updatevorgangs mit den beiden Funktionstasten F1/F2 am DSO korrekt > gemacht hast. Jup, habe ich gemacht. Zum glück haben auch die neusten Mainboards immer noch eine COM-Schnittstelle. Da werde ich mich wohl mal um eine Blende kümmern müssen. Vielen Dank und liebe Grüße, Tom
Moin Tom, wenn du ganz sicher gehen möchtest, kannst du ja mal das Screenshot-Programm starten, da bekommst du auch noch mal eine Bestätigung auf den Schirm, bzw. Dos-Fenster. Nicht vergessen die korrekten Parameter (COM1-9, Baudrate...) in die Batch einzutragen. Desweiteren kommt es auch vor, das wenn du einen anderen USB-Port verwendest, das dieser eine andere COM-Port Nummer zugewiesen bekommt! Mal im Gerätemanager nachschauen, welche Zuweisung dein COM-Port von Windows gewählt hat. Auch dort, müssen die Parameter passen! Gruß Michael
Hallo, ich habe gerade mir ein Welec W2024A zu gelegt und musste feststellen das das sourceforge Wiki nicht mehr da ist (z.B. http://sourceforge.net/apps/trac/welecw2000a/wiki/HardwareImprovement). Gib es das noch irgend wo weil ohne ist schwer an Infos zu kommen? Gruß Mx
Das ist mir leider auch schon aufgefallen. Aber nachdem das Weleg-Geraffel schon so unbefriedigend ist, hatte ich auch keinen Nerv mehr, auch noch den (wirklich bemerkenswerten und heldenhaften) Open Source Bemühungen hinterherzulaufen. Irgendwie wird man müde und fragt sich, ob man an dem Punkt ist, das Teil in die Bucht zu setzen (denn hier im Markt wird ja alles zerrissen) und sich was Anständiges zu kaufen... Nichtsdestotrotz: Im Web-Archiv unter http://web.archive.org/web/20130326014650/http://sourceforge.net/apps/trac/welecw2000a/wiki/HardwareImprovement findet man noch Rudimente.
Oh, das hatte ich noch gar nicht bemerkt. Grundsätzlich kann ich empfehlen die letzte Firmwareversion (1.2BF6.8) herunter zu laden und aufzuspielen. Es ist Einiges an Dokumentation darin enthalten und mit dieser Firmwareversion kann man das DSO schon ganz gut benutzen. Ich bin zur Zeit dabei mich mit Langwellen/Mittelwellen/Kurzwellenempfang zu beschäftigen. Schwingkreise, Antennen, Vorverstärker etc. - dafür kann man das Oszi eigentlich sehr gut gebrauchen. Gruß Hayo
Hello everyone! Is it possible doing something like this with the witting DSO and using a pc based signal generator software? http://www.youtube.com/watch?v=uMH2hGvqhlE If so, can someone get in the details of how this is done? Using FFT function and hod function?
Angehängte Dateien:
-
screen-0002.png
5,9 KB
Zuerst möchte ich mich bei allen Beteiligten bedanken für diese großartige Firmware. Der Verbesserung gegenüber dem Original ist einfach gewaltig! Nun zu meinem Anliegen/Verbesserungsvorschlag. Beim Screenshot werden zwar die Messergebnisse bzw. die Cursor-Ergebnisse angezeigt (siehe Screenshot), jedoch nicht die Cursor-Werte in den Softkeys. Es wäre halt sehr hifreich wenn nicht nur die Werte über den Softkeys erhalten bleiben, sondern auch die Softkeys der vorherigen Anzeige (bevor man in das Print-Menue gewechselt hat) mit den Istwerten ausgedruckt würden. Andreas
Hallo Andreas, sowas in der Art ist mir auch damals durch den Kopf gegangen, deshalb gibt es die Möglichkeit mit einem doppelten Druck auf den Quick Print Button den Screenshot anzustoßen ohne dass die Funktionsbuttons wechseln. Diese Funktion ist ebenso wie die meisten Zusatzfunktionen in der Datei "Special Functions" beschrieben :-) Viel Spaß noch mit Deinem DSO
Hallo Hayo, Danke für die prompte Antwort. Ich war so glücklich darüber dass ich mein DSO innerhalb von nur wenigen Stunden "umgebaut" habe. In dieser Euphorie ist mir diese Datei leider "entgangen" :-0 Ich werde den Beitrag mal im Auge behalten, falls noch Erweiterungen kommen. Danke!
Angehängte Dateien:
-
01_Sweep_Generator.jpg
260 KB -
02_MW_Antenna.jpg
290 KB -
03_Bode_Plot_W2022A.jpg
68 KB -
04_Bode_Plot_W2022A.jpg
67 KB -
05_Bode_Persistent_W2022A.jpg
40 KB -
06_Bode_Plot_SDS8102.jpg
66 KB -
07_Bode_Plot_SDS8102.jpg
64 KB -
08_Bode_Plot_SDS8102.jpg
64 KB
Ja es kommt noch was. Und zwar zum Beitrag von Alessandro:
> Is it possible doing something like this with the witting DSO ...
Yes indeed it is! A very interesting link you posted there. To explain
it I used the following measuring configuration:
- object to be measured is a MW loop antenna like it had been used in
the 1930s to 1940s. It is a resonant circuit with resonance between 500
KHz and 2MHz which can be adjusted with a variable capacitor.
- function generator HP3325A. Every signal generator with sweep function
can be used - but there must be a special sync output. We don't need the
signal sync output but the sweep sync out. That means, we need to know
when the sweep starts and when the sweep stops.
- the DSO is a W2022A and as reference an Owon SDS8102
What we have to do is to connect the sweep sync to channel 2 as trigger
signal. Set the timebase so that you can see one or a half period of the
sync signal. The effect is that we can see the complete sweep range on
our screen.
Now we connect the normal signal output via T-piece adapter to channel 1
and the end of the wire terminated with 50 Ohm to the antenna.
The sweep generator starts at 10 KHz and stops at 2MHz in continuous run
mode. The starting edge of the trigger signal (our sweep sync) has to be
on the left screen side. Now we can see the frequency response of our
system with 10KHz on the left screen side and 2MHz on the right screen
side. The quality of the plot on the W2022A is a little bit worse than
the plot on the SDS8102. That may be caused by some speed optimizations
in the
graphic routine. Switching the display into persistent mode leads to a
better result.
I hope the explanation was helpful - otherwise don't hesitate to ask!
Hayo
:
Bearbeitet durch User
Hallo Hayo, I have in my lab the HP3325A also,will test the sweep with my 8GHz Wiltron. Another nice application for our dso W2022. Hope you will have time to improve the trigger stability also .. Thank you! Sandro
Hi Sandro, the sweep sync out is on the backside and is called 'Marker' (frequency). You have to set the marker frequency with the button 'MKR FREQ' on a value between sweep start frequency and sweep stop frequency.
Hallo werte Gemeinde, es haben verschiedene User meine "Triggertest-Version" herunter geladen, aber leider keine Resultate zurück gemeldet :-( Genauer gesagt, hatte ich mir besonders die Pulsweiten Triggerei vorgenommen und durch eine kleine Änderung zum Laufen gebracht. Ich habe inzwischen weiter getestet und geforscht und meine, der PW Trigger tut mit der Testversion im Normalmodus genau was er soll, wenn passende Parameter eingestellt sind und setzt nach dem Verändern von Parametern auch wieder ein, wenn die Parameter wieder passen. @Ulrich An anderen Geschichten hab ich mich nicht "vergriffen". Hayo W. schrieb: > Aber vielleicht könntest Du mir sagen was Du genau verändert > hast, dann kann ich das gezielter testen und evtl. in das nächste > Release einbauen. Hallo Hayo, wichtigste Änderung für die Funktion PW-Trigger ist die Freigabe von Start_Record() am Ende der SetupTrigger Funktion. Die hattest Du wohl wegen einem Single-Shot Problem auskommentiert, welches Du aber wohl in der 6.8 gefixt hattest :-) Allerdings denke ich nach weiterer Suche in den Quellen, das offenbar vielleicht das Aussetzen des Edge-Triggers nur ein vermeintliches Aussetzen ist, da die angezeigte Triggerposition auf dem Schirm teilweise nicht das ist, was als Pegel zur Hardware geschrieben wird. Ursache könnten die kleinen Korrekturen bei der Pegelberechnung sein (Hardware::TriggerCorrection). Ich habe Diverses versucht, bin letztendlich aber an der zeitlich zum Triggermarker versetzten Anzeige der z.B. Sinusschwingung hängen geblieben :-( Die Triggercorrection scheint auch teilweise wirkungslos zu sein? Mit welcher Variablen oder Funktion kann man denn den Schwingungszug auf dem Schirm relativ zum Triggermarker verschieben?? Hier muss der GURU wieder ran :-) Hayo, ich hab Dir mal meine Fragmente der hardware_t angehängt. Kannst ja mal vergleichen. Die meisten Änderungen sind Kommentare für mein Verständnis... Beste Grüße Jürgen PS: Ich nutze z.B. die Codewarrior IDE zum Dateivergleich. Macht sich sehr gut.(Search,Compare Files..)
Hi Jürgen, ich bin noch nicht zum Testen gekommen, aber ich werde insbesondere Deine Zeile am Ende von SetupTrigger mal genauer auf ihre Wirkung testen. Vielleicht bringt es ja was, dann mach ich eine neue Version fertig. > Mit welcher Variablen oder Funktion kann man denn den Schwingungszug auf > dem Schirm relativ zum Triggermarker verschieben?? Das ist die Funktion UserIF::ON_MemoryPosition(void) (hier werden die Interruptwerte des Drehgebers ausgewertet) wobei die Funktion Display::RecalcTimeParameters() innerhalb dieser Funktion eine wichtige Rolle spielt. Gruß Hayo
:
Bearbeitet durch User
Hi Hayo, > Das ist die Funktion UserIF::ON_MemoryPosition(void) (hier werden die > Interruptwerte des Drehgebers ausgewertet) wobei die Funktion > Display::RecalcTimeParameters() innerhalb dieser Funktion eine wichtige > Rolle spielt. Danke für den Hinweis, ich habe das eben mal überflogen. Das ist um diese Uhrzeit für mich zu schwere Kost :-) Ich sehe mir das aber auf jeden Fall genauer an! Gruß Jürgen
Hallo Jürgen, ich habe auch schon etwas mit der Konzentration zu kämpfen (könnte am Wein liegen) aber ich konnte mir nicht verkneifen schon mal vorab mit der unveränderten 6.8 ein paar Tests zu machen. Ich konnte hierbei nur eine Konstellation beim Pulsweitentrigger ausmachen, die zum Stillstand führt. Und zwar ist das im Modus Pulsweite zwischen Wert 1 und 2. Wenn Wert 1 (also der untere Wert) im Normaltrigger-Modus unterschritten wird, dann bleibt die Kiste stehen. Da hilft auch kein Ändern des Signals am Generator oder Ändern des unteren Grenzwertes. Wenn man allerdings die Timebase einmal vor und wieder zurück dreht, dann läuft es wieder. D.h. beim Ändern der TB wird ja ein StartRecord() abgesetzt. Also könnte es durchaus sein, dass Deine Änderung hier hilfreich ist. Guats Nächtle Hayo
:
Bearbeitet durch User
Ok, nach langer Zeit mal wieder eine neue Version! Angeregt durch Jürgen habe ich mich noch mal auf den Pulsweitentrigger gestürzt. Das Ergebnis ist ganz erfreulich. Im "Normal" Modus arbeitet der PW-Trigger jetzt in allen drei Bereichen (>, <, ><) ohne stehen zu bleiben. Zusätzlich habe ich noch einen Bug im Single Trigger des Peak Detect beseitigt. @Jürgen Ich habe die meisten Deiner Änderungen übernommen weil sie mir inhaltlich korrekt erschienen. Das hat aber nicht viel gebracht. Nur die letzte Zeile in SetupTrigger() hat dafür gesorgt, dass beim Unterschreiten des unteren Schwellwertes die Acquisition weiter ging wenn man den Wert am DSO nachgeregelt hat. Wenn jedoch stattdessen das Signal am Funktionsgenerator geändert wurde, blieb das Gerät trotzdem "eingefroren". Hierfür (oder vielmehr dagegen) habe ich jetzt im ADC-Handler einen kleinen Workaround eingebaut, der dafür sorgt, dass es beim Pulsweitentrigger keinen "Freeze" mehr gibt. Gruß Hayo p.s. ach ja, was dadurch jetzt natürlich auch geht, dass ist der Single PW-Trigger. D.h. wenn man den Single Trigger setzt solange die Pulsweiten unter dem unteren oder über dem oberen Schwellwert liegen, passiert nichts. Erst wenn ein Puls kommt, der von der Weite im richtigen Bereich liegt wird ein Event ausgelöst.
:
Bearbeitet durch User
Hallo allerseits, zur Zeit bin ich dabei meine Kurzwellenantennen via Bode Plott zu vermessen. Dabei sind mir einige Fehler in der aktuellen Firmware aufgefallen. Da musste ich natürlich gleich eine neue Version bauen. Gruß Hayo
Habe ich eben installiert - vielen Dank!! (Noch nix Negetives bemerkt) Viele Grüße, Egberto
Freut mich zu hören. Ich bin auch schon an der nächsten Version dran. Diesmal mit neuem Feature und einigen Umbauten unter der Haube. Ihr merkt schon, ich habe gerade einen Lauf... Gruß Hayo
Super, Danke Hayo! Seitdem ich das letzte mal reingeschaut habe, habe ich natürlich den Faden verloren und alten die SF.net-Seiten sind irgendwie futsch. Ich such mir 'nen Wolf und weiss irgendwie nicht, was der letzte Stand ist. Kannst Du mal bitte kurz sagen: 1. Welche Hardware-Modifikationen sind nötig (um das DSO mit einigem Anstand verwenden zu können)? 2. Wo sind die jeweils aktuellen Firmware-Sourcen zu finden (auf SF.net sind ja nur die Builds, die Source-Repositories sind oll). Github? Bis dann, Johann
Die Sourcen sind im Release dabei: http://sourceforge.net/projects/welecw2000a/files/Open%20Source%20Firmware/ Ich würde mir auch wünschen, dass es eine vernünftige Webseite zu diesem Projekt gibt. Es steckt so viel Arbeit darin, dass das kaputte Sourceforge-Ding dem tollen Projekt in keiner Weise gerecht wird. Gerade als neuer hat man es schwerer als nötig.
Ein ganz kleiner Bugreport von mir, tritt zum Beispiel im Trigger menu auf und lässt sich wie folgt reproduzieren: - Funktionstaste 1 "Mode" drücken, Popup erscheint - Funktionstaste 3 "Trigger Auto Level" mehrfach drücken Es wird die Funktion Trigger Auto Level ausgeführt, aber das der Timeout des Mode-Popups wird bei jedem Druck zurückgesetzt. Vielen Dank für euer Engagement Hayo und Jörg!
keinGast schrieb: > Die Sourcen sind im Release dabei: > http://sourceforge.net/projects/welecw2000a/files/Open%20Source%20Firmware/ Oh, kein Versionskontrollsystem (git, hg, svn, cvs, ...) dafür? Nicht dass ich da gross mitmischen könnte, aber momentan scheint halt alles an Hayo zu hängen. Hat der keine Böcke mehr, wird's duster... Schlagt mich nicht, wenn's irgendwo steht: FPGA-Sourcen (VHDL, Verilog) sind gar nicht verfügbar? Oder gibt's zumindest ein Grundgerüst ohne IP-Cores?
Johann Wackener schrieb: > Kannst Du mal bitte kurz sagen: > 1. Welche Hardware-Modifikationen sind nötig (um das DSO mit einigem > Anstand verwenden zu können)? Da gibt es viele Verbesserungen. Weiter oben hat ein freundlicher Threadleser diesen Archivlink zur Verfügung gestellt: http://web.archive.org/web/20130326014650/http://sourceforge.net/apps/trac/welecw2000a/wiki/HardwareImprovement Die wichtigste Doku ist in SFN zu finden: http://sourceforge.net/projects/welecw2000a/files/Hardware/Modifications/ Aber in Kürze: - anständige Belüftung durch diverse Änderungen am Lüfter. Hierzu gibt es von mir die Doku "Optimizing Thermal Design" in drei Ausbaustufen. - der externe Triggereingang kann etwas Überarbeitung gebrauchen. Hier gibt es einen Optimierungsvorschlag den Jörg mal gemacht hat und den ich dann mit einigen Bildern dokumentiert habe - die analoge Eingangsstufe hat im originalen Zustand mit einigen Unzulänglichkeiten zu kämpfen. Da wäre der nichtlineare Amplitudengang, der schlecht gewählte Aussteuerbereich der zu starkem Rauschen führt, schlechter kapazitiver Abgleich von Werk aus (Trimmer unter der Abschirmung), einige ungünstige Bauteildimensionierungen. Optimierungen gibt es da einige. Ein Ansatz geht soweit, eine komplette Platine mit eigener Eingangsstufe für jeden Kanal einzubauen. Der Aufbau der Platine und der Einbau ins Gerät ist nicht ganz einfach. Die firmwareseitige Unterstützung steckt auch in den Kinderschuhen da nur einige Wenige den Umbau gemacht haben. Deutlich einfacher und günstiger sind die Low Budget Mod und die OPA653 Mod, die in letzter Zeit einige erfolgreich ausprobiert haben. Löten an SMD-Bauteilen solltest Du auf jeden Fall können. Noch ein Hinweis zu der Bestückung der originalen Eingangsschaltung: Der Eingangsverstärker OPA656 ist maßgeblich für Frequenzgang und Bandbreite des DSO verantwortlich. Der Unterschied zwischen den 200MHz Versionen und den 100MHz Versionen besteht darin, dass in den 100MHz Versionen ein Fake verbaut wird welches deutlich geringere Bandbreite hat! Zu erkennen an einem grünen Lackpunkt auf dem Gehäuse. Es besteht weiterhin der Verdacht, dass in späteren 200MHz Geräten ebenfalls diese Bauteile verwendet wurden um Geld zu sparen bzw. mehr Geld nehmen zu können als für die 100MHz Geräte. Die wenigsten Besitzer solcher Geräte bemerken das. > 2. Wo sind die jeweils aktuellen Firmware-Sourcen zu finden Ich veröffentliche die hier. Du findest sie auch auf SFN. Es gab auch ein svn mit allen aktuellen Entwicklungszweigen. Durch die SFN-Umstellung ist das etwas in der Versenkung verschwunden. Ich weiß jetzt nicht ob Jörg das evtl. schon wieder aktualisiert hat. Ziel ist es jedenfalls irgendwann diese NIOS 1 Firmware abzulösen durch eine Firmware die auf dem von Jörg selbst entworfenen NIOS 2 Core aufsetzt. Das kann aber noch etwas dauern, daher gibt es zwischendurch immer noch Erweiterungen an der aktuellen Firmware. Gruß Hayo
:
Bearbeitet durch User
Angehängte Dateien:
-
Persistent.jpg
140 KB
Wie angekündigt hier die neue Version mit neuer Display-Funktion. Bei anderen DSOs habe ich gesehen, dass diese bei der persistenten Display-Funktion die Möglichkeit bieten einstellbar das nicht mehr gültige Signal auszublenden. Unser W20xxA konnte bisher nur Persistenz an/aus. Das konnte ich natürlich so nicht stehen lassen! Die neue Firmware kann jetzt Lebenszyklen (Lifecycles) von 5s/10s/25s/50s und Unendlich darstellen. Am besten kann man das testen wenn man die Fade Out Time auf 5s einstellt und dann das Testsignal in Amplitude oder Frequenz verstellt (siehe Bild). Der kleinere Bug im Triggermenü ist auch behoben - danke für den Hinweis. Viel Spaß Hayo
Hi Hayo, I tested the new functions,working and useful,only the memory 1 save/recall function fails from 1.2.BF6.9 onward.For example saving sinewave, recall is different,appear dc voltage.Downgrade solve it,may you check this little bug? Thank you Sandro
Hi Sandro, I checked it but I can't find the problem. All seems to work correct. Please describe in detail under which conditions and parameters the problem occured. Hayo
Johann Wackener schrieb: > Kannst Du mal bitte kurz sagen: > 1. Welche Hardware-Modifikationen sind nötig (um das DSO mit einigem > Anstand verwenden zu können)? Da fällt mir noch ein, es gibt einen Umbau für den Akkubetrieb von Markus, den sollte man auf jeden Fall auch erwähnen. Ist zwar nicht nötig, aber unter gewissen Bedingungen hilfreich: Beitrag "Wittig(welec) DSO W20xxA Umbau Akku-Betrieb" Ach und was unter die gleiche Kategorie fällt mir aber entfallen ist, weil das für mich an meinen Geräten so selbstverständlich ist - die Trigger LEDs: Beitrag "Re: Wittig(welec) DSO W20xxA Hardware" Beitrag "Re: Wittig(welec) DSO W20xxA Hardware" Beitrag "Re: Wittig(welec) DSO W20xxA Hardware" -> möchte ich nicht mehr missen! Gruß Hayo
Gibt es den Inhalt von http://sourceforge.net/apps/trac/welecw2000a/wiki/RemoteControlAPI noch irgendwo?
Angehängte Dateien:
-
screen-0002.jpg
64 KB -
screen-0003.jpg
62 KB
Hi Hayo, setting is :default,input 1 kHz calibrator,CH1,500mVdiv, 500KSa,500 uS/,but also with other settings. Save to Memory 1,disconnect the probe,then recall ,the waveform is only a line and trigger setting go also itself from combi to normal . This bug is random,pls see the enclosed diagrams. Thank you, Sandro
I tried hard, but the problem does not occure on my DSOs. I have the suspicion that the "Auto" trigger might be the guilty one. Can you try it once more with the "Normal" trigger? @all Has anyone else the same problem? Hat noch jemand Probleme beim Speichern und Wiederholen der Signale aus dem Speicher? Hayo
Hayo W. schrieb: > I tried hard, but the problem does not occure on my DSOs. I have the > suspicion that the "Auto" trigger might be the guilty one. Can you try > it once more with the "Normal" trigger? I can confirm, that the trigger mode, if set to combi, is somehow set to normal. I don't know how save/recall should work. Should I be able to view stored traces 1 and 2 at the same time? Should I be able to overlay a saved trace on the live signal?
keinGast schrieb: > I can confirm, that the trigger mode, if set to combi, is somehow set to > normal. Yes I know the bug. It is solved in the next version. > I don't know how save/recall should work - go to Save/Recall - choose a memory place - push "Save Trace" -> signal will be stored into flash - switch off the signal input - push "Recall Trace" -> signal should be displayed as before - or push "Overlay Trace" -> old signal and actual signal will be displayed Hayo
:
Bearbeitet durch User
Ok hier die neue Version mit einigen Verbesserungen, Bugfixes und einer neuen versteckten Funktion zum Umlabeln der Modelversion. Details stehen in der Datei Special Functions.txt Hayo
Hallo Hayo, noch mal ein kleiner Bug, wieder bzgl. dem Popup-Timeout: - im Trigger-Menu das Mode-Popup öffnen - dann an der Timebasis drehen - das Popup bleibt offen, so die Timebasis verändert wird. Ist das ein Architekturproblem?
keinGast schrieb: > Ist das ein Architekturproblem? Nicht direkt! Es handelt sich vielmehr um konkurierende Interrupts. Der Timer-Interrupt des Popup Timeouts (schönes Denglisch) konkuriert hier mit dem Interrupt des Rotary Interface (Drehgeber-Interrupt). Letzterer unterbricht die Bildausgabe und damit auch die Möglichkeit das Popup zu schließen, obwohl der Timeout schon längst zugeschlagen hat. Damit kann man aber wohl ganz gut leben denke ich. Wenn wesentlich mehr Rechenleistung zur Verfügung stünde könnte man das sicherlich auch geschmeidiger lösen. Für 12MHz aber wohl ganz akzeptabel. Gruß Hayo
:
Bearbeitet durch User
Johann Wackener schrieb: > Oh, kein Versionskontrollsystem (git, hg, svn, cvs, ...) dafür? ... doch schon immer ... nun auch mit all den Versionen vom Hayo. http://sourceforge.net/p/welecw2000a/code/HEAD/tree/ Grüße Andiiiy
Hi Hayo, I confirm that the bug comes from auto and combi settings,with normal trigger save/recall are correct. Ciao Sandro
Hi Andiiiy, hab schon gesehen, dass Email von SFN im Postfach war wegen des Checkin. Ich wusste gar nicht mehr, dass da noch ein Repository eingerichtet ist. Muss ich mir mal wieder alles richtig einstellen. Bin jetzt aber erst mal weg ....muss in Griechenland segeln :-) Hayo
unser Hayo iss schon ein armer Tropf, wir werden dich bedauern wenn du in Griechenlan in der Sonne schmorst und unsern schoenen Regen hier verpasst :p vlG Charly
Hayo: nice job with persistence that now is settable. This remind me about the interpolation matter because in that way it improve the waveforms on the screen even if trigger instability worsens the drawn. So any news for sin(x)/x interpolation or whatever that can improve the drawn of the waveforms on the screen that is very crude until now. I think it was discussed in the past. So long, 400
~ ~ The hidden functions can be reached by using a serial terminal and special keys on the pc keyboard. ~ ~ ~ - Shift + O ~ Renaming function to change the model label for modified devices. Depending on the hardware ~ settings (hardware menu -> Gain) the label will be changed and written into the protected flash. ~ This label has no influence to the hardware functions. It is only for display. ~ ~ ~ Gain Label ~ ----------------------------------------- ~ Factory W20xxA (no change) ~ LB-Mod W202xA / OPA656 Mod ~ OPA653 W203xA / OPA653 Mod ~ 24.5Ohm W202xA (W2022A or W2024A) ~ Add On W203xA / LMH6518 Mod ~ ~ ~ ~ !!!! Be carefeful, some changes can't be set back !!!! ~ Hayo: We can put them there but we can't rewrite or overwrite them again. Why can't be some changes set back? So long, 400
김사백 schrieb: > Why can't be some changes set back? If your DSO is a W2012A or a W2014A and you change the Label to LB-Mod your DSO will become a W2022A or a W2024A. There is no possibility for the firmware to see if the DSO is really a W2022/W2024 because the hardware is the same (only the OPA656 is different). So it can't be set back to W2012/W2014 in the moment (only mnually with a separate function I could write). All this is only for display and has no influence to the function. Greetings from the Ionian Sea Hayo
:
Bearbeitet durch User
Hayo thanks. That's the same thing that I thought. If it's possible to change it then it's even possible to set it back. Have a nice travel. 400
Angehängte Dateien:
Ab der BF.5.8XE bis zur aktuellen BF.7.1 (ab hier wird übrigens auch die trigonometric Tabelle ins Flash geschrieben), wird der Sinus, bei drücken der Test-Signaltaste, nicht mehr korrekt dargestellt! Ich habe mir mal die Mühe gemacht, ab welcher Firmware-Version das der Fall ist. Angefangen hatte ich bei BF.5.6, da war noch alles ok. Jetzt ist die Tabelle mit der 5.8XE fertig geschrieben, komischer Weise wird nun auf dem 2.Kanal kein Testsignal ausgegeben, hmm... Ok, nach dem aus u. wieder Einschalten, wird der Sinus auf Kanal2 angezeigt, allerdings, (wie oben schon beschrieben)auch mit einer viel zu kleinen Amplitude. Ich wollte das nur mal so erwähnen ;-) Ein Pic anbei. Achso...wem beim schreiben der trigonometric Tabelle ins Flash, ein Fehler passiert ist, braucht nur auf die BF.5.7 downgraden, dann wird ab der BF5.8XE diese wieder neu geschrieben(ich habe es ja gerade getestet) Gruß Michael
Hmm, schau ich mir mal an wenn ich zurück bin. Für das Schreiben der Trigo-Tabellen könnte ich auch noch eine Hidden Function einbauen, dann kann man das jederzeit refreshen. Hayo
Mir ist aufgefallen, dass die Triggerschwelle nicht mit skaliert, wenn man die vertikale Auflösung V/div umschaltet. BTW: Kann das Firmware-Projekt (also das von Hayo massgeblich betreute) vielleicht nach Github umziehen? Dann könnte man da wird das Wiki etablieren, ausserdem ist der Bugtracker dort ziemlich knorke. SF.net nervt, ist so unübersichtlich - wra früher mal toll, aber mittlerweile ist es nicht mehr oldscool, sondern einfach nur noch oll. Github bietet auch einen Downloadbereich für Releases (https://help.github.com/articles/creating-releases/).
One thing I always wonder is what is the purpose of that function, what the test signal meaning is? What does it do? 400
Welecverbastler schrieb: > Mir ist aufgefallen, dass die Triggerschwelle nicht mit skaliert, wenn > man die vertikale Auflösung V/div umschaltet. Ja, das ist aber kein Fehler, sondern so gewollt. Hintergrund ist der Umstand, dass der Trigger auch nur im Anzeigebereich des Grids arbeitet. Größere Triggerlevel sind unwirksam (Signal und Triggerlevel liegen dann außerhalb des ADC-Aussteuerbereichs). Daher ist es in diesem Fall praktikabler den Level am Grid zu orientieren, d.h. den Level in Relation zum Grid konstant zu halten. So hält man den Trigger immer im Aussteuerbereich. Ziel bei der Wahl des Spannungsbereiches ist es ja im Normalfall, das Signal im Gridbereich komplett darzustellen. > Kann das Firmware-Projekt (also das von Hayo massgeblich betreute) > vielleicht nach Github umziehen? Das müsste man sich mal ansehen. Grundsätzlich spricht nichts dagegen. SFN gefällt mir auch nicht so besonders. 김사백 schrieb: > what > the test signal meaning is? > What does it do? It is a software generated signal which is loaded into the signal buffer instead of the ADC value register. It can be used to test some of the firmeware functions like "Quick Measure", "Noise Filter", "Math" etc. . It does not work with functions which are operating on hardware layer level (driver level) like "Average". It is only a simple signal simulating routine. I'm thinking about improving it... Hayo
Hi, bin gerade erst zurück und hatte einige Ideen. Zum Einen habe ich das Rotary Interface nochmals genauer unter die Lupe genommen. Leider ist es die Hardware- (FPGA) Implementierung die hier für das schlechte Ansprechverhalten verantwortlich ist (etliche Impulse werden einfach verschluckt). Um das Ganze erträglicher zu machen habe ich für die Zerolevel-Verstellung den Code nochmals überarbeitet. Der Zerolevel lässt sich jetzt etwas flüssiger verstellen und springt nicht mehr ganz so heftig. Wichtig ist, dass man nicht allzu schnell am Drehgeber kurbelt, da dann das Interface die Impulse schlichtweg verschluckt (quasi ein Null Device). Weiterhin habe ich den Ansatz mit dem skalierenden Triggerlevel von Welecverbastler aufgegriffen und eine mögliche Umsetzung eingebaut. Beides betrifft nur Kanal 1, dadurch kann man direkt mit Kanal 2 vergleichen, der komplett unverändert arbeitet. Ich bitte um Rückmeldung ob die beiden Änderungen eine Verbesserung sind. Short version in english: Please test the new implemented scaling triggerlevel and the new rotary handler for zerolevel adjustment. both available only on channel 1 to be able to compare with the originally working channel 2. Hayo
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.