Wittig(welec) DSO W20xxA Open Source Firmware (Teil3)

[Roberto (Gast)]

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

[Mirko B. (horace)]

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

[Peter M. (none)]

Hallo rowue,

Rolf W. schrieb: Wittig(welec) DSO W20xxA Open 
Source Firmware (Teil2)
> Nein, ich war der erste - mit den 184 ;) - hätten wir uns mal
> absprechen sollen ;)

Ich habe mich missverstaendlich ausgedrueckt. Ich war leider in der 
Mitte dabei: will heissen Auktion vom 23. Jun. 220 Teuro, deswegen 
Glueckwunsch :-)

> Das ist eher eine Preisdeckelung - warum mehr als 295,- bieten ;)

Ja, klar.

>> Ich hatte eine Mail an tek4you_eu geschickt mit dem Angebot ein W2012A
>> fuer 250 Teuro zu erwerben.
>> Keine Antwort. Der Auktionshandel mit Herrn Wittig lief aber sehr rund.
>
> Naja, etwas auf die Lauer legen und Du hast eins für 250 und weniger ;)

Stimmt.

>>> Generell sollte - egel ob BF oder OS die Hardware-Version egal...
>>
>> Vielen Dank, danach habe ich gesucht 8))) Dann bleibt 8C7.0E drauf ;-)
>
> Etwas anders als Du denkst ;) - aber Backup von der alten,
> OS/BF Fw drauf und gut ist ;)

Meine Frage bzgl. Hardware-Version war dahingehend, dass diese den 
Versionsstand der Signalverarbeitung + Nios-Core im FPGA beschreibt A 
(siehe Anhang). Diese wird im SPI-Flash B gespeichert. Bleibt also bei 
8C7.0E.
1.2.BF.1.8 ist der Code fur den Nios, der im parallelen Flash C abgelegt 
wird. Die Nios FW wird ueber RS232 D mittels GERMSloader im Flash C 
gespeichert. Altenativ zu Testzwecken kann man auch das SRAM E nehmen. 
Nach dem Ausschalten natuerlich dann weg. Stimmt das so?

>>> SF ist leider nicht bei allen beliebt ;)
>>
>> Sehr schade! Ich frag mich nur warum? Nur wegen der Anmelderei?
>
> Weiß ich nicht - ich nutze das SVN dort ;)

Ich meinte das Forum 
http://sourceforge.net/apps/phpbb/welecw2000a/index.php Und dann 
Neudeutsch als Sprache, da es ja viele gibt, die mit Deutsch Probleme 
haben.
Dann waere alles zusammen und man koennte in einem Forum suchen!

>> Prima, Hayo hat ja wohl die Vermutung, dass in der Signalverarbeitung im
>> FPGA auch der Wurm drin ist.
>
> Da braucht Hayo keine Vermutung zu haben - dass ist Gewissheit!!!
>
> a) Haben wir letztes Jahr 'nen Filter abgeschaltet, der für
> Schwingungen gesorgt hat - in der OS bleibt der (wahrscheinlich)
> abgeschaltet, in der BF ist er per Default eingeschaltet, kann
> aber übers Menue abgeschaltet werden ;)
> http://sourceforge.net/apps/phpbb/welecw2000a/view...
>
> b) Sind die Signale bei 250/500MSa/s extrem verwürfelt, siehe:
> http://sourceforge.net/apps/trac/welecw2000a/ticket/44
> Das ist gerade mit in dem Schwung, den ich mache und nach dessen
> Abschluß wohl eine OS 0.93 ansteht (wenn keiner schreit ;)
>
> c) Sind die Samples bei 1GSa/s nicht äquistiant, siehe:
> http://sourceforge.net/apps/trac/welecw2000a/ticket/53
>
> a), b) und c) wurden hier (inkl. Thread eins) schon veröffentlicht
> und nachgewiesen - da braucht keiner zu vermuten ;)
>
> Zur Beseitigung der Fehler habe ich "gerade" (März) einen Umzug
> von Hamburg nach Freiburg hinter mir und muß mich hier auch erstmal
> an eine neue Umgebung und einen neuen Tätigkeitsbereich gewöhnen ...
>
> Wen Du mir beim Arbeiten über die Schulter schauen möchtest, meine
> Änderungen pflege ich im branch "rowue-signal" in's svn auf Sourceforge
> ein. Allerdings möchte ich davon abraten, den Source zu verwenden,
> bevor ich ihn in den trunk gemerged (eingefügt) habe, auch wenn
> ich vor dem Commit teste, sind das noch einige offene Baustellen.

Danke fuer die Hinweise, das kommt dann spaeter.

Gruss, Peter

[Rolf W. (rowue)]

Peter M. schrieb:
> Hallo rowue,
>

Hi Peter ...

das sind gerade 1000 Fragen auf einmal, die ich auch nur
zum Teil beantworten kann ;)

> Rolf W. schrieb: Wittig(welec) DSO W20xxA Open
> Source Firmware (Teil2)
>> [Bucht  ...]

O.K. ich hatte mich halt schon länger auf die Lauer gelegt
und mir 'nen Maximalpreis ausgemacht - diesmal hatte ich
sehr viel Glück ... - Allerdings habe ich auch schon
ein 2014, also nicht den Druck ;) -
>
>>> [Bucht II]

Interessanterweise werden nach dem letzten Handel keine
neuen Geräte reingestellt - aber vielleicht warten die
Herren auch gerade die WM ab (könnte sich lohnen ;)

>
>>>> Generell sollte - egel ob BF oder OS die Hardware-Version egal...
>>>
>>> Vielen Dank, danach habe ich gesucht 8))) Dann bleibt 8C7.0E drauf ;-)
>>
>> Etwas anders als Du denkst ;) - aber Backup von der alten,
>> OS/BF Fw drauf und gut ist ;)
>
> Meine Frage bzgl. Hardware-Version war dahingehend, dass diese den
> Versionsstand der Signalverarbeitung + Nios-Core im FPGA beschreibt A
> (siehe Anhang). Diese wird im SPI-Flash B gespeichert. Bleibt also bei
> 8C7.0E.
> 1.2.BF.1.8 ist der Code fur den Nios, der im parallelen Flash C abgelegt
> wird. Die Nios FW wird ueber RS232 D mittels GERMSloader im Flash C
> gespeichert. Altenativ zu Testzwecken kann man auch das SRAM E nehmen.
> Nach dem Ausschalten natuerlich dann weg. Stimmt das so?

Das wird Dir vielleicht jmd. aus der Leon-3 Gruppe beantworten
können ;) - Ich weiß nur, dass Du mit dem komplett Backup auch
die angesagt Hardware-Version änderst (und deren Verhalten) - sprich:
Wenn Du auf ein .0E das Backup von 'ner 0L einspielst, meldet die
sich als .0L und kann auch Probleme bei der Signal-Aquise haben.

>
>>>> [SF, SVN, PHPBB]
>
> Ich meinte das Forum
> http://sourceforge.net/apps/phpbb/welecw2000a/index.php Und dann
> Neudeutsch als Sprache, da es ja viele gibt, die mit Deutsch Probleme
> haben.
> Dann waere alles zusammen und man koennte in einem Forum suchen!

War mir schon klar ;) - es gab auch immer wieder Versuche, dieses
Forum zum phpBB hinzubewegen - generell ist aber dort die Beteiligung
geringer ... - und menschen sind eher eine träge Masse ;)

>
>>> [Signal-Verarbeitung]

Dieser Umstand wäre etwas, was mich, wenn ich neu einsteigen
würde auch eher zu einer Mitarbeit am Leon-3 als am Nios
anregen würde - die Nios-FW (inkl. FPGA) ist halt etwas sehr
verbuggt ...
>
> Danke fuer die Hinweise, das kommt dann spaeter.
>
> Gruss, Peter

Grüße,

   rowue

[Jürgen (Gast)]

Rolf W. schrieb:
>>
>> Meine Frage bzgl. Hardware-Version war dahingehend, dass diese den
>> Versionsstand der Signalverarbeitung + Nios-Core im FPGA beschreibt A
>> (siehe Anhang). Diese wird im SPI-Flash B gespeichert. Bleibt also bei
>> 8C7.0E.
>> 1.2.BF.1.8 ist der Code fur den Nios, der im parallelen Flash C abgelegt
>> wird. Die Nios FW wird ueber RS232 D mittels GERMSloader im Flash C
>> gespeichert. Altenativ zu Testzwecken kann man auch das SRAM E nehmen.
>> Nach dem Ausschalten natuerlich dann weg. Stimmt das so?
>
> Das wird Dir vielleicht jmd. aus der Leon-3 Gruppe beantworten
> können ;) - Ich weiß nur, dass Du mit dem komplett Backup auch
> die angesagt Hardware-Version änderst (und deren Verhalten) - sprich:
> Wenn Du auf ein .0E das Backup von 'ner 0L einspielst, meldet die
> sich als .0L und kann auch Probleme bei der Signal-Aquise haben.

@ Rolf W.

Das solltest Du inzwischen schon selbst beantworten können!! Dazu ist 
nicht die LEON - 3 Gruppe nötig!
Die Darstellung von Peter M. ist absolut korrekt mit einer kleinen 
Ergänzung:
Die NIOS 1 - Hardware kopiert die NIOS - Firmware nach Reset immer 
zunächst in den RAM ( E ) und startet sie dort!

Die LEON - 3 Entwicklung ist eine hervorragende Arbeit von Alex, die ich 
die ganze Zeit mit Hochachtung beobachtet habe! Aber man kann verfolgen, 
wie lange die Entwicklung bis zum jetzigen Stand gedauert hat. Dabei war 
der Alex der Einzige der FPGA-Gilde, der überhaupt einen brauchbaren und 
funktionierenden Entwurf erreicht hat! ( siehe T8051 - und ZPU - Design 
)
Und es ist bis heute noch nicht ein Design, welches einfach so praktisch 
nutzbar ist.
Deshalb arbeite ich an der Beseitigung der Fehler in der NIOS-1-FW mit, 
sogut es eben meine Zeit zulässt.

@ all
Übrigens denke ich, daß sich Hayo überhaupt nicht rechtfertigen muss, 
wenn da irgend jemand kommt, der es wiedermal besser zu wissen glaubt!!
Solche Diskussionen führen keinen Schritt weiter!
Also bitte: Erst lesen ( wenn es auch teilweise lange dauert ;-) ), dann 
nachdenken und dann erst schreiben!

So, jetzt habe ich auch diesen Thread mit unproduktiven Dingen 
verlängert. Musste aber mal heraus.

Schönen Abend und beste Grüße,
Jürgen

[Jürgen (Gast)]

Hallo Hayo,

wie ist der Stand beim Ext.Trigger?

Habe heute zum Thema ein paar Messungen gemacht. DUT ist W2012A und die 
Screenshots kommen vom W2024A. Hab mir leider durch meinen
Clip den U6/Pin 1 abgerissen :-( Wenigstens halten die Clips ordentlich 
;-)

CH1 : U6/1 ext. Triggerausgang zum FPGA   / Tastkopf 1:1
Ch2 : U16/1 PWM - TP Filter - Ausgang     / Tastkopt 1:10
CH3 : Q4/3 TP - Filter - Eingang  Kollektor Q4   Tastkopf 1:1

Signalgenerator: Eigenbau DDS-2-Kanal mit 2,3 KHz Sinus 6 V pp, 
symmetrisch zu GND

Sieht alles zunächst aus, wie es soll. Allerdings finde ich die 
Ausgangsspannung der PWM ( U6/4) viel zu wellig!Damit ist kein stehendes 
Bild beim Trigger zu bekommen.Ich denke, wir müssen die Dimensionierung 
des aktiven TP-Filter überarbeiten!?
Hast Du irgendwo in der FW etwas gefunden, die Ausgangsfrequenz der PWM 
höher zu setzen? Mit 469 Hz wirkt die TP-Filterdimensionierung nicht so 
gut.

Leider bleibt das 3/4-Problem :-(

Beste Grüße,
Jürgen

[Rolf W. (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

[Peter M. (none)]

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

[Hayo W. (blueflash)]

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

[Hayo W. (blueflash)]

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

[Falk Willberg (dl3daz)]

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

[Hayo W. (blueflash)]

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

[Rolf W. (rowue)]

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

[Hayo W. (blueflash)]

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

[Rolf W. (rowue)]

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

[Querdenker (Gast)]

Hallo,

ganz schön ruhig geworden, lag das nun am Fußballspiel oder liegt das an 
der anstehenden Feriensaison?

Der Querdenker

[Stefan E. (stefan_e)]

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.

[Guido (Gast)]

Hallo Stefan,

niemand hat Schuld, aber am Ende ist die SVN-Version schlicht im
Chaos untergegangen.Jeder hat einfach die öffentliche Version
geändert und kein Mensch hat mehr den aktuellen Zustand überblickt.
Ich bin davon überzeugt, dass die OS-Version zu buggy ist um sie
überhaupt zu testen und habe sie daher auch nie aufgespielt.

Klar bringt eine Versionsverwaltung Vorteile, so stümperhaft
eingesetzt aber sicher nicht. Ich verstehe, dass Hayo nicht
alle Änderungn der OS übernehmen will, was aber noch lange nicht
bedeutet, dass alle Änderungen verworfen werden.

Ein neuer Anlauf mit mehreren Branches wäre sicher machbar.

Gruß, Guido

[Darius (Gast)]

Guido schrieb:
> Ich bin davon überzeugt, dass die OS-Version zu buggy ist um sie
> überhaupt zu testen und habe sie daher auch nie aufgespielt.

Dann hast du sicherlich auch mitbekommen, dass bspw. Rolf daran arbeitet 
und in aller Regelmäßigkeit Änderungen eincheckt und das einige wichtige 
Erkenntnisse dank der OS-Version und deren Mitstreitern erst möglich 
geworden sind?

Dieses Hochgejubel von Hayo - nichts gegen dich persönlich Hayo - ist 
wirklich fehl am Platz und nervt mich persönlich auch schon eine ganze 
Weile. Statt lange herum zu lamentieren sollte mit aller Konsequenz SVN 
oder ähnliches eingesetzt werden, denn wer hat Lust sich das ChangeLog 
durchzulesen, zumal da auch nicht alles drin festgehalten ist.

Wenn angeblich alle an einem Strang ziehen, wie kann es dann zu einer 
Versionstrennung kommen? Am besten trinkt ihr alle mal ein Bier zusammen 
und rauf euch mal wieder zusammen, dann würdet ihr auch wieder 
gemeinschaftliche Fortschritte machen.

Danke.

[Peter M. (none)]

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

[Hayo W. (blueflash)]

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

[Rolf W. (rowue)]

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 (Gast)]

Hallo Rolf,

du jast schon recht, meine Bemerkungen beziehen sich auf den
Stand von vor ca. 2 Jahren. Ich habe damals keine Chance mehr
gesehen die SVN-Änderungen auch nur nachzuvollziehen, das war
einfach zu chaotisch. Wenn du und andere das jetzt sinnvoller
aufziehen, bin ich, wie oben geschrieben, der letzte, der sich
dagegen wehrt.

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

Gruß, Guido

[Rolf W. (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 ;)

[Peter M. (none)]

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

Gruss, Peter

[Falk Willberg (dl3daz)]

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

[Rolf W. (rowue)]

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

[Rolf W. (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 (Gast)]

So, dann haben wir es ja jetzt zusammen: Alle Verbesserungen sind
natürlich wünschenswert! Die Gesamtsoftware ist aber so komplex,
dass jede Änderung in vielen Bereichen Anpassungen erfordert. Die
extrafast-Zeichenroutine muss sich halt auch im Quickmeasure, im
Math-Modus,im XY-Modus, im Delayed-Mode usw. behaupten. Ich finde
die Idee grundsätzlich gut, verstehe aber Hayo, wenn er sie ablehnt,
weil sie in manchen Modi noch nicht funktioniert und hierbei die
Vorteile der Interpolation verloren gehen.

Dieses war mein Hauptproblem mit dem Trunk im SVN. Jeder hat einfach
seine Änderungen eingepflegt und am Ende resultierte eine nur noch
eingeschränkt nutzbare Firmware.

Imho ist Hayos Vorgehen für solche Änderungen optimal, weil er sie
über das Menü ein- und ausschaltbar macht, so dass bis zur
endgültigen Entscheidung jeder User nach seinem Geschmack probieren
kann. Verschiedene Zeichenroutinen hatten wir, Dank Hayo; ja von
Anfang an.

Gruß, Guido

[Rolf W. (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

[Peter M. (none)]

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

[Michael W. (slackman)]

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

[Hayo W. (blueflash)]

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

[Rolf W. (rowue)]

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

[egberto (Gast)]

die 1.3 und 1.2 gibt es immer noch bei welec.de....

[Charly B. (charly)]

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

[Rolf W. (rowue)]

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

[Michael D. (mike0815)]

Hi Rolf,

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

Gruß Michael

[Michael D. (mike0815)]

Ich noch mal,

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

...jetzt muß ich aber los

Gruß Michael

[Peter M. (none)]

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

[Peter M. (none)]

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

[Martin H. (martinh)]

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

[Michael D. (mike0815)]

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?

[Roberto (Gast)]

@Charly B. (charly)
>auch wenns etwas OT ist, ich habe mir bei Wittig ein DSO ersteigert,
>vor fast 2 Wochen bezahlt aber es kommt nix, wirklich nix, ich habe
>Ihn mehrfach angemailt,

Probiere mal alle eMail's die Du von Ihm finden kannst.
(auch die Benachrichtigung über Ebay)
Ich hatte mal an eine eMail von Ihm geschrieben, die auch nie ankam..?!
Die andere die ich gefunden habe, hatte dann funktioniert!
(habe ich aber nicht mehr)

l.G. Robert

[Rolf W. (rowue)]

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)

[Charly B. (charly)]

@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

[Peter M. (none)]

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

[Charly B. (charly)]

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

[Peter M. (none)]

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

[Peter M. (none)]

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

[alex008 (Gast)]

Hallo!

Das Wetter ist nun wieder so schlecht geworden, dass ich wieder fürs 
Entwickeln am LEON3-Design genügend motiviert bin.

@ Übertragungsprobleme über die Serielle für das NIOS-Design:
Ich hatte bei meinem Software-Upload auf dem FPGA unter Windows lange 
sehr viele Probleme. Im Endeffekt war es ein Pufferüberlauf im 
TX-Pufferspeicher, den ich beim WaveRecorder (C++) unter Windows XP mit 
der Funktion FlushFileBuffers() oder ähnlich beseitigt habe.

Im Moment suche ich den Grund, weshalb ich bei meinen Hardware-Filtern 
eine zu geringe Erweiterung der Auflösung in den Bits bekomme. 
Vielleicht liegt es auch daran, dass das Spektrum des Signalrauschens so 
hochfrequent ist, dass einzig die Filterstufe 0 (1GS->100MS) die 
Auflösung definitiv erhöht.
So wie es im Moment ist, macht eine geringere Auflösung als 5 mV/div? 
(nicht nachgemessen und skaliert) keinen Sinn. Das Signal bekommt man 
zwar Rauschfrei rein, sieht aber sehr digital aus.

Dass sich der DAC von mir nicht ansteuern lässt, finde ich auch etwas 
komisch, stimmt da vielleicht der Plan von Slog nicht ganz?


MfG
Alexander

[Michael H. (stronzo83)]

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

[alex008 (Gast)]

Hallo Michael!

Ich habe den Fehler gestern gefunden und behoben!
Es war ein kleine versteckte Verwechslung (for Schleife) im 
SignalSelector, wodurch immer nur die Daten von den ersten 2 
Trigger-Kanälen (der Trigger hat vier 8 Bit Kanäle, der DownSampler 2 16 
Bit Kanäle) an den Trigger weitergegeben wurden.

Jetzt funktioniert es prächtig!
Ich kann damit (momentan noch unskaliert) bei 500 µV/div ein fast 
rauschfreies Signal über den ganzen Bildschirm anzeigen. Einen noch 
kleineren Wertebereich habe ich noch nicht geschafft, da leider mein 
Funktionsgenerator weniger Signal nicht zulässt, und ich keine 100:1 
Tastköpfe besitze!

Der DAC ist das nächste, was ich mir ansehen werde!

Mein aktueller Sourcecode mit dem vorkompilierten SOF-File findet man 
hier.
http://github.com/alexvie/welecw2000a

Anmerkung: Ich habe Roberts Verbesserungen der Bedienbarkeit vom 
WaveRecorder noch nicht eingepflegt, dass kommt sobald ich mit dem DAC 
kommunizieren kann.

Viele Grüße an Alle!
Alexander

[Michael H. (stronzo83)]

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

[Michael D. (mike0815)]

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

[Michael D. (mike0815)]

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

[alex008 (Gast)]

Hallo!

Ich habe hier beide Dateien zum Testen der HW Filter angehängt.

Zum Testen eignet sich ein Frequenzgenerator mit einem HI und einem LO 
Ausgang hervorragend.

Zum Triggern:
Der Trigger ist noch nicht umgeschrieben, damit er 4 Bits von den oberen 
(gemessenen) und 4 Bits von den unteren 8 Bits (erweiterten) triggern 
kann.

Es empfiehlt sich entweder den "Externen Trigger" (Auto Mode) zu 
verwenden, oder auf einen anderen Kanal mit höherem Signalpegel zu 
triggern.

Zur unausgereiften Software:
DC/AC Umschaltung und die Triggerenstellung müssen eingestellt werden, 
die GUI zeigt anfangs noch falsche Einstellungen.

Popup Fenster verschwindet bspw. mit der Mode Coulping Taste.

Das Welec hat Störungen und genügend Rauschen in jedem Frequenzbereich, 
dass ein weiteres Downsampling noch was bringen würde.

10000:1 reicht aber fürs Erste :)!
Rest geht in Zukunft mit Software im schaffbaren Roll-Mode!

WaveRecorder version sollte egal sein, solange neuer als die vom Preview 
ist!

ProbeComp geht noch nicht!

Viel Freude beim Ausprobieren!
Alexander

[branadic (Gast)]

Hallo und guten Abend,

wie ihr vielleicht Walters Messprotokoll entnommen habt hat die neue 
Eingangsstufe einen Stand erreicht, an der sie nicht mehr nur extern 
getestet werden kann, sondern direkt mit dem Oszi verheiratet werden 
muss.

Dazu ist es notwendig, dass das Oszi die Programmierung der 
Eingangsstufe übernimmt.
Grundsätzlich ist es erst einmal wurscht ob das im NIOS oder im LEON 
durchgeführt wird, wichtig ist vielmehr dass es irgendwo implementiert 
wird und getestet werden kann.

Das Rauschen ist, wie ebenfalls dem Protokoll von Walter entnommen 
werden kann, unter Laborbedingungen soweit reduziert worden, dass nun 
auch vertikale Ablenkungen bis 1mV/div einstellbar sein sollten. Also 
ein deutlicher Performancegewinn.

Daher nun meine Bitte an alle Programmierer die Schnittstelle für die 
neue Eingangsstufe zu implementieren. Denn leider scheint es hier 
reichlich ruhig geworden zu sein.

Danke, branadic

[jofri (Gast)]

Hallo!

angeregt durch die Diskussion habe ich auch ein W2012 HW-Version 8C7.0E 
ersteigert.
Beim Testen ist mir aufgefallen das die TB bei 10MSa/s nicht genau 
stimmt.

Bild 1 : CAN-Datentelegramm im Base Frame Format
  ID 555, 8 Datenbyte mit Wert 0x55, Baudrate 500 Kbit/s
  zwischen X Cursors genau 83 bit, korrekte Darstellung bei 5MSa/s
  gezoomt auf 20µs/div
Bild 2 : dasselbe noch ein Mal bei 10MSa/s

TB-Register 0xFFFFFFF3 -> ca. 9,638 MSa/s default
TB-Register 0xFFFFFFF4 -> ca. 10,4 MSa/s

Das ist bei der org. FW 1.4 sowie 1.2.BF.1.8 und 1.2-OS-0.92a gleich.


Ist das bei euch auch so?

Durch weitere Versuche habe ich herausgefunden, das man bei
TB-Register 0xFFFFFFF6 ziemlich genau auf 12,5MSa/s kommt.
Wenn man jetzt den Faktor 4 auf 5 ändert sollte, alles genau stimmen.
Nur da bin ich auf eure Hilfe angewiesen. Ich verwende derzeit den SF 
trunk (rev317)
und weiß einfach nicht was alles zu ändern ist, damit alle modes das 
auch mitbekommen.
An dieser Stelle noch ein herzliches Danke an alle die mit geholfen 
haben die Firmware zu verbessern.

Grüße, jofri

[Guido (Gast)]

Oha, mal wieder ein Anfänger mit Oszi. Die Zeitbasiseinstellung dieser
Geräte gibt man in s/Div an, nicht in S/s. Dann stimmt die Anzeige
ganz offensichtlich und du musst dir keine Sorgen machen.

Aber mal im Ernst, würdest du die Firmware eines Messgerätes nach dem
Takt eines fremden CAN-Signals kalibrieren? Da stimmt ja vllt. das
Timing nicht. Das sollte man zumindest mit einem anderen Oszilloskop
überprüfen.

Gruß, Guido

[Bert (Gast)]

Hallo branadic,

branadic schrieb:
> Daher nun meine Bitte an alle Programmierer die Schnittstelle für die
> neue Eingangsstufe zu implementieren. Denn leider scheint es hier
> reichlich ruhig geworden zu sein.

Bert schrieb im Beitrag: #1399962:
Beitrag "Re: Wittig(welec) DSO W20xxA Hardware"

Da ich mit dem LMH6518 "angefangen" habe, mache ich auch mit.
Ich arbeite zur Zeit an einer "eigenen" FW-Version (NIOS) und könnte die 
Schnittstelle einbauen. Ich würde mein DSO am Kanal 2 (=> für W20x2 und 
W20x4) umbauen und für diesen Kanal die neuen Eingangsstufe 
unterstützen.
So kann ich die FW testen und zwei Kanäle (alt und neu) miteinander 
vergleichen.

Aber zunächst muss ich mal eine Platine aufbauen und einbauen.
Ist das Layout jetzt fix?
Ist der aktuelle Schaltplan verfügbar?

Gruß Bert

[Rolf W. (rowue)]

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?

[jofri (Gast)]

Hallo Guido und rowue!

>Oha, mal wieder ein Anfänger mit Oszi.

Du hast mich sofort durchschaut.

>Aber mal im Ernst, würdest du die Firmware eines Messgerätes nach dem
>Takt eines fremden CAN-Signals kalibrieren?

Da hast Du schon Recht, aber wenn das Abbild des erwartete 
Signalzeitverhalten bei 25MSa/s und 5MSa/s stimmen und nur bei 10MSa/s 
nicht, gehe ich davon aus, das Timing des Can-controllers OK ist und 
eben die Sampelrate nicht.

>Wie oben beschrieben, wäre mein Tip, dass die Samplerate
>selbst bei 10MSa/s liegt, bloß in der Abbildung auf die
>20 µs/DIV 'nen Fehler drin ist (nach dem Motto: ich bilde
>40 Samples auf ein DIV ab, es müssten aber 42 Samples sein ;).
>In der Soft wird viel mit Integer gemacht, da kann sowas gut
>passieren.

Ich hab natürlich im Code nach einen Fehler gesucht und nichts gefunden.
Glaube aber nicht das bei der Darstellung Fehler sind, zumal beim Zoomen
auf andere Zeitbasen entweder der Fehler gleich weitergegeben wird oder
eben bei richtiger Signalzeitdarstellung in den unteren Zoom stufen auch 
nicht auftritt.

>Mein Vorschlag wäre, da ein Ticket im trac aufzumachen, da
>kann mensch die entsprechenden Daten besser sammlen - hier
>könnte das in dem DSO-Source ähnlichen Wildwuchs schnell
>untergehen.

Da kenne ich mich noch nicht aus.

> Windows oder Linux? Wenn Windows: haste 'nen gcc drauf?

beides, das zusammenkratzen des CDK war gar nicht so einfach.

Grüße, jofri

PS: bin jetzt ein paar Tage auf Urlaub.

[branadic (Gast)]

Bert schrieb:
> Da ich mit dem LMH6518 "angefangen" habe, mache ich auch mit.
> Ich arbeite zur Zeit an einer "eigenen" FW-Version (NIOS) und könnte die
> Schnittstelle einbauen. Ich würde mein DSO am Kanal 2 (=> für W20x2 und
> W20x4) umbauen und für diesen Kanal die neuen Eingangsstufe
> unterstützen.
> So kann ich die FW testen und zwei Kanäle (alt und neu) miteinander
> vergleichen.
>
> Aber zunächst muss ich mal eine Platine aufbauen und einbauen.
> Ist das Layout jetzt fix?
> Ist der aktuelle Schaltplan verfügbar?
>
> Gruß Bert

Hallo Bert,

ist schön wenn du helfen könntest, allerdings stehe ich selbst einer 
zusätzlich dritten FW-Version etwas kritisch gegenüber. Ist ja schon 
schade das es zwei Versionen gibt. Jetzt noch eine dritte...?
Oder gehe ich da von etwas falschem aus und du baust auf einer der 
beiden bestehenden FW-Versionen auf?

Das Layout enthält noch zwei kleinere Makel, die sich aber leicht 
umschiffen lassen. Natürlich haben wir noch ein paar Leiterplatten die 
aufgebaut werden könnten.
Die Layoutdaten und den Schaltplan stellen wir erst öffentlich, wenn wir 
sicher sind das die Leiterplatte den finalen Stand erreicht hat. Vorher 
macht das einfach keinen Sinn, denke ich.

Vielleicht kontaktierst du mich mal direkt:

branadic (eddy) user (punkty) sourceforge (punkty) net

Gruß, branadic

[branadic (Gast)]

Ein Hallo an die Programmierer,

ich möchte hier kurz noch ein paar Worte zur neuen Eingangsstufe, ihrer 
Programmierung und was wir für die Messung im Oszi benötigen würden 
verlieren und gebe daher die Worte aus einem Gespräch in unserer 
Skype-Gruppe wieder:

Für den Anfang würde es helfen den LMH6518 mit dem Datenwort „00050A“ zu 
initialisieren, was einer minimalen Verstärkung entspricht.  Die 3 
führenden Nullen (12 binär) bleiben für alle Verstärkungs- und 
Bandbreitenänderungen konstant.

Damit man allerdings auch messen kann wie sich die Einstellungen 
auswirken, wäre eine funktionierende Signaldarstellung nötig, an der man 
die Signalamplitude und Form genau ablesen kann. Sonst fehlt die 
Möglichkeit das Zusammenspiel der Eingangsstufe mit der Oszi-Elektronik 
zu bewerten. Die Signaldarstellung und der Trigger sollten demnach 
funktionieren.

Ein funktionierender DAC-Abgleich ist eine weitere Voraussetzung.

Die Ansteuerung des LMH6518 ist prinzipiell gleich angedacht wie die des 
LTC2612 der, wie vorgeschlagen, durch den LTC2602 ersetzt werden sollte 
- eine SPI Schnittstelle mit 24bit Schieberegister.
Clock wird an FPGA Y8 bereitgestellt, das Signal liegt invertiert an 
Pin2 von U27 (LTC2612) vor.
Data wird an FPGA Y5 bereitgestellt, das Signal liegt invertiert an Pin2 
von U27 an.
FPGA U8 (LSB), FPGA T8, FPGA AA13 (MSB) bilden, ebenfalls invertiert, 
eine 3-bit-Adresse, die die CS bzw Latch aktiviert. FPGA U9 fungiert 
vermutlich als Enable.
Im Fall von U27, dem Offsetabgleich für Kanal 1 und 2, ist das die 
Adresse 6.

Die Adressen 0 (Pin 15 an U25), 1 (Pin 14 an U25), 3 (Pin 12 an U25) und 
4 (Pin 11 an U25) sind laut Schaltplan nicht belegt und wurden deswegen 
für die CS-Ansteuerung des LMH6518 jeweils auf Kanal 1, 2, 3, 4 
vorgesehen. Der komplette Datensatz ist jeweils 24 bit für jeden 
LMH6518.
Die CLK für alle 2 bis 4 LMH6518, je nach Modell, liegt auf der gleichen 
Leitung wie für den LTC2612 und kann z.B. an Pin 3 von U23 abgegriffen 
werden. Das Datensignal nutzt ebenfalls die gleiche Leitung wie für den 
LTC2612 und liegt z.B. an Pin 2 des U23 an.

Zusammengefasst heißt das, gleiche Programm-Sequenz, Adresse 6 für 
Offset auf Kanal 1 und 2 wie gehabt,
Adr. 0 – für Kanal 1. – LMH6518
Adr. 1 – für Kanal 2. – LMH6518
Adr. 3 – für Kanal 3. – LMH6518
Adr. 4 – für Kanal 4. – LMH6518

vorausgesetzt, der zurückentwickelte Schaltplan ist korrekt.

Ich hoffe damit die offenen Fragen gelöst zu haben. Natürlich werden wir 
diese Info in reduzierter Form auch auf SF setzen.
Was die Hardware angeht, so verfügt die Eingangsstufe über die 
3-Wire-SPI, diversen Spannungsversorgungen, dem Eingang und dem 
differentiellen Ausgang. Das derzeitige Layout findet man hier:

http://welecw2000a.sourceforge.net/docs/Hardware/B...

Eine Anschlussbelegung kann ich gerne noch nachreichen, sollte jedoch im 
Moment nicht zwingend erforderlich sein.
Es wäre toll, wenn sich in absehbarer Zeit etwas an der Programmierung 
zur Eingangsstufe tun würde, weil dann jeder der möchte schneller davon 
profitieren kann.

branadic

[branadic (Gast)]

Hallo noch mal, ihr Programmierer,

im Anhang findet ihr mal ein Bild mit der derzeitigen Anschlussbelegung 
der Huckepackplatine.
Damit sollten wirklich sämtliche notwendige Informationen zur Verfügung 
stehen, um die Programmierung der neuen Eingangsstufe in einer der 
Firmwares einzupflegen.

Vielleicht kann man beim Start des Oszis mit den Softkeys ja eine kurze 
Abfrage vorsehen, ob und auf welchem Kanal die originale bzw. neue 
Eingangsstufe vorhanden ist? Nur so eine Idee.

Gruß, branadic

[Hayo W. (blueflash)]

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 (Gast)]

Hallo Hayo,

gut zu wissen das es weiter gehen wird.
Wie ich schon sagte wäre es schön, wenn schnellstmöglich eine Lösung 
bereit stehen könnte. Leider gibt es an der LEON-Front noch ein paar 
Hürden zu meistern, wo die entsprechenden Entwickler jedoch dran sind, 
wie zum Beispiel die DAC-Ansteuerung.

Um schnell abschätzen zu können was die neue Eingangsstufe jedoch kann 
und wo noch nachgebessert werden muss müssen wir einfach mit dem 
bestehenden NIOS-Design vorlieb nehmen.

Auf lange Sicht jedoch muss der Wechsel auf das LEON-Design erfolgen, 
aber darin sind wir uns ja alle einig.

Das Beste wäre, wenn der LMH6518 bereits beim Booten richtig 
initialisiert würde und der AUX-Ausgang schnellstmöglich abgeschaltet 
würde, weil sich die Stromaufnahme des Verstärkers drastisch reduziert 
und damit auch seine Abwärme.
Wir versuchen in einem weiteren Redesign noch mal Fläche für Abwärme 
vorzusehen, jedoch sollten wir alle nur denkbaren Vorkehrungen treffen 
die es zu treffen gilt. Keine Ahnung wie sich das sonst bewerkstelligen 
ließe?
Vielleicht ließe sich im Hardwaremenü die neue Eingangsstufe auswählen, 
jedoch werden die Einstellungen erst nach einem Neustart des Gerätes 
aktiv?

Sämtliche Informationen zur Implementierung habe ich ja bereits bereit 
gestellt. Das heißt zumindest an fehlender Information mangelt es 
derzeit nicht :)

Gruß, branadic

[Rolf W. (rowue)]

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

[branadic (Gast)]

Hallo Rolf,

wird die neue Eingangsstufe mit SPI angesteuert, so kann man am SDIO die 
aktuellen Einstellungen abrufen.
Wenn man also einmal eine Startinitialisierung schreiben würde ließe 
sich prüfen, ob diese auch so geschrieben wurde. Falls nicht ist die 
originale Eingangsstufe drin.
Wäre das eine Möglichkeit?

branadic

[Rolf W. (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 (Gast)]

Rolf W. schrieb:
> (Den DAC würde ich gerne so lassen, wie er ist - den nutze
> ich gerade für die Autokalibrierung auf die "Widerstandslöter")

Hallo Rolf,

in den neuen kleinen Spannungsbasen werden wir aber nicht umhin kommen 
den DAC gegen seinen pinkompatiblen Kollegen auszutauschen.

Was insgesamt das Durcheinander mit den Widerstandslötern angeht, so 
schätze ich doch werden auch diese, sobald denn die neue Eingangsstufe 
endgültig freigegeben ist, dem Beispiel der Entwickler folgen und diese 
nachrüsten oder nachrüsten lassen.

Sicherlich werden einige am Anfang erst einmal nur einen Kanal tauschen 
um den direkten Vergleich alt gegen neu zu ziehen.

Nicht vergessen dürfen wir dabei jedoch die zusätzlich dazugewonnenen 
Spannungsbasen 1mV/div, 2mV/div und 5mV/div.

Gruß, branadic

[Rolf W. (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 ;)

[Michael D. (mike0815)]

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

[Rolf W. (rowue)]

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.

[Rolf W. (rowue)]

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

[Michael D. (mike0815)]

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

[Rolf W. (rowue)]

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

[Hayo W. (blueflash)]

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

[Hayo W. (blueflash)]

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 (Gast)]

Hallo Hayo,

in letzter Zeit ist es ja eher ruhig hier geworden und von Stefan hat 
man ja auch schon lang nichts mehr gehört. Aber mir soll es recht sein, 
solange es gemacht wird.

Was den Bug angeht so muss ich gestehen, dass ich noch auf einer der 
letzten OS-Firmware-Varianten sitze und deine letzten Versionen gar 
nicht mehr aufgespielt und getestet habe. Liegt eben auch daran, dass 
ich nicht mehr "DAS" Verbesserungspotential in der NIOS-Firmware sehe. 
Die jetzt umgesetzten Routinen werden wohl auch nicht ins LEON-Design 
portierbar sein.

Aber angeregt durch die neuen Oszis von Rohde & Schwarz wollt ich mal 
nachfragen, ob die FFT nicht grundsätzlich auch am Welec eher in 
Richtung der Funktionalität eines Spekanalyzers angepasst werden sollte? 
Also das man, abhängig natürlich von der Samplerate und Timebase, die 
Centerfrequenz und den Span einstellt. Ich find das im Umgang einfach 
viel besser als die weit verbreitete Lösung die man in vielen DSOs 
vorfindet.

branadic

[Hayo W. (blueflash)]

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

[Guido (Gast)]

Hayo W. schrieb:
> Da müßte mir jemand auf die Sprünge helfen. Ich
> kenne nur einige DSO-Implementierungen und reine PC-Softwarelösungen.


Hallo Hayo,

mache ich doch gerne :-)).SAs heben einen Search-Modus, in dem die
volle Bandbreite um die Mittenfrequenz auf dem Schirm dargestellt wird.
So ist es jetzt auch bei der FFT. Zur genaueren Analyse verkleinert man
am SA die Bandbreite (stufenweise) und kann dann durch Verschieben der
Mittenfrequenz durch das gesamte Band laufen. Dabei nimmt die Auflösung
und die Empfindlichkeit gegenüber dem Search-Modus sehr stark zu. Um
Letzteres auch auf dem Welec zu implementieren, müsste man aber auf
Mehrfachsampling umsteugen, was sicher einen riesigen Azfwand bedeutet.

Gruß, Guido

[branadic (Gast)]

Hallo Guido,

danke für die von dir gelieferte Erklärung.
Das man keinen vollständigen SpecAnalyser im Welec realisieren kann ist 
klar. Es geht vielmehr um die Bedienbarkeit der FFT, sprich man gibt die 
Mittenfrequenz und eine Bandbreite an, die dargestellt werden soll. Die 
exakte Mittenfrequenz und die Bandbreite ist natürlich nur im Rahmen der 
Zeitbasis und Samplerate einstellbar, aber dennoch ist diese Form der 
Bedienung deutlich zweckmäßiger als die aktuell implementierte FFT.

branadic

[Guido (Gast)]

Hi branadic,

wenn ich mich recht entsinne, funktioniert aber der Cursor in der
FFT. Damit kommt es dem Search-Modus schon recht nahe.

Aber wir wollen ja besser werden als die anderen. ;-)

Gruß, Guido

[Rainer W. (rawi)]

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?

[Rainer H. (rha)]

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

[Hayo W. (blueflash)]

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

[Jürgen (Gast)]

Hallo Hayo!

Rainer W. schrieb:
> aus meiner Sicht ist das Problem beim "Recall" nicht aufgefallen, weil
> keiner die so implementierten Funktion braucht. Sie taugt nur, um

Das ist mir wohl zu stark vereinfacht!

> 1. Settings zu speichern (mitgespeicherte Kurven bedeutungslos)

OK, kann sein.

> 2. Meßkurven zu archivieren (macht mein PC)

Hier ist diese Funktion unser eingebauter "USB-Stick". Ich will eben 
auch unabhängig von einem PC sein, und gegebenenfalls später erst die 
Kurven speichern.

Ein Problem/Bug in der Firmware ist, wenn ich das richtig gesehen habe, 
daß der vorgegebene Bereich von 64k per Kurve beim 4-Kanaler nicht mehr 
zum Speichern der Einstellungen reicht. ( 4 x ca 300 Byte = ca. 1200 
Byte per Kurve für Einstellungen + 4 x 16k Daten)
Vielleicht kannst Du die Einstellungen für die Kurven in einen obersten 
z.B. 128k Bereich verfrachten und dafür etwas weniger Speicherungen 
zulassen?
Bzw. hast Du sicher schon eine Lösung :-)
Die Overlay Funktion greift ja wohl "nur" auf die gespeicherten Daten zu 
und widerspricht nicht dem Save/Recall.

Gruß Jürgen

[Hayo W. (blueflash)]

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

[Rainer W. (rawi)]

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.

[Jürgen (Gast)]

Hi Hayo,

Hayo W. schrieb:
> Andere Lösungen wären erstmal deutlich aufwändiger - fragt sich ob der
> Nutzen den Aufwand rechtfertigt.

Du hast recht.Ich hatte nicht beachtet, daß sich der Flashbaustein nur 
in 64k-Sektoren löschen lässt. D.h. man muss bei z.B. 2 x 64k Sektoren 
am oberen Ende zuerst entscheiden,in welchen Sektor man schreiben muss - 
diesen auslesen und puffern - Daten ändern und zurückschreiben. Ich 
hatte erst angenommen, man kann 2k - Sektoren ändern.
Wäre aber schon die saubere Lösung... :-)

@rawi
Das ist natürlich der Luxus! Aber es gibt riesige Pausen bei der 
Signalbeobachtung in der Zeit des Abspeicherns und man knallt sich bei 
eher periodischen Signalen ev. unbeabsichtigt sehr schnell den Speicher 
voll mit gleichen Signalverläufen.

[Hayo W. (blueflash)]

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

[Michael D. (mike0815)]

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

[Hayo W. (blueflash)]

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

[Hayo W. (blueflash)]

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

[Jürgen (Gast)]

Hayo W. schrieb:
> macht der Netzschalter an meinem 4-Kanalgerät jetzt auch die Grätsche -
>
> zum Glück hab ich ja den neuen Schalter schon liegen.

Hayo, ich hab gar kein Problem mehr mit dem Netzschalter. Habe 
allerdings die hier

Beitrag "Re: Wittig(welec) DSO W20xxA Hardware"

genannte Schraube nachgerüstet. Kann ich wirklich empfehlen!

Gruß Jürgen

[Michael D. (mike0815)]

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

[Hayo W. (blueflash)]

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

[Michael D. (mike0815)]

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

[Jürgen (Gast)]

Hayo W. schrieb:
> Keine Angst, Dein Schalter wird auch noch abrauchen, die sind ganz
> einfach Billigschrott.

Ich hoffe doch nicht!

> Was ist das mit der Schraube?

Siehe Bild.( leider bloß vom Handy ) Ich hatte den Eindruck, daß das 
ganze Chassis beim Betätigen des Schalters nach hinten ausweicht und so 
das "Gebritzel" entsteht.
Das Blechchassis wird am vorderen Kunststoffgehäuseteil festgeschraubt.
Ihr könnt es ja mal probieren.

Grüße

[Hayo W. (blueflash)]

Nein das Gebritzel entsteht ganz eindeutig im Schalter. Ich hatte den 
alten Schalter mal auseinandergenommen, wie es darin aussah wollt Ihr 
nicht wissen...

Hayo

[Jürgen (Gast)]

Und hier das Bild :-)

[Hayo W. (blueflash)]

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 (Gast)]

Hayo W. schrieb:
> Nein das Gebritzel entsteht ganz eindeutig im Schalter.

Ich habe dem ja nicht widersprochen!

[Hayo W. (blueflash)]

@Jürgen,

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

Hayo

[Michael D. (mike0815)]

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

[branadic (Gast)]

Hallo Allerseits,

inzwischen ist die dritte und allem Anschein nach letzte PCB Version 
fertig designed und wird in wenigen Tagen bestellt.
Hiermit bieten wir allen die an der SW-Entwicklung beteiligt sind die 
Möglichkeit an dieser Bestellung zu partizipieren.

Die Abmessungen der Platine sind 17x22mm. Ein Bild des vorerst finalen 
Layouts findet ihr unter:

http://welecw2000a.sourceforge.net/docs/Hardware/B...

Die Kosten für eine Leiterplatte schätzen wir auf 3,-€/Stück inkl. der 
Versandkosten für den Versand in einem Briefumschlag.

Wer sich an dieser Bestellung beteiligen möchte hat bis zum 25.08.2010 
Zeit sich unter branadic [at] user (punkt) sourceforge {punkt} net zu 
melden.
Ihr bekommt dann noch am 25.08.2010 abends eine Mail mit den Kontodaten 
und habt dann bis zum 30.08.2010 Zeit das Geld zu überweisen.
Nach dem 25.08.2010 können keine weiteren Bestellungen mehr 
berücksichtigt werden.
Die Leiterplatten werden vorraussichtlich am 27.09.2010 fertig gestellt 
sein und dann versandfertig gemacht.

Ich möchte ausdrücklich darauf hinweisen, dass die Leiterplatten mit 
SMD-Bauteilen bestückt werden müssen. Bauteilgrößen sind über 0603 und 
0402 auch SOT23-5 (Spannungsregler), LLP16 (LMH6518), µSOP8 (MAX4477), 
SC70-3 (SI1300) und M04 (NE3508). Ihr solltet also die Fähigkeiten und 
Möglichkeiten besitzen solche Packages auch zu verarbeiten.

Wer diesbezüglich unsicher ist sollte einen Blick auf die Messprotokolle 
von Walter und mir werfen.

An dieser Stelle möchte ich mich auch für die großartige Zusammenarbeit 
mit Walter bedanken und uns die Daumen drücken, dass wir bald die 
Möglichkeit erhalten werden die Eingangsstufe unter realen Bedingung zu 
testen.

branadic

[Michael H. (stronzo83)]

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

[branadic (Gast)]

Fehler meinerseits, da ist mir ein "s" appanden gekommen. Ich werde 
keinerlei Bestellungen hier im Forum entgegennehmen, ansonsten verliere 
ich den Überblick. Ich denke das versteht ihr.

Die Mailadresse ist branadic {ed} users (punkt) sourceforge [punkt] net

branadic

[Kurt Bohnen (kurt)]

Hallo branadic

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

Mfg,
Kurt

[branadic (Gast)]

Hallo Kurth,

ich sag mal so, könnte sein muss aber nicht sein. Wenn die Leiterplatte 
wirklich so funktioniert wie gewünscht werde ich keine mehr brauchen und 
Walter auch nicht. Daher kann ich keine feste Zusage machen. Die 
Board-Files werden dann aber öffentlich gestellt, sodass da zur Not auch 
jemand anderes etwas organisieren könnte.

Vielleicht noch ein Hinweis am Rande:
Die Leiterplatten haben eine Dicke von 0,4mm zzgl. Kupferauflage. Dünnes 
Basismaterial ist notwendig, weil wir zwischen Gehäuse und Mainboard 
nicht sehr viel Platz haben und die Bauteile auch noch etwas an Höhe 
schlucken. Das Board kommt nämlich auf die ADC gegenüberliegende Seite 
des Mainboards. Es geht also ziemlich eng zu.
Nicht jeder Lieferant verarbeite so dünnes Basismaterial und das auch 
noch zu günstigen Konditionen. Daher werden die Leiterplatten auch in 
Bulgarien gefertigt.
Das sollte für euch aber nicht das Entscheidungskriterium sein.

branadic

[Rolf W. (rowue)]

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

[Rainer W. (rawi)]

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

[Hayo W. (blueflash)]

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.

[Michael D. (mike0815)]

oha, Petra liest mit ;-))

[Hayo W. (blueflash)]

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

[Hayo W. (blueflash)]

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

[branadic (Gast)]

Hallo zusammen,

all diejenigen die mich bisher wegen Leiterplatten angeschrieben haben 
dürften eine Mail mit einem Formular vorgefunden haben, in dem auch die 
Kontodaten zu finden sind.

Wer noch Leiterplatten bestellen möchte, den bitte ich mich nur kurz 
anzuschreiben dss Ihr Leiterplatten wollt, mehr Text ist nicht 
notwendig. Ihr werdet darauf hin von mir eine Mail mit dem Formular 
bekommen, dass ihr mir dann ausgefüllt zurückschickt.
Das wahrt die Übersichtlichkeit und macht es mir einfacher.

Einen schönen sonnigen Sonntag ;)

branadic

[Luc (Gast)]

Hi guys, Hayo, branadic, Rolf W., Michael D., Rainer W., Jürgen and all.
Thank all You very much for the hard work done, as always a really great 
job!!!
Now I would not overstate but recently I had occasion to use a WaveAce 
224 DSO by LeCroy and it was not so superior to my W2022A!
Is true, the LeCroy tigger is better, more stable, but the noise is 
incredibly high, especially on the scale "2" and although the total 
screen's area is 1/4 than Welec (320x240 pixel resolution against 
640x480).
Then even after warmed up changing the VOLT/DIV's scale on the WaveAce 
the signals are dancing and their offset are not correctly.
The VOLT/DIV's accuracy is greater in WaveAce but the W2022A's time base 
is a little better than LeCroy.
Of course the WaveAce's automatic measurements are more sophisticated as 
well its generals ability but generally the W2022A can replicate most of 
them.
I can say that thanks to your work You are able to make the 
Welec/Wittig's DSO competitive with what the market currently offers, so 
again many thanks to all, really thanks very much to all You!!!
Vielen Dank!!!

Luc

p.s. in the 1.2.BF.1.5's version was introduced the new RMS calculation 
for Quick Measure warning that the new routine is a little bit slower 
because of the additional calculations but the speed may be increased
by exchanging the multiplications with shift operations, which was not 
made for lack of available's time.
Now has someone the time?

[Hayo W. (blueflash)]

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

[Manfred H (Gast)]

Hallo Hajo und all ihr anderen Weltverbesserer,
nein im Ernst, das DSO ist seit ihr am Werke seid brauchbarer geworden. 
Trotzdem freu ich mich auf jenen Punkt, wo es auch wirklich das tut, was 
man gerne von ihm hätte.

Habe die neueste Version 1.2.BF.1.10.HE aufgespielt. Die Overlayfunktion 
funktioniert bei mir nicht einwandfrei. Aber vielleicht mach ich ja was 
falsch. Auf Wunsch beschreibe ich gerne Näheres dazu.

Aber eines der wichtigsten Features, die man vom DOS gerne hätte, ist 
bei mir die Darstellung einzelner Signalimpulse, was bei mir nach wie 
vor nicht möglich ist.

Beispiel: Ein Resettaster über einen Widerstand an Plus wird gedrückt um 
das Prellverhalten zu messen. Das DSO auf negative Flanke eingestellt, 
der Mode auf "normal" und Run (grüne Taste). Drücken der Resettaste - 
keine Reaktion. Auf Stop und dann auf Single gedrückt löst der Trigger 
nach weniger als einer Sekunde auch ohne ankommende negative Flanke aus. 
Der Triggermode hat auf "auto" umgestellt. Auch andere Triggermodi und 
Kombinatinen bieten keine Möglichkeit, das Prellen zu sehen.

Dagegen funktioniert das Triggern bei periodischen Signalen 
(Probe-Signal) einwandfrei.

Was ich nicht verstehe: bin ich der einzige, bei dem solches nicht 
funktioniert, sonst müssten doch andere auch schon darauf hingewiesen 
haben.

Da ich weiß, wie komplex diese Materie ist, gilt meine Bewunderung 
trotzdem dem Einsatz von euch allen. Dafür ein herzliches Danke.

[Jürgen (Gast)]

Hallo Hayo,

Manfred H schrieb:
> Beispiel: Ein Resettaster über einen Widerstand an Plus wird gedrückt um
> das Prellverhalten zu messen. Das DSO auf negative Flanke eingestellt,
> der Mode auf "normal" und Run (grüne Taste).....

Im Bild ein Resettaster mit gleichen Einstellungen.
Und ja, es ging beim ersten Mal nicht! Keine Triggerung. Das hängt 
sicher mit der Reihenfolge der Betätigung der Tasten am Oszi zusammen. 
Habe aber  keine Vorstellung nach welchem Zustand welcher Variablen ich 
dabei suchen muss, wenn es wieder mal nicht funktioniert ;-)

Habe mit der Triggerung sowieso ein Problem:
Z.B. gefällt mir die Bedienungsreihenfolge -STOP-Single- überhaupt 
nicht!
Die HP-Oszis nehmen immer ein einfaches Betätigen des -Single- Tasters 
an. Dies ist sehr praktisch, da man normalerweise "alle Hände voll zu 
tun" hat, wenn ein Problem zu beheben ist und schnell mal ein Bild zur 
weiteren Analyse zu machen ist.
Aber gut Ding will eben Weile haben! Wird schon noch!

Jürgen

[Hayo W. (blueflash)]

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

[Charly B. (charly)]

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

[branadic (Gast)]

Hallo Leute,

noch mal die Bitte an alle, prüft eure Mailkonten und schickt mir das 
Bestellformular ausgefüllt zurück.
Jeder der mich bisher angeschrieben hat hat dieses von mir zugeschickt 
bekommen.
Mittwochabend ist "Einsendeschluss".

branadic

[Rainer W. (rawi)]

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

[Hayo W. (blueflash)]

@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

[Rainer H. (rha)]

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

[alex008 (Gast)]

Liebe Gemeinde!

Ich kann nun die DACs über den LEON3 ansteuern. Der Fehler lag meist nur 
darin, dass die DAC Ansteuerung einen großen Offset vom Offset aufweist 
und die Drehknöpfe von minderer Qualität sind.
Aus diesem Grund muss ich nun eine Kalibrierung implementieren.

Ich kann mir zwar schon gut vorstellen, wie ich das machen werde, 
trotzdem würden mich vorher ein paar Codebeispiele interessieren, damit 
die Genauigkeit und die Zeitdauer in einen optimalen Rahmen liegen.
Mann muss nicht alles selbst neu erfinden!

Ich möchte diesbezüglich auf ein gravierende negative Auswirkungen 
hinweisen, falls man auf Signale triggern will, die kleiner als das LSB 
vom ADC sind (Das LEON Design kann das Grundsätzlich). Unter Umständen 
muss man da den mysteriösen Mux in der Eingangsplatine vom offenen 
Eingang auf den gefilterten PWM-Digitalausgang des FPGAs stellen, damit 
sich der DC-Offset beim Einschalten der HW-Filter nicht zu stark ändert.

@branadic
Mir gefällt die FFT vom Yokogawa DLM2054 auch sehr gut, da kann man 
selbst das Sichtfenster (Frequenzmitte, Frequenzstop) in einem sehr 
weitem Bereich einstellen. Bessere Ergebnisse erreicht man jedoch wenn 
man eine Oberschwingungsanalyse macht (DFT, die sich auf die 
Grundfrequenz synchronisiert).

Das hat das DLM2054 auch, jedoch nur für 50 oder vielleicht auch 60 Hz. 
Damit kann man eine Abnahme von kleinen PFC Strömen machen.

MfG
Alexander

[Stefan E. (stefan_e)]

>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

[Hayo W. (blueflash)]

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

[Rainer H. (rha)]

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

[Hayo W. (blueflash)]

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

[Rainer W. (rawi)]

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

[Rainer H. (rha)]

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

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

Gruß,
Rainer

[Hayo W. (blueflash)]

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

Gruß Hayo

[Rainer H. (rha)]

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

[Hayo W. (blueflash)]

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

[Manfred H (Gast)]

Erst heute komm ich wieder in meine Werkstatt: Mein Oszi hat einen 
phantastischen Tag. Der Trigger löst plötzlich im Normal-Mode mit Run 
(grüne Taste) aus.  Nicht aber im Single-Mode. Immerhin kann ich so 
Einzelereignisse beobachten.

Problembeschreibung: Stop, dann Single-Mode gedrückt - jetzt geht es 
ohne Triggerauslösung nach knapp einer Sekunde in den Auto-Mode über. 
Damit sind keine Einzeltrigger möglich. (Teste die neueste Version. Muss 
noch mit einer älteren Version probieren, vielleicht dann!?)

Triggerpegel: Speziell im niedrigen Bereich (unter 0,5cm Bildschirmhöhe) 
scheint bei mir der Trigger nicht auszulösen. Darüber sehr wohl.

Overlay-Darstellung: Der Overlaymode funktioniert (heute) und ist zum 
Vergleichen von Signalverläufen prima geeignet. Kompliment.

Was soll ich sagen. Wenn mein Oszi gut drauf ist, bin ich es auch.
Gruß MH

[Hayo W. (blueflash)]

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

[Charly B. (charly)]

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

[Luc (Gast)]

Hi Hayo and all!

Hayo W. schrieb:

>that is an interresting comparison for LeCroy is a big player in the DSO
>scene and the price for this devices is much higher than for our Welec.
>So I think we don't have to be unhappy about our choice to buy this
>device from Welec and we will be motivated to optimize it in future.

Yes, I think so too.
But I am frank, when I bought my W2022A I already knew that smart guys 
were improving it.
I had read some of their presentations on the group, I saw that they 
were competent persons, engineers, engineering students and so.
So already I knew I would have well spent my money.
Then, even if I am not an expert, I had guessed that anyway its hardware 
should not be so poor.
I think as it stands now, thanks to your work, the DSO is competitive 
with what the market offers even at higher price.
I believe that if Mr. Wittig had You as collaborators Wittig/Welec now 
would be a great brand in the DSO's world.
I do not want to do the devil's advocate but I believe that Mr. Wittig 
was a bit unlucky, no shortage of ideas but not so for the ability to 
put them into practice.

Hayo W. schrieb:

>By the way - did You test the new overlay function in the 1.10 HE? What
>do You think about it?

I'm currently away from home and my W2022A.
But even here I have a friend with a W2012A so we updated it to the 1.10 
HE version.
I'm sincere now I do not quite understand how to use this new overlay 
function feature.
I seem to understand that it can simultaneously display two stored 
waveforms so they can easily compare (following up to my previous 
message, roughly something like the Pass/Fail Mask Testing function of 
LeCroy WaveAce).
The problem is that when I use the overlay function three strange things 
happen:
1) the source of trigger switches on channel 2 even though it was set to 
channel 1 and the settings of the DSO is set to CH1.
There is a checkmark on CH1 but in the top bar on the screen there is 
the channel 2 as trigger source and infact channel 2 is now the trigger 
source.
2) the waveform stored as a reference and the waveform stored with the 
overlay's function are identical but out of phase.
3) since been updated to 1.10 HE, the yellow light of CH1 button is 
flickering, turns on and off randomly.
I will surely do something wrong, I'm a bit tired now.
Please,Hayo could you explain to me how to use the overlay function?
Maybe you've already explained it, but I do not understand very well the 
German.:-(
I apologize but I'm a bit cooked now, I'm sorry for my bad English more 
than usual...:-(
Hayo again many thanks to You and all, really thanks very much to all 
You!!!
Vielen Dank!!!

Luc

[Hayo W. (blueflash)]

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

[Martin H. (martinh)]

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

[Jürgen (Gast)]

Hallo Hayo,

so gefällt mir die Start/Stop/Single - Logik wieder :-)
Du warst aber wieder mal schnell !
Die Pulse With Triggerung funktioniert leider nicht. Die Ursache hab ich 
auch gefunden. Da hat sich zumindest dieser Bug auf Zeile 756 in 
userif_t eingeschlichen. Hier muss TRIG_PULS und nicht TRIG_EDGE stehen.
Damit funktioniert die Pulse With Triggerung dann.

Laßt euch den Kaffee schmecken!

Gruß Jürgen

[Jürgen (Gast)]

Kleiner Nachtrag:

Bei Pulse Width Triggerung muss zwingend Holdoff auf "Off" stehen!

Gruß Jürgen

[Charly B. (charly)]

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

[Rainer W. (rawi)]

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

[Hayo W. (blueflash)]

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

[eProfi (Gast)]

Was sehr praktisch ist: forced trigger   oder   button trigger
Durch (nochmaliges) Drücken einer Taste wird in normal oder single 
sofort ein Trigger ausgelöst.

Es soll also 4 Modi geben:

AUTO
am Ende wird eine einstellbare Zeit gewartet, ob ein Trigger kommt,
wenn nicht, wird trotzdem gestartet

NORM /   FORC oder BUTT
nur starten, wenn Trigger   oder Taste
(ist praktisch AUTO mit unendlicher Wartezeit)

SING /   FORC oder BUTT
einmal triggern    oder Taste
danach geht er auf STOP

STOP
nicht triggern

Oder ist das bereits jetzt möglich?


Bei unserem LeCroy gibt es noch zwei LEDs: READY (lechtet sobald er 
"scharf" ist, d.h. geht kurz aus, bis alle Daten verarbeitet sind)  und 
TRIG (leuchtet, wenn die Triggerbedingung erfüllt ist)


Rolf/Hayo:
ich wäre gestern gern dabeigewesen, es gab bestimmt viel zu lernen.
Will auch einen 2024er und mitmachen!!!  ;-)
Da ich vom LeCroy recht verwöhnt bin, würde ich gern alle die netten 
Features auch im Wittig implementieren und für zu Hause haben.

Worauf habt ihr euch geeinigt?

[Luc (Gast)]

Gute Sonntag Hayo and all!

Luc schrieb:

>I have a friend with a W2012A so we updated it to the 1.10
>HE version.
>The problem is that when I use the overlay function three strange things
>happen:
>1) the source of trigger switches on channel 2 even though it was set to
>channel 1 and the settings of the DSO is set to CH1.
>There is a checkmark on CH1 but in the top bar on the screen there is
>the channel 2 as trigger source and infact channel 2 is now the trigger
>source.
>2) the waveform stored as a reference and the waveform stored with the
>overlay's function are identical but out of phase.
>3) since been updated to 1.10 HE, the yellow light of CH1 button is
>flickering, turns on and off randomly.

I updated the W2012A with the excellent new 1.2.BF.1.11 version and all 
problems are gone!:-)))
Now it work like a charm, so Hayo and all guys, thank very much for the 
great work done, really a wonderful job!!!:-)))
The overlay function feature now works without problems so that is no 
longer even need to explain the use, rougly it is what I meant about the 
LeCroy WaveAce function.
The only thing I can add about this is, be could done so you can slide 
horizontally the waveforms so that is simple superimpose them?
However this new feature is very useful, thanks again!
Really Very well also for the change in the Run/Stop/Single logic, it is 
a good implementation that further enhances the DSO, many, many thanks 
also for introducing this amazing feature!!!:-)))
Now I await for the implementation of the Rolf's Auto calibration and 
all that follow.
Really a amazing job, in my opinion I think adding the "center" & "span" 
function and cursors to the FTT the Welec oscilloscopes could to better 
compete on equal terms with what the market currently offers even at 
higher price.
Of course, also I await news about LEON 3 VHDL design implementation.
About this I hope that programming of LEON 3 VHDL design on to DSO 
becomes as simple as a firmware update.
Any news for me is always welcome!:-)
Hayo again many thanks to You and all, really thanks very much to all 
You!!!
Vielen Dank!!!

Luc

[Rainer H. (rha)]

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

[Rainer W. (rawi)]

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.

[Hayo W. (blueflash)]

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

[Luc (Gast)]

Hi Rainer H., Rainer W. and all!

Rainer H. schrieb:

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

I agree with You.
I often use TDS series oscilloscopes by Tektronix and other manufacturer 
too and the trigger's zero position is at the center of the screen.
Anyway I think it is more of a philosophy question that other thing 
because then when I use my W2022A I have no big problem.
So I agree also with Rainer W. when he write:

Rainer W. schrieb:

>Eigentlich gibt es zwei verschiedene Bedienphilosophien zwischen denen
>man umschalten können müßte: Eine für Meßaufgaben die triggerzentriert
>sind (deine Version) und die klassiche Version für Signale, die auf den
>Triggerzeitpunkt folgen.

Therefore from my point of view this is not a real bug.

Gruß

Luc

[bingeradeimdienst (Gast)]

>leider komme ich immer noch nicht dazu auf die Posts hier zu antworten

Wieder beim Griechen an der Ouzo-Kanne!! HeHe!! ;-);-)

Vielen Dank für die neue Version und viele Ideen für die nächste!!!


bingeradeimdienst

[Hayo W. (blueflash)]

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

[Stephan S. (outsider)]

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.

[Rainer H. (rha)]

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

[branadic (Gast)]

Hallo,

traurigerweise scheinen einige den Sinn von Stichtagen nicht zu 
verstehen. So sind noch Bestellungen nach dem 25.08. bei mir 
eingegangen, die ich nur in Ausnahmen berücksichtigen konnte und das 
Geld haben auch noch nicht alle überwiesen, was noch viel trauriger ist!

Das Nutzen ist bereits komplett gesetzt. Viel Überproduktion ist nicht 
zu erwarten und ich lege mir verständlicherweise nicht Massen an 
Leiterplatten auf mein privates Lager.

Weitere Bestellungen können also nicht berücksichtigt werden. Wer zu 
spät kommt, aus welchen Gründen auch immer, hat jetzt schlichtweg Pech.

branadic

[Michael D. (mike0815)]

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

[Stephan S. (outsider)]

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

[Luc (Gast)]

Hi Rainer H. and all!

Rainer H. schrieb:

>the bug I meant was the incorrect PreTrigger time after changing the
>timebase. Not the trigger zero in the middle of the screen.

Oh!, I am really very sorry for the mistake!:-(
Rainer H., I apologize for the error, my understanding of German is 
really very lack!:-(
In fact you wrote

Rainer H. schrieb:

>Bug: Die PreTrigger Anzeige wechselt beim Ändern der Zeitbasis nicht,
>erst wenn sie das nächste Mal verstellt wird.

but I've not understood correctly, so still so many excuses again Rainer 
H.:-(
Now I have nostalgia of my military service when I had a German 
translator...
Sorry again Rainer H.!:-(

Gruß

Luc

[Michael D. (mike0815)]

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

[Rainer W. (rawi)]

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

[Hayo W. (blueflash)]

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

[Luc (Gast)]

Hi Hayo and all!

Hayo W. schrieb:

>Mit Rolf hatte ich einen regen Gedankenaustausch, von dem auch schon
>einiges eingeflossen ist, unter anderem die inline Math-Funktionen, die
>die FFT etwas beschleunigen. Auch die RMS-Berechnung und die XY-Anzeige
>sind schneller geworden.

Hayo and Rolf thank all You very much for the really great job!!!

Gruß

Luc

[Peter M. (none)]

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

[Rainer W. (rawi)]

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

[Hayo W. (blueflash)]

@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

[Hayo W. (blueflash)]

@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

[Hayo W. (blueflash)]

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

[Mirko B. (horace)]

Hier kam ja schon mal der Vorschlag ein Wiki einzurichten (so wie die 
Artikel hier im Forum) -  da kann das Existierende rein und Schritt für 
Schritt von allen up to Date gehalten werden.
Wo könnte man so etwas denn ansiedeln? Hier im Forum?

Grüße,

Mirko

[Kurt Bohnen (kurt)]

Ein Wiki haben wir doch schon:

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

[Mirko B. (horace)]

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

[Hayo W. (blueflash)]

Ü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 (Gast)]

Hayo W. schrieb:
> Ich dachte da an ein Officedokument (Word oder so)

Danke, dass du das schreibst. Dann bin ich als Linux-User schon mal
außen vor (puuhh). ;-)

Gruß, Guido

[Rainer W. (rawi)]

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. (Gast)]

Das hätte aber wieder den Nachteil, das man eine Versionsverwaltung o.ä 
bräuchte (zumindest wenn mehrere daran arbeiten wollen) - was ja schon 
bei der Firmware selbst ein Problem ist.
Wenn man so ein Wiki hat, kann man doch bestimmt den Inhalt irgendwie 
exportieren oder die html-Seiten einfach ausdrucken.

[Hayo W. (blueflash)]

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

[Mirko B. (Gast)]

Ich habe einfach mal getestet....

Artikel hier im Forum:

http://www.mikrocontroller.net/articles/Ausgangsst...

Unter Mac OS mit Safari (Reader Funktion) als PDF ausgedruckt - so 
schlecht sieht das ja gar nicht aus oder?

[Mirko B. (Gast)]

Und die eingebetteten Links zum bearbeiten scheinen auch aus dem PDF 
heraus zu funktionieren.

[The MaSc (Gast)]

Eventuell könnte man ja ein vorhandenes Handbuch von Agilent/Tek 
hernehmen (je nachdem, zu welchem DSO die Welec-Frimware mehr 
gemeinsamkeiten hat).
Dann hat man bereits eine Struktur sowie Beschreibungstexte.
Anzupassen wären dann "nur noch" die Screenshots, Funktionen, deren 
Bedienung unterschiedlich ist sowie Funktionen, die beim Welec vorhanden 
sind aber bei der Referenz nicht.

Ich denke die aktiven Entwickler und Tester wissen sicher, welchem Oszi 
das Welec (OSS bzw Hayo's BF) am meisten ähnelt.

[Hayo W. (blueflash)]

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

Gruß Hayo

[Peter M. (none)]

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

[rowue (Gast)]

Zum Thema Doku könnte DocBook ganz interessant sein, daraus lassen
sich verschiedene Textausgaben ableiten.

Und das Ganze mit svn zu verknoten um eine Versionsverwaltung zu haben
ist auch nicht schlecht (häufig genug bei Texten aller Art verwendet)

Grüße,

   rowue

(gerade etwas am rotieren ;)

[Hayo W. (blueflash)]

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

[Roberto (Gast)]

Hallo

Also ein Wiki finde ich eine sehr gute Idee!!
Ich habe mir auch schon oft gedacht, eine Doku (in Deutsch) wäre sehr 
gut.

Das Wiki hätte den Vorteil, dass da jeder mitmachen kann, dass es 
Plattform unabhängig ist und auch mal kurz etwas geändert werden kann..
Damit fallen auch die Schranken, die man sonst überwinden muss wenn man 
das selber in einem Textprogramm macht....
Dann könnte ich sogar etwas beisteuern :-)

Wenn man die Doku dann noch in ein pdf umwandeln kann, ist es perfekt!

l.G. Roberto

[Mirko B. (Gast)]

ja, ja!!!

Nur bei einem Wiki kann jeder leicht mitarbeiten und man muß nicht 
umständlich irgendwelche Versionen verwalten oder abgleichen.

Ein Beispiel aus der Artikelsammlung hier habe ich ja weiter oben schon 
gebracht.

Viele Grüße,

Mirko

[Hayo W. (blueflash)]

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

[Roberto (Gast)]

Gut wäre auch ein Wiki ohne Anmeldung!
Dann machen auch viel mehr Leute mit.
l.G.Roberto

[Michael D. (mike0815)]

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

[Charly B. (charly)]

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

[Hayo W. (blueflash)]

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

[Hayo W. (blueflash)]

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

[Ein Gast (Gast)]

Hallo Hayo und Entwickler,

wird das Welec auch ohne Nachrüstung der LEDs noch zu bedienen sein? Ich 
wollte eigentlich nicht dran rumlöten/-bohren usw. (manch anderer 
vielleicht auch nicht)
Daher die Frage ob die Software weiterhin so sein wird, das ich mit dem 
Welec auch ohne Umrüstung arbeiten kann (die LEDs als Quelle 
zusätzlicher Informationen). Oder werden damit dann 
Feedback-Informationen abgebildet, die ich für das Arbeiten mit dem DSO 
zwingend benötige.
Könnte man die Infos nicht einfach in der Kopfzeile auf dem TFT 
einblenden?

Sorry wenn ich vielleicht blod frage, ist mir aber grad so in den Sinn 
gekommen.

[Hayo W. (blueflash)]

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

[Hayo W. (blueflash)]

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

[Jürgen (Gast)]

Hi Hayo,

vergiss bitte den "Pulse Width Bug" nicht. Der ist zumindest noch in der 
2.0_preview enthalten!
Ohne den sieht es dann wie im Bild aus :-)

Gruß Jürgen

[Hayo W. (blueflash)]

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

[Roberto (Gast)]

Hallo
Für alle neuen oder seltenen, hier nur kurz der Link vom Hardware 
Thread:
Beitrag "Wittig(welec) DSO W20xxA Hardware"
Wo es um den Einbau der Led's geht :-)
l.G. Roberto

[A. F. (frankalicious)]

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

[Hayo W. (blueflash)]

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

[A. F. (frankalicious)]

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.

[Michael D. (mike0815)]

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

[Mirko B. (Gast)]

@Hayo

wie Michael D. im Hardwaethread schon schrieb, kann das LED-geblinke in 
manchen Situationen auch nerven.
Könntest du das im Hardwaremenü irgendwie abschaltbar machen (da könnte 
man ja dann auch später den LEDs verschiedene Funktionen zuordnen)?

Nur so als Anregung.

Viele Grüße,

Mirko

[branadic (Gast)]

Mirko B. schrieb:
> da könnte
> man ja dann auch später den LEDs verschiedene Funktionen zuordnen

Sinnigerweise werden die LEDs nur für Triggerfunktionen verwendet, 
schließlich befinden sie sich auch im Bereich des Triggermenus.

branadic

[Mirko B (Gast)]

aber auch da wären ja verschiedene Modi denkbar....

[Hayo W. (blueflash)]

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

[Rainer W. (rawi)]

@ 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")

[Hayo W. (blueflash)]

Alles klar Rainer,

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

Gruß Hayo

[Rolf W. (rowue)]

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

[Hayo W. (blueflash)]

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

[Rainer H. (rha)]

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

[Mirko B. (Gast)]

@hayo

Ist wahrscheinlich ein Feature und kein Bug - wenn ich den Noise-Filter 
einschalte und dann die Kiste aus und wieder an mache ist die 
Einstellung wieder weg.

Meine Vorstellung wäre eher "wie verlassen, so auch beim wieder 
einschalten"

Ist aber nicht wirklich ein Problem.

Vielen Dank für die neue Version - die LEDs blinken ganz lustig.

Mirko

PS: Und wenn du alle Bugs beseitigt hast, kannst du ja mittels FFT und 
den LEDs eine Lichtorgel implementieren;-)!

[Hayo W. (blueflash)]

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ß (Gast)]

Hallo!


Erstmal ein Danke an alle, die an der Entwicklung beteiligt sind!

Ich habe ein W2022A. Angeblich beträgt die Analogbandbreite ja 200MHz, 
aber man findet im Netz ja einiges zu dem "Ringing" das ab 80MHz 
auftreten soll. (Konnte ich noch nie nachmachen, besitze keinen 
Funktionsgenerator der so hochfrequente Signale erzeugen kann ;) )
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?
Kann man das irgendwie einschätzen?
Ich hoffe das ist nicht zu dämlich gefragt.


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

- Bei der Quickmeasure funktion lässt sich die Quelle bei mir nicht mit 
dem Softbutton umschalten. Quickmeasure funktioniert nur auf dem Kanal, 
der auch getriggert wird, was an sich ja Sinn macht. Wenn ich aber ein 
Verstärktes Sinussigal gegenüber dem Ursprünglichen darstelle, die beide 
die gleiche Frequenz haben, könnte ich ja beide ausmessen. Oder macht 
das keinen Sinn? In welchem Fall ist ein Umschalten vorgesehen?

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

Vielen Dank für eure Arbeit,


mfg

Steffen

[Hayo W. (blueflash)]

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

[Mirko B. (Gast)]

>Wenn Du also nach dem Einstellen des Noise-Filter
>einfach an der Timebase drehst wird es auch gespeichert.

ok, technisch einsehbar, aber doch von der Bedienung her ziemlich 
blöd...

Aber wie gesagt, nicht wirklich ein Problem, eher was fürs (extrem) 
Feintunig.

Schönes Wochenende,

Mirko

[Michael D. (mike0815)]

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

[Steffen Weiß (Gast)]

Hi!

Danke für die Antworten!

Bis 60MHz reicht mir völlig :) Dann bin ich ja zufrieden.

Hayo W. schrieb:
> Du mußt den Triggermode auf Normal oder Combi stellen, dann geht's!

Ah ok, danke. Hätte ich ja selbst drauf kommen können .. Hab mir jetzt 
nochmal das Handbuch von dem Teil und das Handbuch der Agilent-Vorlage 
angesehen - mach ich das nächste mal vorher, sorry.
Ist mein erstes Oszi für daheim, hab noch nicht viel an so einem Gerät 
gearbeitet.
Danke für die Geduld und Info! Gerade wollte ich noch fragen was ein 
Combi trigger ist, weil das scheint ja keine Original-Fkt. zu sein, habs 
dann aber im "Teil 2" von diesem Thread gefunden. Wirklich schwierig, 
hier mal durchzublicken ;)

Michael D. schrieb:
> Habe gerade mal dein Problem getestet, das Umschalten des Sourcekanal im
> Quickmeasure dauert zwar einen Augeblick, funzt aber einwandfrei!

Also ich habe keine Ahnung was ich falsch mache, bei mir geht das nicht.
Auf Kanal 1 liegt ein Sinus von ca. 4Vpp, auf Kanal 2 das verstärkte mit 
ca. 10Vpp. Frequenz ist 2,5kHz.
Triggersource ist Kanal 1 -> Drücke "Quick Measure", er vermisst 
automatisch Kanal 1 und zeigt mir Frequenz und Vpp an. Sehr gut.
Jetzt drücke ich den Softbutten für die Quelle und wähle Kanal 2 an, 
aber da tut sich nichts. Ändere ich den Triggermodus auf Kanal2 und 
drücke QuickMeasure dann funktioniert dieser auf Kanal2, schaltet aber 
nicht auf Kanal 1.

Kann ich irgendwie überprüfen ob die Firmware richtig aufgespielt ist?

Vielen Dank für die Hilfe, und vor allem für die Firmware :D

mfg

Steffen

[Stefan (Gast)]

@Steffen Weiß

Erst im QuickMeasure-Menü den Kanal wählen (ganz links), dann die 
Funktion, dann auf Measure. Bei bereits gestarteten Messungen kannst du 
den Kanal nicht ändern. Erst löschen und dann neu anlegen.

[Hayo W. (blueflash)]

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

[Hayo W. (blueflash)]

Oh, Stefan war schneller als ich :-)

[Rainer W. (rawi)]

@ 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

[Hayo W. (blueflash)]

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

[Mirko B. (Gast)]

Ich habe auch noch eine Kleinigkeit (ist bestimmt schon länger so)- im 
Math. werden außerhalb der FFT (*,+ usw.) die Kanäle 3 und 4 komplett 
ignoriert - lässt sich doch bestimmt noch einbauen?

Schönes Restwochenende,

Mirko

[Thomas O. (kosmos)]

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.

[Daniel G. (sh0dan)]

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

[Hayo W. (blueflash)]

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

[Hayo W. (blueflash)]

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

[Thomas O. (kosmos)]

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

[Hayo W. (blueflash)]

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

[Mirko B. (Gast)]

und bitte das Math für Kanal 3 + 4 nicht vergessen!

Viele Grüße,

Mirko

[Peter M. (none)]

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

[Peter M. (none)]

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

[Hayo W. (blueflash)]

Hallo allerseits,

es ist wieder still geworden, daher hier eine kleine Aufmunterung. Bei 
meinen Aufräumarbeiten bin ich dabei etliche Funktionen noch mal zu 
überarbeiten. So auch die Kalibrierroutinen. Dabei habe ich die 
DAC-Kalibrierung noch mal redesigned und die ADC-Kalibrierung etwas 
runder gemacht.

Die Routinen arbeiten jetzt so zuverlässig (und schneller), dass ich die 
alte "Search Zerolines" von WELEC jetzt ganz rausgeworfen habe (lief ja 
ohnehin nicht richtig).

Die Kalibrierung ist jetzt super einfach:

- Calibrate ADC
- Calibrate DAC

-> fertig

Ich habe die Funktionen bewußt nicht zusammengelegt, da ich es 
angenehmer finde beide Kalibrierungen getrennt durchführen zu können. 
Ich bitte um Rückmeldung, ob das bei Euch auch so gut funktioniert wie 
bei mir. Zusätzlich sind in der C4 auch noch einige Fehler beseitigt. 
Sie ist also eigentlich durchaus eine vollwertige Version nur dass die 
FFT noch nicht fertig ist.


And here in English:

The C4 contains new calibration routines. Calibration works much easier 
and more precisely now.

- Calibrate ADC
- Calibrate DAC

-> ready

The old (bad working) "Search Zerolines" written by WELEC disappeared 
completely. So let me know if it works on Your DSOs as good as on mine.

Hayo

[Mirko B. (Gast)]

Danke Meister (verbeug) ...;-))

Ne mal im ernst, hast du auch das Math für Kanal 3+4 eingebaut (bin in 
der Firma, kann nicht testen).

Viele Grüße + vielen Dank,

Mirko