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 im Beitrag #1768702: 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 im Beitrag #1768702: 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

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.

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/brows...

Eine gute Recherche hat schon ihre Vorteile....

>
> Gruß, Guido

Grüße,

   rowue

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/miles...

gerade bin ich an der Kalibrierung (#46,
http://sourceforge.net/apps/trac/welecw2000a/ticket/46),
die allerdings von den Auswirkungen her etwas zeitaufwendig ist
(geht komplett durchs System und so wie der Source um
Refaktorisierung bettelt ....)
>
> Gruß, Guido

Beste Grüße,

   rowue

PS: habe auch den Fehler in der C-Routine zum Auslesen der ADC's
gefunden - kannst Dir die alte mal in Ruhe ansehen, Du wirst lachen
oder weinen - je nach dem ;)

Nur zur Info. Meine Erfahrungen mit dem Firmeware Backup habe ich hier
http://sourceforge.net/apps/phpbb/welecw2000a/view...
beschrieben.

Gruss, Peter

Guido schrieb:

...

> Ich hatte nach Falks ausscheiden noch gelegentlich im SFN
> nachgeschaut und den Eindruck, dass dieses tot ist. Schön,
> wenn sich da wieder etwas tut, hier hat man das halt nicht
> mitbekommen.

Da mein Name genannt wird, sage ich auch noch etwas dazu:

Mein Ziel war eher, die Darstellungsgeschwindigkeit und die
Fernsteuermöglichkeiten zu verbessern. Das ist nämlich der Punkt, der
mich am meisten stört. Das Video muß ich nicht nochmal posten, aber
>10fps sagen schon genug.

Da mein Weg, die Y-Koordinaten direkt aus ADC-Werten über eine Tabelle
zu indizieren, keine Freunde gefunden hat, habe ich den noch eine Weile
selbst verfolgt.

Die Fernsteuerung und Daten/Screendump hat Hajo ja in "seine" Versionen
"übernommen".

Die schweren Verzerrungen bei >30MHz konnte ich auch beseitigen, leider
trt dadurch das Problem der Spikes auf. Das halte ich für lösbar,
zumindest für Kanal 1+2. Die Funktionen der einzelnen Bits in den
Registern lassen sich auch testen, ohne den Netzschalter über Gebühr zu
belasten:
https://sourceforge.net/apps/trac/welecw2000a/wiki...

Mein Fazit: Es könnten reichlich Verbesserungen eingebaut werden. Aber
wie soll das gehen? Im SVN fehlen Hayos letzte Änderungen, ob Hayo
einsieht, daß die serielle Steuerung sinnvoll ist, ist fraglich. WIMRE
hat er die schon einmal wieder entfernt.

Falk

Falk Willberg schrieb:
> Guido schrieb:
>
> ...
>
>> Ich hatte nach Falks ausscheiden noch gelegentlich im SFN
>> nachgeschaut und den Eindruck, dass dieses tot ist. Schön,
>> wenn sich da wieder etwas tut, hier hat man das halt nicht
>> mitbekommen.
>
> Da mein Name genannt wird, sage ich auch noch etwas dazu:
>
> [Darstellungsgeschwindigkeit und Fernsteuerbarkeit]

Die Geschwindigkeit ist wirklich atemberaubend - allerdings
fehlen diverse Bedienmöglichkeiten des Gerätes, weshalb ich
erstmal den anderen Weg gewählt habe.
>
> Da mein Weg, die Y-Koordinaten direkt aus ADC-Werten über eine Tabelle
> zu indizieren, keine Freunde gefunden hat, habe ich den noch eine Weile
> selbst verfolgt.

Naja, die Indizes hatte ich Dir noch eingebaut - Do you remember?
Und just for info: AFAIR verwendet die BF derzeit auch Indizes,
und in der OS habe ich die - alten - alten Zeichenroutinen auch
auf diese umgestellt. Evtl. werde ich zu einem späteren Zeitpunkt
auch Dein und Jörgs direktes Schreiben in den Video-Puffer übernehmen,
aber derzeit habe ich andere Baustellen ....

Wenn Du eine schnelle Darstellung einbaust, welche die übrigen
Funktionen des Gerätes nicht beeinträchtigt, wird sich keiner
ein Problem haben. Aber auch >10fps wenn Cursor, etc nicht
funktionieren.

>
> [Verbesserungen, Hayo, SVN]

Zu erst: ich möchte zu diesem Zeitpunkt in keinster Weise
über Hayo diskutieren - dieser ist derzeit im Urlaub. Du wirst sicher
auch keine Diskussionen über Dich lesen wollen, wenn Du
aus dem Urlaub zurückkommst, oder?

Zum Thema SVN: Ich checke meine Änderungen ein - damit sie genutzt
werden können. Wenn andere das nicht machen, ist das ihre Sache.
Mehr Spass bringt es, wenn alle das machen.

Dich hatte ich in den letzten Wochen und Monaten in verschiedensten
Bezügen auch auf dieses Projekt angesprochen - Dein einziger Kommentar
war: "Das wird alles nichts mehr."

Wenn ich Dinge anfange, ziehe ich sie auch durch und versuche dabei
gute Arbeit zu machen. Andernfalls nehme ich mich selbst nicht ernst -
und dann wird es auch kein anderer machen.

>
> Falk

Beste Grüße,

    rowue

Peter M. schrieb:
> Nur zur Info. Meine Erfahrungen mit dem Firmeware Backup habe ich hier
> http://sourceforge.net/apps/phpbb/welecw2000a/view...
> beschrieben.
>

Toll!

> Gruss, Peter


Grüße,

   rowue

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/view...
>> 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

Ich noch mal,

die HW-Ver. von dem Dump ist: 8C7.0L

...jetzt muß ich aber los

Gruß Michael

Michael D. schrieb:
> Hi Rolf,
>
> hier hast du einen kompletten Original-Dump von meinem DSO, allerdings
> mit der 1.4 Ver. von Welec.
> Das Teil ist über 3MB groß!
> Dabei ist ist noch ein Backup mit ca. 1,8MB, da weiss jetzt leider nicht
> mehr, was ich da gesichert habe, kannst ja mal nach schauen, was da
> passt.
>
> Gruß Michael

Hallo Michael,

durch Zufall bin ich glaube ich ueber deinen damaligen Thread gestolpert
Beitrag "Re: Wittig(Welec) W2022A Firmware sichern und Update durchfüren?"

rowue sucht eine 4Ch-Version.

Gruss, Peter

Rolf W. schrieb:
> Kurze Frage,
>
> hat hier jmd. ein Backup seiner alten (Orignal) FW
> für ein
>
> W20X4A, Hardware-Version 8C7.C9
>
> und würde mir evtl. mit einer Kopie aushelfen
> (Seriennummer ändere ich wieder auf meine) - ich
> hatte hier einen kleinen Betriebsunfall und finde
> mein Backup nicht mehr (resp. die Platte auf
> der das war ...)
>
> Beste Grüße,
>
>       rowue

Hallo rowue,

da ich im Moment vor allem lese, wie der ganze Kram funktioniert bin ich
ueber einige FW Dumps gestolpert.

http://sourceforge.net/apps/phpbb/welecw2000a/view...
Beitrag "Re: Wittig(welec) Oszilloskop firmware problem"
Beitrag "Re: Wittig(welec) Oszilloskop firmware problem"
Beitrag "Re: Wittig(welec) Oszilloskop firmware problem"

Leider stehen die Hardware-Versionsnummern nicht dabei. Kann man die in
den Dumps finden?

Moege es nuetzen!

Gruss, Peter

Rolf W. schrieb:

> W20X4A, Hardware-Version 8C7.C9

Hallo Rolf,

Anbei mein backup (W2024A HW 8C7.C9 SW 1.4) hoffe dass das hilft.

Martin

hi Peter,

eigentlich sollten die diesbezüglich gleich sein ob 2 oder 4 Kanal.
Habe den Dump mal in einen Hexeditor geladen, in der Informationsspalte
steht nur:--------# WelecUpdater V0.4.8A22...ansonsten nur die HEX.
Ob da überhaupt etwas von einer HW-Version steht? Vielleicht wissen die
Programierexperten da mehr?!?

Gruß Michael


PS. Peter: Hast du meine Maill bekommen?

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/...

(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/view...
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

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

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

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 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

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

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

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/wel...

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

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

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

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, 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

...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

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

@Jürgen,

das mit der Ecke ist trotzdem eine gute Idee, werd ich gleich mal
nachrüsten wenn ich den Schalter austausche.

Hayo

Hayo W. schrieb im Beitrag:
> So da ist sie, die Holiday Edition. Der Urlaub muß ja auch für was gut
> sein ;-)
>
...da hat sich 'Frau' bestimmt gefreut...:))
>
> Was ist neu?
>
> - die Overlay Funktion
> - Bug im Speichermangement beim Save/Recall gefixed
> - Timebase switching USTB <-> Normal überarbeitet, Bug gefixed
>
> Zum Overlay:
>
> Das gespeicherte Signal wird in den Standrdfarben dargestellt und über
> die aktuellen Live-Signale gelegt die in gelb/grau dargestellt werden.
> Das aktuelle Live-Signal wird auf die gleichen Einstellungen gesetzt wie
> das gespeicherte Signal. Alle sinnvollen Aktionen sind in diesem Modus
> möglich (Timebase, Math, Cursor etc.)
>
...schön, wenn man weiß, was drinnen ist. :)
Was macht das USB-Interface?
>
> Einfach ausprobieren und wie immmer bitte Eure Erfahrungen rückmelden.
>
> Gruß Hayo

Hayo W. schrieb:
> @Jürgen,
>
>
>
> das mit der Ecke ist trotzdem eine gute Idee, werd ich gleich mal
>
> nachrüsten wenn ich den Schalter austausche.

Ist ja'n Ding!
...nach dem ich das Teil schon zig mal zerlegt hatte, dachte ich, das
diese verloren gegangen sei und hab da eine aus der Bastelkiste
reingeschraubt! Dann haben Die die einfach weggelassen?

Gruß Michael

Hallo 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

Hallo branadic

also wird es später noch eine weitere Sammelbestellung geben?

Mfg,
Kurt

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.

oha, Petra liest mit ;-))

Joo, aber jetzt ist sie beim Fernsehen und ich hab gerade den
Überknüller rausgefunden -> siehe HW-Thread.

He, alle an der Ostsee?

32 Downloads und noch keine Rückmeldung? Ist alles so perfekt, dass es
nichts zu berichten gibt? Kann ich mir ja nicht so richtig vorstellen...

Sag mal einer was zu der aktuellen FW. Oder ist die Funktion eher nicht
so interessant?

Haut ruhig Eure Meinung raus, ich bin mental stabil...


Hayo

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 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 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

>Zur Ansteuerung der neuen Eingangsstufe:

>Rolf hatte die Idee, dass Stefan sich der Sache evtl. annehmen könnte...
>Stefan - wie wär's damit?

Ab Oktober könnte es evtl. was werden. Vorher gehts wirklich net. Zuviel
zu tun :-(

Gruß,
Stefan

Rainer H. schrieb:
> Hallo zusammen,
> ich habe gerade mal mit der "Single" Messung gespielt. Ich gehe davon
> aus, dass eigentlich eine Messung beim Erkennen des Triggers ausgelöst
> werden soll, aber...

korrekt, tut es auch. Hab es gerade geprüft.

> Beim Stop läßt sich die Zeitbasis nicht wirklich verändern (kürzere
> Zeiten werden nicht erreicht). Dabei springt der eingeblendete Balken
> mit dem Triggericon komisch.

Da im Stopmodus keine neuen Messungen durchgeführt werden (sagt der Name
ja schon) kann die Zeitbasis nur im Rahmen des aktuellen
Messwertevorrats verändert werden. Dieser hängt von der zuletzt
eingestellten Zeitbasis ab. Genaue Zusammenhänge sind der Programmers
Reference zu entnehmen die ich den BF-Ausgaben immer beilege.

Ebenfalls damit hängen die Sprünge im Memory-Scroll Fenster zusammen.

> Wenn man als Signal einfach das 1kHz Signal aus dem Oszi nimmt, kann man
> schnell feststellen, das das Triggern nicht wirklich zuverläßig
> funktioniert. Es löst aus, ohne das das Signal hinterher den Schluß
> zuläßt warum.

Also bei mir läßt sich das sehr gut nachvollziehen. Er triggert genau
mit dem richtigen Pretrigger an der richtigen Flanke des nächsten
Messdurchgangs. Also genau das was er soll.

> Ferner kann mann mit dem 1kHz Signal beim Verlängern der Zeitbasis schön
> sehen, wie Schwebungen entstehen, d.h. es erscheint beim langsamen
> Abtasten die Schwebung aus dem Signal und der Abastrate.

korrekt. Das ist halt die Natur der Sache.

> Schöner wäre,
> wenn man erkennen könnte, dass das Signal zu schnell für die Abtastrate
> ist.

Das hieße, das man während der Messung die ganze Zeit die Hauptfrequenz
des Signals bestimmen müßte und dann auf das Abtasttheorem überprüfen
müßte. Das kostet Performance, was sich in niedrigeren
Bildwiederholraten äußert. Könnte man natürlich evtl. abschaltbar
machen. Ist der praktische Nutzen denn so hoch? Wird das an anderen DSOs
so gemacht?

Gruß Hayo

Hayo W. schrieb:
> Rainer H. schrieb:
>> Hallo zusammen,
>> ich habe gerade mal mit der "Single" Messung gespielt. Ich gehe davon
>> aus, dass eigentlich eine Messung beim Erkennen des Triggers ausgelöst
>> werden soll, aber...
>
> korrekt, tut es auch. Hab es gerade geprüft.
>

Hm. Bei mir auch, manchmal, scheinbar abhängig von der Zeitbasis.
Langsamer ist besser ?
Einstellungen: 1kHz Rechteck (Oszi), (1:10) 200 mV/ 20µs, Stop, dann
Single, mehrfach, der Trigger wird nicht getroffen.


>> Beim Stop läßt sich die Zeitbasis nicht wirklich verändern (kürzere
>> Zeiten werden nicht erreicht). Dabei springt der eingeblendete Balken
>> mit dem Triggericon komisch.
>
> Da im Stopmodus keine neuen Messungen durchgeführt werden (sagt der Name
> ja schon) kann die Zeitbasis nur im Rahmen des aktuellen
> Messwertevorrats verändert werden. Dieser hängt von der zuletzt
> eingestellten Zeitbasis ab. Genaue Zusammenhänge sind der Programmers
> Reference zu entnehmen die ich den BF-Ausgaben immer beilege.
>
> Ebenfalls damit hängen die Sprünge im Memory-Scroll Fenster zusammen.
>

Ich glaube die Reference ist zu hoch / unerklärt für mich.

Versuch doch mal im Stop die Zeitbasis zu ändern und dann per Single
oder Run zu messen. Irgendwie ändert sich die Zeitbasis nicht.
D.h. die Anzeige in der ersten Zeile ändert sich, das (erfasste) Signal
auch, aber nicht wie erwartet. Bei weiteren Messungen stimmt die
Zeitbasis nicht mehr. Auch die Frequenzmessung per Quick Measure
stolpert.

>> Wenn man als Signal einfach das 1kHz Signal aus dem Oszi nimmt, kann man
>> schnell feststellen, das das Triggern nicht wirklich zuverläßig
>> funktioniert. Es löst aus, ohne das das Signal hinterher den Schluß
>> zuläßt warum.
>
> Also bei mir läßt sich das sehr gut nachvollziehen. Er triggert genau
> mit dem richtigen Pretrigger an der richtigen Flanke des nächsten
> Messdurchgangs. Also genau das was er soll.
>
>> Ferner kann mann mit dem 1kHz Signal beim Verlängern der Zeitbasis schön
>> sehen, wie Schwebungen entstehen, d.h. es erscheint beim langsamen
>> Abtasten die Schwebung aus dem Signal und der Abastrate.
>
> korrekt. Das ist halt die Natur der Sache.
>
>> Schöner wäre,
>> wenn man erkennen könnte, dass das Signal zu schnell für die Abtastrate
>> ist.
>
> Das hieße, das man während der Messung die ganze Zeit die Hauptfrequenz
> des Signals bestimmen müßte und dann auf das Abtasttheorem überprüfen
> müßte. Das kostet Performance, was sich in niedrigeren
> Bildwiederholraten äußert. Könnte man natürlich evtl. abschaltbar
> machen. Ist der praktische Nutzen denn so hoch? Wird das an anderen DSOs
> so gemacht?

Wie die anderen Hersteller das erkennen weiß ich ehrlich gesagt nicht.
Unser Tek TDS220 zeigt ein zu schnelles Rechteck als vollständig
gefüllte Fläche an, so als wenn die Pegelwechsel häufiger sind als die
Pixelbreite es hergibt.
Ich hoffe mich verständlich ausgedrückt zu haben. Für mein Empfinden ist
das stimmiger, dann komme ich auf die Idee "reinzuzoomen" bis ich was
erkennen kann. Beim Welec komme ich mglw. gar nicht auf die Idee der
Unterabtastung.

>
> Gruß Hayo

Gruß,
Rainer

Rainer H. schrieb:

> Hm. Bei mir auch, manchmal, scheinbar abhängig von der Zeitbasis.
> Langsamer ist besser ?
> Einstellungen: 1kHz Rechteck (Oszi), (1:10) 200 mV/ 20µs, Stop, dann
> Single, mehrfach, der Trigger wird nicht getroffen.

Ok, hab Deinen speziellen Fall mal nachgestellt. Wenn die Signalperiode
nicht mehr auf den Screen passt trifft der Trigger irgendwie nicht
richtig. Sobald mindestens eine Periode zu sehen ist klappt es.

Der Grund ist mir momentan nicht genau bekannt. Ich kann da nur so
ungefähr vermuten.


> Versuch doch mal im Stop die Zeitbasis zu ändern und dann per Single
> oder Run zu messen. Irgendwie ändert sich die Zeitbasis nicht.
> D.h. die Anzeige in der ersten Zeile ändert sich, das (erfasste) Signal
> auch, aber nicht wie erwartet. Bei weiteren Messungen stimmt die
> Zeitbasis nicht mehr. Auch die Frequenzmessung per Quick Measure
> stolpert.

Ja Du hast recht. Das ist definitiv ein Bug. Da muß ich wohl mal ran.
Danke für den Tip.


> Wie die anderen Hersteller das erkennen weiß ich ehrlich gesagt nicht.
> Unser Tek TDS220 zeigt ein zu schnelles Rechteck als vollständig
> gefüllte Fläche an, so als wenn die Pegelwechsel häufiger sind als die
> Pixelbreite es hergibt.
> Ich hoffe mich verständlich ausgedrückt zu haben. Für mein Empfinden ist
> das stimmiger, dann komme ich auf die Idee "reinzuzoomen" bis ich was
> erkennen kann. Beim Welec komme ich mglw. gar nicht auf die Idee der
> Unterabtastung.

Es könnte aber sein dass das kein Feature ist, sondern nur daran liegt,
dass die Bildschirmauflösung von 320 x 240 beim Tek nicht mehr hergibt!

Gruß Hayo

Hayo W. schrieb:
> Es könnte aber sein dass das kein Feature ist, sondern nur daran liegt,
> dass die Bildschirmauflösung von 320 x 240 beim Tek nicht mehr hergibt!

Der TDS220 kann die Signaländerungen zwischen den später gespeicherten
Abtastpunkten erkennen, wenn er im Peak Detect Mode läuft:
"Peak Detect - High frequency and random glitch capture; captures
glitches as narrow as 10 ns using acquisition hardware at all time/div
settings between 5 µs/div and 5 s/div."

Hayo W. schrieb:
> Es könnte aber sein dass das kein Feature ist, sondern nur daran liegt,
> dass die Bildschirmauflösung von 320 x 240 beim Tek nicht mehr hergibt!
>
> Gruß Hayo

Stimmt wohl. Allerdings finde ich ein "zu schnell" wechselndes Signal,
das quasi statisch dargestellt wird, irreführend. Mir ist schon klar,
dass die Schwebung von Signal und Abtastung so aussieht. Die
Signaländerung fällt dabei jedoch völlig unter den Tisch. Wie gesagt,
man muß immer viele (schnelle) Zeitbereiche durchgehen um rauszukriegen,
wie das Signal wohl wirklich aussieht. Irgendein Hinweis auf die (nicht
dargestellten) Pegeländerungen wären schön, und der "vollgemalte"
Bildschirm ist recht intuitiv.

Gruß,
Rainer

In diesem Fall hilft "Autoscale". Dann wird nämlich auf die Zeitbasis
geschaltet die den tatsächlichen Verlauf anzeigt.

Gruß Hayo

Hayo W. schrieb:
> In diesem Fall hilft "Autoscale". Dann wird nämlich auf die Zeitbasis
> geschaltet die den tatsächlichen Verlauf anzeigt.
>
> Gruß Hayo

Guter Tipp.
Allerdings gibt es danach wieder 2 Häkchen vor den Triggermodi.
Der Trigger im "Auto" Modus scheint auch von einer ganzen (Signal-)
Periode abhängig zu sein (wie "Single"), vielleicht hilft das beim
Fehler einkreisen...

Gruß,
Rainer

Rainer H. schrieb:
> Hayo W. schrieb:
>> In diesem Fall hilft "Autoscale". Dann wird nämlich auf die Zeitbasis
>> geschaltet die den tatsächlichen Verlauf anzeigt.
>>
>> Gruß Hayo
>
> Guter Tipp.
> Allerdings gibt es danach wieder 2 Häkchen vor den Triggermodi.

Upps, stimmt. Hatte ich auch noch nicht gesehen - kommt auch auf die
Liste!

> Der Trigger im "Auto" Modus scheint auch von einer ganzen (Signal-)
> Periode abhängig zu sein (wie "Single"), vielleicht hilft das beim
> Fehler einkreisen...

Muß ich mir mal näher ansehen.

Gruß Hayo

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

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,

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

Hallo zusammen, hallo Hayo,
ich hätte noch einen Bug zu melden und einen Wunsch für die SW
anzuregen.

Bug: Die PreTrigger Anzeige wechselt beim Ändern der Zeitbasis nicht,
erst wenn sie das nächste Mal verstellt wird.
Anmerkung: Ein bisschen irritierend finde ich den PreTrigger eh, für
mich ist die zeitliche 0 eher im Kordinatenursprung, d.h. PreTrigger 0
würde für mich zur Anzeige des Triggers in der Mitte des Bildschirmes
führen. Neg. Zeiten nach links, pos. nach rechts. Vielleicht bin ich
auch nur TDS-geprägt. Was sagen unsere erfahrenen Experten dazu?

Wunsch: In der "Delayed" Anzeige die Einstellung der Zeitbasis zu
erlauben und die "Zoomstufe" über den universellen Drehknopf zu
verändern. Vorteil: Man muß nicht zw. "Main" und "Delayed" über die
Softkeys umschalten um die Zeitbasis zu ändern. Vielleicht könnte man
auch noch weiter reinzoomen?

Viele Grüße,
Rainer

Hallo Rainer H.,

Rainer H. schrieb:
> Anmerkung: Ein bisschen irritierend finde ich den PreTrigger eh, für
> mich ist die zeitliche 0 eher im Kordinatenursprung, d.h. PreTrigger 0
> würde für mich zur Anzeige des Triggers in der Mitte des Bildschirmes
> führen.

ich finde, man braucht beides. Die übliche und aktuell imlementierte
Pre-Trigger Logik ist historisch aus Pre-DSO-Zeiten gewachsen. Ohne
Speicher beginnt das Bild zwangsweise immer erst mit dem
Trigger-Ereignis. In Anlehnung daran beginnt beim DSO die
Datenaufzeichnung bei Pre-Trigger Einstellung "0" mit dem
Triggerereignis.
Eigentlich gibt es zwei verschiedene Bedienphilosophien zwischen denen
man umschalten können müßte: Eine für Meßaufgaben die triggerzentriert
sind (deine Version) und die klassiche Version für Signale, die auf den
Triggerzeitpunkt folgen.

Im jetzigen Stadium würde ich eine Umschaltung aber als "nice-to-have"
einordnen.

Gruß
Rainer W.

Hallo allerseits,

leider komme ich immer noch nicht dazu auf die Posts hier zu antworten,
ich muß Euch leider auf morgen vertrösten.

Gruß Hayo

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 Peter,

>...Das gleiche
>Problem habe ich auch wenn ich vom Handy oder der Kamera aus per
>Infrarot (ist auch als COM angemeldet) was übertragen will...


Sind denn die Parameter vom Comport bei beiden Rechnern identisch?
Baudrate, Protokolle, FIFO-Puffer, etc. ?

Gruß Michael

Ja, die sind gleich eingestellt. Obwohl ich an den Werten vom Fifo noch
nie was rumgestellt habe.

Hi 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

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

Ein Wiki haben wir doch schon:

http://sourceforge.net/apps/trac/welecw2000a/

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

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

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

Die Welecs orientieren sich stark an Agilent (HP). Wobei es natürlich
jetzt Firmwareseitig einige Abweichungen gibt.

Gruß Hayo

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/brows...

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.js...

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

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

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

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

Ja ich hab das jetzt auch auch nur schnell rausgehauen, damit alle
LED-Löter schon mal was zum angucken haben. Das "offizielle" Release
wird noch etwas dauern, da ich im Augenblick etwas viel zu tun habe.

Gruß Hayo

Hallo zusammen,

ich glaub ich hab im Screenshot-Programm ein kleinen Bug gefunden:
Die Abfrage auf eine gültige Startnummerierung ist nicht ganz richtig.

ndex: w2000a-screenshot.cpp
===================================================================
--- w2000a-screenshot.cpp       (Revision 417)
+++ w2000a-screenshot.cpp       (Arbeitskopie)
@@ -886,7 +886,7 @@
                        break;
                case 'n':
                        fnum = atoi(optarg);
-                       if (fnum < 0 && fnum > 9999)
+                       if (fnum < 0 || fnum > 9999)
                                errx(1, "invalid start of file numbering given, use -n num, where 0 <= num <= 9999");
                        break;
                case 'i':

Noch ein kurzer Hinweis,

in der 2.0 prev muckt der Triggerlevel etwas aufgrund der aktuellen
Änderungen, also nicht wundern, ich korrigiere das noch und gebe dann
eine korrigierte prev raus, da die Baustelle an der FFT noch etwas
länger dauert.

Die XY-Funktion ist übrigens schon Bug bereinigt und läuft auch
schneller als vorher.



@frankalicious

ist das die BF oder die OS Version? Ich schau da mal bei Gelegenheit
nach.


Guats Nächtle

Hayo

Hayo W. schrieb:
> @frankalicious
>
> ist das die BF oder die OS Version? Ich schau da mal bei Gelegenheit
> nach.

Es geht um das PC Screenshot Programm. Da gibt es doch kein BF und OS,
oder?
Die Zeilenangaben beziehen sich auf die Version im fmf branch, wobei die
Version im trunk das gleiche Problem hat.

A. F. schrieb:
> Hayo W. schrieb:
>> @frankalicious
>>
>> ist das die BF oder die OS Version? Ich schau da mal bei Gelegenheit
>> nach.
>
> Es geht um das PC Screenshot Programm. Da gibt es doch kein BF und OS,
> oder?

Doch, gibt es!
Kann am DSO über die Softkeys ausgewählt werden und die Software
Screenshot für OS und BF, ist in den vorherigen Bf-Versionen mit
enthalten!
Siehe Foto!!!

> Die Zeilenangaben beziehen sich auf die Version im fmf branch, wobei die
> Version im trunk das gleiche Problem hat.

Gruß Michael

Ja hatte ich auch schon angedacht, das könnte man im Hardwaremenü mit
unterbringen. Dann ließe sich das schön nach eigenen Bedürfnissen
anpassen.

Gruß Hayo

@ Hajo,
ich habe auch noch einen kleinen Schönheits-Bug, falls du da im Source
mal vorbeikommst:

Wenn für den Erfassungs-Mode "Noise Filter" aktiv war, sind nach einem
"Autoscale" zwei Haken im Menü ("Normal" und "Noise Filter")

Alles klar Rainer,

das läßt sich schnell beheben, werd ich nachher mal machen.

Gruß Hayo

A. F. schrieb:
> Hayo W. schrieb:
>> @frankalicious
>>
>> ist das die BF oder die OS Version? Ich schau da mal bei Gelegenheit
>> nach.
>
> Es geht um das PC Screenshot Programm. Da gibt es doch kein BF und OS,
> oder?
> Die Zeilenangaben beziehen sich auf die Version im fmf branch, wobei die
> Version im trunk das gleiche Problem hat.

Hi frankalicious

habe ich gerade im fmf-branch gefixt.

Und es gibt Unterschiede im Screenshot zwischen BF und OS - auch gerade
im Bezug auf den fmf-Branch (u.a. weil dieser bei den Dumps Meta-Daten
übermittelt)

Grüße,

  rowue

So, rechtzeitig zum Wochenende für's heimische Basteln die 2.
Kompilation der BF.2.0 prev.

- die LED Ansteuerung ist jetzt korrigiert
- der Autoscale/Acquire-Menu Bug ist gefixed
- der Puls Width Bug ist gefixed (aber nur kurz geprüft)
- der Mode/Coupling Button hat jetzt eine erweiterte Funktionalität, man
kann durch wiederholtes Drücken den Triggermode umschalten

Viel Spaß

Hayo

Hallo Hayo,
das Umstellen des Modus gefällt mir gut. Schönes Feature.
Ich nehme an, Du bist bei der PreTrigger Anzeige (und den etwas wirren
Sprüngen der PreTrigger Zeit beim Wechsel der Zeitbasis) noch nicht
vorbeigekommen?

@LEDs:
Wir 2-Kanaler (W2022) habe noch 2 fast sichtbare LEDs unter den (nicht
vorhandenen) Kanal-Wahl-Knöpfen. Und vermutlich noch jede Menge
zugehörige IOs (nicht vorhandene Tasten, Knöpfe). Kann man die nicht
noch (sinnvoll) verwerten, ohne die SW komplett zu verkomplizieren?
Obwohl... ist vielleicht eher was für den HW-Thread.


Viele Grüße,
Rainer

Wo ich gerade am Updaten bin - ich habe den Single-Trigger Bug
beseitigt. Hier die dritte Kompilation.

@Mirko

>wenn ich den Noise-Filter
>einschalte und dann die Kiste aus und wieder an mache ist die
>Einstellung wieder weg.

Nicht alle Veränderungen werden sofort gespeichert, sondern nur
"wichtige" Ereignisse, z.B. bei Veränderung der Timebase oder Ähnliches,
da sonst die Bedienung zu zäh wird (das Schreiben ins Flash dauert
relativ lange). Wenn Du also nach dem Einstellen des Noise-Filter
einfach an der Timebase drehst wird es auch gespeichert.

Gruß Hayo

Steffen Weiß schrieb:

> Leider besitze ich kein Vergleichsgerät, aber mich würde sehr
> interessieren, bis zu welcher Bandbreite das scope mit der aktuellen
> Firmware brauchbare Messergebnisse liefert?

Also bis 60MHz in der High Frequency Einstellung (Hardwaremenu) kein
Problem. Auch bei höheren Frequenzen geht es noch, aber die Amplitude
stimmt dann nicht mehr, weil der Amplitudengang bei Frequenzen ab 100MHz
einen ziemlichen Buckel hat.

> Ich hoffe das ist nicht zu dämlich gefragt.

Niemals!

> Zur Firmware selbst:
>
> -Könnte man bei der Cursorfunktion den Regler etwas empfindlicher
> machen? Bei mir funktionieren die nur sehr langsam, und es ist ein ganz
> schönes gekurbel, bis man einen Impuls ausgemessen hat. Und ich hab
> dabei immer angst, dass der Knopf draufgeht ;)

An der Sache bin ich schon länger dran, das ist leider ein unschöner
Punkt. Ich habe da schon mit Quadratischen und Kubischen Kennlinien
experimentiert, aber es ist immer der Spagat zwischen schnell und genau.

> - Bei der Quickmeasure funktion lässt sich die Quelle bei mir nicht mit
> dem Softbutton umschalten.

Muß ich mir mal ansehen...
>
> - Wenn ich z.B. das 1kHz Rechtecksignal nehme, lässt es sich ganz normal
> darstellen, bis ich die Zeitauflösung so hoch wähle, dass weniger als
> eine Periode dargestellt werden. Ab diesem Zeitpunkt lässt sich das
> Signal nicht mehr triggern. Ist das normal? Ich meine mich dunkel daran
> erinnern zu können, dass das bei den analogen in der Ausbildung nich so
> war.

Du mußt den Triggermode auf Normal oder Combi stellen, dann geht's!

Gruß Hayo

Hi Steffen,

>> - Bei der Quickmeasure funktion lässt sich die Quelle bei mir nicht mit
>
>> dem Softbutton umschalten.

Habe gerade mal dein Problem getestet, das Umschalten des Sourcekanal im
Quickmeasure dauert zwar einen Augeblick, funzt aber einwandfrei!


Gruß Michael

Hallo Steffen,

der Combi Trigger ist eine spezielle Funktion (geschrieben von Stefan)
für das Welec als Alternative zum teilweise schlecht funktionierenden
Autotrigger. Die Namensgebung sagt es eigentlich schon, es ist eine
Kombination aus Autotrigger und Normaltrigger.

Das wesentliche Problem beim Autotrigger ist der recht kurze Timeout,
deshalb funktioniert er bei hohen Frequenzen ganz anständig, bei
niedrigen aber eher nicht so gut. Der Combi-Trigger hat einen wesentlich
längeren Timeout und arbeitet daher auch bei niedrigen Frequenzen recht
zuverlässig.



Zum Quickmeasure: Das Bedienkonzept ist so, dass mit "Select" die Art
der Messung ausgewählt wird und mit "Measure" die Auswahl angewendet
wird. Wenn Du also die Source wechselst, änderst Du nicht die laufende
Messung, sondern Du mußt mit "Select" und "Measure" dem Gerät mitteilen,
dass Du ein neue Messung auf einem andern Kanal machen möchtest.

Deine Firmware wird schon ganz richtig aufgespielt sein, denn es geht
entweder ganz oder gar nicht.

Gruß Hayo

Oh, Stefan war schneller als ich :-)

@ Hayo

Mit dem Pulse Width Trigger sehe ich noch zwei Probleme:

1. Die Triggerlevel Anzeige (Marke im Screen) wird für Ch.1 angezeigt
und reagiert auf den Level-Regler. Das DSO triggert aber auf Ch.2 auf
einen anderen Level, der unter Edge-Trigger vorher mal für Ch.2
eingestellt war und irgendwo in der Mitte des Ch.2-Signals liegt.

2. Wieso triggert das DSO überhaupt (oft) an der Stelle auf das gezeigte
Ch.2-Signal? Signaldauer ist "50 us" und Triggerbedingung ist " > 80
us".

Und noch eine Anregung: Ich fände es praktisch, wenn der Softbutton
"PreTrig" aus dem "Edge"-Triggermenü auch im "Pulse Width"-Menü zur
Verfügung stände. Platz wäre ja noch und man könnte sich das Hin- und
Herschalten sparen.

Gruß und schönen Sonntag
Rainer

Rainer W. schrieb:
> @ Hayo
>
> Mit dem Pulse Width Trigger sehe ich noch zwei Probleme:

Muß ich mir mal in Ruhe ansehen

> Und noch eine Anregung: Ich fände es praktisch, wenn der Softbutton
> "PreTrig" aus dem "Edge"-Triggermenü auch im "Pulse Width"-Menü zur
> Verfügung stände. Platz wäre ja noch und man könnte sich das Hin- und
> Herschalten sparen.

Ist machbar, mal sehen ob ich das irgendwo mit einschieben kann.

Gruß Hayo

super Arbeit bisher, wäre es vielleicht noch möglich ins Denoise-Menü
einen 6 oder 7 bit Modus zu integrieren, also einfach ein oder 2
Schiebe-Befehle und das störende Rauschen bei binär Signalen wäre
Vergangenheit.

Hallo zusammen,

zuerst einmal danke an Hayo, der so viel Zeit investiert um eine gute
Firmware für das W20xx zu erstellen.

Wie ich schon vor längerer Zeit angekündigt habe, wollte ich mich ja mit
einem besseren Firmware-Updater für Windows beschäftigen. Na ja, wie das
mit solchen Vorhaben so ist, immer kommt etwas wichtigeres dazwischen.

Aber dieses Wochenende habe ich mir die USB-Kommunikation einmal
angesehen und kann unter Windows schon einmal (ohne extra Treiber - nur
HID-Modus) Befehle an das Scope senden. D.h. Buttons ein-/ausschalten
geht schon mal. Bevor ich jetzt versuche die Firmware über die
Flash-Befehle in der BF-Firmware zu flashen hätte ich noch zwei fragen:

@Hayo: Funktionieren die in der Tabelle dokumentierten Flash-Befehle
(lesen/schreiben) in der Firmware? Nicht das ich hier etwas versuche,
was noch nicht implementiert ist.

@Alle: Kann ich mir das Scope kaputt flashen oder kriege ich über den
GERMS-Montior immer ein Backup in den Flash gespielt? So wie ich die
bisherigen Posts verstandan habe: Ja - oder?

@Alle: Gibt es schon einen USB-Uploader für Windows (ich hab nichts
gefunden)? Nicht dass ich hier das Rad zum zweiten mal erfinde...

Ich werd's jetzt erst einmal mit einem Flash-Dumper per USB versuchen.
Danach mache ich mich daran einen SREC-Parser zu basteln. Hoffentlich
dauert's diesmal nicht wieder 10 Monate ;)

Thomas O. schrieb:
> super Arbeit bisher, wäre es vielleicht noch möglich ins Denoise-Menü
> einen 6 oder 7 bit Modus zu integrieren, also einfach ein oder 2
> Schiebe-Befehle und das störende Rauschen bei binär Signalen wäre
> Vergangenheit.

Hallo Thomas,

eine solche Funktion habe ich bislang nicht eingebat, da es die
Situation nicht wirklich verbessert. Man sieht zwar das Rauschen nicht
mehr, aber es wird ja dadurch nicht der Rauschabstand verbessert. D.h.
man macht das DSO im Prinzip nur unempfindlicher.

Da der Aufwand aber nicht so groß ist kann ich das mal mit einbauen,
dann kann man sich das aussuchen.

Gruß Hayo

Daniel G. schrieb:

> Wie ich schon vor längerer Zeit angekündigt habe, wollte ich mich ja mit
> einem besseren Firmware-Updater für Windows beschäftigen. Na ja, wie das
> mit solchen Vorhaben so ist, immer kommt etwas wichtigeres dazwischen.

Ja das kenne ich auch gut...

> Aber dieses Wochenende habe ich mir die USB-Kommunikation einmal
> angesehen und kann unter Windows schon einmal (ohne extra Treiber - nur
> HID-Modus) Befehle an das Scope senden. D.h. Buttons ein-/ausschalten
> geht schon mal. Bevor ich jetzt versuche die Firmware über die
> Flash-Befehle in der BF-Firmware zu flashen hätte ich noch zwei fragen:

Super, das ist ja echt prima. Ich komme nämlich erstmal nicht dazu. Ich
nehme an Du hast Dir das Template für Linux schon mal angesehen welches
ich beigepackt hatte. Für WINUSB sollte das recht ähnlich gehen.
Desweiteren hatte ich im Internet eine Seite gefunden auf der sie zeigen
wie man schnell und einfach ein grafisches (WIN) Interface baut um einen
µC über USB anzusteuern. Die Seite müßte ich sonst noch mal raussuchen
wenn Du willst.

> @Hayo: Funktionieren die in der Tabelle dokumentierten Flash-Befehle
> (lesen/schreiben) in der Firmware? Nicht das ich hier etwas versuche,
> was noch nicht implementiert ist.

Also es gibt zwei APIs, nämlich das Alte von WELEC, dass ich soweit
repariert habe, dass die PC-Sofware so einigermassen funktioniert.

Und dann das Neue von mir. Wenn Du jetzt neue Funktionen implementierst,
bitte das neue API verwenden, denn das Alte ist völlig verwurstet und
unübersichtlich. Beide findest Du in dem File commif_t.cpp der
Firmware-Source. Die Befehle sollten eigentlich aktuell sein, aber sind
noch nicht alle fertig implementiert. Das Schreiben ins Flash z.B. ist
im neuen API noch nicht implementiert. Falls Du da was brauchst, was
noch fehlt , dann sag bescheid, ich bau Dir das dann ein - oder Du
machst es selber und schickst mir das dann.


> @Alle: Kann ich mir das Scope kaputt flashen oder kriege ich über den
> GERMS-Montior immer ein Backup in den Flash gespielt? So wie ich die
> bisherigen Posts verstandan habe: Ja - oder?

Solange Du ein Backup hast kannst Du Dein Flash ruhig komplett löschen,
Du kannst es über den GERMS-Monitor immer wieder laden. Kein Grund zur
Sorge also.

> @Alle: Gibt es schon einen USB-Uploader für Windows (ich hab nichts
> gefunden)? Nicht dass ich hier das Rad zum zweiten mal erfinde...

Nein. Gibts noch nicht. Wäre mal eine coole Sache, weil es gerade für
Neueinsteiger viel einfacher wäre.

> Ich werd's jetzt erst einmal mit einem Flash-Dumper per USB versuchen.
> Danach mache ich mich daran einen SREC-Parser zu basteln. Hoffentlich
> dauert's diesmal nicht wieder 10 Monate ;)

Wenn Du Infos brauchst, einfach nachfragen, ich bemühe mich da möglichst
schnell zu antworten.

Gruß Hayo

@Hayo: Danke, ja mir ist klar das das keinerlei Verbesserung in der
Erfassung bringt, rein optisch ist es aber ne feine Sache wenn man nur
mal serielle Daten Anzeigen möchte und dort nicht unbedingt das Rauschen
drauf ist.

Ich seh mal zu , dass ich das in der nächste Zeit mit einbaue.

Zum Noise Filter:

Im Gegensatz dazu bringt der Noisefiltzer tatsächlich eine Verbesserung.
Denn der filtert nur den Durchschnitt an kurzfristigen Ereignissen
heraus.

Ein Rechtecksignal z.B. würde aber tatsächlich noch mit voller Auflösung
angezeigt werden, auch wenn es nur ein Bit Amplitude hätte, was etwa 2
bis 3 Pixel entspricht.

Gruß Hayo

Daniel G. schrieb:
> @Alle: Gibt es schon einen USB-Uploader für Windows (ich hab nichts
> gefunden)? Nicht dass ich hier das Rad zum zweiten mal erfinde...

Hallo Daniel,
nein, musst du nicht. Bei sourceforge gibts eine SW von Markus Mueller
fuer Windows und Linux (WelecUpdater.exe). Leider dauert der DL (unter
Windows) doppelt so lang wie beim GERMSloader. Upload keine Ahnung.
Ausserdem hat er kleine Fallstricke, wie hier beschrieben
http://sourceforge.net/apps/phpbb/welecw2000a/view...
Den Link zur SW gibts da auch. Sourcen gibt es glaube ich auch.

Gruss, Peter

Hallo Admin,
bitte loesch doch den Mist von mir! Gnadenlos die Frage nicht verstanden
;-) Sorry!

Gruss, Peter

Peter M. schrieb:
> Daniel G. schrieb:
>> @Alle: Gibt es schon einen USB-Uploader für Windows (ich hab nichts
>> gefunden)? Nicht dass ich hier das Rad zum zweiten mal erfinde...
>
> Hallo Daniel,
> nein, musst du nicht. Bei sourceforge gibts eine SW von Markus Mueller
> fuer Windows und Linux (WelecUpdater.exe). Leider dauert der DL (unter
> Windows) doppelt so lang wie beim GERMSloader. Upload keine Ahnung.
> Ausserdem hat er kleine Fallstricke, wie hier beschrieben
> http://sourceforge.net/apps/phpbb/welecw2000a/view...
> Den Link zur SW gibts da auch. Sourcen gibt es glaube ich auch.
>
> Gruss, Peter