Hallo Guido Vermutlich werden sie das Gerät nur aufnehmen können, wenn die Schnittelle klar definiert ist. Mann müsste sich halt da bei Interesse zusammenreden.. Es gibt zwar bei ProfiLab auch eine Serielle Schnittstelle. Mit der könnte man vermutlich die Steuerparameter von DSO schon ansprechen?! Mit Linux habe ich nix am Hut, darum habe ich mich dafür noch nicht schlau gemacht. l.G. Roberto
Hallo Leute, Der neue Waverecorder ist nun fertig. Es sind nun deutlich weniger Argumente beim Aufruf nötig, was die Bedienung deutlich erleichtert. Ein Screenshot kann nun einfach mit waverecorder --screenshot gestartet werden (hier wird ein Defaultdateiname gewählt, wobei bereits vorhandene Screenshots nicht überschrieben werden. Es kann auch ein Name angegeben werde mit waverecorder --screenshot -f dummyfilename. Die Kommandos -u (Schnittstelle), -b (Baudrate) und -p (Schnittstelle zum Oszi, FPGA oder leon) sind nicht mehr nötig, da sie in der Konfigurationsdatei gespeichert werden. -b und -u können angegeben um den in der Konfigurationsdatei gespeicherten Wert für den aktuellen Aufruf zu überschreiben (um das ganze besser skriptbar zu machen). Eine Binary für Windows ist unter https://sourceforge.net/apps/trac/welecw2000a/attachment/wiki/Leon%20Binaries/ zum runterladen. Derzeit arbeite ich am VHDL-Design um die Encoder in Hardware sicher zu machen. Erste Versuche zeigen bereits Erfolge. Ein schönes, einmal sonniges Wochenende Grüße Robert
Hi all, I'm sorry for my poor english, but I live in italy and I do not understand german. I have a welec w2012, I'm very interested to collaborate with the developement on open source software. I don't know now if I will have time to write code, but I'm surely interested to test new versions and to give suggestions, in both hardware and software environments. I've seen the schematic in http://sourceforge.net/apps/trac/welecw2000a/ and there are some things that I don't understand, I think that there are errors on schematic. I've tried on EmbDev.net but I'm not able to find any thread on welec/wittig. Finally, if possible, I wish to look source codes of the firmware, I haven't find them in the web. Thanks to all Franco
Hi franco, I'm one of the contributors to the alternative leon3 design of Alex. Some weeks ago we switched from Sourceforge code hosting to git (http://github.com/Crazor/welecw2000a). All our code (fpga design, firmware and other necessary stuff related to the leon design is hosted there) We are using Skype as our main communication program. You can add me "xxrazer6xx". We do speak English there. I think the sourcecode of Hayos fimware is published with the download. Regards from sunny Austria Robert
franco schrieb: > >I've seen the schematic in http://sourceforge.net/apps/trac/welecw2000a/ >and there are some things that I don't understand, I think that there >are errors on schematic. Hi Franco and all guys. Franco what do you think is wrong and where? Regards, Luc
Hey Hayo, sowohl ich als auch die Italiener haben Probleme damit, dass hin und wieder das Signal "einfriert", was dann manchmal durch drehen an der Zeitbasis, manchmal nur durch 2x RUN/STOP wieder zu beheben ist. Das hatten wir irgendwann schonmal diskutiert, ich weiß aber nicht mehr, was dabei herauskam... Triggermodus war Combi, bei Normal dasselbe Problem, Auto habe ich noch nicht getestet. Wann es auftritt, ist schwer zu sagen, es scheint aber vor allem bei den etwas langsameren Zeitbasen vorzukommen und dann immer nach einem Wechsel der Zeitbasis. Gruß Michael P.S.: Bitte fangt jetzt nicht wieder an, mir den Trigger zu erklären, ich kann Oszilloskope bestens bedienen
I do not understand the flow of the input signal in this schematics: http://welecw2000a.sourceforge.net/docs/schematics/Analog-Input-Part_assignment_V3_4.pdf The signal goes through the input attenuator, then it must reach the first amplifier U1. I see that from the blue point 16 to the blue point 2 (non-inverting input of the opa656N) there is no DC coupling. It seems that the first stage is the OP1177, but I don't believe it beacouse it has a unity-gain bandwith of only 1,3 MHz !!! So I thik something is wrong! I think this part of schematic is important to understand where the input nise is generated.... And are there news about the new input board? Thanks Franco
Hi franco, imho you are wrong. First amplifier is U1. U2 only delivers DC and DC-offset from the dac. Do you still know bootstrapping_stages? This is kind of that. I think that the schematics are pretty good, but there might be some errors anyway. So never mind to check them. Kind regards, Guido
franco schrieb: >I do not understand the flow of the input signal in this schematics: >http://welecw2000a.sourceforge.net/docs/schematics... >The signal goes through the input attenuator, then it must reach the >first amplifier U1. >I see that from the blue point 16 to the blue point 2 (non-inverting >input of the opa656N) there is no DC coupling. >It seems that the first stage is the OP1177, but I don't believe it >beacouse it has a unity-gain bandwith of only 1,3 MHz !!! >So I thik something is wrong! >I think this part of schematic is important to understand where the >input nise is generated.... Hi Franco and all guys. Franco try to look at this: http://welecw2000a.sourceforge.net/docs/Hardware/Improving_Input_Stage_branadic_Part_5.pdf franco schrieb: >And are there news about the new input board? Franco, new news I do not know but try to look here please: http://sourceforge.net/apps/trac/welecw2000a/wiki/HardwareImprovement Regards, Luc
Hi luc, thank you for the updated links. Google translator helped me to understand last documents in german. I think that the choice of LMH6518 is very good, I have some dubt about the layout, at hier frequency is very important every millimeter in positionig components and wire. But I think that branadic is more or less readuy to test the new version of pickaback, and, I think, we all are waiting for the results. Many compliments to all, it is a great work. Source code: I've find only the "original" welec source, i read them and i'm very interested to look the source of new version of Hayo..... :-) I have some suggestion, due to my experienxe with the welec scope: for example I think that is good increase sample frequency at middle and low speed timebase. If you must observe small pulse or glitch , a bigger sample rate is better. Regards Franco
Hi Guido, sorry but I seen your message only now, I'm a little confused between many messages in many language... hum... you say that the dc component of the signal, plus the dc offset is handled from U2, the ac part goes through capactor c9? may be. I'm thinking about.... Thank you ,Guido regards Franco
Angehängte Dateien:
Hallo Robert, habe gerade mal deinen neuen Waverecorder herunter geladen und werde ihn heute Abend mal testen. Jetzt ist erstmal die Sonne an der Reihe, soll später ja Gewitter geben... Erst mal ein Lob für dein neues Werk, habe das Teil schon mal gestartet...Neugier :) Im Dosfenster geht gleich die Configuration los, man kann sehr bequem die Parameter eintragen, nun meine Frage: im obigen Screenshot stehen die unterstützten Gerätschaften---enter Platform:---(W2012, 2022, 2024...) zur Auswahl, für was steht die ---SBX---??? ...noch was, für die Screenshotfunktion muß ich noch eine Batch erstellen, oder? PS. hast du mittlerweile Kontakt mit dem "Forker" auf Github ? Vollmars...den kenne ich doch? Gruß Michael
Hallo Michael, Michael D. schrieb: > Jetzt ist erstmal die Sonne an der Reihe, soll später ja Gewitter > geben... Ich liege auch im Freien und genieße den Tag ;) Michael D. schrieb: > Im Dosfenster geht gleich die Configuration los, man kann sehr bequem > die Parameter eintragen, nun meine Frage: im obigen Screenshot stehen > die unterstützten Gerätschaften---enter Platform:---(W2012, 2022, > 2024...) zur Auswahl, für was steht die ---SBX---??? SBX steht für Sandbox, ein FPGA Board auf dem Design auch lauffähig ist. Michael D. schrieb: > ...noch was, für die Screenshotfunktion muß ich noch eine Batch > erstellen, oder? Ja kannst du machen wenn du willst. Ein Screenshot ist einfach mit --schreenshot möglich. Ist also in der Kommandozeile auch sehr komfortabel. Michael D. schrieb: > PS. hast du mittlerweile Kontakt mit dem "Forker" auf Github ? > Vollmars...den kenne ich doch? Nein habe ich noch nicht. Michael D. schrieb: > Erst mal ein Lob für dein neues Werk, habe das Teil schon mal > gestartet...Neugier :) Danke für die Blumen. Gruß aus der sonnigen Steiermark Robert
Hayo W. schrieb: > Jan F. schrieb: > >> [...] > > The BF-version is controlled by the scope, so it can be started with few > parameters. The OS-version is controlled by parameters on the PC-side. You can even start the OS Version without any further options (apart from Port) and can use the scope to choose between the output: Color Screenshot Black-White Screenshot CSV Raw-CSV > So the Softbuttons have limited function here. Maybe it would be nice to change the dump-output-type on the scope (ascii/csv) via softbutton - but apart of this I've used the softbuttons many time to gather different outputs (take one screenshot before the (raw) data dump) (Indeed to change the output from csv to ascii you have to specify this on the cl ;) > >> [...] > > The BF-version informs You via console messages when it is receiving a > screenshot. AFAIR - the OS Screenshot does this also ;) > > Hayo Kind reg's, rowue
Michael H. schrieb: > Hey Hayo, > > sowohl ich als auch die Italiener haben Probleme damit, dass hin und > wieder das Signal "einfriert", was dann manchmal durch drehen an der > Zeitbasis, manchmal nur durch 2x RUN/STOP wieder zu beheben ist. > Das hatten wir irgendwann schonmal diskutiert, ich weiß aber nicht mehr, > was dabei herauskam... > Triggermodus war Combi, bei Normal dasselbe Problem, Auto habe ich noch > nicht getestet. > Wann es auftritt, ist schwer zu sagen, es scheint aber vor allem bei den > etwas langsameren Zeitbasen vorzukommen und dann immer nach einem > Wechsel der Zeitbasis. Hi, also die Italiener sagten dass es bei der FFT auftritt. Bei Dir tritt es auch im Zeitbereich auf? Muß ich mal versuchen nachzustellen, ist bei mir bislang nicht aufgetreten. Danke und Gruß Hayo
franco schrieb: > Source code: I've find only the "original" welec source, i read them and > i'm very interested to look the source of new version of Hayo..... :-) The actual versions are without source code, but with the next version I will put the source code into the download package. Hayo
Roberto schrieb: > Hallo Hayo (Hallo Leute) > > Möchte da mal ein Programm erwähnen, dass ich mir vor kurzem gekauft > habe (99,-) > Es heißt "ProfiLab-Expert 4.0" von Abacom > http://abacom-online.de/html/profilab-expert.html > > Ich bin echt begeistert davon!!!! Hallo Roberto, das hört sich gut an. Ich kann folgendes anbieten: - mit dem nächsten Release gibt es eine Schnittstellenbeschreibung der original WELEC USB-Schnittstelle - es gibt eine Beschreibung der neuen USB-Schnittstelle die ich implementiere - wenn es eine Beschreibung für ein schon unterstütztes Gerät gibt, kann ich dieses Protokoll ebenfalls im WELEC einbauen (hatte ich ja schon mal irgendwann vorgeschlagen) Gruß Hayo
Hallo Leute, Michael H. schrieb: > Hey Hayo, > sowohl ich als auch die Italiener haben Probleme damit, dass hin und > wieder das Signal "einfriert", was dann manchmal durch drehen an der > Zeitbasis, manchmal nur durch 2x RUN/STOP wieder zu beheben ist. > Das hatten wir irgendwann schonmal diskutiert, ich weiß aber nicht mehr, > was dabei herauskam... > Triggermodus war Combi, bei Normal dasselbe Problem, Auto habe ich noch > nicht getestet. > Wann es auftritt, ist schwer zu sagen, es scheint aber vor allem bei den > etwas langsameren Zeitbasen vorzukommen und dann immer nach einem > Wechsel der Zeitbasis. > Gruß > Michael Kann ich bestätigen, tritt bei mir sporadisch auch auf. Durch drehen an den Zeitbasis geht es dann wieder. Signalform z. B. Pulsfrequenz ca. 20 bis 100Hz, Tastverhältnis ca. 20%, 5V-Puls. Ich versuche noch genauere Zusammenhänge zu finden. Gruß Bert
Bert schrieb: > Kann ich bestätigen, tritt bei mir sporadisch auch auf. > Durch drehen an den Zeitbasis geht es dann wieder. > Signalform z. B. Pulsfrequenz ca. 20 bis 100Hz, Tastverhältnis ca. 20%, > 5V-Puls. Ich versuche noch genauere Zusammenhänge zu finden. > > Gruß Bert Hi, am besten wärs wenn man das direkt reproduzieren könnte. Dann käme ich der Sache am schnellsten auf die Spur. Gruß Hayo
Hallo Hayo, ich bekomme das "einfrieren" zu 90% hin, wenn ich an der horizontalen Verschiebung drehe, ca. 5 clicks. Am besten unmittelbar nach der Verstellung der Zeitbasis, die horizontale Verschiebung drehen. Signal ca. 15Hz, 6V Rechteckpuls, Zeitbasis 2ms/Div bis 10ms/Div. Gruß Bert
Hallo Hayo, das "einfrieren" passiert auch manchmal ohne horizontaler Verstellung. Signal ca. 6 Hz, Zeitbasis 10ms/Div. Das Bild friert immer dannn ein, wenn der obere "Trigger"-Balken ausgeblendet wird. Gruß Bert
Hallo Bert, ich hatte wohl dasselbe "Einfrierproblem" bei den niedrigen Frequenz-Messungen, Restripple-Messungen bei stab.Netzgeräten z.B.! Vielleicht schaltest du mal die "Browserfunktion" an, so das der "Trigger" -Balken am Display bestehen bleibt, warscheinlich ist das DSO mit dem ein u. Ausblenden des Selbigen etwas überfordert, teste das mal! Gruß Michael
Hallo zusammen, ich melde mich mal nach laengerer Zeit zurueck, diverse Gruende haben mich vom Basteln abgehalten. Verzeiht mir, dass ich den langen Thread nur teilweise gelesen bzw. ueberflogen habe. Es freut mich, dass die Entwicklung voranschreitet und auch neue Besitzer hinzu gekommen sind. Was mich etwas gewundert hat ist, dass Hayo die Sourcen nicht mehr im .zip Archiv mitliefert. Wenn ich das recht verstehe liegt das daran, dass im Moment nur Hayo daran arbeitet. @Hayo: Es waere schoen wenn Du die Sourcen trotzdem wieder dabei packst, auch wenn diese nicht "poliert" sind. So kann mal selbst nachschauen oder Hand anlegen, wenn was klemmt. Ich persoenlich wuerde auch wieder zu den Screenshot und Datendump-Funktionen beitragen wollen, sofern es meine Zeit zulaesst (im Moment gibt es ja anscheinend zwei Varianten). Niklas
Angehängte Dateien:
-
50Hz_10ms01.png
260 KB -
50Hz_2ms02.png
250 KB
...ich habe das jetzt noch mal auf die Schnelle getestet und den "Browser" eingeschaltet. Im 1. Foto habe ich eine Wechselspannung 50Hz mit 9,1V Pk-pk (AC) mit 10ms/Div und im 2. Foto 2ms/Div eine Zeit lang laufen lassen und nix friert ein, man sieht auf den Fotos den eingeschalteten "Browser" ! Gruß Michael
Niklas O. schrieb: > Hallo zusammen, > > ich melde mich mal nach laengerer Zeit zurueck, diverse > Gruende haben mich vom Basteln abgehalten. Hallo Niklas, welcome back :-) > Verzeiht mir, dass ich den langen Thread nur teilweise gelesen > bzw. ueberflogen habe. Schon klar, ist etwas unübersichtlich... > Es freut mich, dass die Entwicklung voranschreitet und auch > neue Besitzer hinzu gekommen sind. Ja und wir haben auch neue Mitstreiter aus Italien. > Was mich etwas gewundert hat ist, dass Hayo die Sourcen nicht mehr > im .zip Archiv mitliefert. Wenn ich das recht verstehe liegt das > daran, dass im Moment nur Hayo daran arbeitet. > @Hayo: Es waere schoen wenn Du die Sourcen trotzdem wieder dabei > packst, auch wenn diese nicht "poliert" sind. So kann mal selbst > nachschauen oder Hand anlegen, wenn was klemmt. Ja ich wollte da dem Open Source Projekt nicht in die Quere kommen und hatte vorgeschlagen einen eigenen Branch für meine Sourcen anzulegen. Da aber jetzt schon mehrere danach gefragt haben werden ich die Sourcen bei der nächsten Version beilegen. > Ich persoenlich > wuerde auch wieder zu den Screenshot und Datendump-Funktionen > beitragen wollen, sofern es meine Zeit zulaesst (im Moment gibt > es ja anscheinend zwei Varianten). Ich arbeite gerade am USB-Interface (siehe weiter oben). Da gäbe es Bedarf an einer USB-Screenshot-Variante. Für Linux kann ich schon ein USB-Template beisteuern, bei WIN_USB arbeite ich noch daran. Die neue Version werde ich daher "etwas unfertig" mit den USB-Spezifikationen und den Sourcen in den nächsten Tagen rausgeben. Gruß Hayo
Hallo Michael D. und Hayo, das "Einfrieren" tritt bei mir nur auf, wenn die "Browser"-Funktion deaktiviert ist. Das "Einfrier"-Problem scheint mit dem Ausblenden des "Browser"-Balkens zusammen zu hängen. @Hayo: Wann steht denn die externe Trigger-Funktion bei Dir auf dem Plan? Gruß Bert
Ok, ich hab's jetzt auch geschafft das Signal einzufrieren. Wie Ihr schon sagtet bei langsamer Timebase (5 ms/Div) und dann im Browser langsam hin und her drehen, dann klappt's. Muß ich mal sehen woran das liegen kann. Danke für die Hinweise Hayo
Hayo W. schrieb: > to avoid such problems, I distribute the corresponding PC-addons with > the released versions in one package. > It is recommended to use those versions from the package. Maybe other > versions are working as well but it is not tested OK, I was not aware of this. I downloaded them separately. I will add a readme file to the downloads section telling about this. ie something like "Please use the version available in the firmware download package, as this ensures that firmware and application have been tested together. Other versions may not be fully compatible"
Bert schrieb: > Hallo Michael D. und Hayo, > > das "Einfrieren" tritt bei mir nur auf, wenn die "Browser"-Funktion > deaktiviert ist. Das "Einfrier"-Problem scheint mit dem Ausblenden des > "Browser"-Balkens zusammen zu hängen. > > Gruß Bert ...ei sag' ich doch, das war aber schon immer so bei dem Teil, egal was für eine SW-Ver. da drauf war... Ich unterstelle mal, das das Ein u. Ausblenden des Browsers etwas zuviel Rechenleistung erfordert, da bleibt der Rest vielleicht auf der Strecke! Hayo meinte mal, das eh' noch einiger Müll beseitigt werden müsse, vielleicht liegt's daran... Gruß Michael PS. Hayo, ich habe mal eine Schaltung für den ICS511 entworfen, ich schicke sie dir mal, schaust du mal drüber?
Ha, hab Ihn! War noch ein Relikt aus alten WELEC-Zeiten. Deshalb trat es auch in allen alten Versionen auf. Aber jetzt ist Schluß! Da hat der Kerl doch in der Interrupt Service Routine des Timer 3 (der steuert die Anzeigedauer des Browserfensters) einen Hardwareaufruf abgesetzt, der die ADC anhält. Hatte ich glatt übersehen, rechnet aber auch keiner mit. Fix auskommentiert und schon ist alles in Butter... Gruß Hayo
Hayo W. schrieb: > Ha, hab Ihn! > > War noch ein Relikt aus alten WELEC-Zeiten. Deshalb trat es auch in > allen alten Versionen auf. Aber jetzt ist Schluß! > > Da hat der Kerl doch in der Interrupt Service Routine des Timer 3 (der > steuert die Anzeigedauer des Browserfensters) einen Hardwareaufruf > abgesetzt, der die ADC anhält. Hatte ich glatt übersehen, rechnet aber > auch keiner mit. > > Fix auskommentiert und schon ist alles in Butter... > Sehr, sehr geil. Vielen Dank Hayo. Gruß Sven
Ach ja, schon mal vorab zur neuen BF.1.6 Die Zusammenarbeit mit der original WELEC PC-Software klappt ganz gut. Leider sind einige Bugs direkt in der PC-Software (war ja nicht anders zu erwarten). Aber alle Besitzer eines Zweikanal Gerätes sind fein raus, die merken davon nichts, da es nur die Kanäle 3 + 4 betrifft. Aber für "geschenkt" kann man immerhin einige Funktionen wie Messwertexport, FFT und Messwertberechnung (peak-peak etc.) nutzen. Gruß Hayo
Hayo W. schrieb : > Da hat der Kerl doch in der Interrupt Service Routine des Timer 3 (der > > steuert die Anzeigedauer des Browserfensters) einen Hardwareaufruf > > abgesetzt, der die ADC anhält. unglaublich, man meint, du wärs't mit der Software geboren worden :)) ...wieso friert's dann nicht ein, wenn das Browserfenster geöffnet bleibt oder war die Interruptanforderung nur für das öffnen u. schliesen? Gruß Michael PS. Hayo: Was ist, kann ich dir die Schaltung mal schicken?
Niklas O. schrieb: > ich melde mich mal nach laengerer Zeit zurueck, diverse > Gruende haben mich vom Basteln abgehalten. Hi, willkommen zurück. > Was mich etwas gewundert hat ist, dass Hayo die Sourcen nicht mehr > im .zip Archiv mitliefert. Wenn ich das recht verstehe liegt das > daran, dass im Moment nur Hayo daran arbeitet. Das ist ein Henne-Ei-Problem. Wenn Du in den hiesigen Threads nach "SVN" suchst, wirst Du eine Ursache finden. Gruß, Falk, der Deine Screenshot-Funktion verschlimmbessert hat ;-) P.S.: Ich will mich nicht streiten, aber mit NIOS ist das Ende der Fahnenstange bzgl. Performance und "Spikes" ungefähr da: http://www.youtube.com/watch?v=aD_A3JPSxlc http://www.youtube.com/watch?v=5tb16NtTws0
Hallo zusammen, vielen Dank an die fleißigen Hände der Entwicklerfraktion. Ich verfolge mit Begeisterung Eure Fortschritte. Ich habe mal 'ne ganz einfache Frage: Warum verschwinden bei Zeiten > 1s die 0V Marken? Die Spannung dann einzuschätzen wird schwierig. Oder steckt Absicht dahinter? Viele Grüße und vielen Dank, Rainer
Rainer Haape schrieb: > Hallo zusammen, > vielen Dank an die fleißigen Hände der Entwicklerfraktion. Ich verfolge > mit Begeisterung Eure Fortschritte. > Ich habe mal 'ne ganz einfache Frage: Warum verschwinden bei Zeiten > 1s > die 0V Marken? Die Spannung dann einzuschätzen wird schwierig. Oder > steckt Absicht dahinter? Hmm, kann ich momentan nichts zu sagen, da ich in der Firma bin und kein Gerät hier habe. Schau ich mir nachher mal an. Gruß Hayo
Michael D. schrieb: > unglaublich, man meint, du wärs't mit der Software geboren worden :)) Zumindest kenne ich sie jetzt schon fast auswendig ;-) > ...wieso friert's dann nicht ein, wenn das Browserfenster geöffnet > bleibt oder war die Interruptanforderung nur für das öffnen u. > schliesen? Nur für's Schließen. Beim Start des Browserfensters wird der Timer gestartet, wenn dann der Timer abgelaufen ist wird die Timer3 ISR aufgerufen. Zu diesem Zeitpunkt ist dann entscheidend ob gerade ein Acquisition-Lauf gestartet ist oder nicht. Wenn der nämlich schon durch ist, bleibt der Aufruf ohne Auswirkung, wenn er aber gerade läuft, dann erwischt es ihn kalt... d.h. das Acquisition_Ready Signal wird nie gesendet (weil der Lauf ja abgebrochen wurde) und der weitere Ablauf wartet dann bis Start_ADC irgendwann mal wieder aufgerufen wird. Das geschieht aber nur bei einigen wenigen Ereignissen, z.B. wenn man an der Timebase dreht oder den Stop/Start Knopf drückt. Gruß Hayo
Rainer H. schrieb: > Warum verschwinden bei Zeiten > 1s > die 0V Marken? Die Spannung dann einzuschätzen wird schwierig. Oder > steckt Absicht dahinter? So hab's mal gecheckt, ja es lag Absicht dahinter, da ja die Triggermarken hier keinen Sinn machen hab ich der Einfachheit halber alles ausgeblendet. Da ich aber Dein Anliegen gut nachvollziehen kann hab ich das jetzt etwas eleganter gelöst und nur die Triggermarken ausgeblendet. Die Nulllinien werden jetzt wieder angezeigt. Gruß Hayo
Jupp, hier ist sie, das USB-Interface ist noch in Arbeit aber es geht schon etwas. Die Änderungen stehen wie immer im changelog. Diesmal sind die Sourcen dabei und auch ein USB-Template für Linux. Die USB-Spezifikation findet Ihr im Programmers Guide, der jetzt die einzelnen Exceldateien ersetzt. Leider wird auf SFN der Upload Link nicht mehr automatisch aktualisiert seit Jan das geändert hat. Und noch mal auf auswärts: Hi, get here the new 1.2.BF.1.6 - USB-Interface is still under construction but some features work. Changes are described in the changelog. Sources are in the package and also an USB-template for Linux. The USB-specs can be found in the programmers guide which replaces the single Excel files. The upload link on SFN points to the old version because there is no automatic update since Jan changed some settings. Hayo
Angehängte Dateien:
-
screenshot-0002.png
4,2 KB
Guten Abend, habe gerade mal die neuste Version installiert. Den folgenden Fehler kann icht nicht reproduzieren, er ist beim ändern der Timebase aufgetreten nachdem ich CH2 deaktiviert hatte. Gruß, moud PS: Habe ein 2022A PPS: Nochmal Danke für deine Arbeit! Endlich ist das Oszi sein Geld wert!
moud schrieb: > Guten Abend, > > habe gerade mal die neuste Version installiert. Den folgenden Fehler > kann icht nicht reproduzieren, er ist beim ändern der Timebase > aufgetreten nachdem ich CH2 deaktiviert hatte. Huch, wie hast Du das denn hingekriegt????? Hattest Du nach dem Firmwareupdate einen Reset bzw. Neustart durchgeführt? Sonst läuft das DSO eventuel in undefinierten Betriebszuständen. Gruß Hayo
Hayo W. schrieb: > Huch, wie hast Du das denn hingekriegt????? Hattest Du nach dem > Firmwareupdate einen Reset bzw. Neustart durchgeführt? Guten Morgen, wie gesagt, ich weiß es nicht. DSO war definitiv neu gestartet und ich war dabei die sehr komfortable Screenshot-funktion mit dem 2x drücken auf "Quick Print" auszuprobieren. Also mach dir mal keinen all zu großen Kopf. Wenn ichs nochmal schaffe, melde ich mich. Gruß moud
Noch ein kleiner Nachtrag zu den original WELEC PC-Anwendungen: - das Firmwareupload via USB funktioniert zwar, braucht aber sage und schreibe 1h20m für den kompletten Upload. Desweiteren habe ich auch nur den "Upgrade" von 1.2.BF.1.6 auf WELEC 1.3 getestet. Ob die Open Source Versionen geladen werden weiß ich nicht. Es ist ein neues USB-Firmwareuploadprogramm geplant. - das PC-Programm zur Messdatenaufbereitung und Fernsteuerung des DSO arbeitet ganz akzeptabel, wenn man davon absieht, das Kanal 3 die Zusammenarbeit zum Teil verweigert und Kanal 4 falsch skalierte Werte liefert. Bei letzterem kann ich evtl. korrigierend eingreifen, bei Kanal 3 sieht es nicht so gut aus. And in english: - firmware upload via USB with the original WELEC program works, but needs incredible 1h20m for the upload. It is tested only the "upgrade" of 1.2.BF.1.6 to WELEC 1.3 - other combinations may work or not. A new USB Frirmware update program is planned in future. - The PC-program for data export and romote control works partly, channel 1 + 2 are ok, channel 3 doesn't have any ambition to work and channel 4 has wrong scaled values which might be corrected on DSO-side. Hayo
Hallo Hayo, folgendes Problem beim Quickprint in der 1.6er Ver. : Bei ---"Save to BMP"--- bleibt das Oszi stehen und wacht auch nicht mehr auf. Bei 2x ---"Quickprint"--- drücken ist alles Ok, tritt auf bei beiden Screenshotver. auf, OS u. BF. Ich habe die 1.5er noch mal geflasht und dort funzt alles einwandfrei, wer hat das mal getestet? ...noch was, hat die BF1.5er Screenshot einen Schluckauf, braucht ja ewig, bis die fertig ist mit generieren! Gruß Michael PS. Hayo, ich habe gestern den ICS511 mit Quarzen zum laufen gebracht, das Ding rennt ja wie der Teufel! Bis 160MHz geht's noch! Ich werde später mal was im HW-Thread berichten.
Oh sorry, da hatte ich testweise die original WELEC Screenshot Funktion eingebaut und vergessen wieder rauszunehmen. Hier die 2. Compilation mit korrigierter Screenshotfunktion. Hi, I forgot a testfunction in the screenshot (BMP) Menu which causes a crash. Please use the 2. compilation provided here. Hayo
moud schrieb: > habe gerade mal die neuste Version installiert. Den folgenden Fehler > kann icht nicht reproduzieren, > DSO war definitiv neu gestartet und ich > war dabei die sehr komfortable Screenshot-funktion mit dem 2x drücken > auf "Quick Print" auszuprobieren. Da haben wir dann wohl auch die Ursache für Dein merkwürdiges Problem gefunden....und gleich gelöst. Hayo
Hi Hayo and all guys thanks for the excellent work! Really thanks very much to all You! Vielen Dank! Luc
Thank you Hayo! I've see the source file, Thank you, now I have some reading to do! :-) Franco
Hallo Hayo, Danke für die Referenzmarken im Rollmodus, da fällt die Orientierung doch viel leichter. Viele Grüße, Rainer
Rainer H. schrieb: > Hallo Hayo, > Danke für die Referenzmarken im Rollmodus, da fällt die Orientierung > doch viel leichter. Stimmt, aber mir ist noch ein Grund aufgefallen warum ich die ausgeblendet hatte - wegen der niedrigen Wiederholrate im USTB-Modus "schmieren" die Marken etwas beim Verstellen, aber damit kann man wohl leben. Gruß Hayo
Hallo Hayo, Bert schrieb: > @Hayo: > Wann steht denn die externe Trigger-Funktion bei Dir auf dem Plan? Kannst Du schon was dazu sagen? Wäre doch schön, wenn solche Grundfunktionen eines Oszi's auch funktionieren würden. Gruß Bert
Ich schau mir das mal an. Vielleicht kann ich ja kurzfristig was machen. Gruß Hayo
Angehängte Dateien:
-
Ext_Trigger.jpg
130 KB
Hi Bert, ich habe Schwierigkeiten Deine Probleme nachzuvollziehen. Bei mir triggert er extern ohne Probleme in allen Einstellungen (Auto, Normal, Combi) und auch bei LF und HF Reject. Holdoff habe ich nicht geprüft -> war off. Einziges Manko war die Skalierung des Levels, die nicht zu stimmen scheint. Was genau funktioniert denn bei Dir nicht? Gruß Hayo
Hallo Hayo, anbei nochmals die Beiträge. Weil egberto auch das Problem hat, glaube ich das es nicht an meiner Hardware liegt. Ich werde nochmals mit der Vers. 1.6 testen. Vielleicht könnten ander Besitzer auch mal sagen ob der externe Trigger funktioniert oder nicht. Bert schrieb: > bei meinem W2024 funktioniert die externe Triggerung nicht. > Firmware: 1.2.BF.1.4. > Bei Ext.-Line-Triggerung bekomme ich bei 100Hz Rechteck ein stehendes > Bild. > Bei Ext-HF und Ext.-LF erfolgt keine Triggerung, egal bei welchem Pegel, > auch nicht wenn ich das Rechteck-Signal über einen DC-Pegel verschiebe. > Hat jemand ähnliche Probleme oder einen Vorschlag? > Gruß Bert egberto schrieb: > @Bert (und natürlich Hayo) > kann ich bestätigen, bei mir läuft das Bild auch.... > Das Problem trat bei mir auch erst auf, nach dem ich auf Kanal 2 > triggern wollte (triggern auf Kanal 1 war bis dahin ok), dann triggerte > er auf Kanal 1 auch nicht mehr.... (TTL Rechteck 2 MHz) > Viele Grüße, > egberto Gruß Bert
So um vorweg mit allen auf der gleichen Basis zu diskutieren hier erstmal etwas Knowhow zum exterrnen Trigger: • Externe Triggerung: Das Triggersignal wird von außen zugeführt, beispielsweise vom Signalgeber selbst. • line: Dabei wird das Triggersignal nicht aus dem Messsignal, sondern aus der 50 Hz Wechselspannung des Netzes gewonnen. Damit bietet sich z.B. die Möglichkeit zu testen, ob irgendwelche angezeigten Störspannungen als Ursache die 50 Hz Netzspannung haben. (In diesem Fall ergibt sich ein stehendes Bild.) • hf-reject: Bei bestimmten Signalen sollen hochfrequente Anteile des Messsignals als Triggerursache ausgeschaltet werden. In diesem Fall wird durch hf-reject ein Tiefpass vor den Triggerkomparator geschaltet. • lf-reject: Im umgekehrten Fall (falls niederfrequente Signale als Triggerursache ausscheiden sollen), wird durch lf-reject ein Hochpass vor den Komparator geschaltet. Ebenfalls ein Hochpassverhalten zeigt die Triggerung bei AC-Kopplung. Die Grenzfrequenz dieses Hochpasses liegt aber wesentlich tiefer. Der Trigger kann mit AC oder DC gekoppelt werden. Also, wenn ich auf line triggere (also auf die Netzfrequenz) ergibt sich bei 50 Hz ein sauberes Bild. Bei anderen Frequenzen läuft das Signal naturgemäß mehr oder weniger schnell durch. Bei lf-reject steht das Signal nicht so sauber, ja nach Triggerlevel steht es dann an irgendeinem Spike am Signal. Am besten sieht es aus wenn ich mit hf-reject triggere, da dann die hochfrequenten (Störanteile) keinen Einfluß haben. Signal: 100Hz Vpp: 15V Ta: 500KSa/s Tb: 500µs/div Trigger: Norm Flanke: rising Gruß Hayo
Potzblitz, kanntet Ihr das schon? Ich meine die zweite Seite mit den Preisen! Stellt Euch vor Ihr hättet tatsächlich soviel Geld dafür ausgegeben... Hayo
Hallo Hayo und Bert, Thema Trigger - funktioniert bei mir (Firmware 1.5) - aber ich kann nicht sagen, ob es die Firmware gebracht hat oder ich nur zu blöd zum bedienen war. Schönes WE egberto
Nachtrag - der Triggerlevel für extern wird im Bild aber nicht angezeigt (ok, hat mit den Signalen dort ja auch nix zu tun) - könnte man den nicht noch irgendwie als Pfeil in einer anderen Farbe dazu malen? Nur so als Vorschlag.
egberto schrieb: > Nachtrag - der Triggerlevel für extern wird im Bild aber nicht angezeigt > (ok, hat mit den Signalen dort ja auch nix zu tun) - könnte man den > nicht noch irgendwie als Pfeil in einer anderen Farbe dazu malen? Nur so > als Vorschlag. Und in Relation zu welcher Nulllinie? Gruß Hayo
Hallo Hayo und egberto, bitte probiert mal folgendes aus. Ext. Triggerung mit Darstellung einer halben Periode und dann ein bischen an der Frequenz rauf und runter drehen. Ab 3 Pulse ist es bei mir auch stabil, darunter wird es instabiler. Frequenz ca. 100Hz oder 1kHz. Gruß Bert
Da ist doch irgendwie der Wurm drin.... 1. Indiz - Triggere ich auf Kanal 1, erhöhe ich die Triggerschwelle durch drehen im Uhrzeigersinn, schalte ich auf Ext. HF rej. ist es plötzlich umgekehrt. 2. Indiz - ich bekomme die Schwelle nur auf max. 2.5 V - geht da nur ttl (+- 2.5 V)? Bei meinen weiteren Versuchen habe auch ich keine externe Triggerung mehr hinbekommen.... Anscheinend scheint wirklich der Level irgendwo in der Luft zu hängen... Zum Thema Nulline - da ich ja das externe Triggersignal nicht auf dem Schirm sehe (und damit verschieben kann, ist die Nullinie nat. in der Mitte - oder? Grüße, egberto
Hallo, der Bereich für externe Triggerung ist imho nicht umschaltbar. Ich sehe da zumindest in der Schaltung nichts. Könnte also gut sein, dass die Triggerschwelle hier nur zwischen 0 und z.B 5 V eingestellt werden kann. Gruß, Guido
Also zumindest bei mir wird beim ext. Trigger oben rechts ein Schwellwert angegeben. Es sollte also einstellbar sein.
Ich habe mal ins WELEC Handbuch geschaut (die Spezifikationen sollten ja wenigstens stimmen ;-)) Der ext. Triggereingang kann 400Vpp ab, es ist ein Abschwächer von 1:1 bis 1:1000 zuschaltbar, die Levelanzeige von +- 2.5 V ist also doch recht obskur. Viele Grüße, egberto
Hallo Leute, was gilt von der Trigger-Mode-Anzeige eigentlich auch für den ext. Trigger? So wie ich das sehe nur der Triggermode, oder? Im Combi-Triggermode habe ich bei Triggerung auf Kanal 1 ein stehendes Bild. Stelle ich auf ext. Trig. um läuft das Bild (je nach Frequenz). Stelle ich den Triggermode auf "Normal" steht das Bild auch bei ext. Trigger. Der ext. Trigger funktioniert scheinbar nur stabil im "Normal"-Mode. Frage, muss das so sein? Gruß Bert
bei mir triggert er im normal Modus gar nicht mehr - spricht für meine These der in der Luft hängenden Triggerschwelle. Bei meinem 1. Versuch (wo es ging) hatte ich vorher bei "normaler" Triggerung recht viel rumgespielt - kann sein, das dadurch die Triggerschwelle für den ext. Trigger auf einem vernünftigen Wert war.
ist bei mir auch so. Drehe ich am Trigger-Level wird es erst instabil und bei weiterer Verstellung kommt dann kein Trigger mehr. Der angezeigte Pegel liegt aber noch im Signal drin und es triggert nicht mehr. Noch was zum angezeigten Trigger-Level: Trigger-Level zunächst erhöhen und dann zurück: von 600mV -> 800mV -> 900mV -> 1mV -> 1,1V zurück 1V. Die angezeigten 1mV sind dann wohl 1V.
Die einstellbare Abschwächung bezieht sich nur auf den verwendeten Tastkopf (1:1 bis 1:1000). Das Gerät selbst hat wohl keine Umschaltung, über den Pegelbreich finde ich nichts. Ihr müsst halt ausprobieren (AC-Signal mit Offset), was eingestellt werden kann und ob die Anzeige hierzu vernünftig ist.
heißt das, es wird nur die Bildschirmanzeige für den Triggerlevel 1,6V ->16V->160V dadurch "umgeschaltet"? Das bringt ja mehr Verwirrung als Information oder? Viele Grüße, egberto
So ist es. Das bringt wenig Verwirrung, wenn man daran denkt(!) es korrekt einzustellen. Passiert mir aber auch immer mal wieder, dass ich das auch auf den Kanälen falsch eingestellt habe und dann über dem Fehler grüble. Gruß, Guido
Hallo Guido, bei den Tek Tastköpfen finde ich das ja ok, wenn das Gerät das auch mitbekommt, aber wenn ich selbst dran denken muß, das noch am Gerät einzustellen, kann ich auch gleich selbst (in Gedanken)durch 10 (oder was auch immer) teilen. Die Einstellerei am Gerät ist doch eigentlich nur eine Fehlerquelle!
ich meinte natürlich multiplizieren...ist halt schon etwas später, das Glas leerer usw....
Hi, meine Gläser sind inzwischen auch schon alle leer, aber trotzdem hier der letzte Stand der Dinge. Also der externe Triggerlevel lässt sich in 33 Schritten zwischen ca. +9V und -9V einstellen. Bei 9V werden aber nur 2,5V angezeigt (Deshalb das Gefühl, dass der Trigger in der Luft hängt). Die Registerwerte und die angezeigten Werte sind einander in zwei Werte-Arrays a 33 Werten direkt zugeordnet. So was habe ich also heute Abend gemacht? Ich habe den Wertebereich auf 129 Werte aufgeblasen und die Skalierung auf die tatsächlichen Werte angepasst, so dass sich das Ganze jetzt etwas geschmeidiger bedienen läßt. Das Ganze gibt es in Kürze in der BF.1.7 So long Hayo
Hallo egberto, natürlich ist es Geschmackssache, die einfachen Hameg machen das ja auch nicht, so dass man selbst daran denken muss. Aber eigentlich machen das heute alle Oszis so, da wird man sich wohl dran gewöhnen müssen. ;-) Gruß, Guido
...dann machen wir uns ein kleines Zettelchen auf dem steht: Probe 1:1 ? 1:10 ? umstellen ! Das kleben wir dann auf das Display, ist dann immer im Sichtfeld...:)
Hallo Hayo, einige Fragen zum Trigger: Bert schrieb: > Noch was zum angezeigten Trigger-Level: > Trigger-Level zunächst erhöhen und dann zurück: > von 600mV -> 800mV -> 900mV -> 1mV -> 1,1V zurück 1V. > Die angezeigten 1mV sind dann wohl 1V. Ist dieses Problem dann mit BF.1.7 erledigt? Bert schrieb: > was gilt von der Trigger-Mode-Anzeige eigentlich auch für den ext. > Trigger? > So wie ich das sehe nur der Triggermode, oder? > Im Combi-Triggermode habe ich bei Triggerung auf Kanal 1 ein stehendes > Bild. Stelle ich auf ext. Trig. um läuft das Bild (je nach Frequenz). > Stelle ich den Triggermode auf "Normal" steht das Bild auch bei ext. > Trigger. > Der ext. Trigger funktioniert scheinbar nur stabil im "Normal"-Mode. > Frage, muss das so sein? Ist es richtig, das der ext. Trigger nur im Normal-Modus funktioniert und der Combi-Modus nicht stabil funktioniert? Wirkt die AC/DC-Kopplung auch beim ext. Trigger? Gilt der TV-Modus nur für Kanal 1 (deshalb dieses Kästchen mit der 1)? Verwirrend finde ich z. B. auch, wenn in der Mode-Anzeige Reject auf "HF-Reject" steht, der ext. Trigger aber auf "ext. LF Rej" eingestellt ist. Danke für die Hilfe! Gruß Bert
Bert schrieb: > Hallo Hayo, > einige Fragen zum Trigger: >> Die angezeigten 1mV sind dann wohl 1V. > > Ist dieses Problem dann mit BF.1.7 erledigt? Ja > Bert schrieb: >> was gilt von der Trigger-Mode-Anzeige eigentlich auch für den ext. >> Trigger? >> So wie ich das sehe nur der Triggermode, oder? Auto und Normal, die Flanke, der Level, hab ich noch was vergessen? >> Der ext. Trigger funktioniert scheinbar nur stabil im "Normal"-Mode. >> Frage, muss das so sein? Der Automode sorgt halt konstruktionsbedingt dafür, dass auch ohne Triggerereignis der Trigger auslöst > Ist es richtig, das der ext. Trigger nur im Normal-Modus funktioniert > und der Combi-Modus nicht stabil funktioniert? Ja, das ist korrekt, das liegt daran, das der Combi-Trigger zusätzlich die Samplewerte eines Signals auswertet. Für den externen Trigger stehen aber keine Werte zur Verfügung. > Wirkt die AC/DC-Kopplung auch beim ext. Trigger? Das sollte sie auf jeden Fall (siehe oben), aber ob sie es auch wirklich tut habe ich noch nicht überprüft. > Gilt der TV-Modus nur für Kanal 1 (deshalb dieses Kästchen mit der 1)? Den TV-Modus hab ich noch nicht untersucht, da mir auch das Hintergrundwissen zur TV-Triggerung fehlt. Vielleicht kennt sich hier jemand damit aus? > Verwirrend finde ich z. B. auch, wenn in der Mode-Anzeige Reject auf > "HF-Reject" steht, der ext. Trigger aber auf "ext. LF Rej" eingestellt > ist. Muß ich mir mal ansehen, vielleicht kann man da was ändern. Gruß Hayo
Hallo Hayo, danke für die Infos! Bedienerfreundlicher fände ich die Anzeige der aktuellen Einstellung bei ext. Trigger und TV-Trigger. Bisher wird nur ein Haken angezeigt. Bei "Source" wird die Kanalnummer angezeigt, da ist es direkt zu erkennen. Vielleicht kann der Haken durch die akt. Einstellung ersetzt werden, das fände ich übersichtlicher. Gruß Bert
Hallo Hayo, und noch ein Hinweis. Hayo W. schrieb: >> Ist es richtig, das der ext. Trigger nur im Normal-Modus funktioniert >> und der Combi-Modus nicht stabil funktioniert? > > Ja, das ist korrekt, das liegt daran, das der Combi-Trigger zusätzlich > die Samplewerte eines Signals auswertet. Für den externen Trigger stehen > aber keine Werte zur Verfügung. Vielleicht sollte bei Aktivierung des ext. Trigger ein evt. eingestellter Combi-Mode automatisch in den Normal-Mode wechseln. Das war nämlich mein Haupt-Problem mit dem ext. Trigger, das der Combi-Mode bei ext. Trigger aktiviert war. Gruß Bert
Angehängte Dateien:
-
TriggerExt_Low.png
3,8 KB -
TriggerExt_High.png
3,9 KB -
TriggerExt_Line.png
3,7 KB
Hallo Bert, > Verwirrend finde ich z. B. auch, wenn in der Mode-Anzeige Reject auf > "HF-Reject" steht, der ext. Trigger aber auf "ext. LF Rej" eingestellt > ist. Ich habe das mal getestet und es zeigt alles so an wie es soll... 1.Foto : Externer Trigger steht auf LOW und wird oben rechts korrekt angezeigt 2. Foto: Ext. Trigger steht auf HIGH, wird auch korrekt angezeigt. 3. Foto: Ext. Trigger steht auf LINE, auch hier stimmt die Anzeige was stimmt da jetzt bei dir nicht? Gruß Michael EDIT: ich kann mich dunkel erinnern, das früher die EXT-Trigger-Einstellung über den Softbutton, angezeigt wurde.
Bert schrieb: > Vielleicht sollte bei Aktivierung des ext. Trigger ein evt. > eingestellter Combi-Mode automatisch in den Normal-Mode wechseln. Das ist eine Idee, werd ich mal einbauen... Hayo
Bert schrieb: > Vielleicht kann der Haken durch die akt. Einstellung ersetzt werden, das > fände ich übersichtlicher. Ich werd mir da mal was überlegen... Hayo
@Michael, schau dir doch mal die Triggerpunkte in deinen Bildern an, dann siehst du, was nicht stimmt (oder hattest du bei dem Screenshot kein stehendes Bild?). Ich habe eben auch noch mal getestet, bei 800 mV hat er auf mein TTL Signal auch getriggert, dann habe ich aber am Pretrigger etwas länger hin und her gestellt ->Bild fror ein, nix mehr mit Trigger.... Noch ein Vorschlag, diese HF/RF/Line Einstellung nur noch im Edge Menü, Ext. Trigger einfach in die Liste der Triggerkanäle aufnehmen (falls das von der Systhematik passt). Schönes WE, egberto
Hallo Leute, @Michael: bitte stelle mal den ext. Trigger auf ext. LF Rej. Dann drückke den Trigger-Mode und unten steht dann z. B. (oder einstellen) bei Reject auf HF Reject. Das sind dann widersprüchliche Anzeigen. Der Reject zeigt HF an, der ext. Trigger ist aber auf LF eingestellt. Das war mein Kritikpunkt. @Hayo: Auch noch ein Vorschlag: Alles was bei ext. Trigger und TV-Trigger keinen Sinn macht z. B. die entspr. Softkeys im Mode-Menu deaktivieren und "unsinnige" Einstellungen ausblenden. Beispiel: Reject oder ggf. Coupling (AC/DC) und ggf. Hold off. Weiß jemand ob der ext. Trigger-Eingang eine Ac/DC-Umschaltung hat? Gruß Bert
Hayo W. schrieb: > Bert schrieb: >> Vielleicht sollte bei Aktivierung des ext. Trigger ein evt. >> eingestellter Combi-Mode automatisch in den Normal-Mode wechseln. > > Das ist eine Idee, werd ich mal einbauen... > Hayo Danach sollte der Combi-Mode nicht mehr einstellbar sein solange der ext. Trigger aktiv ist (Combi-Mode hellgrau wie z. B. inaktive Kanäle bei der Source Einstellung).
Und noch ein Vorschlag - einige haben doch Zugriff auf "ordentliche" Oszis (Tek etc.). Da könnte man sich doch was die Menüführung betrifft einiges abschauen. Ich klink mich erst mal aus, bin ab morgen im Urlaub (und ich nehm das Teil nicht mit!!;-). Viele Grüße, egberto
Hallo, wird ja immer brauchbarer! Gäbe es die möglichkeit für den TV Trigger einen LineSelector zu realisieren? Sprich das man auchsuchen kann auf welche zeile man Triggert und damit immer die gleiche angezeigt wird? Gruß Torsten
Torsten W. schrieb: > Gäbe es die möglichkeit für den TV Trigger einen LineSelector zu > realisieren? Lohnt sich das denn wirklich noch? Die analoge Videotechnik stirbt doch aus, oder?
Angehängte Dateien:
-
TriggerExt_MODE_Coupling.png
3,7 KB
Bert schrieb: > @Michael: > > bitte stelle mal den ext. Trigger auf ext. LF Rej. ...hab' ich > Dann drückke den Trigger-Mode und unten steht dann z. B. (oder > einstellen) bei Reject auf HF Reject. ...jetzt weiss ich, was du meinst: ---MODE-COUPLING--- Stimmt, die Anzeige ist falsch! > Das sind dann widersprüchliche Anzeigen. Der Reject zeigt HF an, der > ext. Trigger ist aber auf LF eingestellt. Das war mein Kritikpunkt. Ich habe noch mal ein Screenshot gemacht: Oben rechts steht wohl "XH" neben dem Triggermode, nach drücken der Mode-Coupling Taste steht dann unten "REJECT LF-REJECT" Das ist ist wohl wiedersprüchlich, entschuldige, konnte das erst nicht nachvollziehen, aber jetzt... Bert, meinst du das, wie es auf dem Screenshot zu sehen ist? Gruß Michael
@Michael: Korrekt und in umgekehrter Einstellung genau so, auch in "Line" Einstellung, dort gibt es vermutlich kein LF-/HF-Reject. Die Reject-Einstellung im Mode-Menue hat keine Auswirkung auf den ext. Trigger und verwirrt nur. Deshalb der Vorschlag, alles auszublenden was bei ext. Trigger und TV-Trigger "unsinnig" ist. Gruß Bert
Ein Lineselector hat vieleicht auch in der heutigen hdtv welt einen gewissen wert da es auch bei hdtv analoge komponentensignale gibt. Lohnt sich allerdings auch nur wenn der aufwand für die realisierung nicht allzugroß ist, da es warscheinlich fast niemand braucht bzw. nur im produktionsbereich anwendung findet.
Hallo Leute, egberto schrieb: > Und noch ein Vorschlag - einige haben doch Zugriff auf "ordentliche" > Oszis (Tek etc.). > Da könnte man sich doch was die Menüführung betrifft einiges abschauen. Anbei das User Guide von der Agilent 6000er Serie. Von Agilent ist ja das Design für die Welec-DSO's "übernommen" worden. Von der Bedienung lässt sich sicher auch noch einiges "übernehmen" z. B. Trigger-Einstellungen. Gruß Bert
Naja, noch gibt es die Signale, nutzen tut sie kaum noch jemand. Ich bin etwas ratlos, wie man das realisieren könnte, da vermutlich V- und H-Sync zusammengefasst am FPGA ankommen. Wie kann man die beiden dann unterscheiden? An der Länge, mit Timer im FPGA? Vielleicht hat Hayo ja in der Firmware irgendwo schon was dazu gefunden. Gruß, Guido
Danke für das Manual - hier ist es also wirklich so, das im Menü Triggerquelle, die Kanäle, Ext und Line auftauchen - den Filter(HF rej etc.) wählt man dann im anderen Menü. (Die anderen Filter wären nat. auch Traumhaft - SPI, I2C...beim 4 Kanaler technisch bestimmt machbar) Grüße, egberto
Nach http://welecw2000a.sourceforge.net/docs/schematics/Ext_Syncro_V1.1.pdf kann man auf Vsync und Composite sync triggern. Fehlt leider ein einzelnes H-sync was die sache etwas komplizierter macht.
Bert schrieb: > @Michael: > > Korrekt und in umgekehrter Einstellung genau so, auch in "Line" > Einstellung, dort gibt es vermutlich kein LF-/HF-Reject. > Die Reject-Einstellung im Mode-Menue hat keine Auswirkung auf den ext. > Trigger und verwirrt nur. Deshalb der Vorschlag, alles auszublenden was > bei ext. Trigger und TV-Trigger "unsinnig" ist. > > ...da haben wir's doch...was eine Geburt. :) > ich bin überzeugt davon, das der Hayo das hin bekommt! > Gruß Bert Gruß Michael
Ich seh schon hier ist richtig was los. Ich bin allerding immer noch dabei den Einstellbereich für den ext. Triggerlevel zu justieren. Da ich jeden Wert einzeln ausmessen muß dauert das etwas... Gruß Hayo
Angehängte Dateien:
-
Signale_LM1881.png
4,1 KB
Guten Abend zusammen, wirehead schrieb: > Nach http://welecw2000a.sourceforge.net/docs/schematics... > kann man auf Vsync und Composite sync triggern. > Fehlt leider ein einzelnes H-sync was die sache etwas komplizierter > macht. So ein richtig ernstes Problem sehe ich da gar nicht. Auf V-Sync gibt es bei jedem Halbbildwechsel eine Flanke und auf C-Sync kommt bei jeder Zeile ein Puls. Allenfalls muß man bei der ersten/letzen Zeile aufpassen. Grundsätzlich sollte das aber klappen. Zum Zeilentriggern müßte man - erst auf V-Sync Flanke triggern und auf Bildanfang warten - bei Trigger-Event mit U26 umschalten auf C-Sync - Trigger-Events bis zur gewünschten Zeile zählen - Signalaufzeichnung starten (Triggerpointer merken) - mit U26 umschalten auf V-Sync und auf's nächste Bild waren - und immer schön die Triggerflanke zwischen den Halbbildern umschalten... Die Frage ist, wie wichtig das für's praktische Leben und in Relation zum Aufwand ist. Gruß Rainer
Rainer schrieb: > Die Frage ist, wie wichtig das für's praktische Leben und in Relation > zum Aufwand ist. Auch ich denke, dass es noch andere Stellen gibt die da erstmal angegangen werden sollten, da der Nutzen einfach größer ist. Wenn der externe Trigger soweit vernünftig funktioniert, werde ich wieder in Richtung USB und Overlay-Funktion weitermachen - es sei denn es gibt noch brennende Probleme anderswo. Gruß Hayo
genau, lieber SPI und I2C Trigger ;-))) Viele Grüße, egberto
Damit hat es sicher keine Eile, wenn es überhaupt möglich ist. C- und V-Sync sind ja zusätzlich noch ODER- verknüpft, so dass am FPGA nur die Kombination ankommt. Was die digitalen Bussignale anbetrifft, halte ich das eh für Quatsch. Dafür ist die Speichertiefe zu gering. Wer sowas braucht (wer braucht sowas eigentlich?) kann sich doch einen MiniLA bauen, der ist dafür viel beser geeignet als ein Oszilloskop und auch sehr günstig. Gruß, Guido
schon klar, war als nette Zugabe gemeint (praktischer als dieses TV Zeugs), erst mal haben aber die Fehlerkorrekturen Vorrang! Viele Grüße, egberto
hier ist ja so ein Teil, ist mit 100MHz angegeben und LPT-Port, der Link dazu ist hier: http://minila.sourceforge.net/hw/mainboard/hw.php?id=hw&sm=mainboard Gruß Michael
Hallo Hayo, ich habe noch ein Problem mit der Pre-Trigger-Anzeige. Firmware: BF 1.4 Zeitbasis: 2ms/Div Trigger: pos. Edge, Pre-Trigger 2ms => Triggerpunkt nach dem ersten Kästchen Verstellung: Zeitbasis auf 1ms/Div Nach einer "Weile" springt die Pre-Trigger-Anzeige auf 1,1ms (sollte 1ms sein). Verstellung: Zeitbasis von 2ms/Div auf 5ms/Div Nach einer "Weile" springt die Pre-Trigger-Anzeige auf 5,5ms (sollte 5ms sein). Jede weitere Verstellung: Pre-Trigger wird nicht mehr aktualisiert. Verstellung Edge (pos. Flanke auf neg. Flanke): Pre-Trigger wird aktualisiert. Gruß Bert
Hallo Hayo, einige Fragen zum ADC- und DAC-Abgleich: Lt. Deiner Beschreibung sollen die Eingänge auf Masse gelegt werden "alle Eingänge von Signalen befreien, oder besser noch alle Eingänge auf Ground legen (mit den Tastköpfen oder einem Kurzschlußstecker)". Ich habe die Eingänge mittels "Coupling" auf Ground gelegt. Funktioniert diese Vorgehensweise auch? Wenn ja, wäre dies einfacher. Die Kanäle 3 und 4 lassen sich bei mir nicht gut abgleichen. Kanal 3 ist 1V unter der Nullinie, Kanal 4 ist 1,5V unter der Nullinie bei Abgleich mit "Coupling" auf Ground. Lasse ich die Eingänge offen oder mit Kurzschlußbrücke ist es noch wesentlich schlechter. Hast Du eine Idee? Gruß Bert
Bert schrieb: > Ich habe die Eingänge mittels "Coupling" auf Ground gelegt. Funktioniert > diese Vorgehensweise auch? Hallo Bert, das funktioniert imho nicht, da hierbei nur rechnerisch die Messwerte auf Null gesetzt werden. Wenn ich mich recht entsinne, ist im Oszi keine Schaltung zum Kurzschluss vorhanden. Also besser die Eingänge offen lassen. Gruß, Guido
Hallo Bert, du hast noch die 1.4er Ver., mein Vorschlag wäre, hau dir die 1.6 drauf und teste da mal den Abgleich! Ich lasse die Eingänge immer offen oder schliese diese mit dem Tastkopp(1:1) auf Masse. Des weiteren hast du noch die Möglichkeit unter 'HARDWARE' im Utility-Menu, verschiedene Modi für den ADC-Abgleich zu testen, vielleicht löst das dein Problem...1V, 1,5V, ist ja gewaltig, geht ja ja garnicht. Widerstände hast du ja keine getauscht, oder? Gruß Michael noch was, leg mal alle Kanäle übereinander und calibrier dann mal, bei mir waren dann alle Kanäle gleich, allerdings habe ich nur das W2022, hatte da aber auch Probleme mit der Nulllinie!
Hallo Leute, das Problem mit dem Abgleich habe ich etwas eingegrenzt. Die 4 Kanäle gleichen gut ab, wenn die Trigger-Source Kanal 1 oder 2 ist. Ist als Trigger-Source der externe Trigger oder der TV-Trigger aktiviert, dann gleichen die Kanäle 3 und 4 sehr schlecht ab. Ist als Trigger-Source der Kanal 3 oder 4 aktiviert, dann gleichen die Kanäle 1 und 2 sehr schlecht ab. Muss ich das jetzt verstehen? Gruß Bert
@Michael: Michael D. schrieb: > Widerstände hast du ja keine getauscht, oder? Alles noch original. @Hayo: Kleiner Verbesserungsvorschlag: Als Abgleichreihenfolge könnte man sich Reihenfolge der Softkeys merken von links nach rechts. Dafür müssten die Softkeys "Calibrate ADC" und "Search Zero Lines" getauscht werden. Gruß Bert
Ohne euch stören zu wollen, wer braucht in Zeiten von HDMI und DVB eigentlich noch diese ganzen TV-Trigger? Bei helmut singer trudeln zur Zeit auch gehäuft TV-Messsender und ähnliches ein...
Bert schrieb: > Hallo Leute, > > das Problem mit dem Abgleich habe ich etwas eingegrenzt. > Die 4 Kanäle gleichen gut ab, wenn die Trigger-Source Kanal 1 oder 2 > ist. > > Ist als Trigger-Source der externe Trigger oder der TV-Trigger > aktiviert, dann gleichen die Kanäle 3 und 4 sehr schlecht ab. > > Ist als Trigger-Source der Kanal 3 oder 4 aktiviert, dann gleichen die > Kanäle 1 und 2 sehr schlecht ab. > > Muss ich das jetzt verstehen? > > Gruß Bert Was'n jetzt? Nach oder vor der Kalibrierung? Oder was meinst du jetzt? Kalibrierung erfolgt im Automodus, bzw. Default-Setup drücken, dann folgt der Abgleich: Search Zerolines, ADC, DAC...funzt bei 5V/DIV! Laut Hayo stimmen dann die anderen Spannungen auch, also die 2V, 1V und 500mV/DIV müssen dann nicht mehr justiert werden. >@Hayo: >Kleiner Verbesserungsvorschlag: >Als Abgleichreihenfolge könnte man sich Reihenfolge der Softkeys merken >von links nach rechts. >Dafür müssten die Softkeys "Calibrate ADC" und "Search Zero Lines" >getauscht werden. Das verstehe ich jetzt wieder nicht, erst ADC, Search Zero und dann DAC? ...was'n nu? Gruß Michael
Hi, kämpfe noch mit den ext. Trigger Menüs. -> die Ground-Coupling Einstellung ist nicht für den Abgleich geeignet, da (wie Guido schon anmerkte) nur das Ausgabesignal auf Null gezogen wird, aber nicht der Eingang. -> beim Abgleich kann man ruhig auch in der Reihenfolge der Knöpfe vorgehen, die Funktion Search Zeroes ist nur für den Grobabgleich. Wichtig ist nur, dass die ADC vor dem Feinabgleich der DACs synchronisiert werden, da sonst der Feinabgleich für die Tonne ist. -> und ein Abgleich sollte für alle Bereich ausreichen. Die Abhängigkeit zur Triggersource ist mir noch nicht aufgefallen, ich schau mir das mal an Gruß Hayo
@Michael: Die Frage ist, was hat die Kalibrierung mit der Trigger-Source zu tun? Ich mache einen Default-Setup und verstelle anschl. nur die Trigger-Source, sonst nichts. Dann erfolgt die Kalibrierung. Hayo schreibt in seiner Anleitung "How to calibrate DAC and ADC.txt": - wenn nicht schon vorher gemacht, jetzt die ADC-Kalibrierung durchführen.... - Jetzt kann man den standard DAC-Abgleich durchführen indem man Search Zero Lines betätigt.... - In der Regel bleiben noch Restoffsets die sich auch durch mehrfaches Betätigen nicht beseitigen lassen. Jetzt kommt der neue DAC-Abgleich ins Spiel. Man stellt also die Kanäle und die Spannungsbereiche ein die man kalibrieren möchte und betätigt "Calibrate DAC".... Für mich ist die Reihenfolge wie folgt: 1. Cal. ADC 2. Search Zero Lines 3. Cal. DAC Als "Eselsbrücke" würde ich die Softkeys in dieser Reihenfolge anordnen. Es sei denn, die Anleitung ist falsch. Gruß Bert
Ne Bert, die Reihenfolge ist von links nach rechts, also nicht "Zero Lines" mitten drin drücken, sondern als erstes - ist ja wie bereits erklärt wurde der Grobabgleich, auf den der Feinabgleich folgt. Kontrolliere außerdem mal, ob eine Änderung der Verstärkung im Utility Menü etwas ändert. Gruß Michael
@ Hayo: Hat es einen besonderen Grund für diese Abgleich-Prozedur? Oder kann der ganze Ablauf: - Default-Setup - Cal. ADC - Search-Zero-Lines - Cal. DAC nich als komplette Sequenz unter einem Softkey ablaufen? Damit wäre es auch für den DAU "Dümmster anzunehmenden User" sicher. Gruß Bert
...bei 'DEFAULT-SETUP' geht das Oszi in die Grundstellung! Würde ein SOFTKEY alles erledigen und du aus Versehen diesen drückst, dann wären alle anderen Einstellungen auch Pfutsch, ausseredem hätte man dann nicht mehr die Möglichkeit, die Sachen separat einzustellen! Macht ja Sinn, wenn ich mehrere Optionen zur Verfügung habe, oder? Bert, >- Cal. ADC >- Search-Zero-Lines >- Cal. DAC ...die Reihenfolge der Keys ist falsch, richtig ist Search Zerol., ADC(Grob), DAC(Fein) Gruß Michael
Hallo Miichael, Michael D. schrieb: > dann nicht mehr die Möglichkeit, die Sachen separat einzustellen! Nenn mir mal eine Anwendung warum die Sachen separat auszuführen sind. Also nur "Search Zero Lines" als Grob-Abgleich. Oder nur einen "Cal. DAC" als Feinabgleich ohne das andere. Mir fällt dazu keine Anwendung ein. Michael D. schrieb: > ...bei 'DEFAULT-SETUP' geht das Oszi in die Grundstellung! > Würde ein SOFTKEY alles erledigen und du aus Versehen diesen drückst,... Ich nehme lieber den "zufälligen" Default-Setup in Kauf, als eine falsche Kalibrierung mit ungenauen Messwerten. Michael D. schrieb: > ...die Reihenfolge der Keys ist falsch, > richtig ist Search Zerol., ADC(Grob), DAC(Fein) Dann sollte Hayo seine Anleitung auch entspr. so schreiben (siehe Zitat weiter oben). Gruß Bert
Hallo Bert, was meinst du mit Anwendung? Mein Welec braucht z.B. einige Zeit zum Warmlaufen, was die Kalibrierung beeinträchtigt. Da bin ich ganz froh, wenn ich dann nicht das ganze Programm durchlaufen muss, sondern die DAC-Kalibrierung separat aufrufen kann und dass dabei die Grundeinstellung nicht verändert wird.
Bert schrieb: > Hallo Miichael, > > Michael D. schrieb: >> dann nicht mehr die Möglichkeit, die Sachen separat einzustellen! > > Nenn mir mal eine Anwendung warum die Sachen separat auszuführen sind. > Also nur "Search Zero Lines" als Grob-Abgleich. ...könnte man evtl. weglassen, weiß der Hayo aber besser! > Oder nur einen "Cal. DAC" als Feinabgleich ohne das andere. > Mir fällt dazu keine Anwendung ein. > ...genau, manchmal ist es notwendig den DAC-mehrmals zu betätigen ohne den ADC, ist schon vorgekommen, das dieser einen "Schluckauf" hatte, dann muß man nicht wieder von vorne anfangen. > Michael D. schrieb: >> ...bei 'DEFAULT-SETUP' geht das Oszi in die Grundstellung! >> Würde ein SOFTKEY alles erledigen und du aus Versehen diesen drückst,... > > Ich nehme lieber den "zufälligen" Default-Setup in Kauf, als eine > falsche Kalibrierung mit ungenauen Messwerten. ...wenn der ADC-abgleich i.O. ist, dann bleibt dieser erstmal erhalten, auch nach dem Ausschalten. Wenn man schon mal soweit ist, hat man ja die halbe Miete und muß nur noch ab u. zu den DAC calibrieren. > > Michael D. schrieb: >> ...die Reihenfolge der Keys ist falsch, >> richtig ist Search Zerol., ADC(Grob), DAC(Fein) > > Dann sollte Hayo seine Anleitung auch entspr. so schreiben (siehe Zitat > weiter oben). (Jetzt muß ich Hayo mal ein bißchen in Schutz nehmen: Der haut hier in die Tasten, das einem schwindlich wird, da bleibt die Eine oder Andere Dokumentation eben mal auf der Strecke) Ich denke, das ist zu entschuldigen!!! Der Eine o. Andere kann ja weiter helfen, wenn's hakt... Ich weiß, es hat sich im Laufe der Entwicklung von Hayo's FW heraus gestellt , das dies die bessere Methode ist die Nullinien dahin zu bekommen, wo sie sein sollen. Ich muß zugeben, das ich auch erst etwas verwirrt war...habe aber "fast" alles, was die FW betrifft, hier mit gelesen, daher weiß ich das jetzt. Der Thread hier, ist schon wieder Kilometer lang, wenn man da nicht regelmässig mit liest, bleibt so Einiges auf der Strecke!!! Ich hatte mal den Vorschlag gemacht, eine schicke Betriebsanleitung mit allem Drum u. Dran zu kreieren, ist leider nicht so einfach, das gäbe ein Buch mit unzähligen Seiten und die Änderungen müssten dann auch noch eingepflegt werden! Also alles in Allem ist das nicht ohne, da wäre dann noch die Zeit und Geld verdiehnen müssen wir alle noch so nebenher :) > > Gruß Bert Gruß Michael
Hallo Michael, deine Ausführungen bestätigen nur meinen Vorschlag! Nicht jeder kennt den Kalibrierablauf auswendig, dieser sollte ja auch nur selten notwendig sein. Das die aktuelle Dokumentation nicht den optimalen Ablauf wiedergibt spricht auch für eine einfache "Komplett-Kalibrierung" per Software, denn damit hätten wir keine Widersprüche zur Doku. Das man bei jedem Einschalten den DAC kalibrieren muss, kenne ich von anderen DSO's (Tek und Agilent) nicht, ist vielleicht Welec spezifisch. Je einfacher die Bedienung ist und umso weniger Bedienungsfehler möglich sind, desto besser ist das Gerät und umso weniger muss man dokumentieren! Das kann ich nach 25 Jahren Software-Entwicklung für Mikrocontroller beurteilen. Es spricht ja nichts dagegen den Softkey für den Feinabgleich (DAC) noch weiterhin "anzubieten". Bei einer guten Hardware sollte er allerdings überflüssig sein! Michael D. schrieb: > ...genau, manchmal ist es notwendig den DAC-mehrmals zu betätigen ohne > den ADC, ist schon vorgekommen, das dieser einen "Schluckauf" hatte, > dann muß man nicht wieder von vorne anfangen. Das sollte eine "gute" Kalibrier-Software erkennen und automatisch korrigieren! Ich bin mal gespannt was Hayo's Analyse zum Thema "Kalibrierung ist abhängig von der Trigger-Source" ergibt. Diesen Test habe ich absichtlich so durchgeführt und nicht aus Dummheit! Es würde mich nicht wundern, wenn da noch einige "Ungereimtheiten" in der Software zu Tage kommen! Gruß Bert
Bert schrieb: > @ Hayo: > Hat es einen besonderen Grund für diese Abgleich-Prozedur? Hi Bert, das ist historisch so "gewachsen", da die Search Zeroes Funktion so schlecht funktioniert, das ich nach den Ursachen bzw. nach Alternativen gesucht habe, die dann erst mal experimentell eingebaut wurden und nach und nach verbessert wurden. > Oder kann der ganze Ablauf: > - Default-Setup > - Cal. ADC > - Search-Zero-Lines > - Cal. DAC > nich als komplette Sequenz unter einem Softkey ablaufen? > Damit wäre es auch für den DAU "Dümmster anzunehmenden User" sicher. Ja man könnte da einiges Zusammenfassen, aber ich denke flexibler ist man wenn man die Möglichkeit hat die Funktionen getrennt zu nutzen. Was ich aber auf jeden Fall noch machen wollte ist, die Search Zeroes und den DAC-Abgleich zusammenzulegen. Der ADC-Abgleich kann wahlweise als Erstes oder als Zweites aufgerufen werden, da dieser Abgleich nur relative Werte vergleicht und keine Absoluten. Der DAC-Abgleich muß aber unbedingt als letztes aufgerufen werden, da hier absolute Werte zur Berechnung verwendet werden. Gruß Hayo
morn Bert, morn Hayo, bei meinem W2022 ist es so, das die ADC-Chips (pro Kanal 4 Stck.)schon nach kurzer Zeit gut warm werden, des weiteren lässt der originale Lüfter auch etwas zu wünschen übrig. Also auch ein Faktor, der die Calibrierung beeinflusst. Eine kleine Abhilfe, haben Kühlkörper auf die ADC's und ein Tausch gegen einen 80er Lüfter gebracht, eine Anleitung dafür ist im HW-Thread. Ich kann mir vorstellen, das bei den 4 Kanal DSO's, die Wärmeentwicklung um einiges höher ist. Gruß Michael
Michael D. schrieb: > Ich kann mir vorstellen, das bei den 4 Kanal DSO's, die Wärmeentwicklung > um einiges höher ist. So ist es. Deshalb läuft hier der Lüfter auch mit mehr Spannung und lärmt daher auch mehr. Ich habe die Kühlkörper schon in Vorbereitung, da ich mir dadurch etwas mehr Temperaturunabhängigkeit verspreche Gruß Hayo
Michael D. schrieb: > Bert schrieb: >> @Michael: >> >> bitte stelle mal den ext. Trigger auf ext. LF Rej. > > ...hab' ich > >> Dann drückke den Trigger-Mode und unten steht dann z. B. (oder >> einstellen) bei Reject auf HF Reject. > > ...jetzt weiss ich, was du meinst: ---MODE-COUPLING--- > Stimmt, die Anzeige ist falsch! > >> Das sind dann widersprüchliche Anzeigen. Der Reject zeigt HF an, der >> ext. Trigger ist aber auf LF eingestellt. Das war mein Kritikpunkt. Jungs Ihr kriegt da was durcheinander! Die Anzeige ist ganz korrekt. Die Anzeige oben bezieht sich auf den tatsächlich eingestellten externen Trigger. Die Anzeige HF Reject bezieht sich auf den normalen Triggermodus des ausgewählten Kanals, welcher aber ja in diesem Moment nicht aktiv ist. Gruß Hayo
Und jetzt kommts, wie ich gerade feststelle hat der Reject Knopf im Mode/Coupling Menu keine Funktion. Ist sozusagen überflüssig wie ein Kropf - deshalb werde ich ihn ausblenden. Also keine Verwirrung mehr. Gruß Hayo
Hallo Hayo, Hayo W. schrieb: > Jungs Ihr kriegt da was durcheinander! ... Genau das ist ja das verwirrende! Da kann man am "Reject" was einstellen, das keinerlei Wirkung hat und das Gegenteil anzeigt, was gerade für den ext. Trigger eingestellt ist. Mein Lösungsvorschlag dazu: Bert schrieb: > Alles was bei ext. Trigger und TV-Trigger keinen Sinn macht z. B. die > entspr. Softkeys im Mode-Menu deaktivieren und "unsinnige" Einstellungen > ausblenden. Bert schrieb: > Korrekt und in umgekehrter Einstellung genau so, auch in "Line" > Einstellung, dort gibt es vermutlich kein LF-/HF-Reject. > Die Reject-Einstellung im Mode-Menue hat keine Auswirkung auf den ext. > Trigger und verwirrt nur. Deshalb der Vorschlag, alles auszublenden was > bei ext. Trigger und TV-Trigger "unsinnig" ist. Bert schrieb: > Danach sollte der Combi-Mode nicht mehr einstellbar sein solange der > ext. Trigger aktiv ist (Combi-Mode hellgrau wie z. B. inaktive Kanäle > bei der Source Einstellung). Ich habe eben mit dem Agilent 6054A gearbeitet. Folgende Dinge sind mir bei der Bedienung positiv aufgefallen. 1. Beim Verschieben des Triggerpegels wird zusätzlich zum Pfeil eine Linie für den Triggerpegel angezeigt. Die Linie wird nach ca. 1s ab "Stillstand" wieder ausgeblendet, das hat mir gut gefallen. Der Trigger- Pegel ist so genau auf dem Signalverlauf (Kreuzungspunkt) sichtbar. 2. Die horizontale Verschiebung funktioniert so, wie ich es intuitiv erwarte, Rechtsdrehung verschiebt das Bild nach rechts, Linksdrehung verschiebt das Bild nach links. 3. Auswahl der Trigger-Source mittels Edge->Source. Es können die Kanäle "1" bis "4" , "Extern" und "Line" angewählt werden. Wenn man das so umsetzt, dann gibt es auch nur ein "Reject"-Softkey für die Kanäle und "Extern". Den TV-Trig. kann man dann auch noch dort unterbringen. Hayo, bitte vergesse folgende Punkt nicht: Pre-Trigger: siehe Beitrag #1746189. Abhängigkeit Kalibrierung und Trigger-Source: siehe Beitrag #1746588. Gruß Bert
Jetzt habe ich mal kurz das Manual des Agilent DSO's überflogen, das sieht ja genauso aus, wie das Welec?!? Die Screenshots haben dieselbe Grafische Oberfläche! Mich würde mal interessieren, ob die Software von dem Agilent, nicht auch auf das Welec passen würde, wenn da noch das FPGA - Design dasselbe ist... Es könnte der Bert doch mal die FW vom Agilent sichern und Hayo schaut sich das Ganze mal! Ginge das??? Gruß Michael
:Ich glaube nicht das da die gleiche hardware in dem gehäuse steckt... Gruß Torsten
...glauben heißt nicht wissen! Da hilft nur auf machen und rein schauen. Ich nehme mir mal kurz die Zeit und schau mal im I-Net nach eventuellen Informationen, noch besser wäre...wer hat denn ein Agilent zur Hand? Da gibts ja 2 Kanal mit 100MHz und 300MHz, da könnte doch passen...
Hallo Leute, ich sagte ja bereits, Welec hat ordentlich das Design abgekupfert bei Agilent. Aber die Preisklasse ist nun mal eine andere!! http://www.datatec.de/cgi-bin/shop/lshop.cgi?action=showdetail&wkid=26759&ls=d&nc=1276529250-26765&rubnum=&artnum=dso6054a&file=1&gesamt_zeilen=0Tsuche--agilent%206054A In dieser Preis- und Leistungsklasse gibt es keine Standard FPGA's mehr. Die sind alle Hersteller spezifisch, die macht Agilent entweder selbst oder lässt machen. Das Betriebs-System vom Agilent ist jedenfalls Windows, da erscheint das Windows-Logo beim hochfahren. Die Bedienung hat Welec sich auch dort abgeguckt, ist ziemlich ähnlich. Die Drehschalter gehen butterweich, aber bei der Preisklasse auch zu erwarten. Gruß Bert
Bert schrieb: > Das Betriebs-System vom Agilent ist jedenfalls > Windows, da erscheint das Windows-Logo beim hochfahren. sorry, stimmt nicht, da hab ich was durcheinander gebracht. Das war der Rohde&Schwarz Spectrum-Analyser mit dem Windows-Logo.
Bert schrieb: > Bert schrieb: > >> Das Betriebs-System vom Agilent ist jedenfalls >> Windows, da erscheint das Windows-Logo beim hochfahren. > > sorry, stimmt nicht, da hab ich was durcheinander gebracht. > Das war der Rohde&Schwarz Spectrum-Analyser mit dem Windows-Logo. Ja Agilent Oszis (MSO6000er, MSO7000er) haben kein Windows. Die LeCroy Waverunner haben dann wieder Windox XP kotz. Da lob ich mir mein Agilent MSO7034. Grüße Robert
@ Hayo habe ich dich richtig verstanden, dass es keinerlei zuschaltbare Triggerfilter gibt? Oh Mann. Hältst du es für machbar, welche nachzurüsten? @Bert Herstellerspezifische FPGAs, jetzt hört's aber auf. Der Sinn von FPGAs ist doch gerade, dass nichts in irgendeiner Weise spezifisch ist. Vermutlich meintest du ASICs? Gruß Michael
Michael H. schrieb: > @ Hayo > > habe ich dich richtig verstanden, dass es keinerlei zuschaltbare > Triggerfilter gibt? Oh Mann. Hältst du es für machbar, welche > nachzurüsten? Ich vermute, dass das mal angedacht war, da der Softbutton ja schon da war. Beim Setzen der Hardwareregister wird das aber nicht berücksichtigt. Ob es da Hardwareseitig schon eine Implementierung gibt die man ansteuern könnte kann ich aber so nicht sehen, leider haben wir keinerlei Hardware bzw. FPGA Spezifikationen von WELEC bekommen. Beim externen Trigger wird das über SetSwitches geschaltet, da gibt es also Filter auf der Platine die irgendwie angesteuert werden. Gruß Hayo
Hi Robert, was macht das LEON3, gibt's was neues zu berichten? Es werden doch bei dem Agilent bestimmt Software updates angeboten, oder nicht? Wenn ja, wird ja vor dem Aufspielen ein Backup gemacht, ist ja wohl bei jeder Firmware pflicht! Wenn Hayo das Backup in die Finger bekommt, könnte er die beiden FW-Versionen vergleichen und wenn absolut keine Kompatibilität vorhanden ist, kann man das ja immer noch in die Tonne kloppen! Ich finde, es wäre einnen Versuch wert, oder ?
Ist aber ziemlich unwahrscheinlich dass das hinhaut Hayo
Hallo Hayo, damit Dir nicht langweilig wird, folgendes Problem: Die Y-Cursor zeigen die Pegel zur Nullinie des ausgewählten Kanals an. Verschiebe ich einen Y-Cursor wird der Wert sehr (quälend!) langsam aktualisiert. Verschiebe ich die Nullinie des Kanals, werden die Y-Cursor-Werte gar nicht aktualisiert. Erst nach einer Cursor-Steuerung, oder Zeitbasis-Änderung werden die aktuellen Y-Cursor-Werte angezeigt. Schnelleres Drehen der Cursor-Verstellung bringt leider keine Cursor-Beschleunigung.Den Cursor von unten nach oben zu drehen ergibt Blasen an den Fingern :-) Wie sieht das denn mit dem ext. Trigger aus, sind da die HF- und LF -Einstellungen auch Dummy's? @Michael H. Michael H. schrieb: > Herstellerspezifische FPGAs, jetzt hört's aber auf. Der Sinn von FPGAs > ist doch gerade, dass nichts in irgendeiner Weise spezifisch ist. > Vermutlich meintest du ASICs? Könnte sein. Aber ob die sich während der Entwicklung eines DSO's x-mal ein ASCI "backen" lassen, bis alles funktioniert, da bin ich mir auch nicht sicher!? Vielleicht deshald der Preis von über 10k€. Gruß Bert
Hallo, wer möchte, darf die Agilent Firmware analysieren. Ich glaube allerdings, das ist Zeitverschwendung!! Anbei folgende Software-Pakete: 5000/6000 Series Oscilloscope System Software, Version 6.00.0004 5000/6000 Series Oscilloscope Library Software, Version 2.24 5000/6000 Series Oscilloscope Graphics Software, Version 2.12 Quelle: http://www.home.agilent.com/agilent/editorial.jspx?cc=US&lc=eng&ckey=666864&nid=-35802.0.00&id=666864 Gruß Bert
...mit was wurden die Dateien denn komprimiert? Mit 7zip krieg ich die nicht auf! Gruß Michael
Michael D. schrieb: > ...mit was wurden die Dateien denn komprimiert? Mit 7zip krieg ich die > nicht auf! Ich vermute das ist eine "eigene" Komprimierung, die das Update-Programm verwendet. @ Hayo: Und noch etwas zur Cursor-Steuerung: Ich aktiviere gleichzeitig Cursor und Delay. Im Delay-Bereich werden die Y-Cursor angezeigt, nicht aber die X-Cursor. Frage ist, ob das so gewollt ist. Ich vermute mal nicht, denn zum genauen Zeitmessen wären die X-Cursor im Delay-Fenster hilfreich. Gruß Bert
Bert schrieb : > Hallo, > > wer möchte, darf die Agilent Firmware analysieren. > Ich glaube allerdings, das ist Zeitverschwendung!! > Nun ja, könnte sein... Es wurde hier schon mehrmals in der Vergangenheit gesagt, das FW u. HW-mässig das Ende der Fahnenstange ist... Plötzlich kam ein 3. Triggermodus, ein funktionierendes FFT, optimierte Delay-Funktion und ein simpler Akkubetrieb dazu. Ein LEON3 von Robert und die Huckepackplatine sind ebenfalls noch in Arbeit ...es ist immer noch Potenzial unterwegs! > > Gruß Bert Gruß Michael
Angehängte Dateien:
-
Delay_Curser01.png
5,6 KB
@ Bert ...die Update-EXE von der 3000er Serie ist über 4MB groß, in der Anleitung steht leider nichts von einer Sicherung! Kannst du deine FW vom Agilent vor dem Update sichern? (ich suche mal nach dem Kompressor für die jpz) Vielleicht machst du mal einen Screenshot von deinem Problem... Hier ist meiner mit "CURSERS" u. "DELAY-MODE" bei mir sind alle Curser vorhanden! Noch mal ein Lob an Hayo, den Delay hast du sauber hin gekriegt!!! Gruß Michael
Michael D. schrieb: > ...mit was wurden die Dateien denn komprimiert? Mit 7zip krieg ich die > nicht auf! > > Gruß Michael Ich hab' mir eine Datei mal angesehen. Ab Byte 240 steht "AGLTZIP". Das deutet sehr stark auf eine "Privatimplementierung" durch Agilent hin. Der Versuch, über die Agilent-Dateien weiterzukommen ist mit Sicherheit sinnlos - nicht wegen des Zip-Formates, sondern einfach weil es eine andere Hardware ist. Gruß, Bernd
OK, ich habs, es ist reproduzierbar. (BF 1.4) Nach einem Default-Setup sind die X-Cursor in beiden Fenstern vorhanden. Ablauf wie folgt: 1. Default-Setup 2. Zeitbasis auf ca. 500µs. 3. Cursor und Delay aktivieren, Kontrolle ob die X-Cursor in beiden Fenstern vorhanden sind. 4. Zurück auf Main-Einstellung (kein Delay, Cursor aktiv). 5. Die X-Cursor gemeinsam (mit X1 X2) bis an den rechten Rand schieben und die Differenz (ca. 3 Kästchen) kleiner wird. 6. Die X-Cursor gemeinsam (mit X1 X2) in die Mitte schieben. 7. Delay aktivieren, die X-Cursor fehlen im Delay-Fenster. 8. Ab jetz sind die X-Cursor im Delay-Fenster weg bzw. man sieht sie am rechten Rand. 9. Oszi aus und wieder einschalten. 10. Cursor und Delay aktivieren, Kontrolle ob die X-Cursor in beiden Fenstern vorhanden sind => die X-Cursor im Delay-Fenster sind weg bzw. man sieht sie am rechten Rand. Zurück auf 1. Nächstes Problem. Trigger-Mode. 1. Triggermode auf Normal stellen. 2. Zeitbasis erhöhen bis 1s, Triggermode schaltet auf "Auto". 3. Zeitbasis auf zurück auf 500ms, Triggermode schaltet auf "Normal". 4. Zeitbasis auf 2s, Triggermode schaltet auf "Auto". 5. Zeitbasis auf zurück auf 500ms, Triggermode schaltet nicht auf "Normal". Drückt man die Mode-Taste unten, ist der Haken bei "Normal", angezeigt wird aber "Auto" 6. Zeitbasis veringern, Trigger-Mode bleibt bei "Auto", Haken ist bei "Normal". Gruß Bert
@ Bert Du bist ja echt fleißig im Fehler finden, das bringt die Firmware sicher auch weiter. Zum Thema ASIC: Die Entwicklung läuft auf Simulationsbasis und auf FPGAs mit VHDL oder Verilog. Wenn alles funktioniert wie es soll, dann kann der Code direkt in ein ASIC umgesetzt werden. Gruß Michael
hallo Bernd, du konntest das File öffnen? Ich habe mir einen Wolf im I-Net gesucht und habe da immer nur was von Puzzels gelesen... Wenn das Sinnlos ist da weiter zu bohren, nun ja, war ja nur so eine Idee, hätte ja sein können, das da was geht. Gruß Michael
Hi, bin grad vom Griechen zurück. Hier tobt ja das Leben! Bert findet die Fehler ja schneller als ich sie überprüfen kann... Ich hab das im Blick, muß das aber nach und nach abarbeiten, da ich dummerweise auch noch für Geld SAP-Programme schreiben muß. Danke für die intensiven Tests und ausführlichen Fehlerberichte Gruß Hayo
Ach ja, hab noch vergessen eins anzumerken. Die Performance ist gerade bei Quickmeasure oder auch bei einfachen Cursoraktionen aufgrund der begrenzten Rechenleistung des 33MHz Prozessors natürlich schnell am Ende. Aussicht auf Besserung bietet hier eigentlich nur das LEON3-Projekt. Als Grundregel kann man aber sagen, je weniger Kanäle aktiv sind desto schneller geht alles. Also nicht benötigte Kanäle immer abschalten! Und zum Reject des externen Triggers: Ja hier funktioniert das tatsächlich, nur beim normalen Kanaltriggern nicht. Gruß Hayo
ja ja, der Bert heizt hier gut an, da kennt der nix...:)) Hayo W. schrieb : > Ach ja, hab noch vergessen eins anzumerken. > > Die Performance ist gerade bei Quickmeasure oder auch bei einfachen > Cursoraktionen aufgrund der begrenzten Rechenleistung des 33MHz > Prozessors natürlich schnell am Ende. Aussicht auf Besserung bietet hier > eigentlich nur das LEON3-Projekt. > oje, 33MHz für 4 Kanäle, bei voller Belastung bleibt ja fast alles stehen. Beim Quickmeasure geht das W2022 auch ganz schön in die Knie... > Als Grundregel kann man aber sagen, je weniger Kanäle aktiv sind desto > schneller geht alles. Also nicht benötigte Kanäle immer abschalten! ...das ist ja wohl logisch! > Ich habe in der Vergangenheit des öfteren Rechner CPU's übertaktet, so das diese gerade noch stabil liefen. Man darf das natürlich nicht übertreiben, sonst macht der Rest der perepherie nicht mehr mit! Könnte man die 33MHz noch ein bißchen hoch takten? So 10-15% müssten doch drinnen sein?!? > Gruß Hayo Gruß Michael
Hi, konnte schon jemand das X-Cursor-Problem nachvollziehen? Ich bekommen meine X-Cursor (Delay und Cursor aktiv) nicht mehr "sortiert", weder mittels ausschalten und auch nicht mit Default-Setup. Die X-Cursor im Delay-Fenster erscheinen von der rechten Seite und wanden nach links ins Bild, wenn ich beide Cursor gemeinsam immer weiter nach links verschiebe. In der oberen Fensterhälfte sind sie dann aber bereits aus dem markierten Bereich (Delay-Sichtbereich) heraus. Diesen Anordnung der X-Cursor bekomme ich nicht mehr "repariert". Gruß Bert
Hi, um *ASIC*-Klarheit zu schaffen und das Thema Agilent Firmware endgültig zu beerdigen: Bert schrieb: > @Michael H. > Michael H. schrieb: >> Herstellerspezifische FPGAs, jetzt hört's aber auf. Der Sinn von FPGAs >> ist doch gerade, dass nichts in irgendeiner Weise spezifisch ist. >> Vermutlich meintest du ASICs? > Könnte sein. Aber ob die sich während der Entwicklung eines DSO's x-mal > ein ASCI "backen" lassen, bis alles funktioniert, da bin ich mir auch > nicht sicher!? Vielleicht deshald der Preis von über 10k€. Michael H. schrieb: > Zum Thema ASIC: Die Entwicklung läuft auf Simulationsbasis und auf FPGAs > mit VHDL oder Verilog. Wenn alles funktioniert wie es soll, dann kann > der Code direkt in ein ASIC umgesetzt werden. Auf der linken Seite dieses Vergleichs steht folgendes. InfiniiVision scopes incorporate acquisition memory waveform processing and display memory in an advanced 013 μASIC Gruß Bert
@ Bert, im kaufmännischem Bereich und in der Werbebranche ist der Unterschied zwischen ASIC und FPGA nicht wirklich bekannt. Alle DSOs die ich bisher gesehen habe, darf ich eigentlich niemandem erzählen, dass ich schon viele Interesse halber geöffnet habe ;) , hatten einen FPGA drin. Da dieser ein anwendungsspezifisches Hardware-Design erhält spricht man schnell von einem ASIC, obwohl die Begrifflichkeit in diesem Fall falsch ist, es bleibt trotzdem ein FPGA. Das einzige echte ASIC das ich in einem DSO bisher gesehen habe, war ein von Tektronix und National Semiconductor gemeinschaftlich entwickelter ADC für ein DSO, den man nicht bei National ordern kann. Im Zeitalter von FPGAs und mittlerweile auch Mixed Signal FPGAs lohnt sich der Guss von ASICs kaum noch, da viel zu unflexibel und nur bei wirklich großen Stückzahlen rentabel (USB- und Ethernet-Controller zum Beispiel). Lasst euch also nicht in die Irre führen. Die Firmware wird euch dennoch nicht viel nützen, ihr kennt weder das Hardware-Design des FPGA im Agilent, noch die Hardware auf der Platine etc. Hier Energie reinzustecken wäre unnötige Liebesmühe. Grüßle, Steve
Hallo Steve. Steve schrieb: > Hier Energie reinzustecken wäre unnötige Liebesmühe. Das sehe ich genauso! Konzentrieren wir uns lieber auf die Verbesserung der NIOS-Firmware und hoffentlich auch bald auf die Leon3-Firmware. Gruß Bert
Bert schrieb: > Hi, > > konnte schon jemand das X-Cursor-Problem nachvollziehen? > Ich bekommen meine X-Cursor (Delay und Cursor aktiv) nicht mehr > "sortiert", weder mittels ausschalten und auch nicht mit Default-Setup. > Die X-Cursor im Delay-Fenster erscheinen von der rechten Seite und > wanden nach links ins Bild, wenn ich beide Cursor gemeinsam immer weiter > nach links verschiebe. In der oberen Fensterhälfte sind sie dann aber > bereits aus dem markierten Bereich (Delay-Sichtbereich) heraus. > Diesen Anordnung der X-Cursor bekomme ich nicht mehr "repariert". > > Gruß Bert Hallo Bert, Ich habe heute Mittag einige Einstellungen bezüglich Curser u. Delay geteste, bleibt alles hübsch! Vielleicht solltest du die Firmware noch mal neu aufspielen, evtl. behebt das dein Problem?!? Nach der Aktuallisierung der FW. DEFAULT-SETUP nicht vergessen! Gruß Michael
Angehängte Dateien:
-
K1_100mV.png
4,3 KB -
K1_50mV_K2_100mV.png
5,3 KB
Jetzt habe ich hier aber ein Problem: ich bin gerade dabei den Restripple eines symetrischen Netzteils zu messen. Ist eine Einweggleichrichtung, daher die 50Hz. Einstellungen sind: Kanal 1 AC-Coupling, 100mV/Div, 50kSa/s Foto 1 jetzt wollte ich auf 50mV/Div, habe ich plötzlich kein Signal mehr! Ich schalte den 2.Kanal mit 100mV/Div dazu und gehe mit Kanal 1 auf 50mV/Div, Signal ist wieder da! Foto 2 Kanal 1 bleibt bei 50mV/Div, Kanal 2 schalte ich ebenfalls auf 50mV/Div, beide Kanäle haben kein Signal mehr! Kanal 1 schalte ich auf 100mV/Div, Kanal 2 bleibt auf den 50mV/Div, plötlich habe ich wieder meine Signale und kann auch bis runter auf 10mV. Sobald ich einen Kanal weg schalte, tut sich unter 100mV/Div nichts mehr... umgekehrt dasselbe. Wie kann das sein??? Gruß Michael EDIT: Jetzt wollte ich testen, ob das auch im Trigger-Automode so ist Jetzt kann ich den Trigger nur noch zwischen COMBI und NORMAL schalten, bei AUTO-Trigger bleibt der Haken bestehen, d.h. ich habe 2 x Haken im Coupling-Mode!!!
Hallo Michael, Michael D. schrieb: > Hallo Bert, > Ich habe heute Mittag einige Einstellungen bezüglich Curser u. Delay > geteste, bleibt alles hübsch! > Vielleicht solltest du die Firmware noch mal neu aufspielen, evtl. > behebt das dein Problem?!? > Nach der Aktuallisierung der FW. DEFAULT-SETUP nicht vergessen! Habe jetzt BF1.6 geflasht, die Cursor im Delay-Fenster funktionieren wieder. Probier bitte mal folgendes aus: 1. Zeitbasis 50ns 2. Cursor aktivieren 3. X-Cursor 2 Kästchen auseinander in der Mitte positionieren. 4. Delay aktivieren, Kontrolle ob die X-Cursor in beiden Fenstern vorhanden sind. 5. Delay deaktivieren 6. Zeitbasis 2ms 7. Delay aktivieren 8. Die X-Cursor im Delay-Fenster sind am rechten Bildrand. Gruß Bert
Hallo Bert, bin gerade dabei...hast du ein Signal(1KHz) am Eingang oder nichts? Gruß Michael EDIT: Hast du von meinem Probl. gelesen? Im Gegenzug, teste das doch mal bitte!
Angehängte Dateien:
-
Delay_2mS_.png
5,8 KB -
Delay_2mS_nach_li_verschob.png
5,9 KB
So, habe alles genau nachvollzogen! Foto 1: Die X1 X2 Curser sind am rechten Bildrand, sieht das bei dir jetzt genauso aus? Foto 2: Ich habe die X1 X2 Curser nach links verschoben, sollten die nicht so ziemlich in der Mitte sein? Gruß Michael
Angehängte Dateien:
-
Delay_500_S.png
5,9 KB
ich noch mal, im DELAY-Modus (2mS) ist der Delay 1mS, dann kann man den Delay noch auf 500µS stellen, dann sin die unteren Curser (X1 X2) in der linken Schirmhälfte, hmm... Damit Jeder weiß, was ich meine, auch hier ein Foto davon! Gruß Michael
Michael D. schrieb: > bin gerade dabei...hast du ein Signal(1KHz) am Eingang oder nichts? > EDIT: Hast du von meinem Probl. gelesen? Im Gegenzug, teste das doch mal > bitte! Ich habe Dein Signal und Einstellungen alles so eingestellt. Bei mir tritt das Problem nicht auf. Auch nicht, wenn ich die Trigger-Kopplung DC/AC verstelle. Meine Eingangs-Widerstände sind allerdings alle noch original, ob daran liegen könnte, keine Ahnung. Wie ist das im Trigger-Normal-Mode? Wie ist das, bei Verstellung der Trigger-Pegels? Cursor: Am Eingang habe ich bei meinem Cursortest nicht anliegen gehabt. Ja, das ist das Problem, die oberen X-Cursor sind nicht mehr innerhalb der Markierungen für den Display-Ausschnitt. Somit laufen die X-Cursor in den beiden Bildschirmhälften nicht mehr synchron. Bei 2ms bekomme ich allerdings die unteren X-Cursor garnicht mehr ins Bild. Erst mit kleineren Zeitbasen klappt das wieder. Gruß Bert
Ich fasses nicht, wie kann das sein, wenn ich eines der beiden Kanäle bei 50mV/Div zu schalte, das ich dann erst wieder messen kann? Übrigens ist das egal ob ich Kanal 1 oder Kanl 2 verwende. Mich würde interessieren, ob das jetzt wirklich nur bei mir so ist, wenn ja, habe ich einen Hardwarefehler! Die Widerstände sind in dem Fall alle original, 0 Ohm also. Vielleicht testet das noch Jemand, damit ich da sicher gehen kann?!? Bei der W2000er Serie existieren mehrere HW-Versionen, ich habe das Model: W2022A mit HW-Vers. 8C7.0L Wer hat denn das gleiche Model? @Bert Cursor: >Am Eingang habe ich bei meinem Cursortest nicht anliegen gehabt. >Ja, das ist das Problem, die oberen X-Cursor sind nicht mehr innerhalb >der Markierungen für den Display-Ausschnitt. Somit laufen die X-Cursor >in den beiden Bildschirmhälften nicht mehr synchron. >Bei 2ms bekomme ich allerdings die unteren X-Cursor garnicht mehr ins >Bild. Erst mit kleineren Zeitbasen klappt das wieder. Da haben wir dasselbe Problem, mit dem Unterschied, das ich meine Curser noch nach links rücken kann! Hayo wird das schon richten, denke ich. Gruß Michael
Hi, ich bin aber erstmal mit dem Trigger beschäftigt. Das Andere muß ich mir mal in Ruhe ansehen. Gruß Hayo
Hallo Leute, hier meine erste Version des Agilent-Erfahrungsberichtes. Ich würde mich freuen, wenn man sich bei der Firmware daran orientieren würde. Die horizontale Verschiebung beim Welec bringt mich zum Wahnsinn! Linksdrehung verschiebt recht, Rechdrehung verschiebt links. Keine Verschiebung über den ganzen Bildschirm möglich. Über den Zweck des Browser-Balkens grüble ich immer noch! Eure Meinung zu diesem Thema und der gesamten Bedienung ist gefragt! Michael D. schrieb: > EDIT: Jetzt wollte ich testen, ob das auch im Trigger-Automode so ist > Jetzt kann ich den Trigger nur noch zwischen COMBI und NORMAL schalten, > bei AUTO-Trigger bleibt der Haken bestehen, d.h. ich habe 2 x Haken im > Coupling-Mode!!! Das ist bei mir jetzt auch da! Ich habe allerdings keine Ahnung "wie ich da hin gekommen bin". Nach einem "Autoscale" war es wieder weg. Gruß Bert
Bert schrieb: > Die horizontale Verschiebung beim Welec bringt mich zum Wahnsinn! Die Einstellung orientiert sich am Browserbalken, dafür stimmt die Drehrichtung. Was am meisten fehlt, ist eigentlich eine Taste, mit der man die hor. Position in die Mitte des dargestellten Bereichs bekommt. Dafür kurbelt man sich wirklich manchmal den Wolf.
... ja, ein progressives Verhalten der Drehelemente wäre schön ;-) irgendwo war hier im Thread jemand, der dem Scope gerne verschiedene Protokolle beibringen wollte um es als Logicanalyzer zu nutzen... Ich habe mir das hier besorgt: http://www.seeedstudio.com/depot/open-workbench-logic-sniffer-p-612.html?cPath=61_68 Spotbillig und wirklich ein cooooles Teil. O.k., man benötigt immer einen Rechner aber dafür wirklich topp! Michel
...was ein lustiger Name:"Logic Sniffer" man könnte das Teil ja glatt in das Frontpanel mit einbauen. Gruß Michael
Dann musst Du aber noch die Kommunikation zwischen dem Scope und dem Sniffer bauen, ebenso, wie die Bedienung und die Anzeige. (Aber cool wär's schon... ) Michel
Bert, das kann ich nur sagen: "dafür" d.h. Signal sollte der Knopfdrehung folgen Die Drehrichtung bei der Vertikalempfindlichkeit empfinde ich auch als ungewohnt. Bei der Bedienung habe ich immer einen Knopf mit Zeiger vor Augen, der auf eine auf dem Gerät aufgedruckte Skala zeigt - Links: hohe Empfindlichkeit, Rechts: niedrige Empfindlichkeit. Andere Meinungen? Wie handhaben das die "Großen" (Tek, Agilent)? Rainer Bert schrieb: > Die horizontale Verschiebung beim Welec bringt mich zum Wahnsinn! > Linksdrehung verschiebt recht, Rechdrehung verschiebt links.
Michael W. schrieb : > Dann musst Du aber noch die Kommunikation zwischen dem Scope und dem > Sniffer bauen, ebenso, wie die Bedienung und die Anzeige. > (Aber cool wär's schon... ) > > Michel ...ist ja beides mit USB ausgestattet, wäre eine Überlegung wert?!? Könnte man das hier in den HW-Thread schieben? Die Seite hier ist knalle voll und der Seitenaufbau geht nur sehr schleppend... @Bert Hast du Gestern, wie du den Test nachvollzogen hast siehe hier: Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil2)" , mit 50 Hz Sägezahn gemessen? Ich habe das Ganze noch mal mit 1KHz Rechteck getestet, da bleiben die Signale komischerweise bestehen, kann auch bis runter auf 10mV/DIV ohne zicken, also doch kein HW-Fehler?!? Gruß Michael
Guido schrieb: > Bert schrieb: >> Die horizontale Verschiebung beim Welec bringt mich zum Wahnsinn! > > Die Einstellung orientiert sich am Browserbalken, dafür stimmt die > Drehrichtung. Um das unter einen Hut zu bekommen, hätte ich folgenden Vorschlag zur Bedienphilosophie: - der Drehregler "Horizontal" verschiebt das Signal - der allgemeine Drehregler "Entry knob" verschiebt das Fenster/Balken... Dann hätte man für jeden Geschmack einen Regler und wäre konsistent zu anderen Markierungsfunktionen (z.B. Cursorpositionierung), bei denen die Markierungselemente auf dem Schirm in der Richtung immer dem "Entry knob" folgen. Die Frage wäre dann allerdings: Wodurch/wann wird der "Entry knob" in seiner Funktion als Fensterverschiebeknopf aktiviert? Rainer
@Hayo, da du gerade mit dem ext. Trigger beschäftigt bist: Bei der Bedienung gibt es noch die kleine Unschönheit, dass der Regler für den Triggerlevel bei Benutzung des ext. Trigger die falsche Drehrichtung hat, d.h. eine Linksdrehung erhöht den Triggerlevel. Beim Triggern auf einen Signalkanal ist die Drehrichung andersrum und ok. (FW 1.2.BF.1.6 C2) Gruß, Rainer
@Rainer Hab ich schon geändert, hat mich auch gestört. @all Beim rumfrickeln hab jetzt die nächste Baustelle gefunden. Bei der Pulsweitentriggerung zieht er den Source-Kanal nicht wie er soll sondern nimmt den der Flankentriggerung. Bin gerade dabei das zu ändern. Außerdem scheint mir beim externen Trigger keine Pulsweitentriggerung möglich zu sein. Ich hab zwar die Menüsteuerung dafür gefunden, aber die Registeransteuerung läßt vermuten, dass das nur heiße Luft ist. Da hoffe ich mal auf Eure Mithilfe, da die Testerei doch enorm viel Zeit kostet. Gruß Hayo
Hallo Rainer, Rainer schrieb: > Die Drehrichtung bei der Vertikalempfindlichkeit empfinde ich auch als > ungewohnt. Bei der Bedienung habe ich immer einen Knopf mit Zeiger vor > Augen, der auf eine auf dem Gerät aufgedruckte Skala zeigt - Links: hohe > Empfindlichkeit, Rechts: niedrige Empfindlichkeit. > Andere Meinungen? Wie handhaben das die "Großen" (Tek, Agilent)? Die Einstellung der vert. Empf. ist beim Agilent genauso wie beim Welec. Das würde ich so lassen, sonst stimmen die Sinus-Symbole auf der Frontplatte nicht mehr (grosser Sinus = empfindlicher, kleiner Sinus weniger empfindlicher). Ich kenne das aber auch nicht anders, selbst bei meinem "uralt" Hameg wird es nach rechts herum immer empfindlicher. Wenn Du Dir anstatt Empfindlichkeit "Signal-Verstärkung" vorstellst, dann passt es wieder. Rechts herum = hohe Verstärkung, wie beim Audioverstärker. Gruß Bert
So, damit Ihr auch vernünftig testen könnt hier die BF.1.7 Leider mußte ich wegen einiger Änderungen am Flash die Einstellungen zurücksetzen. Ihr müßt also Eure Kalibrierungen und Hardwareeinstellungen nochmal machen. Alle Änderungen sind im Changelog dokumentiert. Sourcen sind auch wieder dabei. Please notice: Because of changes in the flash memory I had to reset the Hardwaresettings. You have to calibrate and justify Your settings again. Find all changes in the changelog. Sources are included. Hayo
@Michael Michael D. schrieb: > @Bert > Hast du Gestern, wie du den Test nachvollzogen hast > siehe hier: > Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil2)" , > mit 50 Hz Sägezahn gemessen? Ich habe mit 50Hz Sägezahn getestet. Habe es gerade nochmals versucht. Dein Problem kann ich nicht reproduzieren. Gruß Bert
Bert schrieb: > Die Einstellung der vert. Empf. ist beim Agilent genauso wie beim Welec. > Das würde ich so lassen, sonst stimmen die Sinus-Symbole ... nicht Ok, überzeugt. Dann hat nur mein Multimeter die andere Drehrichtung. Rainer
Hallo Hayo, erster Test 1.2.BF.1.7: - Nach einem "Default-Setup" sollte der ext. Trigger und der TV-Trigger "hellgrau" sein. Ich habe wie blöde auf diesen Softkey gedrückt, bis ich gesehen habe, das man den jetzt unter Source anwählt. Nach dem Einschalten stimmt es! - Default-Setup, Oszi-Ausschalten => gleiches Problem. - Trigger-Kanal anwählen, Softkeys "ext. T." und "TV-T." werden grau, Oszi ausschalten => alles OK, Softkeys bleiben grau. ext. Trigger aktiviert: - keine Trigger-Level-Verstellung möglich - keine Triggerung im Normal-Mode - stehendes Bild bei ext. Line-Triggerung??? Bitte kläre mich mal über USTB auf. Gruß Bert
Stehendes bild bei Linetrigger und normalmode hat mich auch etwas gewundert. Im Startscreen steht noch 2009 :-) Gruß Torsten
@Hayo:
Ich fände es gut, wenn Du wenigsten alle Bugs bzgl. Trigger in einer
Version erledigen würdest. Sonst gibt es zuviele "Versionen" und der
Testaufwand wird auch nicht weniger.
Noch "offene" Trigger-Bugs:
- Pre-Trigger: Beitrag #1746189
- Triggermode: Beitrag #1747812
- Level-Einstellung: Beitrag #1750082
Hayo W. schrieb:
> Hab ich schon geändert, hat mich auch gestört.
Nicht nur beim ext. Trigger.
Bei mir ist die Drehrichtung bei Kanal-Triggerung immer noch falsch
Gruß Bert
Da hatte sich durch die umfangreichen Änderungen an den Menüs noch ein Fehler beim ext. Triggerlevel und bei den Drehrichtungen eingeschlichen. Hier die zweite Compilation. A little bug in the external trigger level display has been undetected. Please use the second compilation Hayo
Hallo Hayo, die Drehrichtung stimmt jetzt, aber immer noch keine externe Triggerung und der Pegel ist bei ext.-Trig nicht änderbar. Gruß, Guido
Angehängte Dateien:
-
External_Trigger.jpeg
44 KB
Hi Guido, das kann ich nicht nachvollziehen, ich hab gerade alles ausprobiert - läuft gut (siehe Screenshot). Ext. Trigger läßt sich gut verstellen, allerdings triggert er am Besten im Normal-Modus. Ich kann den Level auch aus dem Signal herausdrehen, dann bleibt es stehen. Gruß Hayo
erster Test 1.2.BF.1.7_C2: - Default-Setup sollte den Triggerlevel vom ext. Trigger auf 0 setzen. Der wird auf -8,19V gesetzt. ext. Trigger aktiviert: - stehendes Bild bei ext. Line-Triggerung, jetzt aber mit Aktualisierung??? - Bei Normal-Mode und LF-Reject bekomme ich keinen Trigger hin. - Keine "saubere" Triggerung bei Normal-Mode und HF-Reject (Signal wackelt hin und her) bei Triggerpegel von ca. halber Rechteck-Amplitude (2,09V, 2,29V, 2,5V). - Die Signalflanke steht nicht auf dem Triggerpunkt, sondern "kommt" später (zeitverzögert). Bei Kanal-Trigger stimmt das. Trigger-Level: 1. Trigger-Kanal 1 einstellen 2. Trigger-Level auf 2V einstellen 3. Kanal 2 aktivieren 4. Trigger-Kanal 2 einstellen => Trigger-Level wird noch von Kanal 1 angezeigt 5. Drehen des Trigger-Levels, Startwert "war" 0V Problem: Beim Umschalten der Trigger-Source wird der Trigger-Level des aktivierten Kanals nicht angezeigt, erst nach verdrehen des Levels - Unter 875mV bekomme ich keine Triggerung bei Kanal-Trigger, bei ext. Trigger klappt das. Noch "offene" Trigger-Bugs: - Pre-Trigger: Beitrag #1746189 - Triggermode: Beitrag #1747812 So, jetzt gucke ich weiter Fußball! Gruß Bert
Ahja, im Normal-Modus bekomme ich es jetzt auch hin, sehr schön. Was mich noch sehr stört ist die Pretrigger-Einstellung. Wenn da die Anzeige von µs auf ns umspringt und ich von 999 in Einerschritten runterkurbeln soll, kriege ich die Krise. Das passiert aber nicht immer, eine Systematik dahinter habe ich noch nicht entdeckt. Könnte man das nicht prozentual auf die Samplingtiefe beziehen, z.B. in 5-%-Schritten? Wenn du da einen Suchbegriff für die Source hättest, würde ich mir das mal ansehen. Gruß, Guido
Hayo W. schrieb: > Ext. Trigger läßt sich gut verstellen, allerdings triggert er am Besten > im Normal-Modus. Ich kann den Level auch aus dem Signal herausdrehen, > dann bleibt es stehen. Einen wunderschönen guten Abend, mit Sinus 50 Hz 1.5 V ist bei mir extern, normal, hf_rej getriggert kein stehendes Bild hinzubekommen. Bei Triggerung auf Line erfolgt gar keine Aufzeichnung. Die von dir, Bert, beschriebenen Probleme mit den X1-X2 Cursorn beim Delay-Fenster und das fehlende Update der Triggerlevelanzeige bei Wechsel des Triggerkanals treten bei mir auch auf. Die Anzeige vom Triggerlevel wird auch aktualisiert, wenn man die Auswahlliste für den Triggerkanal noch mal öffnet (ohne den Kanal zu ändern). Rainer
Hallo Bert, zu deinen Verweisen: >Noch "offene" Trigger-Bugs: >- Pre-Trigger: Beitrag #1746189 >- Triggermode: Beitrag #1747812 >- Level-Einstellung: Beitrag #1750082 ...damit kann man schlecht was anfangen! Wenn du den Curser über den Orangen Text hälst und mit der rechten Maustaste den Link (vom Topic)in deinen Beitrag kopierst, gelangt man zu dem Beitrag den du meinst, mit den Beitragsnummern kann das hier Keiner nachvollziehen. ...danke schon mal! Gruß Michael
Michael D. schrieb: > ...damit kann man schlecht was anfangen! Jetzt kann ich auch was positives Beitragen ;-) Einfach die Beitragsnummer hinter die URL kopieren, dann kommst du zum richtigen. Hier die direkten Links: Pre-Trigger: Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil2)" Triggermode: Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil2)" Level-Einstellung: Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil2)" Schönen Abend noch, Gruß, Moritz
Um etwas Klarheit in die unterschiedlichen Befunden mit dem externen Trigger zu bringen, habe ich noch mal probiert: Signal: Rechteck mit +/- 400 mV, 1kHz (ProbeComp), Ablenkung: vert hor. 200 us/div Trigger: extern, Norm., HF rej. Triggerlevel < -350 mV: stabiler Trigger, immer fallende Flanke, Flankenwahl wird aber ignoriert -350 .. 300 mV: mehr oder weniger instabiler Trigger >= 500 mV: kein Trigger Muß man das verstehen? Mit Trigger auf Auto ist gar nichts anzufangen. Außerdem ist 1. bei den Rastwerten für den ext. Triggerlevel treten viele krumme Werte und eine Unsymmetrie um die 0 auf (in mV: ..., -550, -350, -100, 0, 100, 300, 500 ..., 1.29, ...). 2. nach "Default Setup" und Umschaltung auf ext. Trigger, Norm wird oben rechts nicht der aktuelle Level angezeigt (Updateproblem s.o.) und der Wert sollte auf Default 0.0 gesetzt werden (nicht -8,19 V, s. Bert) 3. die fallende Signalflanke kommt, unabhängig von der Horizontaleinstellung, anscheinend immer etwa 15 Pixel hinter der Triggermarke. 4. Cursor: Beim Verschieben des Cursors wird der Zahlenwert bei mir erst endlose 5 s später aktualisiert. Vorschlag: 1 s @Hayo: Ganz großes Lob für die engagierte Arbeit!!! Wo nimmst du bloß die Zeit her? Rainer
Rainer schrieb: > Muß man das verstehen? Mit Trigger auf Auto ist gar nichts anzufangen. Ja, das hab ich auch schon festgestellt, aber vermutlich läßt sich das auch nicht ändern, da das eine Hardwaresache zu sein scheint. Ich werde aber trotzdem nochmal forschen ob da was machbar ist. > Außerdem ist > 1. bei den Rastwerten für den ext. Triggerlevel treten viele krumme > Werte und eine Unsymmetrie um die 0 auf (in mV: ..., -550, -350, -100, > 0, 100, 300, 500 ..., 1.29, ...). Das liegt daran (siehe oben) dass ich jeden einzelnen!!!! Wert des jetzt statt 32 auf 112 Werte vergrößerten Werte-Arrays mit dem Multimeter ausgemessen habe, und die Registerwerte weggelassen habe die nicht funktionierten. Das sind die Werte direkt um Null, da lief das Signal einfach durch, und die Werte ganz oben im positiven Bereich, da hing das Sgnal dann komplett und es ging nix mehr. > 2. nach "Default Setup" und Umschaltung auf ext. Trigger, Norm wird > oben rechts nicht der aktuelle Level angezeigt (Updateproblem s.o.) ist in Arbeit > und der Wert sollte auf Default 0.0 gesetzt werden > (nicht -8,19 V, s. Bert) schon geändert > 3. die fallende Signalflanke kommt, unabhängig von der > Horizontaleinstellung, anscheinend immer etwa 15 Pixel hinter der > Triggermarke. bin ich gerade dabei, sieht schon ganz gut aus... > 4. Cursor: Beim Verschieben des Cursors wird der Zahlenwert bei mir > erst endlose 5 s später aktualisiert. Vorschlag: 1 s Meinst du den Timeout für das Browserfenster?? Soll ich den runtersetzen? Aber 5s sind das doch nicht. > @Hayo: Ganz großes Lob für die engagierte Arbeit!!! Wo nimmst du bloß > die Zeit her? ...frag mal meine Frau, die sieht mich kaum noch. Gruß Hayo
Hi Hayo, Hayo W. schrieb : > Meinst du den Timeout für das Browserfenster?? Soll ich den > > runtersetzen? Aber 5s sind das doch nicht. Nein, nicht das "Browserfenser", das ist ja i.O. so! Rainer mein den "Curser-Modus", verschiebst du da die "X1, X2 und oder Y1,Y2, braucht das eine kleine Ewigkeit, bis unten die Werte angezeigt werden (Frequenz und Spannungs-Aktualisierung) Gruß Michael Edit: Jetzt hat sich wieder dieser dämliche Prob-Pinöfkel bei mir verabschiedet, jetzt hab' ich noch eine BNC-Buchse eingebaut und das Teil da angeschlossen...
Hallo Leute, hier meine zweite und letzte Version des Agilent-Erfahrungsberichtes. Das Thema "Bedienung", schein hier kein besonderes Interesse zu finden. Gruß Bert
Den Browserbalken finde ich durchaus nützlich zur Orientierung.
Michael D. schrieb: > Rainer mein den "Curser-Modus", verschiebst du da die "X1, X2 und oder > Y1,Y2, braucht das eine kleine Ewigkeit, bis unten die Werte angezeigt > werden (Frequenz und Spannungs-Aktualisierung) Ja ich weiß, das ist etwas nervig, aber da kann ich leider nichts machen, denn das dauert so lange, weil ein ganzer Hauptschleifendurchlauf abgearbeitet wird und dann noch die Werte berechnet werden. Einzige Abhilfe ist hier möglichst nur einen Kanal aktiv zu haben. Gruß Hayo
Bert schrieb:
> Das Thema "Bedienung", scheint hier kein besonderes Interesse zu finden.
Wie kommst du da drauf? Ich finde, dass der Trigger gerade große
Fortschritte macht und genug Baustellen offen sind, zumal Hayo das alles
im Code umsetzen muß.
zu 1. Reaktion auf Drehregler läßt beim Welec noch Wünsche offen...
zu 2. Triggerlevel als temporäre Linie finde ich sehr gut
zu 3. Drehrichtung Hor.-Position: ändern, d.h. als Signalverschieber
lesen
Browserbalken: finde ich praktisch wegen Visualisierung PreTrigger
Das Agilent kennt wahrscheinlich gar keine PreTrigger Einstellung
sondern steuert alles über den Fangpunkt, oder? Hört sich überlegenswert
an.
zu 4. Run/Stop: Agilent absolut überzeugend, "dafür"
zu 5. X1-X2 Limit-Konzept ist sinnvoll. Beim Welec ist die Veränderung
des Intervalls, nur weil man mal gegen den Rand gestoßen ist, unmöglich.
Die Fehlermeldung "Limit..." halte ich fast für entbehrlich.
zu 6. Das Delay-Fenster beim Welec kommt mir wie das Digital-Zoom bei
Kameras vor (keine echte 2.te Zeitbasis, sondern gestreckte Anzeige
ohnehin vorhandener Samples oder täusche ich mich da?).
Noch was anderes
X-Cursor: Ich finde es unpraktisch, dass sich der Zahlenwert für die
Position auf den Bildschirm bezieht. Eigentlich ist doch die
Triggerposition das Maß der Dinge. Wie macht das Agilent?
So, dass mag erstmal genug sein. Gruß Rainer
Hi Rainer, dich gibt's ja noch! >Noch was anderes >X-Cursor: Ich finde es unpraktisch, dass sich der Zahlenwert für die >Position auf den Bildschirm bezieht. Eigentlich ist doch die >Triggerposition das Maß der Dinge. Wie macht das Agilent? Wie willst du das denn umsetzen? Das Grid fängt ja links bei "0" an, wenn du mitten drinnen bist...dann müsste z.B. der X1 Curser immer auf "0" stehen, das wäre natürlich sehr Praktisch! Nur müsste das Grid-Raster dann immer mit ziehen, so das X1 immer auf "0" sitzt. Vielleicht kann Hayo das ja umsetzen! ... ich kann mir vorstellen, das das eine Menge Arbeit ist, da sieht ihn seine Frau noch weniger...:))) Apropos "Bowser" ...ich bin mit dem ICS511 mal auf 100MHz Sinus gegangen und hatte ein unmögliches Bild! Jetzt kommt's: Verschiebe ich den Sinus nach rechts (Browser ist sichtbart) Wird das Signal plötzlich sauber, schiebe ich das Ganze wieder nach links, habe ich wieder überall Knicke drin. Kann das Jemand bestätigen? Rainer, du hast doch da einen HF-Generator, kannst du das mal nach meiner Beschreibung testen? Gruß Michael
Michael D. schrieb: > Apropos "Bowser" ...ich bin mit dem ICS511 mal auf 100MHz Sinus gegangen > und hatte ein unmögliches Bild! Der ICS511 kann doch garkeinen Sinus. Mit einem 100-MHz-Rechteck sind Probleme doch normal. Gruß, Guido
Michael D.: >>X-Cursor: Ich finde es unpraktisch, dass sich der Zahlenwert für die >>Position auf den Bildschirm bezieht. Eigentlich ist doch die >>Triggerposition das Maß der Dinge. Wie macht das Agilent? > > Wie willst du das denn umsetzen? Gar nicht so kompliziert. Der Zahlenwert soll einfach die Zeitdifferenz zwischen Cursor und Trigger angeben, d.h. Cursor links vom Trigger -> negativer Wert, auf Trigger -> 0.0, rechts vom Trigger -> positiver Wert > Apropos "Bowser" ...ich bin mit dem ICS511 mal auf 100MHz Sinus gegangen > und hatte ein unmögliches Bild! > Jetzt kommt's: Verschiebe ich den Sinus nach rechts (Browser ist > sichtbart) > Wird das Signal plötzlich sauber, schiebe ich das Ganze wieder nach > links, habe ich wieder überall Knicke drin. Das kann ich so bestätigen. Sobald die Triggermarke deutlich links außerhalb liegt, wird's unsauber. Bei mir passiert das, wenn das Noise Filter eingeschaltet ist. Das verferkelte Signal sieht aus, als ob das Filter plötzlich aus ist. Rainer
Hi Guido, jetzt bin ich aber etwas überrascht, was ist dann das hier? Beitrag "Re: Wittig(welec) DSO W20xxA Hardware" siehe Bild 2 @Rainer ...mal schauen, was der Hayo dazu meint, der wird's schon richten... Gruß Michael
Thread beobachten
Seitenaufteilung abschalten