Hallo werte W20xxA Besitzer und Interessierte! Da der Thread: Beitrag "Wittig(welec) DSO W20xxA Open Source Firmware (Teil2)" Schon recht lange ist, habe ich den mal gesplittet! Bitte hier weiterschreiben. Danke :-) l.G. Roberto
Roberto schrieb: > Hallo werte W20xxA Besitzer und Interessierte! > > Da der Thread: > Beitrag "Wittig(welec) DSO W20xxA Open Source Firmware (Teil2)" > Schon recht lange ist, habe ich den mal gesplittet! > > Bitte hier weiterschreiben. Danke :-) > l.G. Roberto Uff, ein Glück! Ich bin hier an der Küste gerade mit Fonic und nur Edge unterwegs...das dauert! Aber wenigstens ist der Fred jetzt fix geladen - vielen Dank! Viele Grüße, Egberto
Angehängte Dateien:
-
block_w2012a_ucnet.png
140 KB
Hallo rowue, Rolf W. schrieb: Wittig(welec) DSO W20xxA Open Source Firmware (Teil2) > Nein, ich war der erste - mit den 184 ;) - hätten wir uns mal > absprechen sollen ;) Ich habe mich missverstaendlich ausgedrueckt. Ich war leider in der Mitte dabei: will heissen Auktion vom 23. Jun. 220 Teuro, deswegen Glueckwunsch :-) > Das ist eher eine Preisdeckelung - warum mehr als 295,- bieten ;) Ja, klar. >> Ich hatte eine Mail an tek4you_eu geschickt mit dem Angebot ein W2012A >> fuer 250 Teuro zu erwerben. >> Keine Antwort. Der Auktionshandel mit Herrn Wittig lief aber sehr rund. > > Naja, etwas auf die Lauer legen und Du hast eins für 250 und weniger ;) Stimmt. >>> Generell sollte - egel ob BF oder OS die Hardware-Version egal... >> >> Vielen Dank, danach habe ich gesucht 8))) Dann bleibt 8C7.0E drauf ;-) > > Etwas anders als Du denkst ;) - aber Backup von der alten, > OS/BF Fw drauf und gut ist ;) Meine Frage bzgl. Hardware-Version war dahingehend, dass diese den Versionsstand der Signalverarbeitung + Nios-Core im FPGA beschreibt A (siehe Anhang). Diese wird im SPI-Flash B gespeichert. Bleibt also bei 8C7.0E. 1.2.BF.1.8 ist der Code fur den Nios, der im parallelen Flash C abgelegt wird. Die Nios FW wird ueber RS232 D mittels GERMSloader im Flash C gespeichert. Altenativ zu Testzwecken kann man auch das SRAM E nehmen. Nach dem Ausschalten natuerlich dann weg. Stimmt das so? >>> SF ist leider nicht bei allen beliebt ;) >> >> Sehr schade! Ich frag mich nur warum? Nur wegen der Anmelderei? > > Weiß ich nicht - ich nutze das SVN dort ;) Ich meinte das Forum http://sourceforge.net/apps/phpbb/welecw2000a/index.php Und dann Neudeutsch als Sprache, da es ja viele gibt, die mit Deutsch Probleme haben. Dann waere alles zusammen und man koennte in einem Forum suchen! >> Prima, Hayo hat ja wohl die Vermutung, dass in der Signalverarbeitung im >> FPGA auch der Wurm drin ist. > > Da braucht Hayo keine Vermutung zu haben - dass ist Gewissheit!!! > > a) Haben wir letztes Jahr 'nen Filter abgeschaltet, der für > Schwingungen gesorgt hat - in der OS bleibt der (wahrscheinlich) > abgeschaltet, in der BF ist er per Default eingeschaltet, kann > aber übers Menue abgeschaltet werden ;) > http://sourceforge.net/apps/phpbb/welecw2000a/view... > > b) Sind die Signale bei 250/500MSa/s extrem verwürfelt, siehe: > http://sourceforge.net/apps/trac/welecw2000a/ticket/44 > Das ist gerade mit in dem Schwung, den ich mache und nach dessen > Abschluß wohl eine OS 0.93 ansteht (wenn keiner schreit ;) > > c) Sind die Samples bei 1GSa/s nicht äquistiant, siehe: > http://sourceforge.net/apps/trac/welecw2000a/ticket/53 > > a), b) und c) wurden hier (inkl. Thread eins) schon veröffentlicht > und nachgewiesen - da braucht keiner zu vermuten ;) > > Zur Beseitigung der Fehler habe ich "gerade" (März) einen Umzug > von Hamburg nach Freiburg hinter mir und muß mich hier auch erstmal > an eine neue Umgebung und einen neuen Tätigkeitsbereich gewöhnen ... > > Wen Du mir beim Arbeiten über die Schulter schauen möchtest, meine > Änderungen pflege ich im branch "rowue-signal" in's svn auf Sourceforge > ein. Allerdings möchte ich davon abraten, den Source zu verwenden, > bevor ich ihn in den trunk gemerged (eingefügt) habe, auch wenn > ich vor dem Commit teste, sind das noch einige offene Baustellen. Danke fuer die Hinweise, das kommt dann spaeter. Gruss, Peter
Peter M. schrieb: > Hallo rowue, > Hi Peter ... das sind gerade 1000 Fragen auf einmal, die ich auch nur zum Teil beantworten kann ;) > Rolf W. schrieb: Wittig(welec) DSO W20xxA Open > Source Firmware (Teil2) >> [Bucht ...] O.K. ich hatte mich halt schon länger auf die Lauer gelegt und mir 'nen Maximalpreis ausgemacht - diesmal hatte ich sehr viel Glück ... - Allerdings habe ich auch schon ein 2014, also nicht den Druck ;) - > >>> [Bucht II] Interessanterweise werden nach dem letzten Handel keine neuen Geräte reingestellt - aber vielleicht warten die Herren auch gerade die WM ab (könnte sich lohnen ;) > >>>> Generell sollte - egel ob BF oder OS die Hardware-Version egal... >>> >>> Vielen Dank, danach habe ich gesucht 8))) Dann bleibt 8C7.0E drauf ;-) >> >> Etwas anders als Du denkst ;) - aber Backup von der alten, >> OS/BF Fw drauf und gut ist ;) > > Meine Frage bzgl. Hardware-Version war dahingehend, dass diese den > Versionsstand der Signalverarbeitung + Nios-Core im FPGA beschreibt A > (siehe Anhang). Diese wird im SPI-Flash B gespeichert. Bleibt also bei > 8C7.0E. > 1.2.BF.1.8 ist der Code fur den Nios, der im parallelen Flash C abgelegt > wird. Die Nios FW wird ueber RS232 D mittels GERMSloader im Flash C > gespeichert. Altenativ zu Testzwecken kann man auch das SRAM E nehmen. > Nach dem Ausschalten natuerlich dann weg. Stimmt das so? Das wird Dir vielleicht jmd. aus der Leon-3 Gruppe beantworten können ;) - Ich weiß nur, dass Du mit dem komplett Backup auch die angesagt Hardware-Version änderst (und deren Verhalten) - sprich: Wenn Du auf ein .0E das Backup von 'ner 0L einspielst, meldet die sich als .0L und kann auch Probleme bei der Signal-Aquise haben. > >>>> [SF, SVN, PHPBB] > > Ich meinte das Forum > http://sourceforge.net/apps/phpbb/welecw2000a/index.php Und dann > Neudeutsch als Sprache, da es ja viele gibt, die mit Deutsch Probleme > haben. > Dann waere alles zusammen und man koennte in einem Forum suchen! War mir schon klar ;) - es gab auch immer wieder Versuche, dieses Forum zum phpBB hinzubewegen - generell ist aber dort die Beteiligung geringer ... - und menschen sind eher eine träge Masse ;) > >>> [Signal-Verarbeitung] Dieser Umstand wäre etwas, was mich, wenn ich neu einsteigen würde auch eher zu einer Mitarbeit am Leon-3 als am Nios anregen würde - die Nios-FW (inkl. FPGA) ist halt etwas sehr verbuggt ... > > Danke fuer die Hinweise, das kommt dann spaeter. > > Gruss, Peter Grüße, rowue
Rolf W. schrieb: >> >> Meine Frage bzgl. Hardware-Version war dahingehend, dass diese den >> Versionsstand der Signalverarbeitung + Nios-Core im FPGA beschreibt A >> (siehe Anhang). Diese wird im SPI-Flash B gespeichert. Bleibt also bei >> 8C7.0E. >> 1.2.BF.1.8 ist der Code fur den Nios, der im parallelen Flash C abgelegt >> wird. Die Nios FW wird ueber RS232 D mittels GERMSloader im Flash C >> gespeichert. Altenativ zu Testzwecken kann man auch das SRAM E nehmen. >> Nach dem Ausschalten natuerlich dann weg. Stimmt das so? > > Das wird Dir vielleicht jmd. aus der Leon-3 Gruppe beantworten > können ;) - Ich weiß nur, dass Du mit dem komplett Backup auch > die angesagt Hardware-Version änderst (und deren Verhalten) - sprich: > Wenn Du auf ein .0E das Backup von 'ner 0L einspielst, meldet die > sich als .0L und kann auch Probleme bei der Signal-Aquise haben. @ Rolf W. Das solltest Du inzwischen schon selbst beantworten können!! Dazu ist nicht die LEON - 3 Gruppe nötig! Die Darstellung von Peter M. ist absolut korrekt mit einer kleinen Ergänzung: Die NIOS 1 - Hardware kopiert die NIOS - Firmware nach Reset immer zunächst in den RAM ( E ) und startet sie dort! Die LEON - 3 Entwicklung ist eine hervorragende Arbeit von Alex, die ich die ganze Zeit mit Hochachtung beobachtet habe! Aber man kann verfolgen, wie lange die Entwicklung bis zum jetzigen Stand gedauert hat. Dabei war der Alex der Einzige der FPGA-Gilde, der überhaupt einen brauchbaren und funktionierenden Entwurf erreicht hat! ( siehe T8051 - und ZPU - Design ) Und es ist bis heute noch nicht ein Design, welches einfach so praktisch nutzbar ist. Deshalb arbeite ich an der Beseitigung der Fehler in der NIOS-1-FW mit, sogut es eben meine Zeit zulässt. @ all Übrigens denke ich, daß sich Hayo überhaupt nicht rechtfertigen muss, wenn da irgend jemand kommt, der es wiedermal besser zu wissen glaubt!! Solche Diskussionen führen keinen Schritt weiter! Also bitte: Erst lesen ( wenn es auch teilweise lange dauert ;-) ), dann nachdenken und dann erst schreiben! So, jetzt habe ich auch diesen Thread mit unproduktiven Dingen verlängert. Musste aber mal heraus. Schönen Abend und beste Grüße, Jürgen
Angehängte Dateien:
-
screenshot-0010.png
6,2 KB -
screenshot-0003.png
5,7 KB
Hallo Hayo, wie ist der Stand beim Ext.Trigger? Habe heute zum Thema ein paar Messungen gemacht. DUT ist W2012A und die Screenshots kommen vom W2024A. Hab mir leider durch meinen Clip den U6/Pin 1 abgerissen :-( Wenigstens halten die Clips ordentlich ;-) CH1 : U6/1 ext. Triggerausgang zum FPGA / Tastkopf 1:1 Ch2 : U16/1 PWM - TP Filter - Ausgang / Tastkopt 1:10 CH3 : Q4/3 TP - Filter - Eingang Kollektor Q4 Tastkopf 1:1 Signalgenerator: Eigenbau DDS-2-Kanal mit 2,3 KHz Sinus 6 V pp, symmetrisch zu GND Sieht alles zunächst aus, wie es soll. Allerdings finde ich die Ausgangsspannung der PWM ( U6/4) viel zu wellig!Damit ist kein stehendes Bild beim Trigger zu bekommen.Ich denke, wir müssen die Dimensionierung des aktiven TP-Filter überarbeiten!? Hast Du irgendwo in der FW etwas gefunden, die Ausgangsfrequenz der PWM höher zu setzen? Mit 469 Hz wirkt die TP-Filterdimensionierung nicht so gut. Leider bleibt das 3/4-Problem :-( Beste Grüße, Jürgen
Jürgen schrieb: > Rolf W. schrieb: >>> >>> Meine Frage bzgl. Hardware-Version war dahingehend, dass diese den >>> Versionsstand der Signalverarbeitung + Nios-Core im FPGA beschreibt A >>> (siehe Anhang). Diese wird im SPI-Flash B gespeichert. Bleibt also bei >>> 8C7.0E. >>> 1.2.BF.1.8 ist der Code fur den Nios, der im parallelen Flash C abgelegt >>> wird. Die Nios FW wird ueber RS232 D mittels GERMSloader im Flash C >>> gespeichert. Altenativ zu Testzwecken kann man auch das SRAM E nehmen. >>> Nach dem Ausschalten natuerlich dann weg. Stimmt das so? >> >> Das wird Dir vielleicht jmd. aus der Leon-3 Gruppe beantworten >> können ;) - Ich weiß nur, dass Du mit dem komplett Backup auch >> die angesagt Hardware-Version änderst (und deren Verhalten) - sprich: >> Wenn Du auf ein .0E das Backup von 'ner 0L einspielst, meldet die >> sich als .0L und kann auch Probleme bei der Signal-Aquise haben. > > @ Rolf W. > > Das solltest Du inzwischen schon selbst beantworten können!! Dazu ist > nicht die LEON - 3 Gruppe nötig! Tja, ich habe mich bisher eher in die Nios-FW eingearbeitet - aber danke für den Hinweis ;) > Die Darstellung von Peter M. ist absolut korrekt mit einer kleinen > Ergänzung: > Die NIOS 1 - Hardware kopiert die NIOS - Firmware nach Reset immer > zunächst in den RAM ( E ) und startet sie dort! O.K. - das ist dann wohl auch die Grundlage für den Ram-Loader ;) > > [Leon-3] Die Software ist wirklich gut - und jedem neuen Entwickler würde ich vorschlagen, sich an diesem Projekt zu beteiligen ;) > Deshalb arbeite ich an der Beseitigung der Fehler in der NIOS-1-FW mit, > sogut es eben meine Zeit zulässt. Da kenne (und kannte) ich mehr von - aber wenn Du mal 'nen Blick in den Code geworfen hast, wirst Du auch wissen, dass da böse Dinge drin sind - auch, wenn sich der Code schon deutlich gebessert hat - und auch weiterhin verbessert wird ;) Und mit den bekannten Probleme in der Signal-Aquise dürfte auch klar sein, dass wir in den 250/500MSa/s und 1GSa/s Modi bestenfalls interpolierte Signale bekommen ... > > @ all > Übrigens denke ich, daß sich Hayo überhaupt nicht rechtfertigen muss, > wenn da irgend jemand kommt, der es wiedermal besser zu wissen glaubt!! > Solche Diskussionen führen keinen Schritt weiter! > Also bitte: Erst lesen ( wenn es auch teilweise lange dauert ;-) ), dann > nachdenken und dann erst schreiben! Wenn ich Hayo was vorzuwerfen hätte, wäre es das, dass er kein svn benutzt (wie damals abgesprochen) - aber letztlich muss er das selbst wissen - ich weiß, welche Vorteile die Verwendung von Versionskontroll-Systemen hat - und wie sich das in einer Kolaboration potenziert - letztlich muss Hayo das aber selbst wissen, Falk und Stefan haben zweimal Code von Ihm eingepflegt. Ich werde das nicht machen. > > So, jetzt habe ich auch diesen Thread mit unproduktiven Dingen > verlängert. Musste aber mal heraus. > > Schönen Abend und beste Grüße, > Jürgen Beste Grüße, rowue
Hallo allseits, danke fuer die Antworten. Rolf W. schrieb: > Das wird Dir vielleicht jmd. aus der Leon-3 Gruppe beantworten > können ;) - Ich weiß nur, dass Du mit dem komplett Backup auch > die angesagt Hardware-Version änderst (und deren Verhalten) - sprich: > Wenn Du auf ein .0E das Backup von 'ner 0L einspielst, meldet die > sich als .0L und kann auch Probleme bei der Signal-Aquise haben. Ja klar, ist ja auch eine andere FPGA-FW. Rolf W. schrieb: >>> [Signal-Verarbeitung] > Dieser Umstand wäre etwas, was mich, wenn ich neu einsteigen > würde auch eher zu einer Mitarbeit am Leon-3 als am Nios > anregen würde - die Nios-FW (inkl. FPGA) ist halt etwas sehr > verbuggt ... Was ich bis jetzt gelesen habe, wohl war. Die org. VHDL-Files gibt es ja wohl auch nicht von Welec, wegen Rechteschnickschnack. Jürgen schrieb: > Die Darstellung von Peter M. ist absolut korrekt mit einer kleinen > Ergänzung: > Die NIOS 1 - Hardware kopiert die NIOS - Firmware nach Reset immer > zunächst in den RAM ( E ) und startet sie dort! Verstehe, danke. Ist da tatsaechlich noch der alte 16biter drin? Das ist mir neu. Gruss, Peter
Hi Jungs, bin in den letzten Tagen wegen des brutal guten Wetters und der WM leider zu nichts gekommen. Letzter Stand beim externen Trigger ist immer noch wie bei der BF.1.8. Allerdings habe ich mehrere Debug Ausgaben eingebaut um evtl. einen Workaround auszutüfteln. Zu SVN: Hatte ich zwischendurch zweimal versucht, allerdings mit mäßigem Erfolg. Dazu kommt, dass sich die OS und BF Versionen in einigen Details unterscheiden, die ich aber bei mir nicht unbedingt ändern möchte. Zudem hatte ich das Gefühl, das die Entwicklung bei der OS-Version etwas stagnierte. Ich habe aber meine Änderungen seit einigen Versionen weitgehend konsistent numeriert, so dass es einigermaßen Einfach ist Änderungen (manuell)in die OS-Version zu übernehmen wenn gewünscht. Zwischendurch habe ich wieder Unterstützung von unseren Italienischen Kollegen (Alessandro) zugesichert bekommen insbesondere im Bereich Signalverarbeitung/FFT. Es geht also noch was. Und natürlich freue ich mich auch über die Fortschritte an der LEON3 Front, denn wir sind uns ja alle einig, das nur ein neues FPGA-Design einen echten Quantensprung bringen kann. Aber wir sind uns (denke ich) auch einig, dass wir in der Zwischenzeit gerne ein gut funktionierendes DSO haben möchten. Bin übrigens ab Ende nächster Woche für drei Wochen im Urlaub und kann mich daher nur sporadisch (je nach WLAN-Versorgung) mal melden. So long Hayo
Peter M. schrieb: > Verstehe, danke. Ist da tatsaechlich noch der alte 16biter drin? Das ist > mir neu. Nein, zum Glück sind wir immerhin bei 32 Bit und 33MHz, sonst ginge da garnichts. Leider wurde beim Entwurf die NIOS-Version ohne zusätzliche Recheneinheit für Multiplikationen gewählt. Aber das LEON3 Design ist da deutlich leistungsfähiger und eröffnet bei der Signalverarbeitung/Interpolation einige Möglichkeiten. Hayo
Hayo W. schrieb: Tut mir leid, aber wenn ich sowas lese, geht mir das Messer in der Tasche auf. > Zu SVN: Hatte ich zwischendurch zweimal versucht, allerdings mit mäßigem > Erfolg. Rolf hatte Dir eine private SVN-Schulung angeboten, ich habe eigens für Dich einen SVN-Server aufgesetzt, den Du, wenn ich mich richtig erinnere, nie benutzt hast. > Zudem hatte ich das Gefühl, das die Entwicklung bei der OS-Version etwas > stagnierte. Das glaube ich Dir nicht, mit Verlaub. Seitdem Du klargemacht hast, daß Du ausschließlich Dein eigenes Ding drehen willst, haben sich etliche von der Entwicklung abgewandt so wie ich auch. Es bringt einfach nichts, wenn jeder sein eigenes Süppchen kocht und sich jemand jeder Teamarbeit verweigert. > Ich habe aber meine Änderungen seit einigen Versionen > weitgehend konsistent numeriert, so dass es einigermaßen Einfach ist > Änderungen (manuell)in die OS-Version zu übernehmen wenn gewünscht. Du glaubst doch nicht ernsthaft, daß sich nochmal jemand findet, der Deinen Kram einpflegt! Das haben wir zwei- oder dreimal versucht und Du hast alle diese Arbeit zunichte gemacht. So, das mußte mal raus. Schönen Urlaub, Falk
Hallo Falk, das hört sich jetzt ziemlich bitterböse an, daher möchte ich nochmals einiges klarstellen: Falk Willberg schrieb: > Hayo W. schrieb: > Rolf hatte Dir eine private SVN-Schulung angeboten, ich habe eigens für > Dich einen SVN-Server aufgesetzt, den Du, wenn ich mich richtig > erinnere, nie benutzt hast. Das ist richtig, aber das lag eher an zeitlichen Engpässen als an nicht vorhandenem Interesse. Ich hatte zwischendurch beruflich in Frankreich zu tun und bin nur sporadisch dazu gekommen mich um das Projekt zu kümmern. >> Zudem hatte ich das Gefühl, das die Entwicklung bei der OS-Version etwas >> stagnierte. > > Das glaube ich Dir nicht, mit Verlaub. Seitdem Du klargemacht hast, daß > Du ausschließlich Dein eigenes Ding drehen willst, haben sich etliche > von der Entwicklung abgewandt so wie ich auch. Es bringt einfach nichts, > wenn jeder sein eigenes Süppchen kocht und sich jemand jeder Teamarbeit > verweigert. Ich habe habe aber schon die ganze Zeit über deutlich gesagt dass ich bei bestimmten Details meine eigenen Entscheidungen treffen möchte in Bezug auf das Firmwaredesign. Das ist denke ich durchaus legitim, nicht nur in Hinsicht auf die von mir bislang investierte Zeit, sondern einfach generell. Ich stelle meine Entwicklungen offen zur Verfügung und biete auch noch Support über die Foren an. Beruflich muß ich oft genug Kompromisse eingehen hinter denen ich nicht unbedingt hundertprozentig stehe weil die Kunden es so wünschen. Wenn ich aber privat meine Zeit investiere für ein solches Projekt, dann nehme ich mir schon die Freiheit mir eine Firmwareversion zu bauen die mir auch zusagt. >> Ich habe aber meine Änderungen seit einigen Versionen >> weitgehend konsistent numeriert, so dass es einigermaßen Einfach ist >> Änderungen (manuell)in die OS-Version zu übernehmen wenn gewünscht. > > Du glaubst doch nicht ernsthaft, daß sich nochmal jemand findet, der > Deinen Kram einpflegt! Das haben wir zwei- oder dreimal versucht und Du > hast alle diese Arbeit zunichte gemacht. Inwiefern habe ich Arbeit zunichte gemacht? Wenn ich einfach nichts mehr gemacht hätte, dann würde die Firmware immer noch auf dem Stand der OS.0.92 rumdümpeln. > So, das mußte mal raus. So, das mußte auch mal raus. > Schönen Urlaub, > Falk Danke, nichts für ungut. Ich hoffe trotzdem auf weiteren Gedankenaustausch zugunsten dieses wirklich interessanten Projekts. Gruß Hayo
Nabend allerseits, insbesondere 'nabend Hayo und Falk ;) Das Wetter ist wirklich genial, auch wenn es mir letzte Woche hier unten zu Warm und zu Windstill war (>30° ohne Windhauch :( Zuerstmal an Hayo: Ich bin Ende August für 'ne Woche in HH, wenn Du möchtest, können wir uns da auf 'nen T zusammenhocken und ich gebe Dir 'ne kurze Einführung in SVN. Für einen selbst hat es den Vorteil, eigene Fehler schneller zu finden ("Das ging doch letzte Woche noch, oder?") - in einer Kolaboration mit anderen kann es den Vorteil haben (bei entsprechender Kapselung -> branches) Änderungen einfacher übernehmen zu können. Ich denke da nur an den Trigger von Stefan ggü. dem merge, den wir vor einiger Zeit aus der BF in die OS gemacht haben ... Wenn Du CVS kennst, kannst Du Dir evtl. vorstellen, was mit SVN geht, aber SVN ist wesentlich freundlicher (und nur durch git oder mercurial zu ersetzen ;) Zur Stagnation der OS - derzeit bin ich wieder am machen und einchecken, hoffe aber, dass die Releases der OS 0.93ff nicht nur an mir hängen werden (bin da aber auch zuversichtlich ;) Zur Signalverarbeitung - klar lässt sich bei dem Gerät mit der FFT (Faltung) und auch mit anderen Punkten noch etwas spielen, allerdings werden wir auch mit einer C^3 Spline in den höheren Sampleraten nur ein interpoliertes Signal bekommen (was aber auch für 99% der Fälle reichen sollte ;) Beste Grüße, schönen Urlaub, rowue
Rolf W. schrieb: > Zuerstmal an Hayo: Ich bin Ende August für 'ne Woche in HH, wenn Du > möchtest, können wir uns da auf 'nen T zusammenhocken und ich gebe Dir > 'ne kurze Einführung in SVN. Für einen selbst hat es den Vorteil, eigene > Fehler schneller zu finden ("Das ging doch letzte Woche noch, oder?") - > in einer Kolaboration mit anderen kann es den Vorteil haben (bei > entsprechender Kapselung -> branches) Änderungen einfacher übernehmen zu > können. Ich denke da nur an den Trigger von Stefan ggü. dem merge, den > wir vor einiger Zeit aus der BF in die OS gemacht haben ... Hi Rolf, ja die Vorzüge sind mir an sich schon klar, da ich aber beruflich (leider) nur noch im SAP-Umfeld programmiere (gebe hier gerade eine ABAP-Schulung) kenne ich mich mit diesen Tools eigentlich überhaupt nicht aus. Ich hab bei mir SVN mit grafischer Oberfläche installiert, hab es auch zwischenzeitlich zum Laufen gebracht, aber dann ging es kurze Zeit später nicht mehr. Ich vermute, dass jemand die Directories verschoben hat. Ende August sollte es eigentlich klappen, da können wir uns gerne mal zusammensetzen. Gruß Hayo
Hayo W. schrieb: > Rolf W. schrieb: > >> [...] > > Hi Rolf, Hi Hayo, > > [SAP + SVN] Naja, Versionskontrolle/SVN nutzt ja nicht nur bei Software ;) Ebenso kannst Du damit Vorträge, Schulungen, Papers, Berichte, etc verarzten - im Endeffekt für alles, was (iterative) Entwicklungsprozesse benötigt, resp. in diesen entwickelt werden kann. Sogar für Messungen hat es Vorteile ;) > Ich hab bei mir SVN mit grafischer Oberfläche installiert, > hab es auch zwischenzeitlich zum Laufen gebracht, aber dann ging es > kurze Zeit später nicht mehr. Ich vermute, dass jemand die Directories > verschoben hat. Ich erinnere mich gerade nicht an so massive Änderungen, aber einfach mal schauen ;) > > Ende August sollte es eigentlich klappen, da können wir uns gerne mal > zusammensetzen. > O.K. ich schau nachher mal in meinen Terminkalender, und schicke Dir 'ne PM mit den Daten, wann ich genau in HH bin ;) > Gruß Hayo Grüße, rowue
Hallo, ganz schön ruhig geworden, lag das nun am Fußballspiel oder liegt das an der anstehenden Feriensaison? Der Querdenker
Hallo, >Ende August sollte es eigentlich klappen, da können wir uns gerne mal >zusammensetzen. Na, das klingt ja fast so, als ob wieder etwas Bewegung in die Akte "svn" kommen könnte. >Ich habe habe aber schon die ganze Zeit über deutlich gesagt dass ich >bei bestimmten Details meine eigenen Entscheidungen treffen möchte in >Bezug auf das Firmwaredesign Es stört mich überhaupt nicht, wenn einer die Linie vorgibt. Nur kann ich Änderungen in einer schlichten Text-Datei nicht zusammenhängend nachvollziehen. Deshalb habe ich damals auch nicht alle deine Änderungen übernehmen können, weil ich schlichtweg nicht mehr durchgeblickt habe und es beim Mergen zu heftigen Problemen gekommen ist(für deren Lösung mit die Zeit zu schade war). Deshalb haben sich die Versionen auseinander entwickelt. Es war nie Absicht einen unabhängige Firmware zu erstellen. >Inwiefern habe ich Arbeit zunichte gemacht? Wenn ich einfach nichts mehr >gemacht hätte, dann würde die Firmware immer noch auf dem Stand der >OS.0.92 rumdümpeln. Also zumindest von mir dümpeln in der 0.92a noch Änderungen bezüglich des Verhalten der Timebase im Stop-Zustand rum. Nach der erneuten Aufspaltung im Frühjahr in BF und OSS habe zumindest ich es als überflüssig empfunden, weiterhin an zwei Versionen zu arbeiten und meine Zeit anderweitig genutzt. Ich möchte hier keinen neuen Krieg losbrechen. Aber ich fände es echt super, endlich konsequent auf svn zu setzen. Mir wäre es auch wurscht, ob die letzten Änderungen aus der OSS einfließen würden oder nicht. Hauptsache andere Entwickler könnten endlich Änderungen leicht nachvollziehen und auch wieder Änderungen ganz einfach einbringen.
Hallo Stefan, niemand hat Schuld, aber am Ende ist die SVN-Version schlicht im Chaos untergegangen.Jeder hat einfach die öffentliche Version geändert und kein Mensch hat mehr den aktuellen Zustand überblickt. Ich bin davon überzeugt, dass die OS-Version zu buggy ist um sie überhaupt zu testen und habe sie daher auch nie aufgespielt. Klar bringt eine Versionsverwaltung Vorteile, so stümperhaft eingesetzt aber sicher nicht. Ich verstehe, dass Hayo nicht alle Änderungn der OS übernehmen will, was aber noch lange nicht bedeutet, dass alle Änderungen verworfen werden. Ein neuer Anlauf mit mehreren Branches wäre sicher machbar. Gruß, Guido
Guido schrieb: > Ich bin davon überzeugt, dass die OS-Version zu buggy ist um sie > überhaupt zu testen und habe sie daher auch nie aufgespielt. Dann hast du sicherlich auch mitbekommen, dass bspw. Rolf daran arbeitet und in aller Regelmäßigkeit Änderungen eincheckt und das einige wichtige Erkenntnisse dank der OS-Version und deren Mitstreitern erst möglich geworden sind? Dieses Hochgejubel von Hayo - nichts gegen dich persönlich Hayo - ist wirklich fehl am Platz und nervt mich persönlich auch schon eine ganze Weile. Statt lange herum zu lamentieren sollte mit aller Konsequenz SVN oder ähnliches eingesetzt werden, denn wer hat Lust sich das ChangeLog durchzulesen, zumal da auch nicht alles drin festgehalten ist. Wenn angeblich alle an einem Strang ziehen, wie kann es dann zu einer Versionstrennung kommen? Am besten trinkt ihr alle mal ein Bier zusammen und rauf euch mal wieder zusammen, dann würdet ihr auch wieder gemeinschaftliche Fortschritte machen. Danke.
Hayo W. schrieb: > Nein, zum Glück sind wir immerhin bei 32 Bit und 33MHz, sonst ginge da > garnichts. Leider wurde beim Entwurf die NIOS-Version ohne zusätzliche > Recheneinheit für Multiplikationen gewählt. Aber das LEON3 Design ist da > deutlich leistungsfähiger und eröffnet bei der > Signalverarbeitung/Interpolation einige Möglichkeiten. Hallo Hayo, sorry fuer die spaete Antwort. Danke fuer die Erlaeuterung. Gruss, Peter
Querdenker schrieb: > Hallo, > > ganz schön ruhig geworden, lag das nun am Fußballspiel oder liegt das an > der anstehenden Feriensaison? Mir war es schlichtweg zu heiß um mich an den Rechner zu setzen. Darius schrieb: > Guido schrieb: >> Ich bin davon überzeugt, dass die OS-Version zu buggy ist um sie >> überhaupt zu testen und habe sie daher auch nie aufgespielt. > > Dann hast du sicherlich auch mitbekommen, dass bspw. Rolf daran arbeitet > und in aller Regelmäßigkeit Änderungen eincheckt und das einige wichtige > Erkenntnisse dank der OS-Version und deren Mitstreitern erst möglich > geworden sind? Das ist korrekt. Ich habe auch etliche wichtige Sachen aus der OS-Version übernommen. Aber mir gefiel eben nicht alles! Daher weicht meine Version in einigen Dingen von der OS-Version ab und ein direktes Mergen ist so ohne Weiteres nicht möglich. Wie wir da weiter vorgehen werde ich mal mit Rolf bei einem kühlen Bier klären, dann kann er mir auch gleich was zu den neuesten Änderungen an der OS.0.92a sagen. > Dieses Hochgejubel von Hayo - nichts gegen dich persönlich Hayo - ist > wirklich fehl am Platz und nervt mich persönlich auch schon eine ganze > Weile. Oh, hab ich was verpasst? Gab es Huldigungen? Das muß man mir doch zutragen. Also ich erinnere mich nur an DSO-Besitzer die sich hier für die Arbeit an der Firmware bedankt haben, worüber ich mich auch sehr gefreut habe, denn auch wenn das hier eine Art Hobby ist, geht doch eine Menge Zeit und Mühe dabei drauf. Die Danksagungen waren doch wohl auch eher an alle der hier Beteiligten gerichtet als nur an mich. > Statt lange herum zu lamentieren sollte mit aller Konsequenz SVN > oder ähnliches eingesetzt werden, denn wer hat Lust sich das ChangeLog > durchzulesen, zumal da auch nicht alles drin festgehalten ist. Ich finde das Changelog ziemlich hilfreich, schon alleine um bei bestimmten Fehlern herauszufinden seit welcher Version die Änderungen existieren. Es sollte eigentlich auch recht komplett sein. Ich vermerke da auch kleinere Änderungen. > Wenn angeblich alle an einem Strang ziehen, wie kann es dann zu einer > Versionstrennung kommen? Warum gibt es so viele verschiedene Linux-Versionen? > Am besten trinkt ihr alle mal ein Bier zusammen das ist immer eine gute Idee... > und rauf euch mal wieder zusammen, dann würdet ihr auch wieder > gemeinschaftliche Fortschritte machen. Das wird schon wieder Gruß Hayo
Guido schrieb: > Hallo Stefan, > Hi Guido, > niemand hat Schuld, aber am Ende ist die SVN-Version schlicht im > Chaos untergegangen.Jeder hat einfach die öffentliche Version > geändert und kein Mensch hat mehr den aktuellen Zustand überblickt. Was zu beweisen wäre - diverse Änderungen wurden besprochen und seit einiger Zeit werden Änderungen in seperaten branches vorgenommen, getestet und danach - evtl. germerged. Aber warst Du nicht derjenige, der etwas von > 300 Änderungen an der OS Version erzählte und nicht blickte, dass diese u.a. auch die Arbeit der FPGA-Gruppe betrafen? Ich komme im aktuelle trunk gerade mal auf 60 > Ich bin davon überzeugt, dass die OS-Version zu buggy ist um sie > überhaupt zu testen und habe sie daher auch nie aufgespielt. Also kannst Du auch keine Aussage über die OS-Version treffen. Da wäre ich vorsichtig mit Vermutungen. > > Klar bringt eine Versionsverwaltung Vorteile, so stümperhaft > eingesetzt aber sicher nicht. Diese Aussage würde ich an Deiner Stelle deutlich überdenken. Aber wie mensch an einer vorherigen Aussage (>300 Änderungen) schon sieht, scheinst Du nicht gerade ein Freund der belegten Äußerungen zu sein. > Ich verstehe, dass Hayo nicht > alle Änderungn der OS übernehmen will, was aber noch lange nicht > bedeutet, dass alle Änderungen verworfen werden. Ich denke, ich würde im Vergleich auch nicht alle Änderungen von Hayo einbauen wollen ;) > > Ein neuer Anlauf mit mehreren Branches wäre sicher machbar. http://sourceforge.net/apps/trac/welecw2000a/browser/fpga/nios/oss/branches Eine gute Recherche hat schon ihre Vorteile.... > > Gruß, Guido Grüße, rowue
Hallo Rolf, du jast schon recht, meine Bemerkungen beziehen sich auf den Stand von vor ca. 2 Jahren. Ich habe damals keine Chance mehr gesehen die SVN-Änderungen auch nur nachzuvollziehen, das war einfach zu chaotisch. Wenn du und andere das jetzt sinnvoller aufziehen, bin ich, wie oben geschrieben, der letzte, der sich dagegen wehrt. Ich hatte nach Falks ausscheiden noch gelegentlich im SFN nachgeschaut und den Eindruck, dass dieses tot ist. Schön, wenn sich da wieder etwas tut, hier hat man das halt nicht mitbekommen. Gruß, Guido
Guido schrieb: > Hallo Rolf, > Hi Guido, > du jast schon recht, meine Bemerkungen beziehen sich auf den > Stand von vor ca. 2 Jahren. Ich habe damals keine Chance mehr > gesehen die SVN-Änderungen auch nur nachzuvollziehen, das war > einfach zu chaotisch. Wenn du und andere das jetzt sinnvoller > aufziehen, bin ich, wie oben geschrieben, der letzte, der sich > dagegen wehrt. Naja, Zeit ist etwas relatives ;) - Wir nutzen das SVN gerade seit einem Jahr ;) - Ansonsten: klar, je nachdem, wie mensch mit "unified diffs" klarkommt, kann es sehr unübersichtlich werden - vor allem, wenn da einige Leute einchecken, wobei ich meine Änderungen vorher immer im Bulk eingecheckt habe (was auch eher nervig war) In diesem Sinne bringt das branchen für uns alle Vorteile, Du checkst Deine Änderungen ein, wenn Du Dir in den Fuß schießt, haut es noch nicht den trunk weg, und wenn die Änderungen abgehangen (getestet) sind, merged Du das Ganze ;) (Ich war halt eben vorher auch etwas zu schüchtern, 'nen branch aufzumachen ;) > > Ich hatte nach Falks ausscheiden noch gelegentlich im SFN > nachgeschaut und den Eindruck, dass dieses tot ist. Schön, > wenn sich da wieder etwas tut, hier hat man das halt nicht > mitbekommen. Naja, ich hatte mir mit dem Einbau des Abschirmbleches hier thermische Probleme eingefangen (und diese auf das Umlöten der Widerstände bezogen) und konnte Falk hat nur etwas unterstützen, danach kam Vortrags- und Umzugsstress. So habe ich dann Anfang April den branch aufgemacht und checke da seit Ende Juni fleissig ein - was ich etwa auf den Zettel gesetzt habe, kannst Du hier nachlesen: http://sourceforge.net/apps/trac/welecw2000a/milestone/1.2-OS-0.93 gerade bin ich an der Kalibrierung (#46, http://sourceforge.net/apps/trac/welecw2000a/ticket/46), die allerdings von den Auswirkungen her etwas zeitaufwendig ist (geht komplett durchs System und so wie der Source um Refaktorisierung bettelt ....) > > Gruß, Guido Beste Grüße, rowue PS: habe auch den Fehler in der C-Routine zum Auslesen der ADC's gefunden - kannst Dir die alte mal in Ruhe ansehen, Du wirst lachen oder weinen - je nach dem ;)
Nur zur Info. Meine Erfahrungen mit dem Firmeware Backup habe ich hier http://sourceforge.net/apps/phpbb/welecw2000a/viewtopic.php?f=5&t=58 beschrieben. Gruss, Peter
Guido schrieb: ... > Ich hatte nach Falks ausscheiden noch gelegentlich im SFN > nachgeschaut und den Eindruck, dass dieses tot ist. Schön, > wenn sich da wieder etwas tut, hier hat man das halt nicht > mitbekommen. Da mein Name genannt wird, sage ich auch noch etwas dazu: Mein Ziel war eher, die Darstellungsgeschwindigkeit und die Fernsteuermöglichkeiten zu verbessern. Das ist nämlich der Punkt, der mich am meisten stört. Das Video muß ich nicht nochmal posten, aber >10fps sagen schon genug. Da mein Weg, die Y-Koordinaten direkt aus ADC-Werten über eine Tabelle zu indizieren, keine Freunde gefunden hat, habe ich den noch eine Weile selbst verfolgt. Die Fernsteuerung und Daten/Screendump hat Hajo ja in "seine" Versionen "übernommen". Die schweren Verzerrungen bei >30MHz konnte ich auch beseitigen, leider trt dadurch das Problem der Spikes auf. Das halte ich für lösbar, zumindest für Kanal 1+2. Die Funktionen der einzelnen Bits in den Registern lassen sich auch testen, ohne den Netzschalter über Gebühr zu belasten: https://sourceforge.net/apps/trac/welecw2000a/wiki/RemoteControlAPI Mein Fazit: Es könnten reichlich Verbesserungen eingebaut werden. Aber wie soll das gehen? Im SVN fehlen Hayos letzte Änderungen, ob Hayo einsieht, daß die serielle Steuerung sinnvoll ist, ist fraglich. WIMRE hat er die schon einmal wieder entfernt. Falk
Falk Willberg schrieb: > Guido schrieb: > > ... > >> Ich hatte nach Falks ausscheiden noch gelegentlich im SFN >> nachgeschaut und den Eindruck, dass dieses tot ist. Schön, >> wenn sich da wieder etwas tut, hier hat man das halt nicht >> mitbekommen. > > Da mein Name genannt wird, sage ich auch noch etwas dazu: > > [Darstellungsgeschwindigkeit und Fernsteuerbarkeit] Die Geschwindigkeit ist wirklich atemberaubend - allerdings fehlen diverse Bedienmöglichkeiten des Gerätes, weshalb ich erstmal den anderen Weg gewählt habe. > > Da mein Weg, die Y-Koordinaten direkt aus ADC-Werten über eine Tabelle > zu indizieren, keine Freunde gefunden hat, habe ich den noch eine Weile > selbst verfolgt. Naja, die Indizes hatte ich Dir noch eingebaut - Do you remember? Und just for info: AFAIR verwendet die BF derzeit auch Indizes, und in der OS habe ich die - alten - alten Zeichenroutinen auch auf diese umgestellt. Evtl. werde ich zu einem späteren Zeitpunkt auch Dein und Jörgs direktes Schreiben in den Video-Puffer übernehmen, aber derzeit habe ich andere Baustellen .... Wenn Du eine schnelle Darstellung einbaust, welche die übrigen Funktionen des Gerätes nicht beeinträchtigt, wird sich keiner ein Problem haben. Aber auch >10fps wenn Cursor, etc nicht funktionieren. > > [Verbesserungen, Hayo, SVN] Zu erst: ich möchte zu diesem Zeitpunkt in keinster Weise über Hayo diskutieren - dieser ist derzeit im Urlaub. Du wirst sicher auch keine Diskussionen über Dich lesen wollen, wenn Du aus dem Urlaub zurückkommst, oder? Zum Thema SVN: Ich checke meine Änderungen ein - damit sie genutzt werden können. Wenn andere das nicht machen, ist das ihre Sache. Mehr Spass bringt es, wenn alle das machen. Dich hatte ich in den letzten Wochen und Monaten in verschiedensten Bezügen auch auf dieses Projekt angesprochen - Dein einziger Kommentar war: "Das wird alles nichts mehr." Wenn ich Dinge anfange, ziehe ich sie auch durch und versuche dabei gute Arbeit zu machen. Andernfalls nehme ich mich selbst nicht ernst - und dann wird es auch kein anderer machen. > > Falk Beste Grüße, rowue
Peter M. schrieb: > Nur zur Info. Meine Erfahrungen mit dem Firmeware Backup habe ich hier > http://sourceforge.net/apps/phpbb/welecw2000a/viewtopic.php?f=5&t=58 > beschrieben. > Toll! > Gruss, Peter Grüße, rowue
So, dann haben wir es ja jetzt zusammen: Alle Verbesserungen sind natürlich wünschenswert! Die Gesamtsoftware ist aber so komplex, dass jede Änderung in vielen Bereichen Anpassungen erfordert. Die extrafast-Zeichenroutine muss sich halt auch im Quickmeasure, im Math-Modus,im XY-Modus, im Delayed-Mode usw. behaupten. Ich finde die Idee grundsätzlich gut, verstehe aber Hayo, wenn er sie ablehnt, weil sie in manchen Modi noch nicht funktioniert und hierbei die Vorteile der Interpolation verloren gehen. Dieses war mein Hauptproblem mit dem Trunk im SVN. Jeder hat einfach seine Änderungen eingepflegt und am Ende resultierte eine nur noch eingeschränkt nutzbare Firmware. Imho ist Hayos Vorgehen für solche Änderungen optimal, weil er sie über das Menü ein- und ausschaltbar macht, so dass bis zur endgültigen Entscheidung jeder User nach seinem Geschmack probieren kann. Verschiedene Zeichenroutinen hatten wir, Dank Hayo; ja von Anfang an. Gruß, Guido
Guido schrieb: > [Änderungen und Komplexität] > > Dieses war mein Hauptproblem mit dem Trunk im SVN. Jeder hat einfach > seine Änderungen eingepflegt und am Ende resultierte eine nur noch > eingeschränkt nutzbare Firmware. Da Du die OS ja laut eigener Aussage nicht getestet hast, finde ich Deine Schlüsse sehr interessant. > > Imho ist Hayos Vorgehen für solche Änderungen optimal, weil er sie > über das Menü ein- und ausschaltbar macht, so dass bis zur > endgültigen Entscheidung jeder User nach seinem Geschmack probieren > kann. Verschiedene Zeichenroutinen hatten wir, Dank Hayo; ja von > Anfang an. Wer sagt Dir, dass nicht auch Falks Änderung optional ein- und ausgeschaltet werden konnte? Hast Du das geprüft? Oder stellst Du jetzt (wieder einmal) einfach eine Behauptung auf? Btw: Die Interpolation kam sehr früh, also fast von Anfang an. > > Gruß, Guido Beste Grüße, rowue
Hallo rowue, Rolf W. schrieb: > Peter M. schrieb: >> Nur zur Info. Meine Erfahrungen mit dem Firmeware Backup habe ich hier >> http://sourceforge.net/apps/phpbb/welecw2000a/viewtopic.php?f=5&t=58 >> beschrieben. > > Toll! Danke. Eine Frage habe ich aber noch. Die Datei ist 25874152 bit gross, das Ganze soll mit 115k2 als Baudrate runtergeladen worden sein und hat ca. 45 Minuten (2678 s, wenn die Anzeige stimmt) gedauert. Bei der Dauer ueberschlage ich aber eher eine Baudrate von 9600! Bei 115k2 wuerde ich eine Backupdauer von unter 5 Minuten erwarten. Kann da jemand weiterhelfen? Gruss, Peter
Hallo Peter, die Software von Wittig ist ziemlich grottig und die hat die üble Datenrate. Jedenfalls ist damit nicht mehr hinzubekommen. Das ist auch der Grund, warum hier ein Pearl-Script zum flashen/laden der neuen Firmware benutzt wird. Allerdings hatte ich am Anfang meinen USB/Seriell Wandler immer direkt angeschlossen und damit hat der Up-/Download ewig gedauert. Mit dem Script ging gar nichts. Erst als ich zusätzlich ein weiteres serielles Kabel benutzt hatte, ging es richtig schnell. Es sieht also so aus, als ob die Wittig Software auch mit der seriellen Verbindung hinkommt (wenn auch sehr langsam), während mit dem Script nur die Nullmodem-Variante funktioniert, dann aber mit richtig Speed (ca. 180 Sekunden). Michel
Hallo Leute, ein kurzer Gruß aus dem Urlaub. Beharkt Euch nicht so, im Prinzip wollen wir alle das Gleiche, nämliche eine coole Firmware. Die schnelle Zeichenroutine von Falk hatte ich nicht abgelehnt, sondern nur nicht so schnell in der OS-Version gefunden. Ich sprech mal mit Rolf drüber wenn wir uns treffen, ob und wie wir das alles zusammenbringen. Gruß Hayo
Kurze Frage,
hat hier jmd. ein Backup seiner alten (Orignal) FW
für ein
W20X4A, Hardware-Version 8C7.C9
und würde mir evtl. mit einer Kopie aushelfen
(Seriennummer ändere ich wieder auf meine) - ich
hatte hier einen kleinen Betriebsunfall und finde
mein Backup nicht mehr (resp. die Platte auf
der das war ...)
Beste Grüße,
rowue
die 1.3 und 1.2 gibt es immer noch bei welec.de....
Moin moin, auch wenns etwas OT ist, ich habe mir bei Wittig ein DSO ersteigert, vor fast 2 Wochen bezahlt aber es kommt nix, wirklich nix, ich habe Ihn mehrfach angemailt, versucht anzurufen, nix !, er hat mitlerweile wieder welche in E*ay eingestellt, also ist er da und nicht irgendwo ohne Internet im urlaub, weiss jemand was naeheres, i komme mich irgendwie verarscht vor vlg Charly
egberto schrieb: > die 1.3 und 1.2 gibt es immer noch bei welec.de.... Da fehlen aber einige Einstellungen aus dem Protected, die für das Setup des FPGAs gebraucht werden (und z.B. für die Signalabtastung wichtig sind). Und wenn Dein Gerät gerade nicht mal mehr weiß, was für ein W2XXX es ist oder welche HW-Version drauf ist, brauchst Du ein komplett Backup der gleichen FPGA-Version. Beste Grüße, rowue
Hi Rolf, hier hast du einen kompletten Original-Dump von meinem DSO, allerdings mit der 1.4 Ver. von Welec. Das Teil ist über 3MB groß! Dabei ist ist noch ein Backup mit ca. 1,8MB, da weiss jetzt leider nicht mehr, was ich da gesichert habe, kannst ja mal nach schauen, was da passt. Gruß Michael
Ich noch mal, die HW-Ver. von dem Dump ist: 8C7.0L ...jetzt muß ich aber los Gruß Michael
Michael D. schrieb: > Hi Rolf, > > hier hast du einen kompletten Original-Dump von meinem DSO, allerdings > mit der 1.4 Ver. von Welec. > Das Teil ist über 3MB groß! > Dabei ist ist noch ein Backup mit ca. 1,8MB, da weiss jetzt leider nicht > mehr, was ich da gesichert habe, kannst ja mal nach schauen, was da > passt. > > Gruß Michael Hallo Michael, durch Zufall bin ich glaube ich ueber deinen damaligen Thread gestolpert Beitrag "Re: Wittig(Welec) W2022A Firmware sichern und Update durchfüren?" rowue sucht eine 4Ch-Version. Gruss, Peter
Rolf W. schrieb: > Kurze Frage, > > hat hier jmd. ein Backup seiner alten (Orignal) FW > für ein > > W20X4A, Hardware-Version 8C7.C9 > > und würde mir evtl. mit einer Kopie aushelfen > (Seriennummer ändere ich wieder auf meine) - ich > hatte hier einen kleinen Betriebsunfall und finde > mein Backup nicht mehr (resp. die Platte auf > der das war ...) > > Beste Grüße, > > rowue Hallo rowue, da ich im Moment vor allem lese, wie der ganze Kram funktioniert bin ich ueber einige FW Dumps gestolpert. http://sourceforge.net/apps/phpbb/welecw2000a/viewtopic.php?f=5&t=53&sid=116d74d958bee7a61137ad97a8832f20#p256 Beitrag "Re: Wittig(welec) Oszilloskop firmware problem" Beitrag "Re: Wittig(welec) Oszilloskop firmware problem" Beitrag "Re: Wittig(welec) Oszilloskop firmware problem" Leider stehen die Hardware-Versionsnummern nicht dabei. Kann man die in den Dumps finden? Moege es nuetzen! Gruss, Peter
Rolf W. schrieb: > W20X4A, Hardware-Version 8C7.C9 Hallo Rolf, Anbei mein backup (W2024A HW 8C7.C9 SW 1.4) hoffe dass das hilft. Martin
hi Peter, eigentlich sollten die diesbezüglich gleich sein ob 2 oder 4 Kanal. Habe den Dump mal in einen Hexeditor geladen, in der Informationsspalte steht nur:--------# WelecUpdater V0.4.8A22...ansonsten nur die HEX. Ob da überhaupt etwas von einer HW-Version steht? Vielleicht wissen die Programierexperten da mehr?!? Gruß Michael PS. Peter: Hast du meine Maill bekommen?
@Charly B. (charly) >auch wenns etwas OT ist, ich habe mir bei Wittig ein DSO ersteigert, >vor fast 2 Wochen bezahlt aber es kommt nix, wirklich nix, ich habe >Ihn mehrfach angemailt, Probiere mal alle eMail's die Du von Ihm finden kannst. (auch die Benachrichtigung über Ebay) Ich hatte mal an eine eMail von Ihm geschrieben, die auch nie ankam..?! Die andere die ich gefunden habe, hatte dann funktioniert! (habe ich aber nicht mehr) l.G. Robert
Nabend, erstmal vielen Dank - insbesondere an Michael, Martin und Peter! Zu den Dumps die Peter gefunden hatte: Auf SF gibt es eine Liste von Leuten und Ihren Geräten, an dieser ließen sich die Dumps identifizieren: http://sourceforge.net/apps/trac/welecw2000a/wiki/usersinstrument (vielleicht sollte ich da meine beiden auch mal eintragen) Martins Dump wird gerade eingespielt. Die Hardware und FW-Versionen stehen auf alle Fälle auch im Dump - wo müsste ich mal nachsehen. Ich kann nur sagen, dass es ziemlich wichtig ist, auch das Dump zu seiner Hardware-Version einzuspielen. (Siehe OS-0.92, OS-0.92a) Bezgl. der 4 Kanäle gibt es explizite Werte für die Kanäle 3 und 4, da wollte ich es nicht dem Zufall überlassen, ob die mitkommen oder nicht. Das Backup ist eingespielt, das DSO ist gebootet - sieht soweit alles gut aus. Vielen Dank nochmal! Beste Grüße, rowue PS: Kennt sich hier jmd. etwas mit C unter Windows aus? Ich bräuchte etwas Hilfe bei der Abfrage des Nutzer/Klarnamens unter Windows (das, was mensch mit getpwuid(getuid()) unter Unix/Linux macht)
@Roberto hatte Ihn ueber Ebay angeschrieben, hab mindestens 200 mal versucht anzurufen, ein einziges mal hatte sich jemand gemeldet der meinet er waehre nicht der H. Wittig, er haette nur ein 'shared Buero' mit Ihm und der H. Wittig waehre am naechsten Vormittag da. Am naechsten Tag hatte ich eine lange Fahrt da konnte ich im 15 Minuten takt anrufen, nichts; da wird mir der Gang zum Rechtsanwalt nicht erspart bleiben .... vlg Charly
Charly B. schrieb: > @Roberto > > hatte Ihn ueber Ebay angeschrieben, hab mindestens 200 mal > versucht anzurufen, ein einziges mal hatte sich jemand gemeldet > der meinet er waehre nicht der H. Wittig, er haette nur ein > 'shared Buero' mit Ihm und der H. Wittig waehre am naechsten > Vormittag da. Am naechsten Tag hatte ich eine lange Fahrt da > konnte ich im 15 Minuten takt anrufen, nichts; da wird mir der > Gang zum Rechtsanwalt nicht erspart bleiben .... > > vlg > Charly Hallo Charly, versuch doch erst mal http://feedback.ebay.de/ws/eBayISAPI.dll?ResolutionCenter Gruss, Peter
@Peter ich verstehe nur nicht warum ich mir MEINE Ware erbetteln muss, ich habe sie/es bezahlt also ist es mein DSO, jetzt muss ich jede menge Energie aufbringen um meine Ware zu bekommen, also irgendwas ist doch da verkehrt, oder ? ; wieder ein Mitglied mehr im Verein 'Servicewüste Deutschland'
Michael W. schrieb: > Hallo Peter, > die Software von Wittig ist ziemlich grottig und die hat die üble > Datenrate. Jedenfalls ist damit nicht mehr hinzubekommen. Das ist auch > der Grund, warum hier ein Pearl-Script zum flashen/laden der neuen > Firmware benutzt wird. > > Allerdings hatte ich am Anfang meinen USB/Seriell Wandler immer direkt > angeschlossen und damit hat der Up-/Download ewig gedauert. Mit dem > Script ging gar nichts. Erst als ich zusätzlich ein weiteres serielles > Kabel benutzt hatte, ging es richtig schnell. Es sieht also so aus, als > ob die Wittig Software auch mit der seriellen Verbindung hinkommt (wenn > auch sehr langsam), während mit dem Script nur die Nullmodem-Variante > funktioniert, dann aber mit richtig Speed (ca. 180 Sekunden). > > Michel Hallo Michel, wenn du bei SF http://sourceforge.net/apps/phpbb/welecw2000a/viewtopic.php?f=5&t=58 schaust, wirst du sehen, dass ich die Wittig SW nie zum laufen bekommen habe. Mit dem WelecUpdater von SF war ich jetzt endlich erfolgreich. Ich glaube du meinst den mit 'Software von Wittig' ;-) Einen USB/Seriell Wandler habe ich nie benutzt. Da haette ich ja noch eine Stolperfalle bei einer Sache die ich zu verstehen versuche. Aber gut zu wissen, trage ich noch bei SF nach. Meine Frage war aber bzgl. GERMSloader: Die Datei ist 25874152 bit gross, das Ganze soll mit 115k2 als Baudrate runtergeladen worden sein und hat ca. 45 Minuten (2678 s, wenn die Anzeige stimmt) gedauert. Bei der Dauer ueberschlage ich aber eher eine Baudrate von 9600! Bei 115k2 wuerde ich eine Backupdauer von unter 5 Minuten erwarten. Vergesst die Frage, ich habe wirklich schon bessere gestellt! Gruss, Peter
Charly B. schrieb: > @Peter > > ich verstehe nur nicht warum ich mir MEINE Ware erbetteln muss, > ich habe sie/es bezahlt also ist es mein DSO, jetzt muss ich > jede menge Energie aufbringen um meine Ware zu bekommen, > also irgendwas ist doch da verkehrt, oder ? ; wieder ein Mitglied > mehr im Verein 'Servicewüste Deutschland' Hallo Charly, soviel Zeit muss sein :-) Ich kann deinen Aerger gut verstehen. Ich denke nur es ist besser, wenn du es so versuchst. Telefonisch hattest du ja wohl keinen Erfolg. Wittig wird dann von Ebay angemailt. Damit ist der Vorfall auch bei denen dokumentiert. Ist bestimmt hilfreich, falls es beim Kadi landet. Paypal hast du wohl nicht benutzt? Hast du ueberprueft, ob die Knete auch auf dem richtigen Konto in der richtigen Hohe angekommen ist? Meine Erfahrungen vor einem Monat waren bzgl. Kaufabwicklung positiv. Auf mein Angebot ein Scope fuer 250 Teuro zu erwerben bekam ich nie eine Antwort. Viel Glueck, Peter
Hallo! Das Wetter ist nun wieder so schlecht geworden, dass ich wieder fürs Entwickeln am LEON3-Design genügend motiviert bin. @ Übertragungsprobleme über die Serielle für das NIOS-Design: Ich hatte bei meinem Software-Upload auf dem FPGA unter Windows lange sehr viele Probleme. Im Endeffekt war es ein Pufferüberlauf im TX-Pufferspeicher, den ich beim WaveRecorder (C++) unter Windows XP mit der Funktion FlushFileBuffers() oder ähnlich beseitigt habe. Im Moment suche ich den Grund, weshalb ich bei meinen Hardware-Filtern eine zu geringe Erweiterung der Auflösung in den Bits bekomme. Vielleicht liegt es auch daran, dass das Spektrum des Signalrauschens so hochfrequent ist, dass einzig die Filterstufe 0 (1GS->100MS) die Auflösung definitiv erhöht. So wie es im Moment ist, macht eine geringere Auflösung als 5 mV/div? (nicht nachgemessen und skaliert) keinen Sinn. Das Signal bekommt man zwar Rauschfrei rein, sieht aber sehr digital aus. Dass sich der DAC von mir nicht ansteuern lässt, finde ich auch etwas komisch, stimmt da vielleicht der Plan von Slog nicht ganz? MfG Alexander
Hey Alex, Ich glaube im Bereich Downsampling hast du mir einiges voraus, selbst habe ich bisher nur einzelne Stufen von Polyphase FIR Filtern dafür verwendet - die haben wie gewünscht gearbeitet, aber dein mehrstufiger Decimator ist ja doch erheblich komplexer. Ich versuche trotzdem mal mitzuraten. falls das Rauschspektrum dir einen Strich durch die Oversampling-Rechnung macht, könnte man ja in der Richtung auch Versuche unternehmen...zunächst extern geeignetes Rauschen addieren und falls es was nützt, könnte man überlegen, wie man das ins Oszi bringt. Ein geeigneter Rauschgenerator sollte sich ja auch als VHDL Block realisieren lassen. Kann es sein, dass nach der ersten Filterstufe kein ausreichendes Restrauschen mehr vorhanden ist, um mit den folgenden Stufen eine Verbesserung der Auflösung zu erzielen? Hast du mal versucht, die erste Stufe rauszunehmen? Also zumindest nach dem was ich über Downsampling weiß, könnte es durchaus sein, dass man an passender Stelle noch mit zusätzlichem Rauschen nachhelfen muss. Viele Grüße nach Österreich Michael
Hallo Michael! Ich habe den Fehler gestern gefunden und behoben! Es war ein kleine versteckte Verwechslung (for Schleife) im SignalSelector, wodurch immer nur die Daten von den ersten 2 Trigger-Kanälen (der Trigger hat vier 8 Bit Kanäle, der DownSampler 2 16 Bit Kanäle) an den Trigger weitergegeben wurden. Jetzt funktioniert es prächtig! Ich kann damit (momentan noch unskaliert) bei 500 µV/div ein fast rauschfreies Signal über den ganzen Bildschirm anzeigen. Einen noch kleineren Wertebereich habe ich noch nicht geschafft, da leider mein Funktionsgenerator weniger Signal nicht zulässt, und ich keine 100:1 Tastköpfe besitze! Der DAC ist das nächste, was ich mir ansehen werde! Mein aktueller Sourcecode mit dem vorkompilierten SOF-File findet man hier. http://github.com/alexvie/welecw2000a Anmerkung: Ich habe Roberts Verbesserungen der Bedienbarkeit vom WaveRecorder noch nicht eingepflegt, dass kommt sobald ich mit dem DAC kommunizieren kann. Viele Grüße an Alle! Alexander
Wozu ein bisschen Regen nicht alles gut ist - da wächst nicht nur das Grünzeug, sondern auch das Leon3 Design... Das klingt ja super, hoffentlich klappt die DAC Kommunikation auch bald. Gruß Michael
Angehängte Dateien:
-
W2000A.sof.gif
19 KB -
sram.bin.gif
25 KB
Hallo Alex und Michael, würde gerne das aktuelle Leon3 in das Ram aufspielen und habe mal das komplette Paket herunter geladen. Die W2000A.sof habe ich gefunden, es wird ja noch die sram.bin benötigt, die in einem anderen Pfad vorhanden ist. Geht das Aufspielen mit dem aktuellen Waverecorder vom Robert wie gehabt? Anbei 2 Screenshots vom Pfad der W2000A.sof und der sram.bin. Vom Erstellungsdatum müssten diese zusammen passen, ist das korrekt? Gruß Michael
Also die sram.bin passt nicht zur W2000A.sof! Erstellungsdatum von beiden Files ist der 25.07.2010 ! Ich habe mal die W2000a.bin (21.05.2010 sram.bin) mit dem Waverecorder 630 KB (21.05.2010) in das Ram geladen! Geht auch nur mit dieser Version. Das Display zeigt wohl alles an, nur bekomme ich kein Signal rein (Probe Comp 1KHz) Wo habt ihr denn die passende sram.bin??? Gruß Michael
Hallo! Ich habe hier beide Dateien zum Testen der HW Filter angehängt. Zum Testen eignet sich ein Frequenzgenerator mit einem HI und einem LO Ausgang hervorragend. Zum Triggern: Der Trigger ist noch nicht umgeschrieben, damit er 4 Bits von den oberen (gemessenen) und 4 Bits von den unteren 8 Bits (erweiterten) triggern kann. Es empfiehlt sich entweder den "Externen Trigger" (Auto Mode) zu verwenden, oder auf einen anderen Kanal mit höherem Signalpegel zu triggern. Zur unausgereiften Software: DC/AC Umschaltung und die Triggerenstellung müssen eingestellt werden, die GUI zeigt anfangs noch falsche Einstellungen. Popup Fenster verschwindet bspw. mit der Mode Coulping Taste. Das Welec hat Störungen und genügend Rauschen in jedem Frequenzbereich, dass ein weiteres Downsampling noch was bringen würde. 10000:1 reicht aber fürs Erste :)! Rest geht in Zukunft mit Software im schaffbaren Roll-Mode! WaveRecorder version sollte egal sein, solange neuer als die vom Preview ist! ProbeComp geht noch nicht! Viel Freude beim Ausprobieren! Alexander
Hallo und guten Abend, wie ihr vielleicht Walters Messprotokoll entnommen habt hat die neue Eingangsstufe einen Stand erreicht, an der sie nicht mehr nur extern getestet werden kann, sondern direkt mit dem Oszi verheiratet werden muss. Dazu ist es notwendig, dass das Oszi die Programmierung der Eingangsstufe übernimmt. Grundsätzlich ist es erst einmal wurscht ob das im NIOS oder im LEON durchgeführt wird, wichtig ist vielmehr dass es irgendwo implementiert wird und getestet werden kann. Das Rauschen ist, wie ebenfalls dem Protokoll von Walter entnommen werden kann, unter Laborbedingungen soweit reduziert worden, dass nun auch vertikale Ablenkungen bis 1mV/div einstellbar sein sollten. Also ein deutlicher Performancegewinn. Daher nun meine Bitte an alle Programmierer die Schnittstelle für die neue Eingangsstufe zu implementieren. Denn leider scheint es hier reichlich ruhig geworden zu sein. Danke, branadic
Angehängte Dateien:
-
screenshot-0000.png
5 KB -
screenshot-0001.png
5,1 KB
Hallo! angeregt durch die Diskussion habe ich auch ein W2012 HW-Version 8C7.0E ersteigert. Beim Testen ist mir aufgefallen das die TB bei 10MSa/s nicht genau stimmt. Bild 1 : CAN-Datentelegramm im Base Frame Format ID 555, 8 Datenbyte mit Wert 0x55, Baudrate 500 Kbit/s zwischen X Cursors genau 83 bit, korrekte Darstellung bei 5MSa/s gezoomt auf 20µs/div Bild 2 : dasselbe noch ein Mal bei 10MSa/s TB-Register 0xFFFFFFF3 -> ca. 9,638 MSa/s default TB-Register 0xFFFFFFF4 -> ca. 10,4 MSa/s Das ist bei der org. FW 1.4 sowie 1.2.BF.1.8 und 1.2-OS-0.92a gleich. Ist das bei euch auch so? Durch weitere Versuche habe ich herausgefunden, das man bei TB-Register 0xFFFFFFF6 ziemlich genau auf 12,5MSa/s kommt. Wenn man jetzt den Faktor 4 auf 5 ändert sollte, alles genau stimmen. Nur da bin ich auf eure Hilfe angewiesen. Ich verwende derzeit den SF trunk (rev317) und weiß einfach nicht was alles zu ändern ist, damit alle modes das auch mitbekommen. An dieser Stelle noch ein herzliches Danke an alle die mit geholfen haben die Firmware zu verbessern. Grüße, jofri
Oha, mal wieder ein Anfänger mit Oszi. Die Zeitbasiseinstellung dieser Geräte gibt man in s/Div an, nicht in S/s. Dann stimmt die Anzeige ganz offensichtlich und du musst dir keine Sorgen machen. Aber mal im Ernst, würdest du die Firmware eines Messgerätes nach dem Takt eines fremden CAN-Signals kalibrieren? Da stimmt ja vllt. das Timing nicht. Das sollte man zumindest mit einem anderen Oszilloskop überprüfen. Gruß, Guido
Hallo branadic, branadic schrieb: > Daher nun meine Bitte an alle Programmierer die Schnittstelle für die > neue Eingangsstufe zu implementieren. Denn leider scheint es hier > reichlich ruhig geworden zu sein. Bert schrieb im Beitrag: #1399962: Beitrag "Re: Wittig(welec) DSO W20xxA Hardware" Da ich mit dem LMH6518 "angefangen" habe, mache ich auch mit. Ich arbeite zur Zeit an einer "eigenen" FW-Version (NIOS) und könnte die Schnittstelle einbauen. Ich würde mein DSO am Kanal 2 (=> für W20x2 und W20x4) umbauen und für diesen Kanal die neuen Eingangsstufe unterstützen. So kann ich die FW testen und zwei Kanäle (alt und neu) miteinander vergleichen. Aber zunächst muss ich mal eine Platine aufbauen und einbauen. Ist das Layout jetzt fix? Ist der aktuelle Schaltplan verfügbar? Gruß Bert
jofri schrieb: > Hallo! > Moin ;) > angeregt durch die Diskussion habe ich auch ein W2012 HW-Version 8C7.0E > ersteigert. Du ärmster ;) > Beim Testen ist mir aufgefallen das die TB bei 10MSa/s nicht genau > stimmt. > > Bild 1 : CAN-Datentelegramm im Base Frame Format > ID 555, 8 Datenbyte mit Wert 0x55, Baudrate 500 Kbit/s > zwischen X Cursors genau 83 bit, korrekte Darstellung bei 5MSa/s > gezoomt auf 20µs/div > Bild 2 : dasselbe noch ein Mal bei 10MSa/s > > TB-Register 0xFFFFFFF3 -> ca. 9,638 MSa/s default > TB-Register 0xFFFFFFF4 -> ca. 10,4 MSa/s > > Das ist bei der org. FW 1.4 sowie 1.2.BF.1.8 und 1.2-OS-0.92a gleich. Hmmm - könnte generell an der Anzeige liegen - und nicht an der Timebase. Hast Du Dir mal 'nen Datendump angesehen und den ausgemessen? > > Ist das bei euch auch so? Mir sind bisher nur Rundungs-/evtl. Zaunlattenfehler aufgefallen, aber ich schau gerne mal nach, wenn ich mit meinen aktuellen Änderungen durch bin. > > Durch weitere Versuche habe ich herausgefunden, das man bei > TB-Register 0xFFFFFFF6 ziemlich genau auf 12,5MSa/s kommt. > Wenn man jetzt den Faktor 4 auf 5 ändert sollte, alles genau stimmen. Wie oben beschrieben, wäre mein Tip, dass die Samplerate selbst bei 10MSa/s liegt, bloß in der Abbildung auf die 20 µs/DIV 'nen Fehler drin ist (nach dem Motto: ich bilde 40 Samples auf ein DIV ab, es müssten aber 42 Samples sein ;). In der Soft wird viel mit Integer gemacht, da kann sowas gut passieren. > Nur da bin ich auf eure Hilfe angewiesen. Ich verwende derzeit den SF > trunk (rev317) > und weiß einfach nicht was alles zu ändern ist, damit alle modes das > auch mitbekommen. Was jetzt alles zu ändern ist, weiß ich so auch noch nicht (bin gerade an der anderen Achse ;) - display_t.cpp dürfte Dein feindlicher Freund sein ;) Mein Vorschlag wäre, da ein Ticket im trac aufzumachen, da kann mensch die entsprechenden Daten besser sammlen - hier könnte das in dem DSO-Source ähnlichen Wildwuchs schnell untergehen. > An dieser Stelle noch ein herzliches Danke an alle die mit geholfen > haben die Firmware zu verbessern. Du gehörst Du jetzt wohl auch zu ;) > > Grüße, jofri Beste Grüße, rowue PS: Windows oder Linux? Wenn Windows: haste 'nen gcc drauf?
Hallo Guido und rowue! >Oha, mal wieder ein Anfänger mit Oszi. Du hast mich sofort durchschaut. >Aber mal im Ernst, würdest du die Firmware eines Messgerätes nach dem >Takt eines fremden CAN-Signals kalibrieren? Da hast Du schon Recht, aber wenn das Abbild des erwartete Signalzeitverhalten bei 25MSa/s und 5MSa/s stimmen und nur bei 10MSa/s nicht, gehe ich davon aus, das Timing des Can-controllers OK ist und eben die Sampelrate nicht. >Wie oben beschrieben, wäre mein Tip, dass die Samplerate >selbst bei 10MSa/s liegt, bloß in der Abbildung auf die >20 µs/DIV 'nen Fehler drin ist (nach dem Motto: ich bilde >40 Samples auf ein DIV ab, es müssten aber 42 Samples sein ;). >In der Soft wird viel mit Integer gemacht, da kann sowas gut >passieren. Ich hab natürlich im Code nach einen Fehler gesucht und nichts gefunden. Glaube aber nicht das bei der Darstellung Fehler sind, zumal beim Zoomen auf andere Zeitbasen entweder der Fehler gleich weitergegeben wird oder eben bei richtiger Signalzeitdarstellung in den unteren Zoom stufen auch nicht auftritt. >Mein Vorschlag wäre, da ein Ticket im trac aufzumachen, da >kann mensch die entsprechenden Daten besser sammlen - hier >könnte das in dem DSO-Source ähnlichen Wildwuchs schnell >untergehen. Da kenne ich mich noch nicht aus. > Windows oder Linux? Wenn Windows: haste 'nen gcc drauf? beides, das zusammenkratzen des CDK war gar nicht so einfach. Grüße, jofri PS: bin jetzt ein paar Tage auf Urlaub.
Bert schrieb: > Da ich mit dem LMH6518 "angefangen" habe, mache ich auch mit. > Ich arbeite zur Zeit an einer "eigenen" FW-Version (NIOS) und könnte die > Schnittstelle einbauen. Ich würde mein DSO am Kanal 2 (=> für W20x2 und > W20x4) umbauen und für diesen Kanal die neuen Eingangsstufe > unterstützen. > So kann ich die FW testen und zwei Kanäle (alt und neu) miteinander > vergleichen. > > Aber zunächst muss ich mal eine Platine aufbauen und einbauen. > Ist das Layout jetzt fix? > Ist der aktuelle Schaltplan verfügbar? > > Gruß Bert Hallo Bert, ist schön wenn du helfen könntest, allerdings stehe ich selbst einer zusätzlich dritten FW-Version etwas kritisch gegenüber. Ist ja schon schade das es zwei Versionen gibt. Jetzt noch eine dritte...? Oder gehe ich da von etwas falschem aus und du baust auf einer der beiden bestehenden FW-Versionen auf? Das Layout enthält noch zwei kleinere Makel, die sich aber leicht umschiffen lassen. Natürlich haben wir noch ein paar Leiterplatten die aufgebaut werden könnten. Die Layoutdaten und den Schaltplan stellen wir erst öffentlich, wenn wir sicher sind das die Leiterplatte den finalen Stand erreicht hat. Vorher macht das einfach keinen Sinn, denke ich. Vielleicht kontaktierst du mich mal direkt: branadic (eddy) user (punkty) sourceforge (punkty) net Gruß, branadic
Ein Hallo an die Programmierer, ich möchte hier kurz noch ein paar Worte zur neuen Eingangsstufe, ihrer Programmierung und was wir für die Messung im Oszi benötigen würden verlieren und gebe daher die Worte aus einem Gespräch in unserer Skype-Gruppe wieder: Für den Anfang würde es helfen den LMH6518 mit dem Datenwort „00050A“ zu initialisieren, was einer minimalen Verstärkung entspricht. Die 3 führenden Nullen (12 binär) bleiben für alle Verstärkungs- und Bandbreitenänderungen konstant. Damit man allerdings auch messen kann wie sich die Einstellungen auswirken, wäre eine funktionierende Signaldarstellung nötig, an der man die Signalamplitude und Form genau ablesen kann. Sonst fehlt die Möglichkeit das Zusammenspiel der Eingangsstufe mit der Oszi-Elektronik zu bewerten. Die Signaldarstellung und der Trigger sollten demnach funktionieren. Ein funktionierender DAC-Abgleich ist eine weitere Voraussetzung. Die Ansteuerung des LMH6518 ist prinzipiell gleich angedacht wie die des LTC2612 der, wie vorgeschlagen, durch den LTC2602 ersetzt werden sollte - eine SPI Schnittstelle mit 24bit Schieberegister. Clock wird an FPGA Y8 bereitgestellt, das Signal liegt invertiert an Pin2 von U27 (LTC2612) vor. Data wird an FPGA Y5 bereitgestellt, das Signal liegt invertiert an Pin2 von U27 an. FPGA U8 (LSB), FPGA T8, FPGA AA13 (MSB) bilden, ebenfalls invertiert, eine 3-bit-Adresse, die die CS bzw Latch aktiviert. FPGA U9 fungiert vermutlich als Enable. Im Fall von U27, dem Offsetabgleich für Kanal 1 und 2, ist das die Adresse 6. Die Adressen 0 (Pin 15 an U25), 1 (Pin 14 an U25), 3 (Pin 12 an U25) und 4 (Pin 11 an U25) sind laut Schaltplan nicht belegt und wurden deswegen für die CS-Ansteuerung des LMH6518 jeweils auf Kanal 1, 2, 3, 4 vorgesehen. Der komplette Datensatz ist jeweils 24 bit für jeden LMH6518. Die CLK für alle 2 bis 4 LMH6518, je nach Modell, liegt auf der gleichen Leitung wie für den LTC2612 und kann z.B. an Pin 3 von U23 abgegriffen werden. Das Datensignal nutzt ebenfalls die gleiche Leitung wie für den LTC2612 und liegt z.B. an Pin 2 des U23 an. Zusammengefasst heißt das, gleiche Programm-Sequenz, Adresse 6 für Offset auf Kanal 1 und 2 wie gehabt, Adr. 0 – für Kanal 1. – LMH6518 Adr. 1 – für Kanal 2. – LMH6518 Adr. 3 – für Kanal 3. – LMH6518 Adr. 4 – für Kanal 4. – LMH6518 vorausgesetzt, der zurückentwickelte Schaltplan ist korrekt. Ich hoffe damit die offenen Fragen gelöst zu haben. Natürlich werden wir diese Info in reduzierter Form auch auf SF setzen. Was die Hardware angeht, so verfügt die Eingangsstufe über die 3-Wire-SPI, diversen Spannungsversorgungen, dem Eingang und dem differentiellen Ausgang. Das derzeitige Layout findet man hier: http://welecw2000a.sourceforge.net/docs/Hardware/Board_V1.1a.png Eine Anschlussbelegung kann ich gerne noch nachreichen, sollte jedoch im Moment nicht zwingend erforderlich sein. Es wäre toll, wenn sich in absehbarer Zeit etwas an der Programmierung zur Eingangsstufe tun würde, weil dann jeder der möchte schneller davon profitieren kann. branadic
Angehängte Dateien:
-
V1.1_Bezeichnung.png
140 KB
Hallo noch mal, ihr Programmierer, im Anhang findet ihr mal ein Bild mit der derzeitigen Anschlussbelegung der Huckepackplatine. Damit sollten wirklich sämtliche notwendige Informationen zur Verfügung stehen, um die Programmierung der neuen Eingangsstufe in einer der Firmwares einzupflegen. Vielleicht kann man beim Start des Oszis mit den Softkeys ja eine kurze Abfrage vorsehen, ob und auf welchem Kanal die originale bzw. neue Eingangsstufe vorhanden ist? Nur so eine Idee. Gruß, branadic
Hallo allerseits, bin gerade aus dem Urlaub zurück und hab mich mal durch die Beiträge gewühlt. Schön zu hören, dass sich an der LEON3 Front was tut. Auch wenn mein erster Versuch das LEON3-Design einzuspielen nicht geklappt hat, bin ich gespannt auf die neuen Möglichkeiten. @Branadic In meinen letzten BF-Versionen gibt es ein Hardwaremenü in dem auch die Anpassung an eine neue Eingangsstufe vorgesehen ist. Hier läßt sich dann sowohl eine entsprechende Skalierung einstellen bzw. die Hardwareansteuerung umstellen. Falls einer der anderen Programmierer da was einbauen möchte böte sich das vielleicht an. Ansonsten könnte ich in Kürze auch etwas dazu beitragen. Mit Rolf wollte ich ja ohnehin beratschlagen ob und wie wir da wieder auf eine Entwicklungslinie kommen, oder wie zumindest die wichtigsten Änderungen in der OS-Version landen. Gruß Hayo
Hallo Hayo, gut zu wissen das es weiter gehen wird. Wie ich schon sagte wäre es schön, wenn schnellstmöglich eine Lösung bereit stehen könnte. Leider gibt es an der LEON-Front noch ein paar Hürden zu meistern, wo die entsprechenden Entwickler jedoch dran sind, wie zum Beispiel die DAC-Ansteuerung. Um schnell abschätzen zu können was die neue Eingangsstufe jedoch kann und wo noch nachgebessert werden muss müssen wir einfach mit dem bestehenden NIOS-Design vorlieb nehmen. Auf lange Sicht jedoch muss der Wechsel auf das LEON-Design erfolgen, aber darin sind wir uns ja alle einig. Das Beste wäre, wenn der LMH6518 bereits beim Booten richtig initialisiert würde und der AUX-Ausgang schnellstmöglich abgeschaltet würde, weil sich die Stromaufnahme des Verstärkers drastisch reduziert und damit auch seine Abwärme. Wir versuchen in einem weiteren Redesign noch mal Fläche für Abwärme vorzusehen, jedoch sollten wir alle nur denkbaren Vorkehrungen treffen die es zu treffen gilt. Keine Ahnung wie sich das sonst bewerkstelligen ließe? Vielleicht ließe sich im Hardwaremenü die neue Eingangsstufe auswählen, jedoch werden die Einstellungen erst nach einem Neustart des Gerätes aktiv? Sämtliche Informationen zur Implementierung habe ich ja bereits bereit gestellt. Das heißt zumindest an fehlender Information mangelt es derzeit nicht :) Gruß, branadic
branadic schrieb: > Hallo Hayo, > Hi Hayo und Branadic, > [Neue Eingangsstufe] meines Erachtens wäre es am besten, wenn auf eine wie auch immer geartete Weise über 'nen Pin abgefragt werden kann, ob da 'ne neue oder eine alte Eingangsstufe am Start ist. Irgendwas über Menues wird immer fies, vorallem, da wir es auch beim Rückstellen auf das Default-Setup beachten müssen. > > Gruß, branadic Grüße, rowue
Hallo Rolf, wird die neue Eingangsstufe mit SPI angesteuert, so kann man am SDIO die aktuellen Einstellungen abrufen. Wenn man also einmal eine Startinitialisierung schreiben würde ließe sich prüfen, ob diese auch so geschrieben wurde. Falls nicht ist die originale Eingangsstufe drin. Wäre das eine Möglichkeit? branadic
Hi Branadic,
Wenn ich Deinen Text oben richtig verstanden habe, werden die
Leitungen für die alten Videoverstärker (U23, Pin 11 und 12)
nicht mehr verwendet, oder? - Rein theoretisch könnte mensch
dann am Anfang das Gerät einmal kurz in einen von der FW definierten
Zustand versetzen (alte Stufe im Modus X, neue Stufe im Modus Y),
1*messen, den DAC "hochschieben", nochmal messen und darüber
feststellen, was für eine Stufe drin ist. Ist zwar "etwas" durch
dir Brust in's Auge, würde aber tendentiell gehen ...
So als anderer Weg ... (von denen, die nach Rom führen ;)
Da müssen wir bloß mit der Summe der Änderungen und den
"Widerstandslötern" aufpassen, dass wir keine "false positives" bekommen
....
(Den DAC würde ich gerne so lassen, wie er ist - den nutze
ich gerade für die Autokalibrierung auf die "Widerstandslöter")
Beste Grüße,
rowue
Rolf W. schrieb: > (Den DAC würde ich gerne so lassen, wie er ist - den nutze > ich gerade für die Autokalibrierung auf die "Widerstandslöter") Hallo Rolf, in den neuen kleinen Spannungsbasen werden wir aber nicht umhin kommen den DAC gegen seinen pinkompatiblen Kollegen auszutauschen. Was insgesamt das Durcheinander mit den Widerstandslötern angeht, so schätze ich doch werden auch diese, sobald denn die neue Eingangsstufe endgültig freigegeben ist, dem Beispiel der Entwickler folgen und diese nachrüsten oder nachrüsten lassen. Sicherlich werden einige am Anfang erst einmal nur einen Kanal tauschen um den direkten Vergleich alt gegen neu zu ziehen. Nicht vergessen dürfen wir dabei jedoch die zusätzlich dazugewonnenen Spannungsbasen 1mV/div, 2mV/div und 5mV/div. Gruß, branadic
branadic schrieb: > Rolf W. schrieb: >> (Den DAC würde ich gerne so lassen, wie er ist - den nutze >> ich gerade für die Autokalibrierung auf die "Widerstandslöter") > > Hallo Rolf, Hi branadic, > > in den neuen kleinen Spannungsbasen werden wir aber nicht umhin kommen > den DAC gegen seinen pinkompatiblen Kollegen auszutauschen. Stimmt - sonst könnte es mit der Null-Kalibrierung schwierig werden ;) > > Was insgesamt das Durcheinander mit den Widerstandslötern angeht, so > schätze ich doch werden auch diese, sobald denn die neue Eingangsstufe > endgültig freigegeben ist, dem Beispiel der Entwickler folgen und diese > nachrüsten oder nachrüsten lassen. Aber wie Du schon meintest benötigt das wohl auch einiges an Geschick und Werkzeug (Mikroskop, etc ;) - dürfte 'ne deutlich andere Hausnummer als die 605 (603?) sein ;) > > Sicherlich werden einige am Anfang erst einmal nur einen Kanal tauschen > um den direkten Vergleich alt gegen neu zu ziehen. Ist von der Kalibrierung her jetzt schon kein Problem ;) > > Nicht vergessen dürfen wir dabei jedoch die zusätzlich dazugewonnenen > Spannungsbasen 1mV/div, 2mV/div und 5mV/div. (Sehr) nett ;) > > Gruß, branadic Grüße, Rolf PS: Bin ab Freitag erstmal 'ne Woche in Kopenhagen (und danach in HH) - also nicht am DSO (und selten am Gerät ;)
moin Rolf, moin Andre, Rolf W. schrieb: > branadic schrieb: >> Rolf W. schrieb: >>> (Den DAC würde ich gerne so lassen, wie er ist - den nutze >>> ich gerade für die Autokalibrierung auf die "Widerstandslöter") >> Autokalibrierung? Wie ist das möglich? Hast du da was zum testen? >> Hallo Rolf, > > Hi branadic, >> >> in den neuen kleinen Spannungsbasen werden wir aber nicht umhin kommen >> den DAC gegen seinen pinkompatiblen Kollegen auszutauschen. > > Stimmt - sonst könnte es mit der Null-Kalibrierung schwierig > werden ;) >> >> Was insgesamt das Durcheinander mit den Widerstandslötern angeht, so >> schätze ich doch werden auch diese, sobald denn die neue Eingangsstufe >> endgültig freigegeben ist, dem Beispiel der Entwickler folgen und diese >> nachrüsten oder nachrüsten lassen. ...handelt es sich hier um die 24 bzw. 33 Ohm und der Abschluß war 150 Ohm, soweit ich mich erinnere? > > Aber wie Du schon meintest benötigt das wohl auch einiges an > Geschick und Werkzeug (Mikroskop, etc ;) - dürfte 'ne deutlich > andere Hausnummer als die 605 (603?) sein ;) die Widerstände im Original sind die 603er, war jetzt kein so großes Problem, diese zu tauschen! Geht aber auch ohne Mikroskop, Lupe mit 3fach u. 10fach Vergrösserung, ginge auch. > >> >> Sicherlich werden einige am Anfang erst einmal nur einen Kanal tauschen >> um den direkten Vergleich alt gegen neu zu ziehen. Vielleicht einigen wir uns auf einen gemeinsamen Wert (24,9 Ohm 1%Tol+ die 150 Ohm abschluß)?!? > > Ist von der Kalibrierung her jetzt schon kein Problem ;) Hardwareoption in der SW von Hayo?!? >> Gruß, branadic > > Grüße, > > Rolf > Gruß Michael
Michael D. schrieb: > moin Rolf, moin Andre, > > Rolf W. schrieb: >> branadic schrieb: >>> Rolf W. schrieb: >>>> (Den DAC würde ich gerne so lassen, wie er ist - den nutze >>>> ich gerade für die Autokalibrierung auf die "Widerstandslöter") >>> > Autokalibrierung? Wie ist das möglich? Hast du da was zum testen? Wie man kalibriert - mensch nehme ein "einigermaßen" genormtes Signal und verwende dies ;) Spass bei Seite: "Releasereif" ist es noch nicht - aber wenn Du möchtest, kannst Du Dir meinen branch aus dem SVN auschecken, compilieren, in Ram laden und damit spielen. Vom Proof of Concept her läuft es, aber es ist noch einiges an Finetuning zu machen. Wenn Du die FW nicht selbst compilieren kannst, bitte kurze PM, dann schiebe ich die mal durch und schicke sie Dir. Aber bitte bedenken: das ist noch keine Release - Fehlermeldungen werde ich ignorieren (außer: Du hast mir das DSO abgefackelt ;) > >>> Hallo Rolf, >> >> Hi branadic, >>> >>> [DAC und Widerstände] > > ...handelt es sich hier um die 24 bzw. 33 Ohm und der Abschluß war > 150 Ohm, soweit ich mich erinnere? Jupp - da kann ich mir schon etwas Bandbreite an verwendeten Widerständen vorstellen. (Da gab es ja auch Kommentare mit 27 Ohm ;) >> > >> [603] Ich war über das USB-Mikro schon ganz glücklich ;) >> >>> >>> Sicherlich werden einige am Anfang erst einmal nur einen Kanal tauschen >>> um den direkten Vergleich alt gegen neu zu ziehen. > > Vielleicht einigen wir uns auf einen gemeinsamen Wert (24,9 Ohm 1%Tol+ > die 150 Ohm abschluß)?!? 1% ist für ein Meßgerät eher über der Obergrenze ... Evtl. geht das auch für eine größere Bandbreite von Widerständen - lass noch mal etwas drüber brüten. >> >> Ist von der Kalibrierung her jetzt schon kein Problem ;) > Hardwareoption in der SW von Hayo?!? Ich meinte eher den o.g. branch. > >>> Gruß, branadic >> >> Grüße, >> >> Rolf >> > Gruß Michael Grüße, Rolf PS: Falls Du intensiver damit spielen willst und z.B. den Screenshot verwenden willst, musst Du letzteren auch einmal aus dem entsprechenden Branch ziehen und compilieren. PPS: Bitte Gerät vor dem Kalibrieren warm laufen lassen.
Nachtrag ... ich habe die Files mal auf meinen Server geladen: https://bone.digitalis.org/dso/ Images von gestern Nacht - danach ist nichts mehr passiert. Wer also damit spielen will, braucht sie nicht zu compilieren. Noch einmal: die ist keine Release. Eher ein "Proof of concept"! Wer damit mehr spielen will und z.B. Datendumps ziehen will, muß sich aus http://welecw2000a.svn.sourceforge.net/svnroot/welecw2000a/pc/w2000a-screenshot/branches/fmf die Screenshot-Sourcen ziehen und selbst durch den Compiler jagen. Ich kann da keine Binaries für Windows zur Verfügnung stellen und nicht mal sagen, ob der Source unter Windows läuft (50/50). Wie beschrieben: das ist keine Release. Beste Grüße, rowue
Hallo Rolf, ich hab's mal gerade ins Ram geladen und die Autokalibrierung gestestet...ist ja abgefahren, was da vor sich geht!!! Was hat es mit "DISPLAY ACCURACY" auf sich? Gruß Michael
Michael D. schrieb: > Hallo Rolf, > ich hab's mal gerade ins Ram geladen und die Autokalibrierung > gestestet...ist ja abgefahren, was da vor sich geht!!! > > Was hat es mit "DISPLAY ACCURACY" auf sich? Eines von den Dingen, die unter dem Punkt Finetuning kommen ... Auflösung und Standardabweichung - Sprich: wieviel mV Du überhaupt noch auflösen kannst und wie stark es rauscht. Beispiel (jetzt aus der Luft gegriffen): (20.41 \pm 30.61) mV sprich: 20.41 mV/Bit mit einer Standardabweichung von 30,61 mV > > Gruß Michael Grüße, Rolf
Hallöchen.... um die Funkstille mal etwas aufzulockern schon mal die Vorabinfo zur nächsten Version. Ihr wisst ja, das die Urlaubszeit keinesfalls Stillstand bedeutet. So wird es auch in Kürze wieder eine Holiday Edition geben. Was ist neu? Die neue Overlay-Funktion ermöglicht es gespeicherte Signale über das aktuelle Signal zu legen, wobei das aktuelle Signal auf die Skalierung und Einstellung des gespeicherten Signals gebracht wird um einen direkten Vergleich zu ermöglichen. Stand: Es funktioniert schon ganz gut, zur Zeit optimiere ich noch Kleinigkeiten wie Farben etc. Kleiner Wehrmutstropfen - das Problem mit den pulsierenden Signalen auf Kanal 3 + 4 (siehe Beiträge zum externen Trigger) ließ sich softwareseitig nicht beheben. Ich vermute dass hier erst der Umstieg auf das LEON3-Design Abhilfe bringen wird. Ich habe an dieser Stelle die Aktivitäten erstmal eingestellt. @Branadic @Stefan Zur Ansteuerung der neuen Eingangsstufe: Rolf hatte die Idee, dass Stefan sich der Sache evtl. annehmen könnte... Stefan - wie wär's damit? Gruß Hayo
Bin gerade auf einen üblen Bug in der Recall-Routine gestoßen, der mir nie aufgefallen ist weil ich lange Zeit nur ein Zweikanalgerät hatte. Beim Speichern und Wiederaufrufen produzieren Kanal 3 + 4 nur Datenmüll!! Dieser Bug stammt noch aus der originalen 1.2 Firmware. Ist das den 4-Kanalgerät Besitzern noch nie aufgefallen? Der Bug ist natürlich in der neuesten Version behoben. Gruß Hayo
Hallo Hayo, in letzter Zeit ist es ja eher ruhig hier geworden und von Stefan hat man ja auch schon lang nichts mehr gehört. Aber mir soll es recht sein, solange es gemacht wird. Was den Bug angeht so muss ich gestehen, dass ich noch auf einer der letzten OS-Firmware-Varianten sitze und deine letzten Versionen gar nicht mehr aufgespielt und getestet habe. Liegt eben auch daran, dass ich nicht mehr "DAS" Verbesserungspotential in der NIOS-Firmware sehe. Die jetzt umgesetzten Routinen werden wohl auch nicht ins LEON-Design portierbar sein. Aber angeregt durch die neuen Oszis von Rohde & Schwarz wollt ich mal nachfragen, ob die FFT nicht grundsätzlich auch am Welec eher in Richtung der Funktionalität eines Spekanalyzers angepasst werden sollte? Also das man, abhängig natürlich von der Samplerate und Timebase, die Centerfrequenz und den Span einstellt. Ich find das im Umgang einfach viel besser als die weit verbreitete Lösung die man in vielen DSOs vorfindet. branadic
branadic schrieb: > Hallo Hayo, > > in letzter Zeit ist es ja eher ruhig hier geworden und von Stefan hat > man ja auch schon lang nichts mehr gehört. Aber mir soll es recht sein, > solange es gemacht wird. Ja mal sehen ob da ein Echo kommt > Was den Bug angeht so muss ich gestehen, dass ich noch auf einer der > letzten OS-Firmware-Varianten sitze und deine letzten Versionen gar > nicht mehr aufgespielt und getestet habe. Der Bug ist schon von Anfang an drin! vermutlich auch in der originalen 1.3 und 1.4 Firmware > Liegt eben auch daran, dass > ich nicht mehr "DAS" Verbesserungspotential in der NIOS-Firmware sehe. Man kann aber schon diverse Funktionen implementieren die dann als Vorlage für das LEON3-Design dienen können > Die jetzt umgesetzten Routinen werden wohl auch nicht ins LEON-Design > portierbar sein. Je noch Hardwareabhängigkeit schon. Zumindest können sie als Vorlage dienen. > Aber angeregt durch die neuen Oszis von Rohde & Schwarz wollt ich mal > nachfragen, ob die FFT nicht grundsätzlich auch am Welec eher in > Richtung der Funktionalität eines Spekanalyzers angepasst werden sollte? > Also das man, abhängig natürlich von der Samplerate und Timebase, die > Centerfrequenz und den Span einstellt. Ich find das im Umgang einfach > viel besser als die weit verbreitete Lösung die man in vielen DSOs > vorfindet. Hier fehlt mir die Erfahrung mit reinen Spektrumanalyzern, hört sich aber interessant an. Da müßte mir jemand auf die Sprünge helfen. Ich kenne nur einige DSO-Implementierungen und reine PC-Softwarelösungen. Gruß Hayo
Hayo W. schrieb: > Da müßte mir jemand auf die Sprünge helfen. Ich > kenne nur einige DSO-Implementierungen und reine PC-Softwarelösungen. Hallo Hayo, mache ich doch gerne :-)).SAs heben einen Search-Modus, in dem die volle Bandbreite um die Mittenfrequenz auf dem Schirm dargestellt wird. So ist es jetzt auch bei der FFT. Zur genaueren Analyse verkleinert man am SA die Bandbreite (stufenweise) und kann dann durch Verschieben der Mittenfrequenz durch das gesamte Band laufen. Dabei nimmt die Auflösung und die Empfindlichkeit gegenüber dem Search-Modus sehr stark zu. Um Letzteres auch auf dem Welec zu implementieren, müsste man aber auf Mehrfachsampling umsteugen, was sicher einen riesigen Azfwand bedeutet. Gruß, Guido
Hallo Guido, danke für die von dir gelieferte Erklärung. Das man keinen vollständigen SpecAnalyser im Welec realisieren kann ist klar. Es geht vielmehr um die Bedienbarkeit der FFT, sprich man gibt die Mittenfrequenz und eine Bandbreite an, die dargestellt werden soll. Die exakte Mittenfrequenz und die Bandbreite ist natürlich nur im Rahmen der Zeitbasis und Samplerate einstellbar, aber dennoch ist diese Form der Bedienung deutlich zweckmäßiger als die aktuell implementierte FFT. branadic
Hi branadic, wenn ich mich recht entsinne, funktioniert aber der Cursor in der FFT. Damit kommt es dem Search-Modus schon recht nahe. Aber wir wollen ja besser werden als die anderen. ;-) Gruß, Guido
Hallo Hayo, aus meiner Sicht ist das Problem beim "Recall" nicht aufgefallen, weil keiner die so implementierten Funktion braucht. Sie taugt nur, um 1. Settings zu speichern (mitgespeicherte Kurven bedeutungslos) 2. Meßkurven zu archivieren (macht mein PC) Was fehlt sind Overlays einzelner Traces, d.h. die visuelle Vergleichsmöglichkeit zwischen gespeicherten Kurven, die dann auch unabhängig vom Original-Offset vertikal verschiebbar sein sollten und neuen Messungen. Derzeit hat man entweder nur gespeicherte Kurven (bzw. bei Chan 3/4 auch nicht) oder nur neue Messungen auf dem Schirm. Andere Baustelle (1.2.BF.1.8): Was ist eigentlich mit der "Holdoff" Einstellung. Bei z.B. 4s Holdoff und kontinuierlichem Signal (hor. 10ms/div) sollte ca. alle 4 s eine neue Erfassung stattfinden. Der Holdoff-Wert wird aber anscheinend ignoriert. Gruß Rainer Hayo W. schrieb: > > Beim Speichern und Wiederaufrufen produzieren Kanal 3 + 4 nur > Datenmüll!! > > Dieser Bug stammt noch aus der originalen 1.2 Firmware. Ist das den > 4-Kanalgerät Besitzern noch nie aufgefallen?
Hallo zusammen, ich hätte noch eine kleine Unschönheit zu vermelden... Beim Umschalten zwischen 500ms/div und 1s/div wird ja der Trigger nicht mehr benutzt und ausgeblendet (scan). Dabei geht bei der Mode-Einstellung irgendwas schief. Wenn "Combi" eingestellt war, tauchen beim Verlassen des Scanbetriebs 2 ausgewählte Modi auf (Haken gesetzt). Ändern führt zu merkwürdigem Auswahlverhalten. Viele Grüße, rha
Rainer W. schrieb: > Hallo Hayo, > > aus meiner Sicht ist das Problem beim "Recall" nicht aufgefallen, weil > keiner die so implementierten Funktion braucht. oder zumindest nur selten nutzt -> ich gebe Dir recht, das sehe ich auch so > Sie taugt nur, um > > 1. Settings zu speichern (mitgespeicherte Kurven bedeutungslos) > 2. Meßkurven zu archivieren (macht mein PC) > > Was fehlt sind Overlays einzelner Traces, d.h. die visuelle > Vergleichsmöglichkeit zwischen gespeicherten Kurven, Auch da hast Du recht, deswegen gibt es in der neuen Version die Overlay Funktion, bin gerade in den letzten Zügen mit den Optimierungen. > Andere Baustelle (1.2.BF.1.8): Was ist eigentlich mit der "Holdoff" > Einstellung. Bei z.B. 4s Holdoff und kontinuierlichem Signal (hor. > 10ms/div) sollte ca. alle 4 s eine neue Erfassung stattfinden. Der > Holdoff-Wert wird aber anscheinend ignoriert. Ich gebe zu, dass ich das etwas aus den Augen verloren habe durch den "Kanal 3 + 4 blinking Bug". Werd ich mir mal als nächstes ansehen, da es ja eine nicht ganz unwichtige Funktion ist. > ich hätte noch eine kleine Unschönheit zu vermelden... > Beim Umschalten zwischen 500ms/div und 1s/div wird ja der Trigger nicht > mehr benutzt und ausgeblendet (scan). Dabei geht bei der > Mode-Einstellung irgendwas schief. Wenn "Combi" eingestellt war, tauchen > beim Verlassen des Scanbetriebs 2 ausgewählte Modi auf (Haken gesetzt). > Ändern führt zu merkwürdigem Auswahlverhalten. Ok, werd ich mir ansehen und beheben. Gruß und danke für die Hinweise Hayo
Hallo Hayo! Rainer W. schrieb: > aus meiner Sicht ist das Problem beim "Recall" nicht aufgefallen, weil > keiner die so implementierten Funktion braucht. Sie taugt nur, um Das ist mir wohl zu stark vereinfacht! > 1. Settings zu speichern (mitgespeicherte Kurven bedeutungslos) OK, kann sein. > 2. Meßkurven zu archivieren (macht mein PC) Hier ist diese Funktion unser eingebauter "USB-Stick". Ich will eben auch unabhängig von einem PC sein, und gegebenenfalls später erst die Kurven speichern. Ein Problem/Bug in der Firmware ist, wenn ich das richtig gesehen habe, daß der vorgegebene Bereich von 64k per Kurve beim 4-Kanaler nicht mehr zum Speichern der Einstellungen reicht. ( 4 x ca 300 Byte = ca. 1200 Byte per Kurve für Einstellungen + 4 x 16k Daten) Vielleicht kannst Du die Einstellungen für die Kurven in einen obersten z.B. 128k Bereich verfrachten und dafür etwas weniger Speicherungen zulassen? Bzw. hast Du sicher schon eine Lösung :-) Die Overlay Funktion greift ja wohl "nur" auf die gespeicherten Daten zu und widerspricht nicht dem Save/Recall. Gruß Jürgen
Hi Jürgen, das hast Du richtig beobachtet. Die Traces werden jeweils in einem Sektor abgespeichert, der aber mit 64 kb gerade für die Signale reicht. Die Idee von Welec (die ich auch erstmal übernommen habe) war, die Daten an das Ende des vierten Kanals dranzuhängen. Da fehlen dann halt 1200 Werte (300 * 4 byte). Leider haben die das aber nicht richtig hingekriegt. Ich hab das jetzt erst mal korrigiert und lösche die Werte bei der Ausgabe wieder, damit es am Signalende nicht so ein Rumgezackere gibt. Andere Lösungen wären erstmal deutlich aufwändiger - fragt sich ob der Nutzen den Aufwand rechtfertigt. Wie seht Ihr das? Bislang hat ja noch nicht mal jemend gemerkt das die beiden unteren Kanäle überhaupt nicht funktionieren. Gruß Hayo
Hi Hayo, > das hast Du richtig beobachtet. Die Traces werden jeweils in einem > Sektor abgespeichert, der aber mit 64 kb gerade für die Signale reicht. > Die Idee von Welec (die ich auch erstmal übernommen habe) war, die Daten > an das Ende des vierten Kanals dranzuhängen. Da fehlen dann halt 1200 > Werte (300 * 4 byte). Aus Symmetriegründen wäre ich dafür, die Einstellungen jeweils am Ende des zugehörigen Kanals zu speichern. Der kleine Verlust wäre imo zu verschmerzen. > Andere Lösungen wären erstmal deutlich aufwändiger - fragt sich ob der > Nutzen den Aufwand rechtfertigt. Hat das Fehlen von Daten am Ende eigentlich ärgerlich Konsequenzen bei der FFT (2^x-Blöcke o.ä.)? @Jürgen: Meine Einwände gegen die Welec-Recall Funktion waren sicher etwas überspitzt. Die 100 speicherbaren Kurven fände ich interessant, wenn man die für das automatische Speichern seltener Ereignisse nutzen könnte, d.h. Trigger auf ein Event und automatisches Sichern in fortlaufendem Speicherplatz.
Hi Hayo, Hayo W. schrieb: > Andere Lösungen wären erstmal deutlich aufwändiger - fragt sich ob der > Nutzen den Aufwand rechtfertigt. Du hast recht.Ich hatte nicht beachtet, daß sich der Flashbaustein nur in 64k-Sektoren löschen lässt. D.h. man muss bei z.B. 2 x 64k Sektoren am oberen Ende zuerst entscheiden,in welchen Sektor man schreiben muss - diesen auslesen und puffern - Daten ändern und zurückschreiben. Ich hatte erst angenommen, man kann 2k - Sektoren ändern. Wäre aber schon die saubere Lösung... :-) @rawi Das ist natürlich der Luxus! Aber es gibt riesige Pausen bei der Signalbeobachtung in der Zeit des Abspeicherns und man knallt sich bei eher periodischen Signalen ev. unbeabsichtigt sehr schnell den Speicher voll mit gleichen Signalverläufen.
Angehängte Dateien:
-
Overlay_01.jpeg
68 KB -
Overlay_02.jpeg
55 KB
Hi, das sind natürlich alles ganz nette Guties. Ich werde erstmal die neue Funktion veröffentlichen und dann die Reaktionen abwarten. Wenn da tatsächlich Bedarf an ausgefeilten Funktionen besteht kann ich ja noch nachlegen. Anbei einige Screenshots der neuen Funktion. Was ich mir auch schon überlegt habe ist eine Inlay-Funktion, die nicht wie die Overlay Funktion das gespeicherte Signal in den Originalfarben über das eingefrorene Live-Signal legt (wie auf den Screenshots) sondern das gespeicherte Signal unter das aktiv laufende Live-Signal legt. Gruß Hayo
Angehängte Dateien:
-
screenshot-0002.PNG
3,6 KB -
screenshot-0001.PNG
3,6 KB
Hi Hayo, wenn du schon am nachlegen bist, dann könntest du doch evtl. die Autokalibrierung von Rolf mit einbauen??? Ich habe diese getestet und bin begeistert von diesem "Feintuning" ! Der Link zu Rolf's Server mit der Flashram ist hier: https://bone.digitalis.org/dso/ oder ich setze es mal als Download-Paket (inkl. GermsLoader, Screenshot) hier rein. Die Screenshotfunktion geht, ansonsten werden im QM-Modus einige Messungen nicht richtig wieder gegeben...hatte Rolf ja angegeben, das das Image noch nicht Releasefähig ist! (Rolf, ich hoffe, das du nichts dagegen hast) Rolf hat diesbezüglich eine tolle Arbeit geleistet, ein fettes Lob an dieser Stelle. Ich dachte nicht, das eine Automatisierung der Nulllinienkalibrierung möglich ist ...ein äusserst nützliches Tool, spart eine Menge Zeit und ist sehr effektiv! Anbei ein paar Screenshots: 1. vor der Kalibrierung 2. nach der Kalibrierung Es werden alle Kanäle automatisch nach einander Kalibriert, feine Sache. Gruß Michael
Michael D. schrieb: > Hi Hayo, > > wenn du schon am nachlegen bist, dann könntest du doch evtl. die > Autokalibrierung von Rolf mit einbauen??? Ich habe diese getestet und > bin begeistert von diesem "Feintuning" ! Hi Michael, Rolf hatte den Status der Routine als "under construction" angegeben. Daher habe ich hier noch nicht weiter geforscht. Wenn ich mich mit Rolf treffe (nächste Woche) werde ich das mal klären. Wenn das Ganze gut funktioniert und von Rolf freigegeben ist werde ich das selbstverständlich übernehmen. @Rainer Der Menü-Bug beim switchen zwischen USTB und Normal ist gefixed. Gruß Hayo
Puh, jetzt bin ich gerade in den letzten Zügen mit der neuen Version, da macht der Netzschalter an meinem 4-Kanalgerät jetzt auch die Grätsche - zum Glück hab ich ja den neuen Schalter schon liegen. Gruß Hayo
Hayo W. schrieb: > macht der Netzschalter an meinem 4-Kanalgerät jetzt auch die Grätsche - > > zum Glück hab ich ja den neuen Schalter schon liegen. Hayo, ich hab gar kein Problem mehr mit dem Netzschalter. Habe allerdings die hier Beitrag "Re: Wittig(welec) DSO W20xxA Hardware" genannte Schraube nachgerüstet. Kann ich wirklich empfehlen! Gruß Jürgen
...wie doof ist das denn? Mußt Bis jetzt habe ich mit meinem Schalter noch Glück gehabt! Wenn du noch welche brauchst, hier liegen noch ein paar rum!!! Ich denke, das man die Kalibrierroutine nicht so einfach in das Image einsetzen kann, oder? ...könnte ich nur programmieren, würde ich das mal probieren(mergen?), schade eigentlich! Bin mal auf deine neue Release gespannt oder gibt das eine Preview? Gruß Michael
Zum Schalter - da hattest Du mir ja zwei zukommen lassen. Der im 2022A funktioniert auch einwandfrei. Im 2024A hatte ich noch den originalen dringelassen, der macht jetzt schöne Britzelgeräusche und zwischendurch geht das Gerät auch ganz aus. Das Wird ein neues Release (1.2.BF.1.10HE) @Jürgen Keine Angst, Dein Schalter wird auch noch abrauchen, die sind ganz einfach Billigschrott. Was ist das mit der Schraube? Gruß Hayo
...jo, würde mich auch interessieren, was das mit dem Schalter, Schraube auf sich hat?!? Gehört zwar in den HW-Thread... Ich hatte mal an der Netzeingangsbuchse (Kaltgeräte) eine Schraube mit Mutter ergänzt, vielleicht wurde die auch nur vergessen? Wie auch immmer, mir scheint die Netzbuchse jetzt ewas stabiler zu sitzen! Welche Neuerungen(Änderungen) in der 1.2.BF.1.10HE sind gemacht? Vielleicht eine kurze Erläuterung? Gruß Michael
Hayo W. schrieb: > Keine Angst, Dein Schalter wird auch noch abrauchen, die sind ganz > einfach Billigschrott. Ich hoffe doch nicht! > Was ist das mit der Schraube? Siehe Bild.( leider bloß vom Handy ) Ich hatte den Eindruck, daß das ganze Chassis beim Betätigen des Schalters nach hinten ausweicht und so das "Gebritzel" entsteht. Das Blechchassis wird am vorderen Kunststoffgehäuseteil festgeschraubt. Ihr könnt es ja mal probieren. Grüße
Nein das Gebritzel entsteht ganz eindeutig im Schalter. Ich hatte den alten Schalter mal auseinandergenommen, wie es darin aussah wollt Ihr nicht wissen... Hayo
So da ist sie, die Holiday Edition. Der Urlaub muß ja auch für was gut sein ;-) Was ist neu? - die Overlay Funktion - Bug im Speichermangement beim Save/Recall gefixed - Timebase switching USTB <-> Normal überarbeitet, Bug gefixed Zum Overlay: Das gespeicherte Signal wird in den Standrdfarben dargestellt und über die aktuellen Live-Signale gelegt die in gelb/grau dargestellt werden. Das aktuelle Live-Signal wird auf die gleichen Einstellungen gesetzt wie das gespeicherte Signal. Alle sinnvollen Aktionen sind in diesem Modus möglich (Timebase, Math, Cursor etc.) Einfach ausprobieren und wie immmer bitte Eure Erfahrungen rückmelden. Gruß Hayo
Hayo W. schrieb: > Nein das Gebritzel entsteht ganz eindeutig im Schalter. Ich habe dem ja nicht widersprochen!
@Jürgen, das mit der Ecke ist trotzdem eine gute Idee, werd ich gleich mal nachrüsten wenn ich den Schalter austausche. Hayo
Hayo W. schrieb im Beitrag: > So da ist sie, die Holiday Edition. Der Urlaub muß ja auch für was gut > sein ;-) > ...da hat sich 'Frau' bestimmt gefreut...:)) > > Was ist neu? > > - die Overlay Funktion > - Bug im Speichermangement beim Save/Recall gefixed > - Timebase switching USTB <-> Normal überarbeitet, Bug gefixed > > Zum Overlay: > > Das gespeicherte Signal wird in den Standrdfarben dargestellt und über > die aktuellen Live-Signale gelegt die in gelb/grau dargestellt werden. > Das aktuelle Live-Signal wird auf die gleichen Einstellungen gesetzt wie > das gespeicherte Signal. Alle sinnvollen Aktionen sind in diesem Modus > möglich (Timebase, Math, Cursor etc.) > ...schön, wenn man weiß, was drinnen ist. :) Was macht das USB-Interface? > > Einfach ausprobieren und wie immmer bitte Eure Erfahrungen rückmelden. > > Gruß Hayo Hayo W. schrieb: > @Jürgen, > > > > das mit der Ecke ist trotzdem eine gute Idee, werd ich gleich mal > > nachrüsten wenn ich den Schalter austausche. Ist ja'n Ding! ...nach dem ich das Teil schon zig mal zerlegt hatte, dachte ich, das diese verloren gegangen sei und hab da eine aus der Bastelkiste reingeschraubt! Dann haben Die die einfach weggelassen? Gruß Michael
Hallo Allerseits, inzwischen ist die dritte und allem Anschein nach letzte PCB Version fertig designed und wird in wenigen Tagen bestellt. Hiermit bieten wir allen die an der SW-Entwicklung beteiligt sind die Möglichkeit an dieser Bestellung zu partizipieren. Die Abmessungen der Platine sind 17x22mm. Ein Bild des vorerst finalen Layouts findet ihr unter: http://welecw2000a.sourceforge.net/docs/Hardware/Board_V1.2.png Die Kosten für eine Leiterplatte schätzen wir auf 3,-€/Stück inkl. der Versandkosten für den Versand in einem Briefumschlag. Wer sich an dieser Bestellung beteiligen möchte hat bis zum 25.08.2010 Zeit sich unter branadic [at] user (punkt) sourceforge {punkt} net zu melden. Ihr bekommt dann noch am 25.08.2010 abends eine Mail mit den Kontodaten und habt dann bis zum 30.08.2010 Zeit das Geld zu überweisen. Nach dem 25.08.2010 können keine weiteren Bestellungen mehr berücksichtigt werden. Die Leiterplatten werden vorraussichtlich am 27.09.2010 fertig gestellt sein und dann versandfertig gemacht. Ich möchte ausdrücklich darauf hinweisen, dass die Leiterplatten mit SMD-Bauteilen bestückt werden müssen. Bauteilgrößen sind über 0603 und 0402 auch SOT23-5 (Spannungsregler), LLP16 (LMH6518), µSOP8 (MAX4477), SC70-3 (SI1300) und M04 (NE3508). Ihr solltet also die Fähigkeiten und Möglichkeiten besitzen solche Packages auch zu verarbeiten. Wer diesbezüglich unsicher ist sollte einen Blick auf die Messprotokolle von Walter und mir werfen. An dieser Stelle möchte ich mich auch für die großartige Zusammenarbeit mit Walter bedanken und uns die Daumen drücken, dass wir bald die Möglichkeit erhalten werden die Eingangsstufe unter realen Bedingung zu testen. branadic
Hallo branadic, ich wollte dir eigentlich eine Email senden, leider kommt die aber zurück. Deshalb hier noch einmal: Hallo branadic, ich möchte bitte zwei von euren Platinen bestellen. Die Überweisung wird bei mir leider sehr knapp, weil ich erst am 28.08. abends aus dem Urlaub zurückkommen werde (morgen geht's los)... falls das Geld dann noch nicht angekommen ist, wäre es super, wenn du noch einen Tag länger warten könntest - das Geld kommt auf jeden Fall. Oder du schickst mir gleich die Kontodaten, dann schaffe ich morgen noch die Überweisung. Ich bin sehr gespannt auf das Ergebnis eurer Arbeit, die mir recht vielversprechend aussieht. Gruß Michael
Fehler meinerseits, da ist mir ein "s" appanden gekommen. Ich werde
keinerlei Bestellungen hier im Forum entgegennehmen, ansonsten verliere
ich den Überblick. Ich denke das versteht ihr.
Die Mailadresse ist branadic {ed} users (punkt) sourceforge [punkt] net
branadic
Hallo branadic also wird es später noch eine weitere Sammelbestellung geben? Mfg, Kurt
Hallo Kurth, ich sag mal so, könnte sein muss aber nicht sein. Wenn die Leiterplatte wirklich so funktioniert wie gewünscht werde ich keine mehr brauchen und Walter auch nicht. Daher kann ich keine feste Zusage machen. Die Board-Files werden dann aber öffentlich gestellt, sodass da zur Not auch jemand anderes etwas organisieren könnte. Vielleicht noch ein Hinweis am Rande: Die Leiterplatten haben eine Dicke von 0,4mm zzgl. Kupferauflage. Dünnes Basismaterial ist notwendig, weil wir zwischen Gehäuse und Mainboard nicht sehr viel Platz haben und die Bauteile auch noch etwas an Höhe schlucken. Das Board kommt nämlich auf die ADC gegenüberliegende Seite des Mainboards. Es geht also ziemlich eng zu. Nicht jeder Lieferant verarbeite so dünnes Basismaterial und das auch noch zu günstigen Konditionen. Daher werden die Leiterplatten auch in Bulgarien gefertigt. Das sollte für euch aber nicht das Entscheidungskriterium sein. branadic
Michael D. schrieb: > Hi Hayo,fo > Hi Michael .... > wenn du schon am nachlegen bist, dann könntest du doch evtl. die > Autokalibrierung von Rolf mit einbauen??? Ich habe diese getestet und > bin begeistert von diesem "Feintuning" ! > Der Link zu Rolf's Server mit der Flashram ist hier: > > https://bone.digitalis.org/dso/ > Sonst finden sich die Sourcen auch im SVN ;) Allerdings habe ich auch nicht ohne Grund geschrieben, dass das Ganze noch nicht releasefähig ist, da dürfte noch locker eine Grössenordnung (10'er Potenz) an "Genauigkeit" drin sein ... (Von evtl. Fehlanpassungen )abgesehen, dass Konzept hat sich halt einmal komplett geändert ;) Anyway - wie dem auch sei, Hayo und ich werden uns nächste Woche mal zusammensetzen und sehen, ob und wie es gemeinsam weitergeht - gerade bin ich durch die Veranstaltung hier einfach etwas zu sehr unter Last. Hayo sieht das Glücklicherweise ähnlich wie ich ... > {...] > > Gruß Michael Beste Grüße, rowue
Hayo W. schrieb: > Was ich mir auch schon überlegt habe ist eine Inlay-Funktion, die ... > das gespeicherte Signal unter das aktiv laufende Live-Signal legt. Fände ich absolut gut!!! Rainer
Michael D. schrieb: > Hayo W. schrieb im Beitrag: >> So da ist sie, die Holiday Edition. Der Urlaub muß ja auch für was gut >> sein ;-) >> > ...da hat sich 'Frau' bestimmt gefreut...:)) Ja, vor allem, da sie dass (!!!!!!!!!) erst nach der Rückkehr erfahren hat! :-) Gruß Ehefrau Petra.
Joo, aber jetzt ist sie beim Fernsehen und ich hab gerade den Überknüller rausgefunden -> siehe HW-Thread.
He, alle an der Ostsee? 32 Downloads und noch keine Rückmeldung? Ist alles so perfekt, dass es nichts zu berichten gibt? Kann ich mir ja nicht so richtig vorstellen... Sag mal einer was zu der aktuellen FW. Oder ist die Funktion eher nicht so interessant? Haut ruhig Eure Meinung raus, ich bin mental stabil... Hayo
Hallo zusammen, all diejenigen die mich bisher wegen Leiterplatten angeschrieben haben dürften eine Mail mit einem Formular vorgefunden haben, in dem auch die Kontodaten zu finden sind. Wer noch Leiterplatten bestellen möchte, den bitte ich mich nur kurz anzuschreiben dss Ihr Leiterplatten wollt, mehr Text ist nicht notwendig. Ihr werdet darauf hin von mir eine Mail mit dem Formular bekommen, dass ihr mir dann ausgefüllt zurückschickt. Das wahrt die Übersichtlichkeit und macht es mir einfacher. Einen schönen sonnigen Sonntag ;) branadic
Hi guys, Hayo, branadic, Rolf W., Michael D., Rainer W., Jürgen and all. Thank all You very much for the hard work done, as always a really great job!!! Now I would not overstate but recently I had occasion to use a WaveAce 224 DSO by LeCroy and it was not so superior to my W2022A! Is true, the LeCroy tigger is better, more stable, but the noise is incredibly high, especially on the scale "2" and although the total screen's area is 1/4 than Welec (320x240 pixel resolution against 640x480). Then even after warmed up changing the VOLT/DIV's scale on the WaveAce the signals are dancing and their offset are not correctly. The VOLT/DIV's accuracy is greater in WaveAce but the W2022A's time base is a little better than LeCroy. Of course the WaveAce's automatic measurements are more sophisticated as well its generals ability but generally the W2022A can replicate most of them. I can say that thanks to your work You are able to make the Welec/Wittig's DSO competitive with what the market currently offers, so again many thanks to all, really thanks very much to all You!!! Vielen Dank!!! Luc p.s. in the 1.2.BF.1.5's version was introduced the new RMS calculation for Quick Measure warning that the new routine is a little bit slower because of the additional calculations but the speed may be increased by exchanging the multiplications with shift operations, which was not made for lack of available's time. Now has someone the time?
Hi Luc, that is an interresting comparison for LeCroy is a big player in the DSO scene and the price for this devices is much higher than for our Welec. So I think we don't have to be unhappy about our choice to buy this device from Welec and we will be motivated to optimize it in future. By the way - did You test the new overlay function in the 1.10 HE? What do You think about it? Regards Hayo
Hallo Hajo und all ihr anderen Weltverbesserer, nein im Ernst, das DSO ist seit ihr am Werke seid brauchbarer geworden. Trotzdem freu ich mich auf jenen Punkt, wo es auch wirklich das tut, was man gerne von ihm hätte. Habe die neueste Version 1.2.BF.1.10.HE aufgespielt. Die Overlayfunktion funktioniert bei mir nicht einwandfrei. Aber vielleicht mach ich ja was falsch. Auf Wunsch beschreibe ich gerne Näheres dazu. Aber eines der wichtigsten Features, die man vom DOS gerne hätte, ist bei mir die Darstellung einzelner Signalimpulse, was bei mir nach wie vor nicht möglich ist. Beispiel: Ein Resettaster über einen Widerstand an Plus wird gedrückt um das Prellverhalten zu messen. Das DSO auf negative Flanke eingestellt, der Mode auf "normal" und Run (grüne Taste). Drücken der Resettaste - keine Reaktion. Auf Stop und dann auf Single gedrückt löst der Trigger nach weniger als einer Sekunde auch ohne ankommende negative Flanke aus. Der Triggermode hat auf "auto" umgestellt. Auch andere Triggermodi und Kombinatinen bieten keine Möglichkeit, das Prellen zu sehen. Dagegen funktioniert das Triggern bei periodischen Signalen (Probe-Signal) einwandfrei. Was ich nicht verstehe: bin ich der einzige, bei dem solches nicht funktioniert, sonst müssten doch andere auch schon darauf hingewiesen haben. Da ich weiß, wie komplex diese Materie ist, gilt meine Bewunderung trotzdem dem Einsatz von euch allen. Dafür ein herzliches Danke.
Angehängte Dateien:
-
screenshot-0000.png
3,7 KB
Hallo Hayo, Manfred H schrieb: > Beispiel: Ein Resettaster über einen Widerstand an Plus wird gedrückt um > das Prellverhalten zu messen. Das DSO auf negative Flanke eingestellt, > der Mode auf "normal" und Run (grüne Taste)..... Im Bild ein Resettaster mit gleichen Einstellungen. Und ja, es ging beim ersten Mal nicht! Keine Triggerung. Das hängt sicher mit der Reihenfolge der Betätigung der Tasten am Oszi zusammen. Habe aber keine Vorstellung nach welchem Zustand welcher Variablen ich dabei suchen muss, wenn es wieder mal nicht funktioniert ;-) Habe mit der Triggerung sowieso ein Problem: Z.B. gefällt mir die Bedienungsreihenfolge -STOP-Single- überhaupt nicht! Die HP-Oszis nehmen immer ein einfaches Betätigen des -Single- Tasters an. Dies ist sehr praktisch, da man normalerweise "alle Hände voll zu tun" hat, wenn ein Problem zu beheben ist und schnell mal ein Bild zur weiteren Analyse zu machen ist. Aber gut Ding will eben Weile haben! Wird schon noch! Jürgen
Hallo Jungs, danke für das Feedback! @Manfred - was genau funktioniert denn nicht beim Overlay? Bin da auf genaue Beschreibungen angewiesen, damit ich entsprechend reagieren kann - warum benutzt Du nicht den Single Shot wie Jürgen? Das genannte Szenario habe ich so auch noch nicht nachgestellt. Muß ich mal testen. @Jürgen Wie genau ist denn beim HP die Bedienlogik bei Stop und Single-Shot? Ich dachte eigentlich, dass das so eher den Praxisanforderungen gerecht wird. Ich ändere das aber gerne wennn dem nicht so sein sollte. Gruß Hayo
moin moin Hayo das mit start/stop/single ist (fast) ok, ich denke aber mich zu errinern das beim agilent6032 auf der arbeit der umweg ueber stop nicht noetig ist dh. im run-mode drueckst du single ohne vorher in stop wechsen zu muessen aber eine andere sache, stell mal 10ms/div ein und gib 100mv 50hz drauf (finger am tastkopf) und schalte dann mal um auf 1s/div oder mehr, iss schon komisch was da kommt, oder ? (hab noch die 1.8 drauf) vlg Charly
Hallo Leute, noch mal die Bitte an alle, prüft eure Mailkonten und schickt mir das Bestellformular ausgefüllt zurück. Jeder der mich bisher angeschrieben hat hat dieses von mir zugeschickt bekommen. Mittwochabend ist "Einsendeschluss". branadic
Hallo Hayo,
> Wie genau ist denn beim HP die Bedienlogik bei Stop und Single-Shot?
Die Umschaltung von Dauererfassung auf Singleshot könnte noch einfacher
sein. Wenn das DSO auf RUN steht und man auf Single Shot wechseln
möchte, muß man immer erstmal auf STOP drücken und kann es dann mit
SINGLE in Meßbereitschaft versetzen.
Ich stelle mir vor:
- DSO steht auf RUN (grün)
- Taste SINGLE -> Scope geht (automatisch) auf STOP und gleich in
Meßbereitschaft.
Rainer
@Rainer + @Charly Ok, das läßt sich machen. Werde ich mal beim nächsten Release berücksichtigen. @Charly bin gerade in der Firma und kann das nicht nachstellen, was kommt denn da bei 1 s/Div oder was kommt nicht? Gruß Hayo
Hallo zusammen, ich habe gerade mal mit der "Single" Messung gespielt. Ich gehe davon aus, dass eigentlich eine Messung beim Erkennen des Triggers ausgelöst werden soll, aber... Beim Stop läßt sich die Zeitbasis nicht wirklich verändern (kürzere Zeiten werden nicht erreicht). Dabei springt der eingeblendete Balken mit dem Triggericon komisch. Wenn man als Signal einfach das 1kHz Signal aus dem Oszi nimmt, kann man schnell feststellen, das das Triggern nicht wirklich zuverläßig funktioniert. Es löst aus, ohne das das Signal hinterher den Schluß zuläßt warum. Ferner kann mann mit dem 1kHz Signal beim Verlängern der Zeitbasis schön sehen, wie Schwebungen entstehen, d.h. es erscheint beim langsamen Abtasten die Schwebung aus dem Signal und der Abastrate. Schöner wäre, wenn man erkennen könnte, dass das Signal zu schnell für die Abtastrate ist. Viele Grüße, Rainer
Liebe Gemeinde! Ich kann nun die DACs über den LEON3 ansteuern. Der Fehler lag meist nur darin, dass die DAC Ansteuerung einen großen Offset vom Offset aufweist und die Drehknöpfe von minderer Qualität sind. Aus diesem Grund muss ich nun eine Kalibrierung implementieren. Ich kann mir zwar schon gut vorstellen, wie ich das machen werde, trotzdem würden mich vorher ein paar Codebeispiele interessieren, damit die Genauigkeit und die Zeitdauer in einen optimalen Rahmen liegen. Mann muss nicht alles selbst neu erfinden! Ich möchte diesbezüglich auf ein gravierende negative Auswirkungen hinweisen, falls man auf Signale triggern will, die kleiner als das LSB vom ADC sind (Das LEON Design kann das Grundsätzlich). Unter Umständen muss man da den mysteriösen Mux in der Eingangsplatine vom offenen Eingang auf den gefilterten PWM-Digitalausgang des FPGAs stellen, damit sich der DC-Offset beim Einschalten der HW-Filter nicht zu stark ändert. @branadic Mir gefällt die FFT vom Yokogawa DLM2054 auch sehr gut, da kann man selbst das Sichtfenster (Frequenzmitte, Frequenzstop) in einem sehr weitem Bereich einstellen. Bessere Ergebnisse erreicht man jedoch wenn man eine Oberschwingungsanalyse macht (DFT, die sich auf die Grundfrequenz synchronisiert). Das hat das DLM2054 auch, jedoch nur für 50 oder vielleicht auch 60 Hz. Damit kann man eine Abnahme von kleinen PFC Strömen machen. MfG Alexander
>Zur Ansteuerung der neuen Eingangsstufe: >Rolf hatte die Idee, dass Stefan sich der Sache evtl. annehmen könnte... >Stefan - wie wär's damit? Ab Oktober könnte es evtl. was werden. Vorher gehts wirklich net. Zuviel zu tun :-( Gruß, Stefan
Rainer H. schrieb: > Hallo zusammen, > ich habe gerade mal mit der "Single" Messung gespielt. Ich gehe davon > aus, dass eigentlich eine Messung beim Erkennen des Triggers ausgelöst > werden soll, aber... korrekt, tut es auch. Hab es gerade geprüft. > Beim Stop läßt sich die Zeitbasis nicht wirklich verändern (kürzere > Zeiten werden nicht erreicht). Dabei springt der eingeblendete Balken > mit dem Triggericon komisch. Da im Stopmodus keine neuen Messungen durchgeführt werden (sagt der Name ja schon) kann die Zeitbasis nur im Rahmen des aktuellen Messwertevorrats verändert werden. Dieser hängt von der zuletzt eingestellten Zeitbasis ab. Genaue Zusammenhänge sind der Programmers Reference zu entnehmen die ich den BF-Ausgaben immer beilege. Ebenfalls damit hängen die Sprünge im Memory-Scroll Fenster zusammen. > Wenn man als Signal einfach das 1kHz Signal aus dem Oszi nimmt, kann man > schnell feststellen, das das Triggern nicht wirklich zuverläßig > funktioniert. Es löst aus, ohne das das Signal hinterher den Schluß > zuläßt warum. Also bei mir läßt sich das sehr gut nachvollziehen. Er triggert genau mit dem richtigen Pretrigger an der richtigen Flanke des nächsten Messdurchgangs. Also genau das was er soll. > Ferner kann mann mit dem 1kHz Signal beim Verlängern der Zeitbasis schön > sehen, wie Schwebungen entstehen, d.h. es erscheint beim langsamen > Abtasten die Schwebung aus dem Signal und der Abastrate. korrekt. Das ist halt die Natur der Sache. > Schöner wäre, > wenn man erkennen könnte, dass das Signal zu schnell für die Abtastrate > ist. Das hieße, das man während der Messung die ganze Zeit die Hauptfrequenz des Signals bestimmen müßte und dann auf das Abtasttheorem überprüfen müßte. Das kostet Performance, was sich in niedrigeren Bildwiederholraten äußert. Könnte man natürlich evtl. abschaltbar machen. Ist der praktische Nutzen denn so hoch? Wird das an anderen DSOs so gemacht? Gruß Hayo
Hayo W. schrieb: > Rainer H. schrieb: >> Hallo zusammen, >> ich habe gerade mal mit der "Single" Messung gespielt. Ich gehe davon >> aus, dass eigentlich eine Messung beim Erkennen des Triggers ausgelöst >> werden soll, aber... > > korrekt, tut es auch. Hab es gerade geprüft. > Hm. Bei mir auch, manchmal, scheinbar abhängig von der Zeitbasis. Langsamer ist besser ? Einstellungen: 1kHz Rechteck (Oszi), (1:10) 200 mV/ 20µs, Stop, dann Single, mehrfach, der Trigger wird nicht getroffen. >> Beim Stop läßt sich die Zeitbasis nicht wirklich verändern (kürzere >> Zeiten werden nicht erreicht). Dabei springt der eingeblendete Balken >> mit dem Triggericon komisch. > > Da im Stopmodus keine neuen Messungen durchgeführt werden (sagt der Name > ja schon) kann die Zeitbasis nur im Rahmen des aktuellen > Messwertevorrats verändert werden. Dieser hängt von der zuletzt > eingestellten Zeitbasis ab. Genaue Zusammenhänge sind der Programmers > Reference zu entnehmen die ich den BF-Ausgaben immer beilege. > > Ebenfalls damit hängen die Sprünge im Memory-Scroll Fenster zusammen. > Ich glaube die Reference ist zu hoch / unerklärt für mich. Versuch doch mal im Stop die Zeitbasis zu ändern und dann per Single oder Run zu messen. Irgendwie ändert sich die Zeitbasis nicht. D.h. die Anzeige in der ersten Zeile ändert sich, das (erfasste) Signal auch, aber nicht wie erwartet. Bei weiteren Messungen stimmt die Zeitbasis nicht mehr. Auch die Frequenzmessung per Quick Measure stolpert. >> Wenn man als Signal einfach das 1kHz Signal aus dem Oszi nimmt, kann man >> schnell feststellen, das das Triggern nicht wirklich zuverläßig >> funktioniert. Es löst aus, ohne das das Signal hinterher den Schluß >> zuläßt warum. > > Also bei mir läßt sich das sehr gut nachvollziehen. Er triggert genau > mit dem richtigen Pretrigger an der richtigen Flanke des nächsten > Messdurchgangs. Also genau das was er soll. > >> Ferner kann mann mit dem 1kHz Signal beim Verlängern der Zeitbasis schön >> sehen, wie Schwebungen entstehen, d.h. es erscheint beim langsamen >> Abtasten die Schwebung aus dem Signal und der Abastrate. > > korrekt. Das ist halt die Natur der Sache. > >> Schöner wäre, >> wenn man erkennen könnte, dass das Signal zu schnell für die Abtastrate >> ist. > > Das hieße, das man während der Messung die ganze Zeit die Hauptfrequenz > des Signals bestimmen müßte und dann auf das Abtasttheorem überprüfen > müßte. Das kostet Performance, was sich in niedrigeren > Bildwiederholraten äußert. Könnte man natürlich evtl. abschaltbar > machen. Ist der praktische Nutzen denn so hoch? Wird das an anderen DSOs > so gemacht? Wie die anderen Hersteller das erkennen weiß ich ehrlich gesagt nicht. Unser Tek TDS220 zeigt ein zu schnelles Rechteck als vollständig gefüllte Fläche an, so als wenn die Pegelwechsel häufiger sind als die Pixelbreite es hergibt. Ich hoffe mich verständlich ausgedrückt zu haben. Für mein Empfinden ist das stimmiger, dann komme ich auf die Idee "reinzuzoomen" bis ich was erkennen kann. Beim Welec komme ich mglw. gar nicht auf die Idee der Unterabtastung. > > Gruß Hayo Gruß, Rainer
Rainer H. schrieb: > Hm. Bei mir auch, manchmal, scheinbar abhängig von der Zeitbasis. > Langsamer ist besser ? > Einstellungen: 1kHz Rechteck (Oszi), (1:10) 200 mV/ 20µs, Stop, dann > Single, mehrfach, der Trigger wird nicht getroffen. Ok, hab Deinen speziellen Fall mal nachgestellt. Wenn die Signalperiode nicht mehr auf den Screen passt trifft der Trigger irgendwie nicht richtig. Sobald mindestens eine Periode zu sehen ist klappt es. Der Grund ist mir momentan nicht genau bekannt. Ich kann da nur so ungefähr vermuten. > Versuch doch mal im Stop die Zeitbasis zu ändern und dann per Single > oder Run zu messen. Irgendwie ändert sich die Zeitbasis nicht. > D.h. die Anzeige in der ersten Zeile ändert sich, das (erfasste) Signal > auch, aber nicht wie erwartet. Bei weiteren Messungen stimmt die > Zeitbasis nicht mehr. Auch die Frequenzmessung per Quick Measure > stolpert. Ja Du hast recht. Das ist definitiv ein Bug. Da muß ich wohl mal ran. Danke für den Tip. > Wie die anderen Hersteller das erkennen weiß ich ehrlich gesagt nicht. > Unser Tek TDS220 zeigt ein zu schnelles Rechteck als vollständig > gefüllte Fläche an, so als wenn die Pegelwechsel häufiger sind als die > Pixelbreite es hergibt. > Ich hoffe mich verständlich ausgedrückt zu haben. Für mein Empfinden ist > das stimmiger, dann komme ich auf die Idee "reinzuzoomen" bis ich was > erkennen kann. Beim Welec komme ich mglw. gar nicht auf die Idee der > Unterabtastung. Es könnte aber sein dass das kein Feature ist, sondern nur daran liegt, dass die Bildschirmauflösung von 320 x 240 beim Tek nicht mehr hergibt! Gruß Hayo
Hayo W. schrieb: > Es könnte aber sein dass das kein Feature ist, sondern nur daran liegt, > dass die Bildschirmauflösung von 320 x 240 beim Tek nicht mehr hergibt! Der TDS220 kann die Signaländerungen zwischen den später gespeicherten Abtastpunkten erkennen, wenn er im Peak Detect Mode läuft: "Peak Detect - High frequency and random glitch capture; captures glitches as narrow as 10 ns using acquisition hardware at all time/div settings between 5 µs/div and 5 s/div."
Hayo W. schrieb: > Es könnte aber sein dass das kein Feature ist, sondern nur daran liegt, > dass die Bildschirmauflösung von 320 x 240 beim Tek nicht mehr hergibt! > > Gruß Hayo Stimmt wohl. Allerdings finde ich ein "zu schnell" wechselndes Signal, das quasi statisch dargestellt wird, irreführend. Mir ist schon klar, dass die Schwebung von Signal und Abtastung so aussieht. Die Signaländerung fällt dabei jedoch völlig unter den Tisch. Wie gesagt, man muß immer viele (schnelle) Zeitbereiche durchgehen um rauszukriegen, wie das Signal wohl wirklich aussieht. Irgendein Hinweis auf die (nicht dargestellten) Pegeländerungen wären schön, und der "vollgemalte" Bildschirm ist recht intuitiv. Gruß, Rainer
In diesem Fall hilft "Autoscale". Dann wird nämlich auf die Zeitbasis geschaltet die den tatsächlichen Verlauf anzeigt. Gruß Hayo
Hayo W. schrieb: > In diesem Fall hilft "Autoscale". Dann wird nämlich auf die Zeitbasis > geschaltet die den tatsächlichen Verlauf anzeigt. > > Gruß Hayo Guter Tipp. Allerdings gibt es danach wieder 2 Häkchen vor den Triggermodi. Der Trigger im "Auto" Modus scheint auch von einer ganzen (Signal-) Periode abhängig zu sein (wie "Single"), vielleicht hilft das beim Fehler einkreisen... Gruß, Rainer
Rainer H. schrieb: > Hayo W. schrieb: >> In diesem Fall hilft "Autoscale". Dann wird nämlich auf die Zeitbasis >> geschaltet die den tatsächlichen Verlauf anzeigt. >> >> Gruß Hayo > > Guter Tipp. > Allerdings gibt es danach wieder 2 Häkchen vor den Triggermodi. Upps, stimmt. Hatte ich auch noch nicht gesehen - kommt auch auf die Liste! > Der Trigger im "Auto" Modus scheint auch von einer ganzen (Signal-) > Periode abhängig zu sein (wie "Single"), vielleicht hilft das beim > Fehler einkreisen... Muß ich mir mal näher ansehen. Gruß Hayo
Erst heute komm ich wieder in meine Werkstatt: Mein Oszi hat einen phantastischen Tag. Der Trigger löst plötzlich im Normal-Mode mit Run (grüne Taste) aus. Nicht aber im Single-Mode. Immerhin kann ich so Einzelereignisse beobachten. Problembeschreibung: Stop, dann Single-Mode gedrückt - jetzt geht es ohne Triggerauslösung nach knapp einer Sekunde in den Auto-Mode über. Damit sind keine Einzeltrigger möglich. (Teste die neueste Version. Muss noch mit einer älteren Version probieren, vielleicht dann!?) Triggerpegel: Speziell im niedrigen Bereich (unter 0,5cm Bildschirmhöhe) scheint bei mir der Trigger nicht auszulösen. Darüber sehr wohl. Overlay-Darstellung: Der Overlaymode funktioniert (heute) und ist zum Vergleichen von Signalverläufen prima geeignet. Kompliment. Was soll ich sagen. Wenn mein Oszi gut drauf ist, bin ich es auch. Gruß MH
Hi Manfred, um Deine Single Shot Problematik nachzuvollziehen brauche ich (und auch alle anderen hier) alle relevanten Parameter Deiner Messung. - Signalform, Frequenz, Pegel - Meßbereiche (Zeit und Spannung) - Gerätetyp 20xx Evtl. einen Screenshot vom Geschehen. Gruß Hayo
Hallo Hayo, bin z.Z. unterwegs deswegen ist es schlecht mit einem Beispiel, auf jeden Fall sollte dann ein breiter Balken erscheinen aber es sieht aus wie ein sinus der extem 'gezoomt' ist wie bei 1ms/S aber nur ungefaehr........ vlg Charly
Hi Hayo and all! Hayo W. schrieb: >that is an interresting comparison for LeCroy is a big player in the DSO >scene and the price for this devices is much higher than for our Welec. >So I think we don't have to be unhappy about our choice to buy this >device from Welec and we will be motivated to optimize it in future. Yes, I think so too. But I am frank, when I bought my W2022A I already knew that smart guys were improving it. I had read some of their presentations on the group, I saw that they were competent persons, engineers, engineering students and so. So already I knew I would have well spent my money. Then, even if I am not an expert, I had guessed that anyway its hardware should not be so poor. I think as it stands now, thanks to your work, the DSO is competitive with what the market offers even at higher price. I believe that if Mr. Wittig had You as collaborators Wittig/Welec now would be a great brand in the DSO's world. I do not want to do the devil's advocate but I believe that Mr. Wittig was a bit unlucky, no shortage of ideas but not so for the ability to put them into practice. Hayo W. schrieb: >By the way - did You test the new overlay function in the 1.10 HE? What >do You think about it? I'm currently away from home and my W2022A. But even here I have a friend with a W2012A so we updated it to the 1.10 HE version. I'm sincere now I do not quite understand how to use this new overlay function feature. I seem to understand that it can simultaneously display two stored waveforms so they can easily compare (following up to my previous message, roughly something like the Pass/Fail Mask Testing function of LeCroy WaveAce). The problem is that when I use the overlay function three strange things happen: 1) the source of trigger switches on channel 2 even though it was set to channel 1 and the settings of the DSO is set to CH1. There is a checkmark on CH1 but in the top bar on the screen there is the channel 2 as trigger source and infact channel 2 is now the trigger source. 2) the waveform stored as a reference and the waveform stored with the overlay's function are identical but out of phase. 3) since been updated to 1.10 HE, the yellow light of CH1 button is flickering, turns on and off randomly. I will surely do something wrong, I'm a bit tired now. Please,Hayo could you explain to me how to use the overlay function? Maybe you've already explained it, but I do not understand very well the German.:-( I apologize but I'm a bit cooked now, I'm sorry for my bad English more than usual...:-( Hayo again many thanks to You and all, really thanks very much to all You!!! Vielen Dank!!! Luc
So Ihr Lieben, während ich auf Rolf warte, der gleich zum Kaffeetrinken kommt, hier die neue BF1.11. Was ist drin? - Die Start/Stop/Single Logik ist jetzt wie bei HP (siehe Beitrag weiter oben) - den Bug in der Stop/Recall/Overlay Logik habe ich beseitigt - es gab mehrere Bugs im Triggermode Popupmenü die jetzt gefixed sind - und noch einige Kleinigkeiten die mir so zwischendurch aufgefallen sind Gruß Hayo
Hallo Hayo, Habe mir die neue Single/Start/Stop Logik angesehen. Die neue Version gefaellt mit sehr. Nur das stop Ikone bleibt immer auf dem Schirm. Ich wuerde es besser finden wenn da der trigger mode steht solange der tigger aktiv ist. Den Overlay mode finde ich soweit OK, es dauert nur etwas lang (ca. 8sek.) bis der auch wirklich angezeigt wird (am Anfang habe ich gedacht das manchmal die taste nicht akzeptiert wurde). Hier wuerde eventuell ein popup-fenster helfen. Wenn der Overlay mode aktiv ist kann man nicht nach single umschalten (man muss zuerst Run/Stop druecken). Ich wurde es wirklich klasse finden wenn du auch den "live" Overlay mode realisieren kannst (hier waehre es eventuell besser das "live" signal in den Kanalfarben zu belassen und das gespeicherte Signal in grau darzustellen) Vielen dank fuer deine tolle arbeit. Martin
Hallo Hayo, so gefällt mir die Start/Stop/Single - Logik wieder :-) Du warst aber wieder mal schnell ! Die Pulse With Triggerung funktioniert leider nicht. Die Ursache hab ich auch gefunden. Da hat sich zumindest dieser Bug auf Zeile 756 in userif_t eingeschlichen. Hier muss TRIG_PULS und nicht TRIG_EDGE stehen. Damit funktioniert die Pulse With Triggerung dann. Laßt euch den Kaffee schmecken! Gruß Jürgen
Kleiner Nachtrag: Bei Pulse Width Triggerung muss zwingend Holdoff auf "Off" stehen! Gruß Jürgen
Angehängte Dateien:
-
200-500mV.jpg
33 KB
Hallo Hayo, i muss dich auch mal loben, iss super die Start/Stop/Single func. bei Start/Stop/ betrieb geht die Singeltaste noch an, ein ueber- bleibsel denk ich bei TB > 1S/Div laesst sich kein trigger mehr einstellen, bzw. der pfeil an der Li. seite ist weg obwohl sich der wert oben Re. aendert, die taste Edge, Mode, Pulse und Singel reagieren nicht mehr ;( zum Bild: das Signal ist entstanden mit offenem eingang nur durch umschalten (hin und herschalten) zw. 200mV und 500 mV (ist bei anderen V/div einstellungen sehr aehnlich), i glaub das war bei der 1.8 nicht, oder ? das konnte i nach ein bisschen spielen feststellen besten dank nochmal f. deine Arbeit & ein schoenes WE Charly
Angehängte Dateien:
-
Single1.png
4,2 KB -
Single2.png
4,3 KB -
Single3.png
4,2 KB -
Single4.png
4,4 KB -
Single5.png
4,3 KB
Hallo Hayo, Klasse Wochenendausgabe!!! :-) Hayo W. schrieb: > - Die Start/Stop/Single Logik ist jetzt wie bei HP (siehe Beitrag weiter > oben) Beim Ausprobieren mit meinem W2024 habe ich gerade noch folgenden (wohl alten Bug) reproduziert: Bei Umschaltung von kontinuierlicher Erfassung auf "Single" geht die erste Messung grundsätzlich schief (s. Bilder). Die zweite und folgende Single-Shot Erfassungen sind dann ok. Input: Probe Comp. an allen vier Kanälen Wenn man auf "Single" umschaltet während kein Signal anliegt und dann den Input wieder anklemmt, sind Ch.1/2 immer ok und Ch.3/4 zeigen kein Signal (Single5.png). Nicht dramatisch, aber vielleicht hast du ja direkt eine Idee wo's haken könnte. Schönes Wochenende Rainer
Hallo Jungs, danke für's Feedback. Komme erst jetzt dazu die Beiträge zu lesen da ich sehr lange mit Rolf zusammengesessen habe. Ich gehe noch auf die einzelnen Punkte ein. Gruß Hayo
Was sehr praktisch ist: forced trigger oder button trigger Durch (nochmaliges) Drücken einer Taste wird in normal oder single sofort ein Trigger ausgelöst. Es soll also 4 Modi geben: AUTO am Ende wird eine einstellbare Zeit gewartet, ob ein Trigger kommt, wenn nicht, wird trotzdem gestartet NORM / FORC oder BUTT nur starten, wenn Trigger oder Taste (ist praktisch AUTO mit unendlicher Wartezeit) SING / FORC oder BUTT einmal triggern oder Taste danach geht er auf STOP STOP nicht triggern Oder ist das bereits jetzt möglich? Bei unserem LeCroy gibt es noch zwei LEDs: READY (lechtet sobald er "scharf" ist, d.h. geht kurz aus, bis alle Daten verarbeitet sind) und TRIG (leuchtet, wenn die Triggerbedingung erfüllt ist) Rolf/Hayo: ich wäre gestern gern dabeigewesen, es gab bestimmt viel zu lernen. Will auch einen 2024er und mitmachen!!! ;-) Da ich vom LeCroy recht verwöhnt bin, würde ich gern alle die netten Features auch im Wittig implementieren und für zu Hause haben. Worauf habt ihr euch geeinigt?
Gute Sonntag Hayo and all! Luc schrieb: >I have a friend with a W2012A so we updated it to the 1.10 >HE version. >The problem is that when I use the overlay function three strange things >happen: >1) the source of trigger switches on channel 2 even though it was set to >channel 1 and the settings of the DSO is set to CH1. >There is a checkmark on CH1 but in the top bar on the screen there is >the channel 2 as trigger source and infact channel 2 is now the trigger >source. >2) the waveform stored as a reference and the waveform stored with the >overlay's function are identical but out of phase. >3) since been updated to 1.10 HE, the yellow light of CH1 button is >flickering, turns on and off randomly. I updated the W2012A with the excellent new 1.2.BF.1.11 version and all problems are gone!:-))) Now it work like a charm, so Hayo and all guys, thank very much for the great work done, really a wonderful job!!!:-))) The overlay function feature now works without problems so that is no longer even need to explain the use, rougly it is what I meant about the LeCroy WaveAce function. The only thing I can add about this is, be could done so you can slide horizontally the waveforms so that is simple superimpose them? However this new feature is very useful, thanks again! Really Very well also for the change in the Run/Stop/Single logic, it is a good implementation that further enhances the DSO, many, many thanks also for introducing this amazing feature!!!:-))) Now I await for the implementation of the Rolf's Auto calibration and all that follow. Really a amazing job, in my opinion I think adding the "center" & "span" function and cursors to the FTT the Welec oscilloscopes could to better compete on equal terms with what the market currently offers even at higher price. Of course, also I await news about LEON 3 VHDL design implementation. About this I hope that programming of LEON 3 VHDL design on to DSO becomes as simple as a firmware update. Any news for me is always welcome!:-) Hayo again many thanks to You and all, really thanks very much to all You!!! Vielen Dank!!! Luc
Hallo zusammen, hallo Hayo, ich hätte noch einen Bug zu melden und einen Wunsch für die SW anzuregen. Bug: Die PreTrigger Anzeige wechselt beim Ändern der Zeitbasis nicht, erst wenn sie das nächste Mal verstellt wird. Anmerkung: Ein bisschen irritierend finde ich den PreTrigger eh, für mich ist die zeitliche 0 eher im Kordinatenursprung, d.h. PreTrigger 0 würde für mich zur Anzeige des Triggers in der Mitte des Bildschirmes führen. Neg. Zeiten nach links, pos. nach rechts. Vielleicht bin ich auch nur TDS-geprägt. Was sagen unsere erfahrenen Experten dazu? Wunsch: In der "Delayed" Anzeige die Einstellung der Zeitbasis zu erlauben und die "Zoomstufe" über den universellen Drehknopf zu verändern. Vorteil: Man muß nicht zw. "Main" und "Delayed" über die Softkeys umschalten um die Zeitbasis zu ändern. Vielleicht könnte man auch noch weiter reinzoomen? Viele Grüße, Rainer
Hallo Rainer H., Rainer H. schrieb: > Anmerkung: Ein bisschen irritierend finde ich den PreTrigger eh, für > mich ist die zeitliche 0 eher im Kordinatenursprung, d.h. PreTrigger 0 > würde für mich zur Anzeige des Triggers in der Mitte des Bildschirmes > führen. ich finde, man braucht beides. Die übliche und aktuell imlementierte Pre-Trigger Logik ist historisch aus Pre-DSO-Zeiten gewachsen. Ohne Speicher beginnt das Bild zwangsweise immer erst mit dem Trigger-Ereignis. In Anlehnung daran beginnt beim DSO die Datenaufzeichnung bei Pre-Trigger Einstellung "0" mit dem Triggerereignis. Eigentlich gibt es zwei verschiedene Bedienphilosophien zwischen denen man umschalten können müßte: Eine für Meßaufgaben die triggerzentriert sind (deine Version) und die klassiche Version für Signale, die auf den Triggerzeitpunkt folgen. Im jetzigen Stadium würde ich eine Umschaltung aber als "nice-to-have" einordnen. Gruß Rainer W.
Hallo allerseits, leider komme ich immer noch nicht dazu auf die Posts hier zu antworten, ich muß Euch leider auf morgen vertrösten. Gruß Hayo
Hi Rainer H., Rainer W. and all! Rainer H. schrieb: >Bug: Die PreTrigger Anzeige wechselt beim Ändern der Zeitbasis nicht, >erst wenn sie das nächste Mal verstellt wird. >Anmerkung: Ein bisschen irritierend finde ich den PreTrigger eh, für >mich ist die zeitliche 0 eher im Kordinatenursprung, d.h. PreTrigger 0 >würde für mich zur Anzeige des Triggers in der Mitte des Bildschirmes >führen. Neg. Zeiten nach links, pos. nach rechts. Vielleicht bin ich >auch nur TDS-geprägt. Was sagen unsere erfahrenen Experten dazu? I agree with You. I often use TDS series oscilloscopes by Tektronix and other manufacturer too and the trigger's zero position is at the center of the screen. Anyway I think it is more of a philosophy question that other thing because then when I use my W2022A I have no big problem. So I agree also with Rainer W. when he write: Rainer W. schrieb: >Eigentlich gibt es zwei verschiedene Bedienphilosophien zwischen denen >man umschalten können müßte: Eine für Meßaufgaben die triggerzentriert >sind (deine Version) und die klassiche Version für Signale, die auf den >Triggerzeitpunkt folgen. Therefore from my point of view this is not a real bug. Gruß Luc
>leider komme ich immer noch nicht dazu auf die Posts hier zu antworten
Wieder beim Griechen an der Ouzo-Kanne!! HeHe!! ;-);-)
Vielen Dank für die neue Version und viele Ideen für die nächste!!!
bingeradeimdienst
bingeradeimdienst schrieb: >>leider komme ich immer noch nicht dazu auf die Posts hier zu antworten > > Wieder beim Griechen an der Ouzo-Kanne!! HeHe!! ;-);-) Verdammt! Woher weißt Du das denn? > Vielen Dank für die neue Version und viele Ideen für die nächste!!! Ja da ist schon wieder einiges am Brodeln. Das Treffn mit Rolf war sehr anregend Gruß Hayo
Also Leute, ich muss echt mal nen riesen Dank und meinen Respekt aussprechen! Die letzte Version die ich getestet hatte war etwa 1 Jahr alt und seitdem haben sich WELTEN getan! Ich bin regelrecht begeistert was jetzt alles geht und vor allem funktioniert. Auch wenn ich noch nicht alles so wirklich durchschaut hab. Was ich zum Beispiel noch vermisse ist ein Force Trig. Gibts sowas irgendwo in einem Menue versteckt? Ich hatte lediglich mal wieder beim Updaten Probleme. Immer nach etwa 5 Sekunden brach das Update ab. Hat da jemand ne Idee was das sein könnte? Dell Latitude Notebook mit Onboard RS232 und WinXPprof. Das gleiche Problem habe ich auch wenn ich vom Handy oder der Kamera aus per Infrarot (ist auch als COM angemeldet) was übertragen will. Das nervt doch ziemlich, sodass ich meinen alten Rechner wieder aktivieren musste, wo dann die gleiche Perl Software einwandfrei lief.
Luc schrieb: > Hi Rainer H., Rainer W. and all! > > > Therefore from my point of view this is not a real bug. Hello Luc, the bug I meant was the incorrect PreTrigger time after changing the timebase. Not the trigger zero in the middle of the screen. > > Gruß > > Luc Gruß, Rainer
Hallo, traurigerweise scheinen einige den Sinn von Stichtagen nicht zu verstehen. So sind noch Bestellungen nach dem 25.08. bei mir eingegangen, die ich nur in Ausnahmen berücksichtigen konnte und das Geld haben auch noch nicht alle überwiesen, was noch viel trauriger ist! Das Nutzen ist bereits komplett gesetzt. Viel Überproduktion ist nicht zu erwarten und ich lege mir verständlicherweise nicht Massen an Leiterplatten auf mein privates Lager. Weitere Bestellungen können also nicht berücksichtigt werden. Wer zu spät kommt, aus welchen Gründen auch immer, hat jetzt schlichtweg Pech. branadic
Hallo Peter, >...Das gleiche >Problem habe ich auch wenn ich vom Handy oder der Kamera aus per >Infrarot (ist auch als COM angemeldet) was übertragen will... Sind denn die Parameter vom Comport bei beiden Rechnern identisch? Baudrate, Protokolle, FIFO-Puffer, etc. ? Gruß Michael
Ja, die sind gleich eingestellt. Obwohl ich an den Werten vom Fifo noch nie was rumgestellt habe.
Hi Rainer H. and all! Rainer H. schrieb: >the bug I meant was the incorrect PreTrigger time after changing the >timebase. Not the trigger zero in the middle of the screen. Oh!, I am really very sorry for the mistake!:-( Rainer H., I apologize for the error, my understanding of German is really very lack!:-( In fact you wrote Rainer H. schrieb: >Bug: Die PreTrigger Anzeige wechselt beim Ändern der Zeitbasis nicht, >erst wenn sie das nächste Mal verstellt wird. but I've not understood correctly, so still so many excuses again Rainer H.:-( Now I have nostalgia of my military service when I had a German translator... Sorry again Rainer H.!:-( Gruß Luc
Hi Stefan, Stephan S. schrieb: > Ja, die sind gleich eingestellt. Obwohl ich an den Werten vom Fifo noch > nie was rumgestellt habe. Manchmal hilft ein wenig Spielerei mit dem Puffer: stell mal den Empfangspuffer auf "8" ..und den Übertragungspuffer auf "14" dann meldest du dich ab und wieder an, das die Einstellungen wirksam werden(man muß nicht neu hoch fahren)! Bei mir hatte hatte das Wirkung. Gruß Michael
Angehängte Dateien:
-
Stop_Run_Messung1.png
3,9 KB -
Stop_Run.png
4,6 KB
Hallo Hayo, Rainer W. schrieb: > Beim Ausprobieren mit meinem W2024 habe ich gerade noch folgenden (wohl > alten) Bug reproduziert: > Bei Umschaltung von kontinuierlicher Erfassung auf "Single" geht die > erste Messung grundsätzlich schief (s. Bilder). Die zweite und folgende > Single-Shot Erfassungen sind dann ok. Das gleiche Problem tritt auf, wenn ich von "Stop" auf "Run" umschalte, d.h. bei der ersten Messung wird in Ch.3/4 kein Signal erfaßt. Zu sehen ist das natürlich nur bei Einzelsignalen (Trig. "Normal"). Hast du beim Trigger irgendetwas Ernstes gemacht? Der scheint jetzt tausendmal besser zu funktionieren - klasse!!! Gruß Rainer
Hallo allerseits, bin zur Zeit etwas busy, habe aber schon wieder eine Menge an der Firmware rumgeschraubt. Es hat sich unter der Haube so viel getan, dass ich mit der Versionsnummer auf 2 gehen werde. Mit Rolf hatte ich einen regen Gedankenaustausch, von dem auch schon einiges eingeflossen ist, unter anderem die inline Math-Funktionen, die die FFT etwas beschleunigen. Auch die RMS-Berechnung und die XY-Anzeige sind schneller geworden. Rolf und ich waren uns einig, dass eine Zusammenführung der OSS und BF-Version aufgrund der mittlerweile großen Unterschiede keinen Sinn macht. Die separate Entwicklung sehen wir beide nicht als Problem. Es wird einen gegenseitigen regen Gedankenaustausch geben damit beide Versionen von guten Ideen profitieren. Meine Entwicklungslinie ist mittlerweile im SVN als eigener Branch eingecheckt. Zu den einzelnen Punkten: @Rainer >Bei Umschaltung von kontinuierlicher Erfassung auf "Single" geht die >erste Messung grundsätzlich schief (s. Bilder). Die zweite und folgende >Single-Shot Erfassungen sind dann ok. Ja hab ich auch schon gesehen, muß ich mal analysieren, vielleicht kann ich das abstellen. @eProfi das mit dem Forced Trigger kenne ich noch nicht. Das könnte man evtl. implementieren. Nebenbei, die Nachrüstung und Ansteuerung der beiden zusätzlichen LED scheint ja kein Problem zu sein. Da werde ich mir auch noch Gedanken zu machen. Das könnte mir wohl gefallen. @Charly Im USTB-Modus läßt sich grundsätzlich kein Trigger einstellen, da in dieser Betriebsart ein Trigger wenig Sinn macht und daher fest auf Auto Free Run eingestellt ist. die falsche Pretriggeranzeige werde ich mir mal ansehen. So muß jetzt wieder los. Bis bald Hayo
Hi Hayo and all! Hayo W. schrieb: >Mit Rolf hatte ich einen regen Gedankenaustausch, von dem auch schon >einiges eingeflossen ist, unter anderem die inline Math-Funktionen, die >die FFT etwas beschleunigen. Auch die RMS-Berechnung und die XY-Anzeige >sind schneller geworden. Hayo and Rolf thank all You very much for the really great job!!! Gruß Luc
Hayo W. schrieb: > @Charly > > Im USTB-Modus läßt sich grundsätzlich kein Trigger einstellen, da in > dieser Betriebsart ein Trigger wenig Sinn macht und daher fest auf Auto > Free Run eingestellt ist. Was ist der USTB-Modus? TB=Timebase? Aber US? Ich habe hier und bei Sourceforge nichts gefunden. Kann mir hier jemand weiterhelfen? Und noch eine Frage an Hayo. Gibt es eine Doku zu deiner Arbeit? Gruss, Peter
Angehängte Dateien:
-
Mess_200ms.png
5,7 KB -
Mess_1_100ms.png
5,2 KB -
Mess_n_100ms.png
5,1 KB
Hallo Hayo, Hayo W. schrieb: > Ja hab ich auch schon gesehen, muß ich mal analysieren, vielleicht kann > ich das abstellen. Das wäre prima. Das Ch.3/4 Problem tritt übrigens auch nach Zeitbereichsumschaltung auf. Anscheinend werden in der ersten Messung nach der Umschaltung für Ch.3/4 Daten dargestellt, die noch vorher mit der alten Zeitbasis gesamplet wurden. Folgende Messungen mit einer festen, auf Knopfdruck ausgelösten Pulsfolge: Mess_200ms - Messung bei 200 ms/div - Direkt nach der Pulsfolge auf 100 ms/div umgeschaltet Mess_1_100ms - Erste Messung nach Umschaltung auf 100 ms/div Mess_n_100ms - weitere Messungen mit 100 ms/div Gruß Rainer
@Peter Sorry, ich dachte das wäre so allgemein bekannt. Aber Du hast natürlich recht, da es keine komplette Doku gibt kann man das ja auch nicht wissen. Eine Doku wäre natürlich wünschenswert, aber ich ändere so oft so viel an der FW, dass ich das in meiner Freizeit einfach nicht schaffe. Also USTB heißt Ultra Slow TimeBase. Das Besondere daran ist, das hier nicht wie in den normalen Timebases jeweils ein ADC-Durchgang dargestellt wird und dann der nächste, sondern jeder Wert einer Signallinie ist jeweils der Mittelwert eines ADC-Durchganges. Je nach Auswahl Roll oder Shift-Modus wird jeder neue Wert entweder an das Ende (rechts) angehängt oder am Anfang (links) eingfügt und schiebt dann alle anderen Werte um eine Position nach rechts. In dieser Betriebsart macht der Trigger natürlich wenig Sinn. Gruß Hayo
@Rainer ich wollte mir mal die Sache mit den beiden zusätzlichen LED ansehen und evtl. auch gleich mal implementieren. Bei der Gelegenheit werde ich mir das mal näher ansehen. Zur Zeit bin ich aber gerade an der FFT am werkeln und komme deshalb nicht dazu. Gruß Hayo
By the way - hätte vielleicht einer von Euch Lust eine Doku zusammenzustellen. Ich würde tatkräftig helfen, aber ich habe halt nicht die Zeit alles allein zusammenzustellen. Auch der FFT-Teil hat sich ja geändert, so dass meine letzte FFT-Doku auch nicht mehr ganz aktuell ist. Gruß Hayo
Hier kam ja schon mal der Vorschlag ein Wiki einzurichten (so wie die Artikel hier im Forum) - da kann das Existierende rein und Schritt für Schritt von allen up to Date gehalten werden. Wo könnte man so etwas denn ansiedeln? Hier im Forum? Grüße, Mirko
Kurt Bohnen schrieb: > Ein Wiki haben wir doch schon: > > http://sourceforge.net/apps/trac/ Eine Bedienungsanleitung (für Hayos Firmware) ist das ja nicht wirklich, einfach so editieren kann man auch nichts, und in deutsch (zumindest als Variante) wäre auch nicht schlecht. Ich finde das Prinzip hier im Forum eigentlich toll, man liest irgendeinen Artikel, entdeckt z.B. nur einem Tippfehler und kann ihn auch als Gast mal schnell korrigieren. Das geht leicht und unkompliziert von der Hand und regt somit zur Mitarbeit an. Mirko
Übrigens wäre eine Doku, zumindest was die Bedienung angeht zu 95% kompatibel zwischen OS und BF Version, da die wesentlichen Unterschiede eher im Inneren zu finden sind. Daher wäre da beiden gedient. Ich dachte da an ein Officedokument (Word oder so) das man dann in PDF konvertieren kann. Wenn wir eine deutsche und englische Version erstellen, gibt es in den italienisch und französischsprachigen Foren bestimmt Leute die das auch noch weiter übersetzen. Hayo
Hayo W. schrieb: > Ich dachte da an ein Officedokument (Word oder so) Danke, dass du das schreibst. Dann bin ich als Linux-User schon mal außen vor (puuhh). ;-) Gruß, Guido
Guido schrieb: > Hayo W. schrieb: >> Ich dachte da an ein Officedokument (Word oder so) > > Danke, dass du das schreibst. Dann bin ich als Linux-User schon mal > außen vor (puuhh). ;-) Wieso? OpenOffice sollte das doch packen ;-)
Das hätte aber wieder den Nachteil, das man eine Versionsverwaltung o.ä bräuchte (zumindest wenn mehrere daran arbeiten wollen) - was ja schon bei der Firmware selbst ein Problem ist. Wenn man so ein Wiki hat, kann man doch bestimmt den Inhalt irgendwie exportieren oder die html-Seiten einfach ausdrucken.
Mirko B. schrieb: > Wenn man so ein Wiki hat, kann man doch bestimmt den Inhalt irgendwie > exportieren oder die html-Seiten einfach ausdrucken. Keine Ahnung. Wenn das so geht ist ein Wiki natürlich nicht schlecht, weil es flexibler ist, aber ob das so geht weiß ich nicht. Tatsache ist, das viele Leute (ich auch) bei Anleitungen und Handbüchern die gute alte Offlineversion aus Papier bevorzugen. Und ein PDF kann man sich schnell mal auf den USB-Stick laden und in der Firma ausdrucken. Hayo
Ich habe einfach mal getestet.... Artikel hier im Forum: http://www.mikrocontroller.net/articles/Ausgangsstufen_Logik-ICs Unter Mac OS mit Safari (Reader Funktion) als PDF ausgedruckt - so schlecht sieht das ja gar nicht aus oder?
Und die eingebetteten Links zum bearbeiten scheinen auch aus dem PDF heraus zu funktionieren.
Eventuell könnte man ja ein vorhandenes Handbuch von Agilent/Tek hernehmen (je nachdem, zu welchem DSO die Welec-Frimware mehr gemeinsamkeiten hat). Dann hat man bereits eine Struktur sowie Beschreibungstexte. Anzupassen wären dann "nur noch" die Screenshots, Funktionen, deren Bedienung unterschiedlich ist sowie Funktionen, die beim Welec vorhanden sind aber bei der Referenz nicht. Ich denke die aktiven Entwickler und Tester wissen sicher, welchem Oszi das Welec (OSS bzw Hayo's BF) am meisten ähnelt.
Die Welecs orientieren sich stark an Agilent (HP). Wobei es natürlich jetzt Firmwareseitig einige Abweichungen gibt. Gruß Hayo
Angehängte Dateien:
-
1000_large.jpg
170 KB
HHayo W. schrieb: > @Peter > > Also USTB heißt Ultra Slow TimeBase. Okay, ich habe es mir schon gedacht. Hier hatte ich dann doch noch was dazu gefunden http://sourceforge.net/apps/trac/welecw2000a/browser/fpga/nios/bf/trunk/src/changelog.txt Die beiden nicht benutzten LEDs auf jeden Fall nutzen. Der Vorschlag von eProfi "Bei unserem LeCroy gibt es noch zwei LEDs: READY (lechtet sobald er "scharf" ist, d.h. geht kurz aus, bis alle Daten verarbeitet sind) und TRIG (leuchtet, wenn die Triggerbedingung erfüllt ist)" ist doch gar nicht schlecht. Schoen, das die Idee des Manuals bei einigen Anklang gefunden hat. Stimmt die Agilent 1000 Series sehen aus wie das Welec, oder vielmehr umgekehrt ;-) (siehe Bild) Sogar die Namen sind gleich. Hier gibts die Anleitungen http://www.home.agilent.com/agilent/techSupport.jspx?pid=1569581&cc=DE&lc=ger&t=80039.k.1&guid=183805 Openoffice waere doch prima. Alle Betriebssysteme koennen es nutzen. Ich weiss nur nicht wie gut Draw mittlerweile funktioniert fuer die Bildchen. Ich wuerde Neudeutsch als Sprache favorisieren. Gruss, Peter
Zum Thema Doku könnte DocBook ganz interessant sein, daraus lassen sich verschiedene Textausgaben ableiten. Und das Ganze mit svn zu verknoten um eine Versionsverwaltung zu haben ist auch nicht schlecht (häufig genug bei Texten aller Art verwendet) Grüße, rowue (gerade etwas am rotieren ;)
Hi, bin genau wie Rolf auch etwas unter Strom, und komme immer nur ein bis zwei Stunden zum Programmieren. Zur Zeit programmiere ich an den noch fehlenden FFT-Funktionen. Zu den LEDs: Die könnt Ihr Euch getrost schon einbauen, denn in der nächsten Version werde ich die auf jeden Fall mit ansteuern. Ob das jetzt so mit dem Trigger Sinn macht muß ich mal prüfen, aber irgendwie werde ich die auf jeden Fall mit "verbraten". Gruß Hayo
Hallo Also ein Wiki finde ich eine sehr gute Idee!! Ich habe mir auch schon oft gedacht, eine Doku (in Deutsch) wäre sehr gut. Das Wiki hätte den Vorteil, dass da jeder mitmachen kann, dass es Plattform unabhängig ist und auch mal kurz etwas geändert werden kann.. Damit fallen auch die Schranken, die man sonst überwinden muss wenn man das selber in einem Textprogramm macht.... Dann könnte ich sogar etwas beisteuern :-) Wenn man die Doku dann noch in ein pdf umwandeln kann, ist es perfekt! l.G. Roberto
ja, ja!!! Nur bei einem Wiki kann jeder leicht mitarbeiten und man muß nicht umständlich irgendwelche Versionen verwalten oder abgleichen. Ein Beispiel aus der Artikelsammlung hier habe ich ja weiter oben schon gebracht. Viele Grüße, Mirko
Da das vorhandene Wiki ja etwas allgemeiner gehalten ist müßten wir dann ein neues Wiki haben, das speziell als "Anwenderhandbuch" ausgelegt ist. Man kann ja durchaus beide Firmwareversionen in einem Kapitel abhandeln wenn sie sich in der Bedienung oder Funktion unterscheiden. Was meint Ihr? Wer könnte denn mal so ein Wiki anlegen? Mir fehlt da etwas die Erfahrung. Bei SFN scheint das ja zu gehen. Gruß Hayo
Gut wäre auch ein Wiki ohne Anmeldung! Dann machen auch viel mehr Leute mit. l.G.Roberto
Hi Hayo, Hayo W. schrieb: > Zu den LEDs: > > > > Die könnt Ihr Euch getrost schon einbauen, denn in der nächsten Version > werde ich die auf jeden Fall mit ansteuern. Ob das jetzt so mit dem > Trigger Sinn macht muß ich mal prüfen, aber irgendwie werde ich die auf > jeden Fall mit "verbraten". ....wie geil ist das denn? Ich habe die schon fast ein Jahr da drinnen! Mit der Blende für die Durchleuchtung müsste man sich noch was einfallen lassen, Jemand eine Idee? Besser dann im HW-Thread! Hi Roberto, >Wenn man die Doku dann noch in ein pdf umwandeln kann, ist es perfekt! > >l.G. Roberto Die fertigen Dokumente in das PDF-Format umzuwandeln könnte ich evtl. in die Hand nehmen. Gruß Michael
Moin moin Hayo, betreff USTB: hab eben am Agilent probiert, da geht selbst bei 50s/div der singel und der normal Trigger Mode, i hab oefter den fall wo lange nichts passiert (mehrere Minuten) und dann kommen mit paar sekunden abstand impulse, da ist das schon hilfreich ist das denn viel mehraufwand das zu implementieren ? vlg Charly
Hallo Charly, das liegt beim Agilent wohl daran dass die da tatsächlich mit einer so langsamen Abtastrate arbeiten. Das entspricht aber nicht dem USTB-Modus beim W2000A. Hier sind solch langsame Abtastraten nicht implementiert. Versuch mal eine von den WELEC original Firmwares, da wirst Du feststellen, dass die langsamen Zeitbasen nicht funktionieren. Der Roll und Shiftmodus haben ja den Verteil, dass man Veränderungen kontinuierlich sehen kann und die Signale sind ja so langsam, dass man bei Auftreten eines Ereignisses locker manuell die Stoptaste drücken kann. Einen reinen Softwaretrigger zu implementieren, wäre wohl möglich - Frage an alle hier: Braucht man sowas? Wenn ja würde ich das mit auf die ToDo-Liste setzen. Hayo
So hier die passende Firmware für die LED-Nachrüster. Es ist eine BF.2.0 preview - d.h. es sind schon etliche neue Sachen und Bugfixes drin, aber die FFT ist noch "under construction". Die LEDs werden (erstmal) folgendermaßen angesteuert: - linke LED an, rechte LED aus, Trigger ist "scharf", es wird auf das nächste Ereignis gewartet - linke LED aus, rechte LED an, Trigger wurde ausgelöst, Daten werden eingelesen Ist echt lustig anzusehen das Geflackere. Viel Spaß Hayo
Hallo Hayo und Entwickler, wird das Welec auch ohne Nachrüstung der LEDs noch zu bedienen sein? Ich wollte eigentlich nicht dran rumlöten/-bohren usw. (manch anderer vielleicht auch nicht) Daher die Frage ob die Software weiterhin so sein wird, das ich mit dem Welec auch ohne Umrüstung arbeiten kann (die LEDs als Quelle zusätzlicher Informationen). Oder werden damit dann Feedback-Informationen abgebildet, die ich für das Arbeiten mit dem DSO zwingend benötige. Könnte man die Infos nicht einfach in der Kopfzeile auf dem TFT einblenden? Sorry wenn ich vielleicht blod frage, ist mir aber grad so in den Sinn gekommen.
Hi, nur keine Scheu bei den Fragen. Nein im Augenblick ist das nur "nice to have", oder wie Leute die mal Yps gelesen haben sagen würden - ein nettes Gimmik. Also Du wirst auch ohne die Nachrüstung problemlos mit dem Gerät arbeiten können. Allerdings weiß ich natürlich nicht was in Zukunft noch an Infos auf den LED abgebildet wird. Aber es wird sicher nicht so entscheidend sein das die Umrüstung zwingend erforderlich wäre. Aber lustig aussehen tut's schon... Hayo
Man kann übrigens gut die Arbeitsweise des Combi-Triggers sehen. Wenn man den Triggerlevel aus dem Signal herausdreht, wird das Flackern ganz langsam und man kann den Timeout schön an den Dioden erkennen. Sobald er wieder im Signal liegt ist die Triggerfrequenz wieder viel höher. Hayo
Angehängte Dateien:
Hi Hayo, vergiss bitte den "Pulse Width Bug" nicht. Der ist zumindest noch in der 2.0_preview enthalten! Ohne den sieht es dann wie im Bild aus :-) Gruß Jürgen
Thread beobachten
Seitenaufteilung abschalten
