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