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

@Hayo,
bitteschön...und du bekommst das schon hin ;-)

@Jürgen,
du kompilierst selbst? Warum?

Gruß Michael

Es ist eine Macke drin! Und ich hab sie auch schon...

Wie schon oben erklärt eine Stelle an der der Kanalindex zurückgerechnet 
wird - Altlast eben - jetzt ist auch mein W2022 richtig kalibriert. 
Moment, ich pack das mal eben in die C3 zusammen, kommt gleich...

Ok,

hoffe jetzt ist es ok.

@Jürgen

die stdint.h gehört ins inc Verzeichnis, dann sollte es gehen. Die kann 
man auch aus dem Internet runterladen. Ich hab sie jetzt mal dazugetan.

Gruß Hayo

Ach ja,

der Haken im Hardwaresetup...

Den hatte ich auch, konnte die Ursache aber nicht feststellen. 
Vermutlich irgendwas aus dem Flash.

Bei mir ist das nach zwei mal benutzen (an/aus/an/aus) weg gewesen.

Hayo

Hayo,
gibt es eine Möglichkeit, die Berechnung und Ablage der Trigonometrie 
Tabellen im Flash manuell erneut zu starten?

Hintergrund: Nach dem Flachen der 6.4 Version heute morgen startete
wie erwartet der Berechnungsprozess. Auf halbem Weg trat aber dann das
allseits gefürchtete Pixelflimmern im Display auf (RAM Lötstellen).
Blöderweise habe ich aber den Berechnungsvorgang nicht abgebrochen,
sondern durchlaufen lassen.
Die RAMs sind jetzt nachgelötet und das Skope scheint auch einwandfrei
zu arbeiten. Dennoch habe ich die Befürchtung, dass evtl. während der
Generierung der Tabellen durch den RAM-Fehler falsche Werte generiert
und im Flash abgelegt wurden.

Danke!

  Lothar

Jürgen schrieb:

> Compiliert aber noch nicht. Es werden 'undefined references to
> 'Opsys::_ExecHdl' angemault. Ich dachte Du hattest das wieder heraus
> genommen?

Nein, die Sourcen sind noch drin. Es wird zwar nicht mehr die volle 
Execution Queue benutzt, aber noch ein einzelner Execution Handler der 
in die Hauptschleife integriert ist. Hintergrund ist der reaktivierte 
Vsync-Interrupt. Ich benutze das zum verzögerten Ausführen von Routinen. 
Man kann beim VSync eine Sprungaddresse hinterlegen (z.B. 
SetupTrigger()) und einen Timeout. Nach Ablauf des Timeout wird die 
Adresse in den Execution Handler geschrieben und beim nächsten 
Schleifendurchlauf ausgeführt.

Damit kann man verhindern, dass beim Kurbeln am Triggerlevel ständig ein 
Hardwarezugriff durchgeführt wird. Erst wenn man aufhört zu kurbeln und 
der Timeout eintritt werden die Neuen Einstellungen übernommen. Benutze 
ich an einigen Stellen.

Benutzt Du das neue Makefile das ich mit ausliefere? Übrigens checke ich 
neuerdings alles im SVN ein, da dank Andi jetzt auch ein BF-Verzeichnis 
eingerichtet ist.

Hayo

Hayo W. schrieb:
> Übrigens checke ich neuerdings alles im SVN ein, da dank Andi jetzt auch ein BF-
> Verzeichnis eingerichtet ist.

... und alle Änderungen ab der Version 1.2.BF.5.0 (Jahr 2011) sind so 
für alle sichtbar!

Gruß Andi

@Hayo
> Ok,

> hoffe jetzt ist es ok.
Jaaa, jetzt ist alles schick!
Die 50ns hatten noch ein wenig gezickt, des öfteren die Offset u. 
Cal.Standart betätigt, dann war es endlich ok.
Ist das eigentlich wurscht, was ich zuerst drücke? Also zuerst den 
Offset dann Cal.Standart, oder besser umgekehrt?

@Jürgen
> Die Frage lautet doch eher "Warum nicht?" bei einem open source project
> :-)
Stimmt auch wieder... ;-)

Gruß Michael

Michael D. schrieb:
> Ist das eigentlich wurscht, was ich zuerst drücke? Also zuerst den
> Offset dann Cal.Standart, oder besser umgekehrt?

Da gibt es wohl ein kleines Mißverständnis, das Calibration Set brauchst 
Du eigentlich überhaupt nicht zu ändern, damit kannst Du nur einfach 
unterschiedliche Kalibrierungen für bestimmte Eingangsoffsets speichern. 
Das hatte ich (glaube ich) für Branadic und seine aktiven Tastköpfe 
eingebaut.

Übrigens habe ich noch einen Bug gefunden, das Channel Delay für Kanal 4 
und das Calibration Set wird nicht im Flash gespeichert, ich ermittle 
schon, aber die C4 wird es erst morgen geben. Vielleicht findet Ihr ja 
noch was, das kann ich dann gleich mit fixen.

Gruß Hayo

Das Calibrationset ist mir schon klar, bleibt ja in meine Fall auf 
Standart stehen. Wenn ich es betätige, tut sich aber trotzdem was. Also 
nur den Offset benutzen?

Der Lothar hat da ein Problem mit der Trigonometrie Tabelle.
Die hattest du das erste Mal in der 5.8XE.
Wenn ich auf eine Vorgängerversion z.B. 5.5 flashe(downgrade) und wieder 
zurück auch die 6.4, wird keine Tabelle mehr geladen, bleibt die jetzt 
für immer im Flash?

Gruß Michael

jetzt fällt es mir wieder ein :-( früher mußten wir 2 Knöppe drücken, 
heute nur noch den Offset.

Mir fällt gerade noch was zum OSS ein. Wenn ich die Browse-Leiste 
eingeblendet lasse, dann sieht man die OSS-Anzeige natürlich nicht mehr, 
wollen wir das so lassen, oder das OSS knapp unter die erste Gritlinie 
versetzen?

Gruß Michael

Hier noch 2 Screenshots zur Verdeutlichung.
Eingangssignal: Daumen auf dem Tastkopf ;-)
save.jpg -> So sieht das Signal aus und wird gespeichert
restore.jpg -> Das wird bei 'Recall' angezeigt

Lothar

Ok,

schnell noch geantwortet:

@Lothar

entweder Du spielst ein Backup ein, oder ich lade Dir hier morgen ein 
spezielles Flashfile hoch das Dein Trigo-Flash neu organisiert.


Das Recall-Problem sehe ich mir morgen mal an.


@Jürgen

ich lade einfach mal das komplette Build hoch in SFN und poste hier den 
Link,
dann sollte das gegessen sein.


@Michael

Ich würde das nur ungern tiefer setzen, dann habe ich das immer direkt 
im Signal.

Hayo

Hallo Hayo,

Danke für den Hinweis.
Wenn es mit dem Einspielen der Originalsoftware getan ist,
sollte ich das eigentlich hinbekommen.

Wollte ich sowieso mal machen. Nur um zu sehen, wie unglaublich schlecht
die Welec Firmware im Vergleich zur BF war.

Lothar

Super!
Hat geklappt.
Momentan initialisiert mein Oszi die Trigonometrie Tabellen neu.
Habe die Original Firmware 1.4 eingespielt.
DAS GRAUEN!!
Unglaublich, dass man DAMIT mal versucht hat, irgend etwas zu messen!

Ich kann nur jedem empfehlen, das mal zu tun.
Dann sieht man überdeutlich, welche Leistung hier mit der OpenFirmware 
erbracht wurde.

Nochmal ausdrücklich 1000 Dank an alle, die das Projekt voran getrieben
und ihre wertvolle Zeit geopfert haben!

Lothar

Hallo Leute,

auch von mir 1000 Dank für die Leistung die hier erbracht worden ist.
Ich werde heute Abend auch mal die neue FW auf das Oszi spielen.

Eine Frage habe ich aber noch.
Wird beim Auspielen das FPGA auch gleich mit geflasht oder muß dies
manuell über JTAG und USB-Blaster drauf?
Ist die FPGA FW auch im Zip-File enthalten?

Danke und Gruß,
Georg.

Lothar Merl schrieb:
> DAS GRAUEN!!
> Unglaublich, dass man DAMIT mal versucht hat, irgend etwas zu messen!

Ein ähnlicher Effekt stellt sich nochmal ein, wenn man vom jetzigen FPGA 
auf das neue Nios II wechselt...  ;-)

Georg X. schrieb:
> Wird beim Auspielen das FPGA auch gleich mit geflasht oder muß dies
> manuell über JTAG und USB-Blaster drauf?
> Ist die FPGA FW auch im Zip-File enthalten?

Die BF-Software enthielt noch nie ein FPGA-Update, sie arbeitet stets 
mit der Originalhardware. Die Software kann den FPGA-Konfigurationsflash 
nicht erreichen.
Dafür wirst du demnächst einen USB-Blaster oder den Slog-Treiber 
brauchen. Wir sind noch nicht besonders gut mit Anleitung zu dem Thema 
aufgestellt.

In die neue Hardware könnte ich theoretisch einen Zugang zum 
Konfigurationsflash einbauen. Dann könnte man aus der Software heraus 
die Hardware updaten, aber sich bei Unterbrechung oder Fehlfunktion auch 
aussperren. In dem Fall bräuchte man eh wieder einen Blaster, und für's 
erste Mal auch. Deshalb habe ich da wenig Ambitionen.

Jörg

@Georg

in dem "doc" Verzeichnis sind Anleitungen was Du installieren must und 
wie Du die Firmware dann ins DSO kriegst. Die original WELEC 
Update-Software (über USB) geht nicht!

Bei Fragen einfach hier melden.


@Jürgen + alle

Das aktuelle SDK-Build hab ich hier hochgeladen:

http://sourceforge.net/projects/welecw2000a/files/Development/SDK_BlueFlash_Build.zip/download

Einfach draufklicken sollte genügen.


@Lothar

Ja gruselig nicht wahr? Ich geb mir das auch ab und zu um mal zu sehen 
wie es früher war, dann freue ich mich hinterher immer über den 
aktuellen Stand.

:-)

Gruß Hayo

Alle gestern gemeldeten Fehler sind bereinigt.

Gruß Hayo

@Jürgen + Andi

Ich habe jetzt /bin  /lib   und /inc ins SVN mit eingecheckt

Hayo

Wow!

So schnell, wie Du die Fehler fixt, kann man die ja kaum finden!

Danke!

Ok und noch ein paar Bugfixes...

Hayo

Oh, einen hatte ich vergessen, habe noch Single Shot für FFT eingebaut.

Hayo

Hab noch einen gefunden: Beim Kalibrieren wird die Delay-Einstellung aus 
dem Flash gelöscht. Die C6 ist in Arbeit...

Hayo

Und hier ist sie...

Hayo

habe sie gleich mal geflasht.
Was macht denn das Häkchen unten rechts im HW-Menu?
Und wieso hat mein "Screenshot" ein Turkisefarbenes Grid, obwohl Weiß 
eingestellt ist? War bei der vorherigen Version nicht, habe das gerade 
getestet.

Gruß Michael

Das mit dem Häkchen hatten wir schon weiter oben, das geht nach einmal 
aus und wieder einschalten weg. Frag bloß nicht wo das her kommt. Hab 
mir schon nen Wolf gesucht.

Die Farbe vom Grid ist im Screenshotprogramm fest vorgegeben. Mit gefiel 
das Grünliche besser, deswegen habe ich das geändert. Kann aber jeder 
selbst im Coding verändern. Das Compilieren müßte eigentlich 
funktionieren wenn man die Cygwin Umgebung bei sich laufen hat, auf 
USB-Stick oder Platte.

Ansonsten nehme ich auch Bestellungen zu Wunschfarben an :-)

Hayo

@Hayo
> Das mit dem Häkchen hatten wir schon weiter oben, das geht nach einmal
> aus und wieder einschalten weg. Frag bloß nicht wo das her kommt. Hab
> mir schon nen Wolf gesucht.
Das ist ja Quatsch damit wertvolle Zeit zu verschwenden!
Mich stört es nicht, meinetwegen können noch 2 dazu, unwichtig...

Mit dem Screenshot, dachte ich nur, das es wäre ein Bug wäre.
Wem die Farbe nicht gefällt, kann ja die vorherige Screenshot-Version 
benutzen, also auch nicht lebenswichtig. ;-)

Gruß Michael

Michael D. schrieb:
> @Hayo
> Mich stört es nicht, meinetwegen können noch 2 dazu, unwichtig...
Mich stört es schon wenn ich nicht weiß warum...

> Mit dem Screenshot, dachte ich nur, das es wäre ein Bug wäre.
Nein ein Feature!

> Wem die Farbe nicht gefällt, kann ja die vorherige Screenshot-Version
> benutzen, also auch nicht lebenswichtig. ;-)
Das stimmt, außer der Farbe sind die identisch. Habe auch keine neue 
Versionsnummer vergeben.

Hayo

Und ich habe mir extra Mühe gegeben, am LCD-Stecker die genauen Bits pro 
Farbe gemessen, um für's neue FPGA und den Osoz-Screenshot die 
originalen Farben zu verwenden, und dann kommt ihr Künstlervolk daher! 
;-)

Jörg

Schande über mich, aber als einer der mit den alten Analog Oszis groß 
geworden ist hat das grüne Grid einfach was Vertrautes für mich...
;-)

Hayo

p.s. bin erstmal eine Woche Ski-fahren, hoffe aber dass ich da irgendwie 
Internetzugang habe.

> und dann kommt ihr Künstlervolk daher!
> ;-)
und das stimmt auch noch! ;-)
fällt unter "Automotive-Design" oder "innovatives Design" :-)

Jörg

> Schande über mich, aber als einer der mit den alten Analog Oszis groß
> geworden ist hat das grüne Grid einfach was Vertrautes für mich...
> ;-)
hm, im Displaymenu hast du diese Farbe "Teal" genannt.
Ist eigendlich ein weiblicher Vorname, der aber auch die Farbe Patrol 
oder Blau-Grün definiert.
Ich war mal ein Fan von dem Farbton.

Wohin geht es denn zum Ski fahren?

Gruß Michael

Nach Schladming, hoffe dass da noch Schnee liegt, sonst hab ich das 
Lappy dabei und programmiere ein wenig :-)

Teal - die Farbe hab ich bei meiner Kiste eingestellt, das gefällt mir 
einfach am Besten. Soll ja auch dem Auge gefallen.

Hayo

Ok, vom HW-Thread nach hier...

> Hi Michael,

> ich vermute Du hast für die Rise/Fall-Timemessung eine zu kleine
> Zeitbasis eingestellt. Dann reichen ihm die Punkte zur Messung nicht
> mehr aus.

> Mach mal einen Screenshot - aber dann im Firmwarethread.
Hier mal 2 Screenshots von der Rise/Fall-Anzeige
Das Signal ist ein Rechteck 1,25 und mit einer Amplitude von 5V, 
Rise/Falltime 1-2ns, Jitter 25ps.
Bei beiden Zeitbasen wird 0s angezeigt, oder es schwankt manchmal 
zwischen "s" und "ns". Dazwischen sollte doch "µs" liegen?!
In höheren Zeitbasen, bzw. Frequenzen, wird die Rise/Falltime korrekt 
angezeigt.

Gruß Michael

EDIT. Achso, mußte leider fotografieren, da das ganze Geraffel zu weit 
vom PC hängt. Vielleicht stricke ich mir noch eine 8m RS232 Leitung... 
:-)

>Gruß Hayo

> p.s. zu Peak Detect sag ich noch was...
ja, sag' was ;-)

Hi Michael,

wie ich schon vermutet habe ist die Zeitbasis für die Messung zu langsam 
und die Pegelaussteuerung ist zu klein. Die Flanke auf Deinen 
Screenshots geht so steil hoch, dass auch bei einer manuellen Messung 
mit den Cursorn die Anstiegszeit Null wäre. Je schräger die "Rampe", 
desto genauer ist die Messung. Gemessen wird die Zeit von 10% bis 90% 
der Flanke. Das sind die beiden gepunkteten Linien im Grid. Die 
Signalamplitude sollte daher auf den jeweils letzten Gridlinien liegen.

In etwa so wie auf dem Screenshot. Das ist die Anstiegszeit meines alten 
HP3310B Signalgenerators.

Dein Signal scheint aber deutlich schneller zu sein. Evtl. ist auch 
einfach das Signal zu schnell für unser Oszi. Um das zu sehen müßtest Du 
aber auf 50 ns auflösen und einen Spannungsbereich wählen in dem Du die 
Amplitude weiter aussteuern kannst.

Wenn dann immer noch nichts geht ist das WELEC einfach zu langsam...
Ich denke eine Anstiegszeit von 5ns sollte es aber schaffen - und das 
ist schon ziemlich schnell.

Gruß Hayo

29ns das ist natürlich eine langsame Anstiegszeit.

Ich habe gestern noch ein paar Messungen mit dem schnellen Signal 
gemacht, müßte so um die 2ns sein, angegeben ist der ICS511 mit 
Rise/Fall-Time von 1nS bei 4pF load. Da kommt ja noch die Leitungslänge, 
Stecker etc. dazu, da könnte es mit 2-3ns hinkommen.
Das Welec ist in der Lage picosekunden zu messen, ob das real ist, kann 
ich nicht beurteilen.
Anbei ein paar Shots
Die 50MHz sehen noch einigermaßen gut aus, bis auf die viel zu hohe 
Amplitude. Hier wird z.B. in ps gemessen.

bei 130MHz habe ich schon 12V
    150MHz  14V :-(
    183MHz  11,2V
    200MHz  4,68V  dieser Wert ist realistischer

Könnte es an den noch nicht ersetzten 24R und 150R bzw. 170R liegen?


Gruß Michael

Michael D. schrieb:

> Das Welec ist in der Lage picosekunden zu messen, ob das real ist, kann
> ich nicht beurteilen.

Nein, kann es nicht. Das sind interpolierte Zeitbasen. da wird das 
Signal nur "gestretcht".

Die schnellste reale Zeitbasis ist 50ns/Div. Da ist ein Pixel eine 
Nanosekunde.

Bei einer Anstiegszeit von 2ns wird es tatsächlich etwas eng. Da ist das 
WELEC wohl einfach zu langsam. Das ist kein Firmwarefehler, sondern Du 
lotest gerade die Grenzen des Gerätes aus - auch nicht übel :-)

Gruß Hayo

> Das ist kein Firmwarefehler...
Ja, das ist mir schon klar.
Wie kommt es, das so ab 100MHz die Amplitude extrem in die Höhe geht und 
ab 200MHz wieder absackt auf einen einigermaßen realistischen Wert?

Übrigens habe ich ohne Tastkopf und direkt mit einem RG174 an BNC sowie 
1:1 ohne Abschluss gemessen.

Da ich noch die originale Bestückung in der Eingangsstufe habe, frage 
ich mich, ob da merkliche Besserung nach der Modifizierung eintritt.
Gibt es da nicht irgendwo eine Dokumentation für vorher u. nachher?

Ich könnte noch einen Vergleich zum Voltcraft 3062C posten, wenn 
Interesse besteht. Da steigt zwar auch die Amplitude, nur nicht so 
extrem hoch.

Gruß Michael

Michael D. schrieb:

> Wie kommt es, das so ab 100MHz die Amplitude extrem in die Höhe geht und
> ab 200MHz wieder absackt auf einen einigermaßen realistischen Wert?

Das ist der Frequenzgang des original bestückten WELEC. Das hatten ja 
einer unserer Hardwarespezi mal vor längerer Zeit genau ausgemessen und 
als Diagramm hier dargestellt (gleich das Erste):

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

> Übrigens habe ich ohne Tastkopf und direkt mit einem RG174 an BNC sowie
> 1:1 ohne Abschluss gemessen.

Das ist allerdings Messtechnisch eine Vollkatastrophe. Da dürfte es auf 
der Leitung lustig klingeln...

Du hast zwei Möglichkeiten:

1. Du schließt den Ausgang Deiner Schaltung mit einem 50 Ohm Widerstand 
ab und machst am anderen Ende (Oszi-Eingang) auch einen Abschluß dran, 
was natürlich die Amplitude verkleinert. Es ist zu prüfen, ob Dein 
Ausgangskreis genügend Ausgangsleistung liefert um die 100 Ohm zu 
befeuern.

2. Du mißt mit einem Tastkopf im 10x Modus, ist am einfachsten, 
erfordert aber bei deinem Signal einen guten Tastkopf mit großer 
Bandbreite.

> Da ich noch die originale Bestückung in der Eingangsstufe habe, frage
> ich mich, ob da merkliche Besserung nach der Modifizierung eintritt.
> Gibt es da nicht irgendwo eine Dokumentation für vorher u. nachher?
Ich habe dazu mal eine Testreihe mit Bildern gemacht, ist aber etwas 
her. In Kürze - bei Verwendung von 24,9/174 Ohm wird der Frequenzgang 
wieder linear und die Eingangsstufe neigt nicht mehr so sehr zum 
Schwingen.
Ich habe mir gerade einen 100er Streifen 24.9 Ohm Widerstände für mein 
W2014A geordert. Wenn Bedarf besteht kann ich die Kombination 24,9/180 
anbieten, einfach PIN mit Adresse schreiben, dann schicke ich ein 
Briefchen...

Gruß Hayo


> Ich könnte noch einen Vergleich zum Voltcraft 3062C posten, wenn
> Interesse besteht.
Dann aber mit korrektem Messaufbau.

Gruß Hayo

So Michael ich hoffe diese kleine Doku beantwortet Deine Fragen zum Peak 
Detect. Ich habe gerade die aktuelle Release fertig und bereite den 
Upload vor. Dann könnt ihr selbst probieren.

Hayo

So, viel Spaß beim Ausprobieren.


You will find the english version of the peak detect docu inside the doc 
directory.

enjoy...

Hayo

Wie mache ich einen (oder mehrere) Screenshots?

Ich beschreibe mal die Prozedur unter Windows, aber unter Linux geht es 
fast genauso.

Also im Verzeichnis screenshot findet man eine Batchdatei scrsh.bat - 
diese muß mit einem Editor auf die eigene Hardware angepasst werden.

Der String "%~dp0\w2000a-screenshot.exe" -c 1 -b -a %* enthält als 
Argument den zu benutzenden COM-Port, hier COM1. Das muß man 
entsprechend anpassen und dann sichern.

Dann das DSO einschalten und per Doppelklick die Batchdatei starten. Das 
Programm verbindet sich mit dem DSO, prüft die aktuelle Firmware auf dem 
DSO und wartet dann auf Screenshots, die man am DSO per Doppeldruck auf 
die Quick Printtaste oder im Printmenü selbst auslöst.

Die Bildschirmausgabe sollte so aussehen:

* Connecting to DSO and retrieving version information... done
  - found firmware version:  6.5
  - found hardware version:  8C7.0.G
  - found model:  W2022A
* Waiting for screenshot, trace, or measurement...

Man kann das Programm natürlich auch direkt mit den Argumenten starten. 
Der Screenshot kann auch umgekehrt vom Programm aus getriggert werden.

Mit -h als Argument bekommt man einen Hilfetext angezeigt.

Das Programm wartet und verarbeitet so lange Screenshots bis es beendet 
wird.

@Martin
Die von Dir beschriebene Meldung läßt mich vermuten, dass Du das DSO 
erst hinterher eingeschaltet hast.

 Gruß Hayo

Nachdem ich mir bei meinem Neuzugang - einem 100 MHz Pulsgenerator, der 
leider defekt bei mir ankam - einen Wolf gesucht habe bis ich die 
Fehlerquellen lokalisiert hatte, läuft das Teil jetzt wie Schmitts 
Katze. Ich habe die Gelegenheit genutzt und passend zu unserem Thema 
weiter oben ein paar Messungen vorzunehmen (gehört ja eigentlich in den 
HW Thread).

Ich war doch positiv überrascht, das WELEC ist gar nicht so übel.

Die Fakten:

Der Pulsgenerator ist spezifziert mit 2.5ns Anstiegszeit. Gemessen habe 
ich mit dem Tektronix 2465A (Bw ~400MHz, Tr ~0,8ns) eine Anstiegszeit 
von 2.4ns.

Wie man auf dem Screenshot sehen kann schafft das W2022A diese 
Anstiegszeit ebenfalls, was ich nicht vermutet hätte. Das entspricht 
einer Bandbreite von 140 - 150 MHz. Das ist schon ganz anständig.

Das W2014A schafft da - genau wie mein OWON SDS8102 - "nur" 3ns, was 
einer Bandbreite von etwas über 100MHz entspricht.

Für diese Messungen muß man im Hardwaremenü unbedingt die Einstellung 
"High Frequency" wählen, da es sonst zu überlagerten Schwingungen kommt.

Gruß Hayo

Hallo,
ich habe ein Problem mit dem Logikmodus. Ich versuche ein zyklisches 
I2C-Signal (alle 2s 10Byte, 100kHz) im TTL-Modus zu betrachten. 
Irgendwie scheint die Zeitauflösung zu spinnen. Das ist so auffällig, 
dass ich mir gar nicht vorstellen kann, dass das noch nicht aufgefallen 
ist.
Wenn ich von 2V Auflösung und 20µs auf Logic TTL5V umschalte wird wie 
erwartet getriggert, wenn ich den Triggermodus wieder auf Normal 
gestellt habe. Allerdings führt dann ein Ändern der Zeitauflösung incl. 
neuem Triggern zu keiner Veränderung in der Zeitachse. Soll heißen das 
Signal bleibt scheinbar in der vorherigen Zeitauflösung, die Anzeige der 
Auflösung oben rechts ändert sich. Bei manchen Änderungen wird auch das 
Signal gestaucht obwohl eine Streckung zu erwarten wäre.

Hat das schon mal jemand gesehen?

Gruß, Rainer

Hat Dein I2C Signal denn TTL-Pegel? Welche Probe-Einstellung hast Du 
eingestellt? Es wird nur 1:1 und 1:10 unterstützt. Das muß auch genau 
passend zur Prüfspitze eingestellt werden, da sonst die Pegel nicht 
stimmen.

Gruß Hayo

Hallo Hayo,

Wenn ich mit der neuen Firmware eine Offset Calibration mache dann 
bekomme ich schöne Streifen auf dem Display. Ist ein W2022A.

Sonst habe ich noch kein merkwürdiges Verhalten feststellen können.

Hallo Stefan,

das ist kein gutes Zeichen. Die Streifen tauchen eigentlich immer nur 
dann auf, wenn es Probleme mit dem RAM oder dem Display gibt. Meine 
beiden W2xxxA machen beide keine Streifen bei der Kalibrierung.

Kannst Du mit einer Kamera evtl. ein Foto davon machen?

Gruß Hayo

Ja, ist es. Jörg hat dafür einen Treiber geschrieben, der auch in der 
aktuellen Firmware auswählbar ist. Wie die Erfahrungen damit sind mußt 
Du Jörg und Branadic selbst fragen. Wer das noch eingebaut hat weiß ich 
nicht.

Gruß Hayo

Hallo,
anbei drei Beweisfotos für das beschriebene Verhalten. Ich bin von 2V zu 
Logik TTL gegangen, habe dann die Zeitachse verstellt (50µs, 20µs, 
10µs). Es wurde auch erneut getriggert. Beim Umstellen von 10µs Logik 
auf 2V (Logik aus) bleibt die falsche Zeitachse. Erst ein Drehen an der 
Zeitauflösung stellt die korrekten Zustände wieder her.

Gruß,
Rainer

Ich check das mal...

Hayo W. schrieb:
> Ja, ist es. Jörg hat dafür einen Treiber geschrieben, der auch in der
> aktuellen Firmware auswählbar ist. Wie die Erfahrungen damit sind mußt
> Du Jörg und Branadic selbst fragen. Wer das noch eingebaut hat weiß ich
> nicht.

Ist schon lange her, ich meine mich dunkel zu erinnern daß das in der 
BF-Firmware noch nicht recht hinhaut. Ich habe den Lowlevel-Support 
dafür gebaut, dann gab es etwas Schwierigkeiten mit der Integration, 
weil das (aus meiner Sicht) alles so vermurkst ist. Kann sein, daß ich 
mich da auf Hayo verlassen habe, das zuende zu stricken, aber er hat 
seine Platine nie eingebaut. Sorry daß wir jetzt beide im Kreis 
aufeinander zeigen...

In Osoz funktioniert es "richtig". Es ist auch möglich, die Kanäle 
unterschiedlich zu bestücken.

Jörg

Rainer, Du hast recht, merkwürdige Dinge gehen da vor. Muß ich mir mal 
genauer ansehen. Da ich über Ostern Besuch bekomme, wird das wohl erst 
was nächste Woche.

Gruß Hayo

Sourceforge drängelt mit Erinnerungs-Emails, wir sollen unser Projekt 
endlich auf deren neue "Allura" Plattform umstellen. Nun kriegt man 
zusätzlich bei jedem Einchecken eine Erinnerung auf den Schirm.

Ich habe mich noch nicht getraut das anzuschubsen. Im Netz liest man 
aber nichts schlechtes. Sicherheitshalber habe ich mir heute ein Backup 
des gesamten Repositories gezogen, das ist die Checkin-Historie. Also 
nicht das Wiki.

Das gleiche habe ich bei einem anderen Sourceforge-Projekt von mir 
gemacht (OpenHC, da mache ich derzeit nichts), und gewissermaßen als 
Vorab-Test für uns das Update-Knöpfchen gedrückt. Damit ist das 
beantragt, wird irgendwann ausgeführt, man bekommt Nachricht. Keine 
Ahnung ob das ein automatisierter Prozeß ist oder da jemand werktags ran 
muß. Mal sehen wie lange das braucht.

Das blöde ist, das die Commits zwische Beantragung und vollzogener 
Migration verloren gehen können. Wir müssen dann also ein Weilchen die 
Füße still halten.

Jörg

Ok Rainer hab doch noch mal schnell versucht das Problem zu lösen. Hatte 
aber keine Zeit das jetzt tiefschürfend zu testen. Sieht aber für mich 
besser aus jetzt. Ich muß jetzt los zum Training und schaue dann gegen 
23:00 noch mal rein.

Gruß Hayo

Naaa, noch keine neuen Erkenntnisse? Morgen (heute) ist doch frei...

Hayo

Hi Luc,

the pulse generator is an old device from the 80ies made in Hungary, 
type TR-0307 (EMG). It is completely analog controlled, no digital stuff 
in it. I like it because of the simple and uncomplicated handling. It is 
constructed very modular with high quality standard parts and is 
therefore good to repair if something is defect. It is working very fine 
now - and it was cheap!

It has a rise time of 2.4ns and many possibilities of signal forming 
(variable rise and fall time), especially simulating fast glitches and 
spikes but also to produce a standard square wave up to 100MHz. Seems to 
be ideal for testing the W2000A models.


> Vielleicht könnten Sie verwenden, um controlloare was passiert, indem
> die vertikale Größe

Unfortunately I did not understand, what you meant with this.


Kind regards

Hayo

Hi Sladjan,

> ...but whan i turn off oscilloscope and on, adc_change12
> register is missing my value.

I changed the storage location of calibration and register values. They 
now have an own flash sector.

> adc_change12 = 28000 is my best setting.

I tested it and it seems to work ok on my W2014A, on the W2022A I got 
strong ringing on the signal. I added it in the hardware menu as "High 
Freq 2"

Regards

Hayo

May be I forgot the saving call for this function. I will check it and 
add it. You can use a work around - after centering you can switch your 
timebase one higher or lower and then back. This will trigger the saving 
routine.

Hayo

Hallo Hayo,
ich bin während der Arbeitszeit am Welec, daher erst jetzt die 
Rückmeldung, sorry.
Die Logikerkennung mit richtiger Timebase scheint zu funktionieren. 
Super, danke.
Jetzt noch ein Analyser für I2C, SPI, UART... oder eine schnelle USB 
online Datenübertagung zur PC-Analyse, dann wäre der (serielle) 
Logicanalyser da.

Bitte nicht als (Auf-)Forderung verstehen, nur ein Wunschtraum.

Viele Grüße,
Rainer

Auch hier kurz der Hinweis auf den WELEC Einsteiger-Thread:

Beitrag "Wittig(welec) DSO W20xxA Einsteiger"

Hayo

Hallo Ricardo,

das weist normalerweise auf das übliche Problem mit dem RAM hin. Bei mir 
konnte ich noch keine Abstürze feststellen. Das heißt - Anschlüsse 
nachlöten.


An Alle:

Hat einer von Euch auch Abstürze?

Gruß Hayo

Hey Hayo,

ja ich kann mich dem Ricardo nur anschließen. Ich habe nur den Vergleich 
zwischen der 6.3, 6.5 und 6.5C3 ...
... die 6.5 und 6.5C3 zeigen einen Blue Screen (rosa Steifen) auf dem 
Display.

Bei Tests mit Jörg war mir der direkte Vergleich vor Tagen aufgefallen 
(leider noch nicht zum posten gekommen).

Grüße Andiiiiy

Ok, danke für den Hinweis!

Dann muß Ricardo ja doch nicht an seinem RAM rumlöten. Ich schau mir das 
mal an ob ich das nachstellen kann, sonst frag ich noch mal nach.

Gruß Hayo

Der Fehler mit den Abstürzen beim Kalibrieren ist bestätigt. Da ist 
irgendwo ein übler Bug drin. Korrektur kommt so schnell wie möglich. Bis 
dahin bitte nur bei Zeitbasen >= 5µs kalibrieren.

Hayo

Der Versuchsballon ist durch, ein Sourceforge-Projekt von mir ist jetzt 
umgestellt:

Jörg H. schrieb:
> Sourceforge drängelt mit Erinnerungs-Emails, wir sollen unser Projekt
> endlich auf deren neue "Allura" Plattform umstellen. Nun kriegt man
> zusätzlich bei jedem Einchecken eine Erinnerung auf den Schirm.
...
> und gewissermaßen als
> Vorab-Test für uns das Update-Knöpfchen gedrückt. Damit ist das
> beantragt, wird irgendwann ausgeführt, man bekommt Nachricht. Keine
> Ahnung ob das ein automatisierter Prozeß ist oder da jemand werktags ran
> muß. Mal sehen wie lange das braucht.

Heute bekam ich Nachricht, also nach knapp einem Monat. In der ersten 
stand, daß das Repository migriert wird, etwa eine Stunde später bekam 
ich Nachricht das es abgeschlossen ist und unter neuere Adresse 
auschecken soll. Habe ich ausprobiert, scheint zu funktionieren.

Unser Welec-Projekt ist über das Warten auf diesen Test so spät dran, 
daß wir jetzt bereits mit Zwangsmigration bedroht werden:
http://sourceforge.net/blog/upgrades-april22/

Wird also irgendwann passieren, nicht wundern.

Jörg

Hat wieder etwas gedauert, aber hier ist sie. Neu ist der Support für 
die Low Budget Mod. Ansonsten Bugfixes.

Bitte nach dem Flashen im Hardwaremenü die Gain-Einstellung prüfen. 
Durch die LB-Mod haben sich die Einträge verschoben.

Hayo

Hallo Hayo,
im Gain Menu steht standartmässig 1.000 !
Welche Gain Einstellung ist für die originale Bestückung relevant und 
welche für die modifizierte?
Beim hochdrehen gehen die Nulllinien beider Kanäle auseinander 
(entgegengesetzt) dann gehen diese automatisch wieder in die 
ursprüngliche Position. Kannst du dazu etwas sagen?

Gruß Michael

Bei 1.00 sind die Skalierungsfaktoren genau so wie sie im Programm 
vorgegeben sind bzw. wie Du sie im PreGain-Menu eingestellt hast. Für 
den Fall, dass bei Dir dann aufgrund von Bauteiltoleranzen oder 
Ähnliches die angezeigten Pegel nicht stimmen, kannst Du dann mit Werten 
die von 1.00 abweichen den Pegel korrigieren. Der eingestellte 
Skalierungsfaktor wird mit dem angezeigten Gain multipliziert.

Beispiel:

Wer die LB-Mod drin hat stellt im PreGain natürlich "LB-Mod" ein. Der 
Skalierungsfaktor ist dann 1.6 bei den 5er Bereichen (Bei Gain 1.00). 
Wenn Du z.B statt 330 Ohm Abschluß nur 300 Ohm verwendest, wirst Du 
einen größeren Skalierungsfaktor benötigen. Dann drehst Du den Gain 
langsam hoch z.B. auf 1.15) und kalibrierst das Gerät nochmal. Danach 
ist der Skalierungsfaktor 1.6 * 1.15 = 1.84

War das einigermaßen verständlich?

Gruß Hayo

p.s. Bin gerade dabei in meinem Zimmer neue Fenster einzubauen, daher 
bin ich etwas "offline".

Jörg H. schrieb:
> Unser Welec-Projekt ist über das Warten auf diesen Test so spät dran,
> daß wir jetzt bereits mit Zwangsmigration bedroht werden:
> http://sourceforge.net/blog/upgrades-april22/
>
> Wird also irgendwann passieren, nicht wundern.

Gestern ist es passiert, unser svn Repository ist umgezogen.
Es ist ganz einfach, die Arbeitskopie auch drauf folgen zu lassen. Noch 
einfacher als die Email von Sourceforge beschreibt, man braucht nur im 
obersten Verzeichnis des eigenen Checkouts folgendes eingeben:

1

svn relocate https://svn.code.sf.net/p/welecw2000a/code

Beim nächsten Checkin wird man dann noch mal nach Username und Password 
gefragt.

Zwei kleine Commits habe ich schon erfolgreich in das neue Repository 
gemacht. Wir sind jetzt übrigens bei svn Revision #999, der nächste 
Commit wird der "Jubiläumscommit" #1000. (Ziemlich genau die Hälfte der 
Checkins ist von mir.)

Jörg

Herr Lehmann schrieb:
> Also bei meinem Scope scheint der Single Shot nicht mehr zu
> funktionieren.

Ja es gibt einen Fehler, der indirekt durch die Umstellung der 
Ausleselänge zustande kommt. Das ist in der BF.6.7 bereits behoben, aber 
ich muß noch die Faktoren für die OPA653 Mod anpassen, dann kommt die 
neue Version.

Gruß Hayo

Kein Problem, bei meinem Tek ist der Drehsinn übrigens auch im 
Uhrzeigersinn zu den kleineren Zeitbasen hin. Passt also gut wie es ist.

Hier die neue Version mit Unterstüzung der OPA653 Mod und noch einigen 
Änderungen/Fixes.


Gruß Hayo

Hey Hayo,
ich hatte ja schon Anfang des Jahres von meinen Spike Problemen auf 
Kanal 2 berichtet. Schon damals hatte "sar" ähnliche Probleme geäußert.
Ich habe das Wittig mittlerweile ausgemustert, allerdings ist mir jetzt 
ein Topic im Marktplatz aufgefallen wo auch wieder jemand ("sh0dan") von 
vorher nicht vorhandenen Spikes auf Kanal 2 berichtet. Die Spikes traten 
scheinbar nach einem Update auf und stehen eventuell wieder in 
Zusammenhang mit der Temperatur.
Bei mir kann ich das zeitlich auf ca. die Version 5.8 eingrenzen, 
möglicherweise auch etwas davor da ich nicht jede Version getestet habe. 
Auf einmal waren jedenfalls dann die massiven Spikes da, die ich davor 
nie! hatte.

Meine Frage:
Hat BF5.8 oder eine vorige Firmware Version einen Speicherbereich oder 
sonstiges verändert, der beim löschen mit Welec Updater oder einem neuen 
Flashen nicht mehr rückgesetzt werden kann?
Ich bekomme bei mir die Spikes in keiner Konfiguration mehr weg. Ich 
denke da an die Funktionen, die ins Flash geschrieben wurden o.ä.

Einen alterungsbedingten Hardware-Defekt, der bei nun 3 Leuten innerhalb 
von wenigen Monaten auftritt, halte ich mittlerweile für sehr 
unwahrscheinlich. Diese "Hardcore-Spikes" (man beachte die Screenshots, 
das ist mehr als "altbekannten" Spikes an der Flanke etc.) wurden 
jedenfalls nach meiner Recherche noch nie vor Dezember 2012 berichtet.

Es ist mit Sicherheit ein Timingproblem das in Zusammenhang mit dem 
FPGA-Design steht und die ADCs betrifft, nur wird dieses nach meinen 
aktuellen Erkenntnissen durch eine Änderung der Firmware hervorgerufen 
bzw. begünstigt.
Ich denke doch, dass das diese Sache mehr als ein Einzelproblem mit 
manchen Scopes ist.
Wäre toll, wenn du dir das aus Firmware Sicht nochmal ansehen könntest.

Hallo Ben,

nach zwei Tagen Sturm im Ionischen Meer in einer einsamen Bucht, bin ich 
heute mal wieder dank WLAN online. Ja das Thema Spikes ist ja kein 
Neues. Auch der Zusammenhang mit dem thermischen Zustand des Gerätes 
wurde mehrfach berichtet. Wobei aber interessanterweise bei einigen 
Geräten die Spikes mit warmem Gerät verschwinden, während bei anderen 
die Spikes erst bei warmem Gerät auftauchen. Wesentlich scheint hier die 
Hardwareversion (FPGA-Version) zu sein. Softwareseitig (Firmware) habe 
ich aber seit einiger Zeit nichts verändert. Bei meinen beiden Geräten 
kann ich auch keine Auffälligkeiten gegenüber vorher feststellen. Hast 
Du evtl. die Hardwareeinstellungen anders als vorher?

Wenn man die "High Frequency" Einstellungen benutzt hat man teils 
deutlich mehr Spikes als in der "Factory" Einstellung - dafür aber keine 
Signalverzerrung bei hohen Frequenzen.

Auch der Ausschnitt des Signals auf der Zeitachse (in denglisch 
"Pretrigger" und "Memory Browser") hat in Verbindung mit der Zeitbasis 
Einfluß darauf. Soll heißen, wenn man mit anderen Einstellungen arbeitet 
als vorher, kann es sein, dass es einem mehr auffällt.

Als Gegentest kann man ein Komplettbackup mit der alten Originalfirmware 
einspielen um zu testen ob es da Unterschiede gibt. Das haben auch schon 
Einige getan um dann festzustellen, dass es vorher auch schon so war, 
aber irgendwie nicht so aufgefallen ist.

Gruß vom Skipper

Hayo

Mit dem neuen FPGA-Design ist das Geschichte, da gibt es keine Spikes 
mehr.
Kein Grund, Geräte dauerhaft auszumustern.

Jörg

das stimmt, ich erwarte auch gespannt das finale FPGA Design. Aber als 
einziges Scopes war das Wittig schon immer sehr gewagt, und mit diesen 
Spikes ist es eben total unbrauchbar. Da kann ich also nicht warten...
Obwohl dieses Projekt inkl. deiner sehr vielversprechenden Arbeit 
eigentlich der Hauptgrund ist, das Wittig noch im Regal stehen zu lassen 
:)
Dennoch- es wurde halt zum Bastel- Scope degardiert und "gemessen" wird 
mit was anderem.

Bleibt für mich auch unabhängig davon, dass der neue FPGA Entwurf besser 
ist ;) die Frage, warum das überhaupt passiert ist- das Original Design 
hatte diesen Fehler (starke Spikes Kanal 2) ja ursprünglich (bei mir und 
2 anderen) nicht.

Hat mir jemand vielleicht ein aktuelles Dump vom 2022A (kompletter 
Speicher) mit der BF-FW?

@Ben
> Hat mir jemand vielleicht ein aktuelles Dump vom 2022A (kompletter
> Speicher) mit der BF-FW?

welche Version denn???

elecBlu schrieb:
> Hast du dir mal die Spike-Screenshots angesehen? Es rammelt die Spikes
> dauerhaft, das fällt jedem sofort auf.
> Natürlich sind nicht alle Geräte betroffen, genauere Untersuchungen
> welche HW Version es ist müssen wir noch anstellen.
> Bei mir sind die Spikes (wie berichtet) auch nie wieder verschwunden
> d.h. auch nicht nach einem Komplettbackup.
> Und dass hier mehrere auf einmal von Spikes berichten, die sie vorher
> nie hatten, ist schon merkwürdig, findest du nicht?

Hi, habe wieder WLAN hier auf dem Boot und nutze die Gelegenheit mal um 
zu antworten. Also wenn Du nach dem Einspielen eines Komplettbackups 
immer noch grobe Spikes hast, gibt es nach meiner Logik nur zwei 
Möglichkeiten:

1. Es ist Dir vorher nicht so aufgefallen, weil Du andere Einstellungen 
verwendet hast.

2. Irgendetwas an Deiner Hardware hat sich geändert (thermisch, 
Alterung, lose Pins etc.)

Jedenfalls ist das Gerät ja nach dem Einspielen des Backups wieder im 
Originalzustand, so dass die BF-Firmware nicht dafür verantwortlich sein 
kann. An der FPGA-Konfiguration kann die Firmware nichts verändern, das 
scheidet also aus.

Gruß Hayo

eben deshalb war ja meine Frage oben ob über oder unter dem üblichen 
Dump- Speicherbereich was geändert wurde/ wird! Insbesondere das 
schreiben der Math- Funktionen ins Flash mit 5.7! Da es in einer 
folgenden Version (ich hatte nicht jedes Release geflasht) auftrat.
Wenn das nicht der Fall ist, kann es das wohl nicht sein das ist mir 
auch klar.
Und es wäre sofort aufgefallen, glaubs oder glaubs nicht, wenn die 
Spikes vorhanden waren, siehe Screens und damalige Beschreibung. Ich 
habe das Gerät 3 Jahre genutzt, genauso wie "sh0dan" mir fast 
identisches berichtet hat.

@ Michael: Hardware 8C7.0, BF Version eigentlich egal.

Also Obacht Leute, nach  3,5 - 4 Jahren verabschieden sich die Welecs 
bevorzugt, hardwarebedingt ;) Gabs nicht 3 Jahre Garantie? Höhö.

Ben L. schrieb:
> eben deshalb war ja meine Frage oben ob über oder unter dem üblichen
> Dump- Speicherbereich was geändert wurde/ wird! Insbesondere das
> schreiben der Math- Funktionen ins Flash mit 5.7!

Naja, wenn Du ein komplettes Backup wieder zurückspielst ist halt alles 
wieder original, also das komplette Flash. Da ist dann nix mehr oberhalb 
oder unterhalb was anders sein könnte. Das Einigen verstärkte Spikes 
aufgefallen sind glaube ich schon. Aber ich kann mir aus besagten 
Gründen nicht vorstellen, dass es einen Zusammenhang mit der BF-Firmware 
gibt. Beide Geräte die ich verwende arbeiten da genauso wie mit der 
originalen Firmware. Beide haben auch sehr unterschiedliches 
Spike-Verhalten. Aber wie Jörg schon anmerkte, ist das ja zum Glück bald 
Geschichte :-)

Gruß vom Skipper

Morgen,
ich hab jetzt das W2022A von sh0dan,von den Spikes merk ich nichts(ca. 
20°C),
aber das Oszilloskop hängt sich oft auf wenn ich Coupling oder Probe 
verstellen möchte, dann ignoriert es alle Eingaben abgesehen von den 
Drehgebern. Firmware ist  1.2.BF.6.7

MFG Henning

wo ich gerade mal dabei bin...
1kHz Rechteck, 25MSa/s 10µs, ist alles schön sauber.
Eine Stufe weiter, also 250MSa/s 5µs, sind die Spikes extrem bis 20ns.
Siehe Shots!
Jetzt stellt sich mir die Frage, was wird ab 250MSa aktiv...

EDIT: Die Screenshotsoftware kennt keinen COM10 ?

Michael D. schrieb:
> Jetzt stellt sich mir die Frage, was wird ab 250MSa aktiv...

Ich kann's grad nicht testen, aber bei meiner Hardware wird es (mit dem 
alten FPGA-Design, versteht sich) oberhalb von 250MSa ganz schlimm. 
Sogar das LCD ist dann gestört.

Die Hardware geht dann in einen Modus der alle 4 ADCs verwendet. Das ist 
wohl irgendwie anstrengender.

Wo wir gerade dabei sind: in der BF-Firmware gibt es immer noch diesen 
merkwürdig großen Sprung von 25 MSa auf 250 MSa. Das muß nicht sein, 
habe ich Hayo auch schon früher drauf hingewiesen, aber vielleicht nicht 
deutlich genug. Hayo, guck dir mal die Funktion CaptureSetTimebase() in 
osoz/platform/nios/src/capture.c an.

Die alte Hardware teilt von 1 GSa abwärts, erstmal mit Halbierungen:
/1: 1 GSa
/2: 500 MSa
/4: 250 Msa
/8: 125 MSa
/16: 62,5 MSa
Dann geht es in 8er Schritten quasi unendlich weiter:
/32: 31,25 MSa
/40: 25 MSa
/48: 20,833 MSa
/56: 17,857 Msa
... usw

Es sind also noch 2 Stufen zwischen 25 und 250 MSa. Zu den langsameren 
Teilern werden die Abstände immer feiner, ist halt reziprok. Der Teiler 
hat volle 32 Bit Auflösung, das geht also bis grotesk langsam.

Jörg

@Jörg
> Ich kann's grad nicht testen, aber bei meiner Hardware wird es (mit dem
> alten FPGA-Design, versteht sich) oberhalb von 250MSa ganz schlimm.
> Sogar das LCD ist dann gestört.
Ja, wie man sieht...
Was händelt dann das neue Design die ADC's, das diese Spikes nicht 
auftreten?

Michael D. schrieb:
> @Jörg
>> Ich kann's grad nicht testen, aber bei meiner Hardware wird es (mit dem
>> alten FPGA-Design, versteht sich) oberhalb von 250MSa ganz schlimm.
>> Sogar das LCD ist dann gestört.
> Ja, wie man sieht...
Nein, anders, bei mir ist dann ein Teil des LCD grisselig. Vermutlich 
gibt es dann Timing-Fehler beim Auslesen des Bildschirmspeichers. Das 
ist also noch ein anderes Problem. Die Spikes hingegen sind vermutlich 
Timingfehler bei der Signalverarbeitung.

> Was händelt dann das neue Design die ADC's, das diese Spikes nicht
> auftreten?

Frag' mich lieber, was das alte Design falsch macht...
Soweit wir wissen hat es keinerlei Timingchecks. Die Synthese weiß gar 
nicht wie schnell die Logik laufen wird und kann deshalb nicht prüfen, 
ob das noch paßt. Die Daten werden dort mit den vollen 250 MHz 
verarbeitet. Das ist zwar das Maximum, was die Einzelkomponenten des 
FPGAs leisten können (Speicher, Multiplizierer, Logikzellen, etc.), aber 
für eine ganze Baugruppe eines Designs viel zu schnell, das Routing und 
die Logik ist auch noch da.
(Das ist ungefähr so, wie ein Auto für 250 km/h zu bauen, weil's grad 
auf den Reifen und dem Tacho draufsteht, ohne den Konstukteuren von 
Bremsen und Fahrwerk zu erzählen was es werden soll.)

Die Sampleverarbeitung van Alex arbeitet mit dem halben Takt und 
verarbeitet pro Takt doppelt so viele Werte, parallel. Zugegeben wird 
auch viel mehr gerechnet, die Filterei gab es ja vorher gar nicht, schon 
von daher können wir nicht so schnell.
Wir fahren also halb so schnell, aber mit 2 Autos, schaffen das gleiche 
rüber.

Jörg

Luc schrieb:
> Coupling channels are labeled as [DC (ext)] and [AC (ext)], I can not
> find GND (yes, I know someone wanted it to be deleted because it is
> really just a dummy fiction, but it seemed to me that in the end it was
> decided to keep it).
> However, what means (ext)?

ext -> External Trigger

This are the settings for the external trigger. Therefore you won't find 
a GND coupling. The coupling for the channels You will find in the 
channel menu of each channel.

> When the waveforms' amplitude exceeds some limit the upper and bottom
> become flat.
Seems that there is something wrong with the gain or with the resistors 
in your mod. Could you provide us with a screenshot?

Kind regards

Hayo

kingcopper schrieb:
> Bis kurz vor BF.5.2 (5.1C?) ist ein Update noch möglich. Bei den darauf
> folgenden Versionen wurde anscheinend ein schnellerer Loader eingeführt,
> was möglicherweise den Fehler verursacht.

Hi, etwas späte Antwort - ab 5.2 (glaube ich) wurde der Loader mit 
komprimiertem Coding eingeführt (UCL). Vermutlich ist das der Grund.

Gruß Hayo

Hi Sandro,

thanks for reporting. I will check this and try to fix it as soon as 
possible.

Greetings and a happy new year to all
from Valle de Aosta in bella Italia

Hayo

moinmoin Hayo & Co.,

ziemlich ruhig hier ;)
habe eben versucht im single mode signale 'einzufangen',
leider wird bei einer TB groesser 5µS in der Ver 6.7
nix mehr dargestellt ;(,
habe mich bis zur 6.3 zureckgeschafft, da scheint es noch
zu funktionieren, koenntest du bitte mal nachsehen und uns
ein update hochladen, vielen Dank!

vlG
Charly

ps. wenn 'Single' auf warten steht (rot) und an der TB
gedreht wird sollte die Signale auf dem Schirm
geloescht werden

Hallo Charly, ich habe Deine Email bekommen, antworte aber trotzdem mal 
hier im Forum. Zur Zeit bin ich mal wieder im Ski-Urlaub :-). Daher auch 
eine etwas verzögerte Reaktion.

Die Probleme mit dem Singletrigger waren mir kürzlich auch schon 
aufgefallen.Da sich bisher noch keiner darüber beschwert hat war ich mir 
nicht ganz sicher ob ich bei mir was falsch eingestellt hatte. Bisher 
bin ich noch nicht dazu gekommen der Sache auf den Grund zu gehen, aber 
ich werde mich mal dransetzen sobald ich wieder zuhause bin.

Gruß Hayo

Moinmoin Hayo,

wollte nur mal kurz 'nachtriggern' ob es schon was neues gibt :)

vG
Charly

Moin,

die Sache ist nicht vergessen. Der Messplatz ist bereits aufgebaut, aber 
ich bin zur Zeit etwas eingespannt und komme daher nicht so richtig dazu 
mich dran zu setzen. Soll aber auf jeden Fall in Kürze weiter gehen.

Gruß Hayo

moinmoin,

super Hayo, dann handelt es sich ja nur noch um nS bis es losgeht ;)

wenn du soweit bist schreib mir event. eine PN, i haette noch
ein paar 'unschoenheiten' die event. mit ein paar Zeilen auch
zu beseitigen sind

vlG
Charly

Dem Charly geht's mal wieder nicht schnell genug :-)))
Eigentlich könntest du uns deine erwähnten "Unschönheiten" mitteilen, 
oder?

Gruß Michael

jojo, so ist das........

ich habe das Oszilloguck sehr oft im einsatz daher ist es
manchmal schon a bissel stoerend wenns nicht so will wie
ich mir das vorstelle....
mit den 'unschoenheiten' will ich jetzt noch keinen verrueckt
machen da ich ein Downgrate auf die 6.3 gemacht habe und event.
die meisten davon schon beseitigt sind, ist also nix geheimes,
wenns hier interessiert kann ich es natuerlich auch hier posten

vlG
Charly

Hi Charly,

bin gerade vom Griechen zurück. Poste das mal ruhig hier, dann kann man 
auch drüber diskutieren in wieweit man da Änderungen einfließen lassen 
sollte.

Muss mich auch erst mal wieder in die ganze Sache reinwursteln da ich 
mich in letzter Zeit mehr mit Langwellen, Mittelwellen und 
Kurzwellenempfang beschäftigt habe. Als krassen Gegensatz zu unserem 
SMD-gespickten DSO habe ich über Winter einen alten U-Bootempfänger aus 
dem 2. Weltkrieg renoviert - da bekommt man schon ein anderes Gefühl für 
die Dimensionen von Bauteilen und Betriebsspannnungen (300V!!!). Wenn 
man bedenkt, dass diese Technik mit den Röhren und Bauteilen in 
Kartoffelgröße damals aktueller Stand der Technik war... Immerhin kann 
ich da noch alles ohne Brille erkennen :-)

Gruß Hayo

moinmoin Hayo,

beim Griechen haett i dir helfen koennen ;)

bei dem U-Boot RX haett i auch gerne mitgemacht, ist immer interessant
wie die Jungs damals gebaut haben, i hab hier auch 'grobtechnik' mit
der 3-500Z, GS31 / GS35 u. 4CX1500 in der Pipeline, komme aber im
moment nicht dazu ;(

hier so ein paar Punkte dir mir einfallen:

1.
die Einstellung f. den Tastkopf wird nicht dauerhaft
gespeichert (z.B. 10:1)

2.
wenn ein Signal zb. mit 5V anliegt das kurze impulse nach
0V hat und man dreht an der TB,, schaltet mal in den Single
& wieder zurueck, usw dann triggert er nicht mehr, man muss
die Probe abklemmen und wieder drann dann laufts als waehre
nix gewesen

3.
ruft man Speicher auf, und ueberlappt signal mit memory dann
vergisst er irgendwann die einstellung f. Y und schaltet dort
auf 2V/Div. (meine ich mich zu errinern)

vielleicht bin i auch zu verwoeht, hatte durch meinen vorherigen
job ein 'grosses' Agilent da, das ist jetzt leider weg  ;((

ps. bitte denk daran dass i mit der 6.3 arbeite weil in spaetern
versionen der Single nicht mehr wollte

vlG
Charly

Moin Hayo,
über deine Ausdrucksweise könnte ich mich immer 
wegschmeißen..."Kartoffelgröße" :-)))

Hast du deine Restauration dokumentiert? Ich finde sowas immer 
hochinteressant und es wäre bestimmt einen eigenen Thread wert!

Es ist schon sehr lange her, das bei Entrümpelungen die Röhrengeräte auf 
der Straße standen. Die habe ich mir immer geschnappt, Röhren ausgebaut 
und gesammelt(als Ersatz für defekte Geräte).
Heute würde ich dafür bestimmt gutes Geld bekommen, leider hatte die 
Verwandschaft alles entsorgt...

Gruß Michael

Oh!

Hätte ich gar nicht gedacht, dass hier auch an sowas Interesse besteht. 
Ist natürlich alles dokumentiert. Ich mache gerne einen Thread dafür 
auf. Das Gerät steht übrigens auch im Horchraum des U995 in Laboe - ich 
poste den Link im neuen Thread.


Hayo

So, wie versprochen hier der Link zum neuen Thread über Röhrenradios - 
bevor es hier zu offtopic wird :-)


Beitrag "Restaurierung alter Röhrenempfänger - Telefunken Ela1012a/b"


Hayo

Hallo Leute,

heute habe ich mich nach der Arbeit mal durchgerungen und mich um die 
Firmware gekümmert. Das Triggerproblem ist nun gefixt.

Bei den anderen gemeldeten Problemen konnte ich das nicht so recht 
nachstellen.

- Die Probeeinstellungen werden bei mir einwandfrei gespeichert.
- die Triggeraussetzer nach drehen der TB und Singleshot habe ich nicht 
hinbekommen -> vielleicht noch mal prüfen und dann genauer beschreiben 
wie man das nachstellen kann
- die Einstellungen beim Overlay haben bei mir problemlos funktioniert
- Im Ultra Slow-TB Modus gab es (leider) auch keine Auffälligkeiten


Das Ganze getestet mit der aktuellen 6.8. Falls da doch noch Bugs sein 
sollten bitte mit genauer Anleitung wie ich das nachstellen kann.

Gruß

Hayo

Danke Hayo!

Danke Hayo!!!

wie beschrieben waren die Fehler bei mir mit der 6.3,
i bekomme verm. am Fr. die neue Platine und dann bin
ich wieder 'verstaerkt' in der HW u.SW  entwicklung
und da 'qualmt' das oszi wieder ;)

vlG
Charly

Hi Jürgen,

die Probleme beim Pulsweitentrigger die Du beschreibst sind mir bekannt. 
Leider kann ich da firmwareseitig nicht viel machen, da das Hauptproblem 
eine lausige Implementierung der Triggerfunktion im FPGA ist.

Gruß Hayo

Aahh, danke Lukas.

Damit kann ich gezielt auf Fehlersuche gehen.

Gruß Hayo

Hi Juergen,

koenntest du bitte auch ein .flash hochladen, Danke!

vlG
Charly

Hallo Jürgen,

ich bin leider noch nicht dazu gekommen Deine Triggermodifikation zu 
testen. Aber vielleicht könntest Du mir sagen was Du genau verändert 
hast, dann kann ich das gezielter testen und evtl. in das nächste 
Release einbauen.

Gruß Hayo

danke, werde uebers WE mal testen

vlG
Charly

Hallo Jürgen,

bin gerade am Testen, kann zum Triggerverhalten aber noch nichts näheres 
sagen, zumindest ist es nicht schlechter geworden ;)

Eine Macke hat sich allerdings eingeschlichen: Die Einstellung für 
PreTrigger wird nicht gespeichert; nach Aus-/Einschalten triggert das 
Welec immer auf den linken Bildschirmrand.

Grüße,
Ulrich

auch kurze Rueckmeldung v. mir: war am WE auf einer anderen
Baustelle, hoffe jetzt auf das verlaengerte WE

vlG
Charly

Hallo werte Gemeinde,

ich stecke zur Zeit in baulichen Maßnahmen am Haus (Carport) und komme 
daher nur dazu den Thread kurz zu lesen. Sobald ich wieder etwas mehr 
Zeit habe bin ich wieder am Ball.

Gruß Hayo

Tom schrieb:
> Ich verwende einen Digitus Serial USB Converter (FTDI) mit Win8 x64.

Sicher daran.


Was ist an

> Please fix the connection issue and retry!

so rätselhaft? ;-)

Gruß, Guido

Hallo Tom,

Guido hat recht, das sieht ganz nach der seriellen Schnittstelle aus. 
Das Beste was Du machen kannst ist, Dir einen alten Rechner mit echter 
serieller Schnittstelle zu suchen (Freunde, Bekannte) und damit das 
Update zu machen. Ich benutze auch einen USB zu seriell Wandler, aber es 
funktionieren halt nicht alle. Da hatten wir schon öfter entsprechende 
Rückmeldungen.

Bei dieser Diagnose gehe ich mal davon aus, dass Du die Initialisierung 
des Updatevorgangs mit den beiden Funktionstasten F1/F2 am DSO korrekt 
gemacht hast.

Gruß Hayo

Moin Tom,
wenn du ganz sicher gehen möchtest, kannst du ja mal das 
Screenshot-Programm starten, da bekommst du auch noch mal eine 
Bestätigung auf den Schirm, bzw. Dos-Fenster.
Nicht vergessen die korrekten Parameter (COM1-9, Baudrate...) in die 
Batch einzutragen.
Desweiteren kommt es auch vor, das wenn du einen anderen USB-Port 
verwendest, das dieser eine andere COM-Port Nummer zugewiesen bekommt!
Mal im Gerätemanager nachschauen, welche Zuweisung dein COM-Port von 
Windows gewählt hat.
Auch dort, müssen die Parameter passen!

Gruß Michael

Oh, das hatte ich noch gar nicht bemerkt. Grundsätzlich kann ich 
empfehlen die letzte Firmwareversion (1.2BF6.8) herunter zu laden und 
aufzuspielen.

Es ist Einiges an Dokumentation darin enthalten und mit dieser 
Firmwareversion kann man das DSO schon ganz gut benutzen. Ich bin zur 
Zeit dabei mich mit Langwellen/Mittelwellen/Kurzwellenempfang zu 
beschäftigen. Schwingkreise, Antennen, Vorverstärker etc. - dafür kann 
man das Oszi eigentlich sehr gut gebrauchen.

Gruß Hayo

Hello everyone!
Is it possible doing something like this with the witting DSO and using 
a pc based signal generator software?
http://www.youtube.com/watch?v=uMH2hGvqhlE

If so, can someone get in the details of how this is done? Using FFT 
function and hod function?

Hallo Andreas,

sowas in der Art ist mir auch damals durch den Kopf gegangen, deshalb 
gibt es die Möglichkeit mit einem doppelten Druck auf den Quick Print 
Button den Screenshot anzustoßen ohne dass die Funktionsbuttons 
wechseln. Diese Funktion ist ebenso wie die meisten Zusatzfunktionen in 
der Datei "Special Functions" beschrieben :-)

Viel Spaß noch mit Deinem DSO

Ja es kommt noch was. Und zwar zum Beitrag von Alessandro:

> Is it possible doing something like this with the witting DSO ...

Yes indeed it is! A very interesting link you posted there. To explain 
it I used the following measuring configuration:

- object to be measured is a MW loop antenna like it had been used in 
the 1930s to 1940s. It is a resonant circuit with resonance between 500 
KHz and 2MHz which can be adjusted with a variable capacitor.

- function generator HP3325A. Every signal generator with sweep function 
can be used - but there must be a special sync output. We don't need the 
signal sync output but the sweep sync out. That means, we need to know 
when the sweep starts and when the sweep stops.

- the DSO is a W2022A and as reference an Owon SDS8102

What we have to do is to connect the sweep sync to channel 2 as trigger 
signal. Set the timebase so that you can see one or a half period of the 
sync signal. The effect is that we can see the complete sweep range on 
our screen.

Now we connect the normal signal output via T-piece adapter to channel 1 
and the end of the wire terminated with 50 Ohm to the antenna.

The sweep generator starts at 10 KHz and stops at 2MHz in continuous run 
mode. The starting edge of the trigger signal (our sweep sync) has to be 
on the left screen side. Now we can see the frequency response of our 
system with 10KHz on the left screen side and 2MHz on the right screen 
side. The quality of the plot on the W2022A is a little bit worse than 
the plot on the SDS8102. That may be caused by some speed optimizations 
in the
graphic routine. Switching the display into persistent mode leads to a 
better result.

I hope the explanation was helpful - otherwise don't hesitate to ask!

Hayo

Hi Sandro,

the sweep sync out is on the backside and is called 'Marker' 
(frequency). You have to set the marker frequency with the button 'MKR 
FREQ' on a value between sweep start frequency and sweep stop frequency.

Hi Jürgen,

ich bin noch nicht zum Testen gekommen, aber ich werde insbesondere 
Deine Zeile am Ende von SetupTrigger mal genauer auf ihre Wirkung 
testen. Vielleicht bringt es ja was, dann mach ich eine neue Version 
fertig.

> Mit welcher Variablen oder Funktion kann man denn den Schwingungszug auf
> dem Schirm relativ zum Triggermarker verschieben??

Das ist die Funktion UserIF::ON_MemoryPosition(void) (hier werden die 
Interruptwerte des Drehgebers ausgewertet) wobei die Funktion 
Display::RecalcTimeParameters() innerhalb dieser Funktion eine wichtige 
Rolle spielt.



Gruß Hayo

Hallo Jürgen,

ich habe auch schon etwas mit der Konzentration zu kämpfen (könnte am 
Wein liegen) aber ich konnte mir nicht verkneifen schon mal vorab mit 
der unveränderten 6.8 ein paar Tests zu machen. Ich konnte hierbei nur 
eine Konstellation beim Pulsweitentrigger ausmachen, die zum Stillstand 
führt. Und zwar ist das im Modus Pulsweite zwischen Wert 1 und 2. Wenn 
Wert 1 (also der untere Wert) im Normaltrigger-Modus unterschritten 
wird, dann bleibt die Kiste stehen. Da hilft auch kein Ändern des 
Signals am Generator oder Ändern des unteren Grenzwertes. Wenn man 
allerdings die Timebase einmal vor und wieder zurück dreht, dann läuft 
es wieder. D.h. beim Ändern der TB wird ja ein StartRecord() abgesetzt. 
Also könnte es durchaus sein, dass Deine Änderung hier hilfreich ist.

Guats Nächtle

Hayo

Ok, nach langer Zeit mal wieder eine neue Version! Angeregt durch Jürgen 
habe ich mich noch mal auf den Pulsweitentrigger gestürzt.

Das Ergebnis ist ganz erfreulich. Im "Normal" Modus arbeitet der 
PW-Trigger jetzt in allen drei Bereichen (>, <, ><) ohne stehen zu 
bleiben.

Zusätzlich habe ich noch einen Bug im Single Trigger des Peak Detect 
beseitigt.


@Jürgen

Ich habe die meisten Deiner Änderungen übernommen weil sie mir 
inhaltlich korrekt erschienen. Das hat aber nicht viel gebracht. Nur die 
letzte Zeile in SetupTrigger() hat dafür gesorgt, dass beim 
Unterschreiten des unteren Schwellwertes die Acquisition weiter ging 
wenn man den Wert am DSO nachgeregelt hat. Wenn jedoch stattdessen das 
Signal am Funktionsgenerator geändert wurde, blieb das Gerät trotzdem 
"eingefroren".

Hierfür (oder vielmehr dagegen) habe ich jetzt im ADC-Handler einen 
kleinen Workaround eingebaut, der dafür sorgt, dass es beim 
Pulsweitentrigger keinen "Freeze" mehr gibt.

Gruß Hayo

p.s. ach ja, was dadurch jetzt natürlich auch geht, dass ist der Single 
PW-Trigger. D.h. wenn man den Single Trigger setzt solange die 
Pulsweiten unter dem unteren oder über dem oberen Schwellwert liegen, 
passiert nichts. Erst wenn ein Puls kommt, der von der Weite im 
richtigen Bereich liegt wird ein Event ausgelöst.

Hallo allerseits,

zur Zeit bin ich dabei meine Kurzwellenantennen via Bode Plott zu 
vermessen. Dabei sind mir einige Fehler in der aktuellen Firmware 
aufgefallen. Da musste ich natürlich gleich eine neue Version bauen.

Gruß Hayo

Freut mich zu hören.

Ich bin auch schon an der nächsten Version dran. Diesmal mit neuem 
Feature und einigen Umbauten unter der Haube. Ihr merkt schon, ich habe 
gerade einen Lauf...

Gruß Hayo

Johann Wackener schrieb:
> Kannst Du mal bitte kurz sagen:
> 1. Welche Hardware-Modifikationen sind nötig (um das DSO mit einigem
> Anstand verwenden zu können)?

Da gibt es viele Verbesserungen. Weiter oben hat ein freundlicher 
Threadleser diesen Archivlink zur Verfügung gestellt:

http://web.archive.org/web/20130326014650/http://sourceforge.net/apps/trac/welecw2000a/wiki/HardwareImprovement

Die wichtigste Doku ist in SFN zu finden:

http://sourceforge.net/projects/welecw2000a/files/Hardware/Modifications/

Aber in Kürze:

- anständige Belüftung durch diverse Änderungen am Lüfter. Hierzu gibt 
es von mir die Doku "Optimizing Thermal Design" in drei Ausbaustufen.

- der externe Triggereingang kann etwas Überarbeitung gebrauchen. Hier 
gibt es einen Optimierungsvorschlag den Jörg mal gemacht hat und den ich 
dann mit einigen Bildern dokumentiert habe

- die analoge Eingangsstufe hat im originalen Zustand mit einigen 
Unzulänglichkeiten zu kämpfen. Da wäre der nichtlineare Amplitudengang, 
der schlecht gewählte Aussteuerbereich der zu starkem Rauschen führt, 
schlechter kapazitiver Abgleich von Werk aus (Trimmer unter der 
Abschirmung), einige ungünstige Bauteildimensionierungen.

Optimierungen gibt es da einige. Ein Ansatz geht soweit, eine komplette 
Platine mit eigener Eingangsstufe für jeden Kanal einzubauen. Der Aufbau 
der Platine und der Einbau ins Gerät ist nicht ganz einfach. Die 
firmwareseitige Unterstützung steckt auch in den Kinderschuhen da nur 
einige Wenige den Umbau gemacht haben. Deutlich einfacher und günstiger 
sind die Low Budget Mod und die OPA653 Mod, die in letzter Zeit einige 
erfolgreich ausprobiert haben.

Löten an SMD-Bauteilen solltest Du auf jeden Fall können.

Noch ein Hinweis zu der Bestückung der originalen Eingangsschaltung: Der 
Eingangsverstärker OPA656 ist maßgeblich für Frequenzgang und Bandbreite 
des DSO verantwortlich. Der Unterschied zwischen den 200MHz Versionen 
und den 100MHz Versionen besteht darin, dass in den 100MHz Versionen ein 
Fake verbaut wird welches deutlich geringere Bandbreite hat! Zu erkennen 
an einem grünen Lackpunkt auf dem Gehäuse. Es besteht weiterhin der 
Verdacht, dass in späteren 200MHz Geräten ebenfalls diese Bauteile 
verwendet wurden um Geld zu sparen bzw. mehr Geld nehmen zu können als 
für die 100MHz Geräte. Die wenigsten Besitzer solcher Geräte bemerken 
das.

> 2. Wo sind die jeweils aktuellen Firmware-Sourcen zu finden
Ich veröffentliche die hier. Du findest sie auch auf SFN. Es gab auch 
ein svn mit allen aktuellen Entwicklungszweigen. Durch die 
SFN-Umstellung ist das etwas in der Versenkung verschwunden. Ich weiß 
jetzt nicht ob Jörg das evtl. schon wieder aktualisiert hat.

Ziel ist es jedenfalls irgendwann diese NIOS 1 Firmware abzulösen durch 
eine Firmware die auf dem von Jörg selbst entworfenen NIOS 2 Core 
aufsetzt.
Das kann aber noch etwas dauern, daher gibt es zwischendurch immer noch 
Erweiterungen an der aktuellen Firmware.

Gruß Hayo

Wie angekündigt hier die neue Version mit neuer Display-Funktion. Bei 
anderen DSOs habe ich gesehen, dass diese bei der persistenten 
Display-Funktion die Möglichkeit bieten einstellbar das nicht mehr 
gültige Signal auszublenden.

Unser W20xxA konnte bisher nur Persistenz an/aus. Das konnte ich 
natürlich so nicht stehen lassen!

Die neue Firmware kann jetzt Lebenszyklen (Lifecycles) von 
5s/10s/25s/50s und Unendlich darstellen. Am besten kann man das testen 
wenn man die Fade Out Time auf 5s einstellt und dann das Testsignal in 
Amplitude oder Frequenz verstellt (siehe Bild).

Der kleinere Bug im Triggermenü ist auch behoben - danke für den 
Hinweis.

Viel Spaß

Hayo

Hi Sandro,

I checked it but I can't find the problem. All seems to work correct. 
Please describe in detail under which conditions and parameters the 
problem occured.

Hayo

Johann Wackener schrieb:
> Kannst Du mal bitte kurz sagen:
> 1. Welche Hardware-Modifikationen sind nötig (um das DSO mit einigem
> Anstand verwenden zu können)?

Da fällt mir noch ein, es gibt einen Umbau für den Akkubetrieb von 
Markus, den sollte man auf jeden Fall auch erwähnen. Ist zwar nicht 
nötig, aber unter gewissen Bedingungen hilfreich:

Beitrag "Wittig(welec) DSO W20xxA Umbau Akku-Betrieb"


Ach und was unter die gleiche Kategorie fällt mir aber entfallen ist, 
weil das für mich an meinen Geräten so selbstverständlich ist - die 
Trigger LEDs:

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

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

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

-> möchte ich nicht mehr missen!

Gruß Hayo

I tried hard, but the problem does not occure on my DSOs. I have the 
suspicion that the "Auto" trigger might be the guilty one. Can you try 
it once more with the "Normal" trigger?

@all

Has anyone else the same problem?

Hat noch jemand Probleme beim Speichern und Wiederholen der Signale aus 
dem Speicher?

Hayo

keinGast schrieb:
> I can confirm, that the trigger mode, if set to combi, is somehow set to
> normal.

Yes I know the bug. It is solved in the next version.


> I don't know how save/recall should work

- go to Save/Recall
- choose a memory place
- push "Save Trace" -> signal will be stored into flash
- switch off the signal input
- push "Recall Trace" -> signal should be displayed as before
- or push "Overlay Trace" -> old signal and actual signal will be 
displayed

Hayo

Ok hier die neue Version mit einigen Verbesserungen, Bugfixes und einer 
neuen versteckten Funktion zum Umlabeln der Modelversion. Details stehen 
in der Datei Special Functions.txt

Hayo

keinGast schrieb:
> Ist das ein Architekturproblem?

Nicht direkt! Es handelt sich vielmehr um konkurierende Interrupts. Der 
Timer-Interrupt des Popup Timeouts (schönes Denglisch) konkuriert hier 
mit dem Interrupt des Rotary Interface (Drehgeber-Interrupt). Letzterer 
unterbricht die Bildausgabe und damit auch die Möglichkeit das Popup zu 
schließen, obwohl der Timeout schon längst zugeschlagen hat. Damit kann 
man aber wohl ganz gut leben denke ich. Wenn wesentlich mehr 
Rechenleistung zur Verfügung stünde könnte man das sicherlich auch 
geschmeidiger lösen. Für 12MHz aber wohl ganz akzeptabel.

Gruß Hayo

Hi Andiiiy,

hab schon gesehen, dass Email von SFN im Postfach war wegen des Checkin. 
Ich wusste gar nicht mehr, dass da noch ein Repository eingerichtet ist. 
Muss ich mir mal wieder alles richtig einstellen. Bin jetzt aber erst 
mal weg ....muss in Griechenland segeln :-)

Hayo

unser Hayo iss schon ein armer Tropf, wir werden dich bedauern
wenn du in Griechenlan in der Sonne schmorst und unsern schoenen
Regen hier verpasst :p


vlG
Charly

김사백 schrieb:
> Why can't be some changes set back?

If your DSO is a W2012A or a W2014A and you change the Label to LB-Mod 
your DSO will become a W2022A or a W2024A. There is no possibility for 
the firmware to see if the DSO is really a W2022/W2024 because the 
hardware is the same (only the OPA656 is different). So it can't be set 
back to W2012/W2014 in the moment (only mnually with a separate function 
I could write).

All this is only for display and has no influence to the function.

Greetings from the Ionian Sea

Hayo

Ab der BF.5.8XE bis zur aktuellen BF.7.1
(ab hier wird übrigens auch die trigonometric Tabelle ins Flash 
geschrieben), wird der Sinus, bei drücken der Test-Signaltaste, nicht 
mehr korrekt dargestellt!
Ich habe mir mal die Mühe gemacht, ab welcher Firmware-Version das der 
Fall ist.
Angefangen hatte ich bei BF.5.6, da war noch alles ok.

Jetzt ist die Tabelle mit der 5.8XE fertig geschrieben, komischer Weise 
wird nun auf dem 2.Kanal kein Testsignal ausgegeben, hmm...

Ok, nach dem aus u. wieder Einschalten, wird der Sinus auf Kanal2 
angezeigt, allerdings, (wie oben schon beschrieben)auch mit einer viel 
zu kleinen Amplitude.
Ich wollte das nur mal so erwähnen ;-)
Ein Pic anbei.

Achso...wem beim schreiben der trigonometric Tabelle ins Flash, ein 
Fehler passiert ist, braucht nur auf die BF.5.7 downgraden, dann wird ab 
der BF5.8XE diese wieder neu geschrieben(ich habe es ja gerade getestet)

Gruß Michael

Hmm, schau ich mir mal an wenn ich zurück bin. Für das Schreiben der 
Trigo-Tabellen könnte ich auch noch eine Hidden Function einbauen, dann 
kann man das jederzeit refreshen.

Hayo

Welecverbastler schrieb:
> Mir ist aufgefallen, dass die Triggerschwelle nicht mit skaliert, wenn
> man die vertikale Auflösung V/div umschaltet.

Ja, das ist aber kein Fehler, sondern so gewollt. Hintergrund ist der 
Umstand, dass der Trigger auch nur im Anzeigebereich des Grids arbeitet. 
Größere Triggerlevel sind unwirksam (Signal und Triggerlevel liegen dann 
außerhalb des ADC-Aussteuerbereichs). Daher ist es in diesem Fall 
praktikabler den Level am Grid zu orientieren, d.h. den Level in 
Relation zum Grid konstant zu halten. So hält man den Trigger immer im 
Aussteuerbereich. Ziel bei der Wahl des Spannungsbereiches ist es ja im 
Normalfall, das Signal im Gridbereich komplett darzustellen.

> Kann das Firmware-Projekt (also das von Hayo massgeblich betreute)
> vielleicht nach Github umziehen?

Das müsste man sich mal ansehen. Grundsätzlich spricht nichts dagegen. 
SFN gefällt mir auch nicht so besonders.



김사백 schrieb:
> what
> the test signal meaning is?
> What does it do?

It is a software generated signal which is loaded into the signal buffer 
instead of the ADC value register. It can be used to test some of the 
firmeware functions like "Quick Measure", "Noise Filter", "Math" etc. . 
It does not work with functions which are operating on hardware layer 
level (driver level) like "Average". It is only a simple signal 
simulating routine. I'm thinking about improving it...

Hayo

Hi, bin gerade erst zurück und hatte einige Ideen. Zum Einen habe ich 
das Rotary Interface nochmals genauer unter die Lupe genommen. Leider 
ist es die Hardware- (FPGA) Implementierung die hier für das schlechte 
Ansprechverhalten verantwortlich ist (etliche Impulse werden einfach 
verschluckt).

Um das Ganze erträglicher zu machen habe ich für die 
Zerolevel-Verstellung den Code nochmals überarbeitet. Der Zerolevel 
lässt sich jetzt etwas flüssiger verstellen und springt nicht mehr ganz 
so heftig. Wichtig ist, dass man nicht allzu schnell am Drehgeber 
kurbelt, da dann das Interface die Impulse schlichtweg verschluckt 
(quasi ein Null Device).

Weiterhin habe ich den Ansatz mit dem skalierenden Triggerlevel von 
Welecverbastler aufgegriffen und eine mögliche Umsetzung eingebaut.

Beides betrifft nur Kanal 1, dadurch kann man direkt mit Kanal 2 
vergleichen, der komplett unverändert arbeitet.

Ich bitte um Rückmeldung ob die beiden Änderungen eine Verbesserung 
sind.


Short version in english:

Please test the new implemented scaling triggerlevel and the new rotary 
handler for zerolevel adjustment. both available only on channel 1 to be 
able to compare with the originally working channel 2.

Hayo