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

[christopher (Gast)]

Hallo Jungs!

Ich habe ein 2 Kanal Welec - ohne irgendwelche Hardware-Modifikationen.
Kann ich die aktuelle Firmware auch ohne irgendwelche Huckepackplatinen 
benutzen?

Hab das mal ein wenig überflogen - ihr macht ja spitzen Arbeit!

Bin eher etwas "Einsteigermäßiger" unterwegs und würde es mich nicht 
trauen in dem Oszi herumzulöten. Bietet jemand von euch profis auch - 
natürlich bezahlte - umbauten an?

Allerbeste Grüße

Christopher

[branadic (Gast)]

@ Christopher,

ja, du kannst die neuste Firmware auch mit einem unmodifizierten Welec 
nutzen.
Ein Umbau wird erwartungsgemäß wohl niemand für dich durchführen, nicht 
weil alle egoistisch sind, sondern vielmehr weil du die notwendige Zeit 
dafür nicht bezahlen könntest. Die Bestückung der Huckepackplatine, der 
Ausbau der obsoleten Bauteile und die Umrüstung samt Einbau der 
Huckepackplatine kosten wirklich gut Zeit.
Am Feedback allein siehst du ja, wie wenig Leute sich die Umrüstung 
schon angetan haben obwohl sie sich mit Material eingedeckt haben. 
Entsprechend wenig Erfahrung liegt hier in Verbreitung vor. Leider, muss 
ich zum Bedauern feststellen. Umgerüstete Geräte wirst du zur Zeit nur 
in der Entwicklergruppe (Skype) finden.

branadic

[Sandro (Gast)]

@ Hayo
What compiler do you use for Welec firmware update?
I have only an editor and looking for a free compiler to do small FW 
mods

Regards,
Sandro

[branadic (Gast)]

Ganz vergessen zu erwähnen, Offset-Verschiebung und der dazugehörige 
Marker passen jetzt natürlich auch nicht mehr zusammen. Vielleicht 
findest du ja die Zeit dein 2-Kanal-Welec mal umzurüsten Hayo? Wenn die 
Unterstützung mal bis zum Ende implementiert wäre würden sicherlich auch 
mehr Leute ihr Welec umrüsten.

branadic

[Blue F. (blueflash)]

@Sandro

How to get and how to use the SDK (devopment kit) is described in the 
documents which You will find in the "doc" directory of my 
"distrubution".



@Branadic

Ja die Umrüstung wollte ich demnächst mal in Angriff nehmen, aber die 
Probleme mit Kanal 3+4 kann ich dann trotzdem nicht sehen.

Hatte übrigens vorhin ein nettes Treffen mit Jörg und wir haben einige 
Ideen für die weitere Entwicklung ausgetauscht. Könnte noch ganz 
interessant werden, zumal Jörg über einige berufliche Erfahrung verfügt 
die uns da recht nützlich sein könnte.

Gruß Hayo

[Jörg H. (idc-dragon)]

Hayo W. schrieb:
> Hatte übrigens vorhin ein nettes Treffen mit Jörg und wir haben einige
>
> Ideen für die weitere Entwicklung ausgetauscht.

Ganz meinerseits!

Wir haben Pläne geschmiedet für einen Software-Neuanfang, der auch 
andere Plattformen (Leon und ganz vage Owon) ermöglichen soll. Dafür zu 
gegebener Zeit ein neuer Tread, bzw. zum Mitmachen einen 
Architekturentwurf im Sourceforge-Wiki.

Vielleicht gewinnen wir ja auch neue Entwickler damit, macht hoffentlich 
mehr Spaß als der alte Code.

Jörg

[Blue F. (blueflash)]

Da das ein etwas langfristigeres Projekt ist, wird die bisherige 
Firmware  natürlich solange parallel weiterentwickelt bis die Neue 
einsatzbereit ist, es wird also auch erst mal weiterhin Updates auf 
Basis der 1.2.BF.x.x geben.

Erstes Ziel der neuen Entwicklungslinie ist erstmal der Hardwarelayer 
und als Grundlage dafür die genauere Untersuchung bzw. Dokumentation der 
NIOS-Hardwareansteuerung.

Ich denke es wird interessant...

Hayo

[Omega G. (omega)]

Nachdem ich die Opensource Firmware bisher nur genutzt habe, habe ich 
jetzt selbst etwas umgebaut bzw. hinzugefügt.

Ich habe in meinem Oszi schon länger einen Li Akku eingebaut, allerdings 
ohne irgendwie die Spannung, Strom oder Kapazität zu überwachen. Diesen 
Umbau habe ich jetzt erweitert: Als Schutz- und Überwachungselektronik 
habe ich die Standardkombination aus Notebookakkus bestehend aus MM1414 
(als Kurzschlussschutz, Über- und Unterspannungsüberwachung) und BQ2060, 
zum messen von Gesamtspannung, Lade-/Entladestrom, Berechnung von 
Kapazität etc.

Abgerufen werden die interessanten Daten vom BQ2060 (momentan nur 
Ladezustand) über einen extra Mikrocontroller und per UART an das Oszi 
übertragen. Da zeige ich diesen Wert jetzt einfach nur noch an. Momentan 
auf UI_Plane3 am Rand des Gitternetzes. Am liebsten würde ich diesen 
Wert aber neben die aktuelle Abtastrate schreiben, aber auf welches 
Plane muss ich dann schreiben?

[Blue F. (blueflash)]

Du kannst Textausgaben in die - Text_Plane - schreiben. Die wird dann je 
nach eingestelltem Layout auf die richtige UI_Plane umgebogen.

Das gilt für die üblichen Ausgabebereiche über und unter dem Grid bzw. 
bei FFT auch neben dem Grid.

Allerdings ist da neben der Abtastrate eigentlich kein Platz mehr. Du 
kommst dann mit anderen Textausgaben ins Gehege.

Gruß Hayo

[Omega G. (omega)]

Hallo,

ich habe nur ein Zweikanal Gerät, also hab ich da etwas Platz.

Danke für die Hilfe, ich hätte nie die richtige Plane gefunden!

Im Foto liegen Kanal 1 und 2 genau übereinander, deshalb sieht man nur 
eine Linie.

[Blue F. (blueflash)]

Nett gemacht :-)

helfe jederzeit gerne.

Gruß Hayo

[Michael H. (stronzo83)]

Hallo mal wieder,
gerade habe ich etwas mit einem STM32F407 gespielt und dabei mal die 
neue "Logic" Funktion des Welec ausprobiert. Leider wurde das 6MHz 
Rechteck dabei zu einer Nulllinie, unabhängig vom gewählten Logikpegel. 
Kann man da irgendwas fehlbedienen oder klappt es bei schnellen 
Digitalsignalen nicht?
Ich war auch etwas verwundert, kein 3.3V CMOS in der Liste zu sehen.

Da ich die Funktion eine gute Idee für das Basteln an Digitalschaltungen 
finde, würde es mich freuen, wenn andere ihre Erfahrungen damit posten 
könnten.

Viele Grüße
Michael

[Blue F. (blueflash)]

Hi,

ich muß zugeben, dass diese Funktionen bislang nur rudimentär getestet 
sind. Ich gelobe aber Besserung. Vor Weihnachten schaffe ich das nicht 
mehr, aber im neuen Jahr sollte das hinhauen.

Gruß Hayo

[Jörg H. (idc-dragon)]

Ich habe einen neuen Thread zu der werdenden neuen Firmware aufgemacht, 
hier der Link:
Beitrag "made from scratch Firmware für Wittig/Welec Oszilloskop W20xxA"

(Bisher war ich damit noch sozusagen im "stealth mode", außer gegenüber 
Hayo und dem Skype-Chat.)


Jörg

[Blue F. (blueflash)]

Michael H. schrieb:

> Hallo mal wieder,
> gerade habe ich etwas mit einem STM32F407 gespielt und dabei mal die
> neue "Logic" Funktion des Welec ausprobiert. Leider wurde das 6MHz
> Rechteck dabei zu einer Nulllinie, unabhängig vom gewählten Logikpegel.

So ich hab doch noch mal zwischen Arbeit und Klamottenpacken getestet. 
Ich konnte da keine Auffälligkeiten feststellen. Als Beispiel mal 
Screenshots zur TTL und LVTTL-Familie.

> Ich war auch etwas verwundert, kein 3.3V CMOS in der Liste zu sehen.
Die Pegel sind kompatibel zu LVTTL, daher kein extra Eintrag.


> Da ich die Funktion eine gute Idee für das Basteln an Digitalschaltungen
> finde, würde es mich freuen, wenn andere ihre Erfahrungen damit posten
> könnten.
Ja, da stimme ich zu. Da ich auch nur begrenzt Zeit zum Testen habe 
würde ich mich über Rückmeldungen freuen.

Am besten mit Screenshots im Logic und Normalbetrieb und kurzer 
Beschreibung (Logicfamilie, Frequenz).


Gruß Hayo

p.s. es gibt noch vor meinem Winterurlaub eine Xmas Edition - vermutlich 
morgen.

[Blue F. (blueflash)]

@Michael

Mir ist gerade eine Idee gekommen woran es liegen könnte!

Hast Du einen Tastkopf mit 10:1 Teiler verwendet? Das wird nämlich zur 
Zeit noch nicht unterstützt. Da geht bei der 5.0 leider nur 1:1.

Bei der Xmas Edition versuche ich das mit einzubauen, mal sehen ob ich 
das noch schaffe.

Gruß Hayo

[Michael H. (stronzo83)]

Hi Hayo,
danke für die Mühe - da ich einen 10:1 Tastkopf verwendet habe, hat sich 
das ganze damit wohl schon geklärt.

Ich bin gespannt auf deine Xmas Edition, noch mehr bin ich aber gespannt 
was aus dem von Jörg angestoßenen Neubau der Software von Grundauf wird.
Sehr vielversprechend und schon erstaunlich weit gediehen, wenn man 
bedenkt, dass der Thread erst ein paar Tage alt ist.

Gruß
Michael

[Blue F. (blueflash)]

In der Tat - und die Xmas Edition profitiert auch schon davon, denn ich 
habe die schnelle MSTEP Multiplikation die Jörg entdeckt hat schon mit 
eingebaut da Jörg so nett war mir die modifizierten Dateien für den 
Compiler zur Verfügung zu stellen.

Der Geschwindigkeitszuwachs ist nicht von schlechten Eltern und läßt 
schon ahnen was wir mit der neuen Firmware evtl, erreichen können.

Kleiner Performancevergleich vorher/nachher:

                   vorher       mit MSTEP    [frames/s]
-------------------------------------------------------
QM (3 Slots)       211           243
FFT 512            160           256
FFT 1024            65           146


Das betrifft natürlich auch alle anderen Funktionen bei denen ausgiebig 
gerechnet wird.

Gruß Hayo

[Blue F. (blueflash)]

Frohe Weihnachten und viel Spaß beim Spielen.

Die FIR und sin(x)/x Routinen sind zwar schon zum Teil implemetiert, 
laufen aber noch nicht so ganz rund, daher sind sie erstmal nicht aktiv. 
Mit dem LED test könnt Ihr ja unter dem Weihnachtsbaum für Stimmung 
sorgen...  ;-)

Bin dann ab morgen im Ski-Urlaub.

Gruß Hayo

[Guido (Gast)]

Na dann:

Schönen Urlaub und vieeel Schnee!

Gruß, Guido

[Blue F. (blueflash)]

Danke,

ich muß mal sehen ob es bei uns im Hotel einen Internetzugang gibt, 
ansonsten

frohe Weihnachten und guten Rutsch.

Gruß Hayo

[Paolo (Gast)]

Thanks a lot, Hayo you are, as usua, very generous and kind...
Have a nice christmas and a very happy new year!!

Regards, Paolo

[Interessierter (Gast)]

ich finde es ja sehr spannend was hier passiert und hab Interesse an dem 
DSO.
Kann mir denn jemand mal sagen wo man das Ding kaufen kann?
Gurgel und E... sind da nicht so auskunftsfreudig....

[Luc (Gast)]

Hi Hayo, Jörg and guys all!

Hayo, thanks You very, very much for the free time You provided 
generously to us and for this new firmware's version!!!
I installed your latest great job, the new 1.2.BF.5.1XE and I tried it a 
bit.
As always I am speechless, RESPECT!!!
I believe also thanks to the integration of the Jörg's code (RESPECT 
also to Him and to all who are involved in the Welec Project) the new 
firmware is incredibly much fast and much more responsive now.
The LED's test idea is brilliant as so its implementation and since the 
upcoming Christmas' holiday can be used as Christmas tree! ;-)
I have seen that some item in some menu it was reduced and this 
streamlines the management.
Some item are instead deactivated (grey) and they will available in the 
future, I hope soon.
Reduced items in Hardware Menu works great for me (W2022A and W2012A) 
even if there are only two setting (Factory and High Frequency, all 
other are now grey deactivated), I used High Frequency setting without 
any spikes' problem.

As always only for knowledge and no for criticism, follow the report 
about some issue I noted:
1) [W2022A & W2012A] The memory management seems to me do not works, 
when I save a waveform in memory 1 and after a new one in the memory 2 
or other, then memory 1 is missed and there is only the last I saved.
2) [W2022A & W2012A] In the Quick Measures, the Fall Time recognized 
fail on channel 2, it seem to me to be calculated as half of the real 
value: channel 1 recognize right and very accurate values as compared to 
other master oscilloscopes I have and I used as champions instruments. 
(*)
3) [W2022A only] Sometime using the Cursors features get garbage on the 
screen, show corrupt labels and wrong values, but this issue was even in 
the former release.

I take this opportunity to wish to You Hayo, Jörg and all guys a Merry 
Christmas!
RESPECT!

Danke und Frohe Weihnachten!

Luc

(*)W2022A is strikingly higher to the W2012A as response time, I believe 
because it is really about 200MHz bandwidth by selected inner 
componentistic circuitry or anyway its inner components are better than 
the same in the W2012A version.

[Krunoslav O. (kruno3)]

Frohe Weihnachten!

Ich habe die Xmas Edition in mein W2022A geflasht und kurz getestet 
(Testsignal). Recht schnell im Vergleich zum Original. Die Filterung und 
Combi-Triggerung sind supper, Displayeinstellungen (Status/Mono-Beige) 
ebenso, usw.
Danke für die Arbeit!
Ich fand auch ein Paar bugs mit dem Trigger welche ich berichten möchte:
1) Beim wechseln zwischen Edge und Pulse Width wird der Trigger-Source 
nicht mitgenommen. Z.B. Extern bei PulseWidth und Source1 bei Edge, nach 
dem Mode-Wechsel.
Ist dass gewünscht?

2)Pulse Width Mode funktioniert nicht richtig. Mal funktioniert der < 
wie es soll(reagiert auf die Zeit-Grenzen), mal der >.
Der der jeweils andere triggert dann immer (unabhängig von der 
eingestelten Zeitlimits) oder nie. Der >< funktioniert nie. Meistens 
triggert er nicht.
Es sieht so aus als würde die beim anderen eingestellte Zeit (die 
inaktive Zeit), oder dessen Logik, ins Triggern mitwirken.

3)Der External Trigger triggert bei PulseWidth immer, unabhängig von den 
Zeiteinstellungen, eigentlich unabhängig ob es einen Signal hat oder 
nicht sehe ich gerade(im Normal Mode).
Wenn die Trigger-Logik wie PulseWidth bei dem Extern nicht geht, man 
sollte die Edge und PulseWidth Tasten sperren.

4)Nach dem wechseln des PulseWidth Modes < zum >, wird nicht getriggert 
bis man die Zeiteinstellungstaste druckt, egal wie die Zeit vorher war. 
Kleinigkeit für den Benutzer, wahrscheinlich schwer zu finden.

5)AutoScale braucht manchmal seeehr laaaangee (>30"). Zweimal passiert.

Verbesserungsvorschläge gibt es wahrscheinlich ein Haufen. Ich werfe ein 
paar dazu:
-beige Funktionstasten sind nicht so mein Geschmack (Vorschlag grau),
-der Oszi reagiert sehr träge auf die Drehschalter und bekommt den 
Winkel der Drehung nicht ganz mit. Ist sicher schwerer Brocken, aber 
stört auch am meisten.
-bei der Zeitbasis 1" wird der Verlauf am Display live gezeichnet, bei 
500ms muss man warten bis alles aufgezeichnet ist. Geht das bei den 
kleineren Zeiten nicht mehr?
-wenn der Verlauf gezeichnet wird, wird der noch ausstehende Teil als 
Nulllinie gezeichnet. Leer wäre besser (ich weiß, Klugsch.....).

Nochmals großen Dank an alle beteiligten und schönen Gruß aus Wien,
Kruno

[Jörg H. (idc-dragon)]

Interessierter schrieb:
> ich finde es ja sehr spannend was hier passiert und hab Interesse an dem
> DSO.
> Kann mir denn jemand mal sagen wo man das Ding kaufen kann?
> Gurgel und E... sind da nicht so auskunftsfreudig....

Such' mal bei Ebay nach den Verkäufer "welecgmbh". Zur Zeit tröpfeln die 
wieder Geräte dort ein, oder du fragst mal mit der Kontaktfunktion an. 
Mit einer normalen Artikelsuche ist das schwer zu finden, weil "Welec" 
dort nicht mit drin steht. Vielleicht dürfen die das aus irgendwelchen 
Gründen nicht.

@All: auch frohe Weihnachten!
Ich mache derweil weiter an der neuen Firmware, siehe dort:
Beitrag "made from scratch Firmware für Wittig/Welec Oszilloskop W20xxA"

Jörg

[Blue F. (blueflash)]

Ein frohes neues Jahr,

bin gerade wieder aus dem Urlaub zurück und noch dabei alles aufzuräumen 
- daher nur eine kurze Rückmeldung.


Luc schrieb:

> Some item are instead deactivated (grey) and they will available in the
> future, I hope soon.
I also hope...

> Reduced items in Hardware Menu works great for me (W2022A and W2012A)
> even if there are only two setting (Factory and High Frequency, all
> other are now grey deactivated), I used High Frequency setting without
> any spikes' problem.
There is only one setting working better in the HF-Range (But also with 
a little spike problem). All others have more problems or don't work, so 
I decided to throw them out.

Also I reduced the entries in the pre gain menu to the three important 
settings.

- Standard for all unmodified scopes (using gain 1.25)
- 24.9 Ohm for modified input stage equipped with two 24.9 Ohm resistors
  and one 150 Ohm resistors (replacing 0 Ohm and 150 KOhm resistors)
- Add-On PCB for the new input stage on its own PCB


> 1) [W2022A & W2012A] The memory management seems to me do not works,
> when I save a waveform in memory 1 and after a new one in the memory 2
> or other, then memory 1 is missed and there is only the last I saved.
I'm sorry but I can't reproduce the problem. On my scopes it is working 
without problems -> see screenshots.


> 2) [W2022A & W2012A] In the Quick Measures, the Fall Time recognized
> fail on channel 2, it seem to me to be calculated as half of the real
> value: channel 1 recognize right and very accurate values
I can't reproduce this also. See screenshot.


> 3) [W2022A only] Sometime using the Cursors features get garbage on the
> screen, show corrupt labels and wrong values, but this issue was even in
> the former release.
Yes I also had the problem, but couldn't reproduce it after restart. Do 
You know how to force it?

Kind regards

Hayo

[Blue F. (blueflash)]

Krunoslav O. schrieb:

> 1) Beim wechseln zwischen Edge und Pulse Width wird der Trigger-Source
> nicht mitgenommen. Z.B. Extern bei PulseWidth und Source1 bei Edge, nach
> dem Mode-Wechsel.
> Ist dass gewünscht?
Nein, hatte ich noch nicht bemerkt, da der Pulsetrigger recht wenig in 
Gebrauch ist (wg. unten genannter Gründe)


> 2)Pulse Width Mode funktioniert nicht richtig.
Ja ist leider ein bekanntes Problem welches sich nicht so einfach 
beheben läßt da die Triggeransteuerung im FPGA eingebrannt ist. Ich 
hatte schon mal die Idee da einen Workaround in die Firmware 
einzuarbeiten. Evtl. läßt sich da mit der neuen Firmware und den von 
Jörg gewonnenen Erkenntnissen etwas machen.


> 3)Der External Trigger triggert bei PulseWidth immer, unabhängig von den
> Zeiteinstellungen, eigentlich unabhängig ob es einen Signal hat oder
> nicht sehe ich gerade(im Normal Mode).
Ist aus den gleichen Gründen etwas unausgegoren. Ich tendiere auch dazu 
den PW-Trigger bei externem Betrieb ganz raus zunehmen.

> 5)AutoScale braucht manchmal seeehr laaaangee (>30"). Zweimal passiert.
Das hängt von der Anzahl der aktiven Kanäle und dem Signal ab. Die 
Autoscalefunktion arbeitet sich Stück für Stück durch alle Zeitbereiche 
und Spannungsbereiche bis alles passt. Im ungünstigsten Fall müssen erst 
alle relevanten Zeitbereiche und dann alle Spannungsbereiche durchsucht 
werden -> läßt sich per Terminal schön nachvollziehen, da ich die 
Debuggausgabe dringelassen habe.


> Verbesserungsvorschläge gibt es wahrscheinlich ein Haufen. Ich werfe ein
> paar dazu:
> -beige Funktionstasten sind nicht so mein Geschmack (Vorschlag grau),
Ist von Agilent so kopiert. Wir haben leider auch nur eine sehr 
begrenzte Farbpalette.

> -der Oszi reagiert sehr träge auf die Drehschalter und bekommt den
> Winkel der Drehung nicht ganz mit. Ist sicher schwerer Brocken, aber
> stört auch am meisten.
Ja, das ist auch ein bekanntes Problem das zum Teil im FPGA verbockt 
wurde. In der neuen Firmware könnte das etwas besser werden, da Jörg für 
die Eventverarbeitung eine Eventqueue vorgesehen hat die das Ganze 
(hoffentlich) etwas flüssiger verarbeitet.

> -bei der Zeitbasis 1" wird der Verlauf am Display live gezeichnet, bei
> 500ms muss man warten bis alles aufgezeichnet ist. Geht das bei den
> kleineren Zeiten nicht mehr?
Mit der aktuellen Polling-Eventverarbeitung leider nicht. Da ist das 
Ende der Fahnenstange schon erreicht. Mit der neuen queuegesteuerten 
Verarbeitung könnte da noch was machbar sein, wir werden sehen.

> -wenn der Verlauf gezeichnet wird, wird der noch ausstehende Teil als
> Nulllinie gezeichnet. Leer wäre besser (ich weiß, Klugsch.....).
Das Ganze ist ein Ringpuffer, dh. irgendwann fängt sowieso das alte 
Signal wieder an. Dann ist da auch keine Nulllinie mehr.

Gruß und willkommen an Bord

Hayo

[Krunoslav O. (kruno3)]

Hallo Hayo
Danke für die Antwort, macht einiges klar. Das letzte Punkt (Ringpuffer) 
auch, wobei ich es als störend empfinde und von anderen DSOs nicht 
kenne.
Gerade beim zweiten Durchlauf kommt ein neues Signal über das alte und 
man muss u.U. genau schauen wo der neue endet und das alte beginnt.
Ist aber nicht so wichtig.
Gruß
Kruno

[Blue F. (blueflash)]

Krunoslav O. schrieb:

> Gerade beim zweiten Durchlauf kommt ein neues Signal über das alte und
> man muss u.U. genau schauen wo der neue endet und das alte beginnt.
Die Stelle ist einfach zu finden - genau beim roten Pretriggermarker am 
oberen Bildrand. Der markiert nämlich im USTB-Modus den aktuellen 
Zeitpunkt - so wie beim normalen Modus eigentlich auch.

Der Grund warum der Puffer nach der Aufzeichnung nicht gelöscht wird ist 
der, dass man im Speicher scrollen kann und sich beliebige vergangene 
Zeitpunkte bis zum Ende des Puffers ansehen kann.

Beim Shift-Modus ist der Puffer vor dem aktuellen Zeitpunkt ja leer, da 
kenne ich das so, dass das Signal als Nulllinie dargestellt wird (wie 
beim Herzschlagmonitor z.B.).

Gruß Hayo

[Stephan S. (outsider)]

Bin nach einem Jahr endlich mal wieder mit festem Wohnsitz in 
Deutschland und hab mal die neue Weihnachtsedition aufgespielt um die 
Akkus zu testen die ich aus China mitgebracht habe. Dazu ne kleine Idee: 
wie wärs wenn man die Zeiten ab z.B. 100 s/DIV nicht mehr in s/DIV, 
sondern in min/DIV skaliert? Wer kann sich schon ohne laufend rum zu 
rechnen was vorstellen wenn der Entladevorgang eines Akkus 2600 s 
gedauert hat? Selbst wenn man das Oszi als Langzeitdatenlogger für 
beliebige andere Daten nimmt denke ich dass Minuten sinnvoller wären.

[Blue F. (blueflash)]

Luc schrieb:
> Hi Hayo, Jörg and guys all!
> As always only for knowledge and no for criticism, follow the report
> about some issue I noted:
> 1) [W2022A & W2012A] The memory management seems to me do not works,
> when I save a waveform in memory 1 and after a new one in the memory 2
> or other, then memory 1 is missed and there is only the last I saved.
Ok, I got it now! When I made some tests with TTL circuits I had the 
same effect as You. I will try to fix it soon. Thanks for reporting :-)


> (*)W2022A is strikingly higher to the W2012A as response time, I believe
> because it is really about 200MHz bandwidth by selected inner
> componentistic circuitry or anyway its inner components are better than
> the same in the W2012A version.
I agree with You. While I made my tests with TTL circuits I could also 
see a difference between my 2022A and my 2014A. The Bandwidth of the 
2022A seems to be really better. On the 2022A the overshots of the 
TTL-signal (20MHz) could be seen very good, while the 2014A did not 
display them.

Hayo

[Warhawk (Gast)]

Hallo zusammen,

ich hab ein kleines Problem bei meinem W2022A mit dem Triggern auf einen 
Fankenwechsel. Ich verwende aktuell die Firmware 1.2.BF.5.1XE (per 
Ramloader hochgeladen)

Ich will einfach nur auf eine steigende Flanke von 0V auf 3V triggern.
Eingestellt habe ich bei Horizontal den Modus "Main" und eine 500ms 
Auflösung.

Der Trigger ist bei Edge auf positive Flanke, Source 1, PreTrigger 
200ms, eingestellt. Im Triggermenü Mode steht im Mode auf Normal, 
Coupling DC, Trigger Level 1.5V, Holdoff 100ms.

Wenn ich jetzt ein 1Hz Signal am Eingang anlege, triggert das Oszi 
nicht.
Die angezeigt Linie bleibt weiterhin auf 0V.
Stell ich die Horizontale-Auflösung des Oszi auf 1s ein, wechselt es 
automatisch in den Roll-Modus und ich kann das Signal sehen.

Hab ich irgend eine Einstellung vergessen oder kann es sein das mit 
meinem Oszi was nicht stimmt. (Das Oszi ist neu).

Vielen Dank für eure Hilfe.

[Michael D. (mike0815)]

Hallo Warhawk,

ich habe mich gerade dazu entschlossen die X-Mas Edition aufzuspielen 
und mal eben deine Einstellungen mit einem 1Hz Rechteck getestet.
Schau mal oben im Screenshot, ob diese mit deinen identisch sind.
Bei 200mS wird ca. alle 7Sec. getriggert, wie man an den LED's sehen 
kann.
Ab 1S Timebase kommst du automatisch in den USTB-Modus (Ultra slow 
Timebase), deswegen der Rollmodus, sonst würde man warscheinlich sehr 
lange warten müssen, bis sich auf dem Bildschirm was tut.
Im 2. Shot bin ich mal auf eine Sekunde gegangen.
Hast vorher ein Default-Setup gemacht?

Gruß Michael

[Warhawk (Gast)]

Hallo Michael,

vielen Dank. ich hab nochmal die Defaults geladen und dann ging es.

Nach dem Aufspielen der Firmware hatte ich aber schonmal die Defaults 
geladen und die ADC Offset kalibiert.

Keine Ahnung warum es nicht ging, aber hauptsache es geht jetzt ;-)

[Michael D. (mike0815)]

dann ist ja alles gut.
Es kann sein, wenn das DSO zickt, man mehrmals Default-Setup drücken 
muß. Vielleicht wird auch nicht immer alles zurück gesetzt, wie auch 
immer...
Ich klatsch mir die Updates immer gleich ins Flash, denn wenn das Teil 
einfriert, komme ich um ein neues Einspielen eh nicht rum!

Btw.
Bis ich beim "Holdoff" auf 100mS angekommen bin, hab' ich mir einen Wolf 
gekurbelt!
Könnte man beim schnelleren Drehen des Enkoders nicht grössere 
Zeitsprünge implementieren?

Gruß Michael

[Jürgen (Gast)]

Hallo zusammen,

Warhawk schrieb:
> Keine Ahnung warum es nicht ging, aber hauptsache es geht jetzt ;-)

leider funktioniert es aber doch nicht. Warhawk hat da eine vollkommen 
richtige Beschreibung geliefert!
Ich habe in den letzten Wochen versucht mal ganz einfach mit meinem 
W2024A zu arbeiten. Oft wusste man nicht, ob das Signal, welches gerade 
mit einem simplen Flankentrigger untersucht wurde nun wirklich nicht da 
war oder ob nur das Oszi hing!!
Diese Hänger treten auf, wenn mann z.B. den Trigger zwischen den 
Eingängen umschaltet oder zwischen Normaltrigger und Combitrigger 
wechselt oder z.B. mal einen Singleshot benötigt. Ich denke, das rührt 
daher, das die Triggereinstellungen teilweise nicht vollständig oder in 
der Firmware an verschiedenen Stellen gesetzt werden und so diverse 
Einstellungen unbeabsichtigt nicht durchgeschalten werden.

Das beeinträchtigt leider den Spaß an der Freude sehr!

Grüße
Jürgen

[Jörg H. (idc-dragon)]

Jürgen schrieb:
> Ich habe in den letzten Wochen versucht mal ganz einfach mit meinem
> W2024A zu arbeiten. Oft wusste man nicht, ob das Signal, welches gerade
> mit einem simplen Flankentrigger untersucht wurde nun wirklich nicht da
> war oder ob nur das Oszi hing!!
> Diese Hänger treten auf, wenn mann z.B. den Trigger zwischen den
> Eingängen umschaltet oder zwischen Normaltrigger und Combitrigger
> wechselt oder z.B. mal einen Singleshot benötigt. Ich denke, das rührt
> daher, das die Triggereinstellungen teilweise nicht vollständig oder in
> der Firmware an verschiedenen Stellen gesetzt werden und so diverse
> Einstellungen unbeabsichtigt nicht durchgeschalten werden.

An dieser Stelle komme ich als nächstes mit der neuen Firmware an. 
Kanaleinstellungen und Offset kann ich mittlerweile, nun kommt Capturing 
und Trigger dran. Wird spannend, was ist wirklich in der Hardware 
kaputt, was in der alten Software, was läßt sich durch Workarounds noch 
hinbiegen, was nicht?
Dieses Arbeitspaket stelle ich mir aufwändiger vor als die bisherigen. 
Wir werden sehen...
Mit der kleinen schlanken Osoz-Firmware (Arbeitstitel) läßt sich 
jedenfalls schön schnell testen. Ein Download in das Gerät dauert 
derzeit 13 Sekunden, und selbst das liegt hauptsächlich an Zeichensätzen 
und Icons, die alle schon drin sind.

Jörg

[Michael D. (mike0815)]

Hallo Jörg,
das hört sich alles sehr interessant an, was du da baust!
Vielleicht gibst du uns mal eine kleine, kompilierte Kostprobe für's RAM 
zum testen? Ist schon spannend...

Gruß Michael

[Jörg H. (idc-dragon)]

Michael D. schrieb:
> Vielleicht gibst du uns mal eine kleine, kompilierte Kostprobe für's RAM
> zum testen?

Gern aber was soll diese Kostprobe denn tun?
Ich arbeite mich von unten hoch, baue einen Layer der die 
"Infrastruktur" des Gerätes in geordneter Weise zugänglich macht. Auf 
diesem Plattformlayer  setzt die Applikation dann auf.
Ist also maximal undankbar, bzw. understatement: nichts von dem wird 
nachher sichtbar sein, aber es macht die eigentliche Arbeit.

Natürlich tun die Programme, die ich da so reinlade schon etwas: es ist 
jeweils spezieller Test-Code für den Plattformlayer, mit dem ich z.B. 
Wertebereiche durchfahre, Geschwindigkeiten messe, Randbedingungen teste 
usw. Man soll sich ja später auf den Unterbau verlassen können.
Es gibt da halt nur recht wenig zu sehen.

Grüße,
Jörg

[Blue F. (blueflash)]

Hallo allerseits,

bin momentan etwas busy und daher nicht so oft in unserer Sache aktiv. 
Hier eine Korrektur des Flashproblems das Luc entdeckt hatte. Das neue 
CPU Timing welches ich nach Jörgs Forschungsergebnissen eingebaut hatte 
brachte die Flash-Schreibroutinen etwas durcheinander. Das ist jetzt 
wieder korrigiert. Weiterhin habe ich das Timing des USB-Host Interface 
angepasst, da dieses ebenfalls dadurch beeinflusst wird.

GRuß Hayo

[Blue F. (blueflash)]

Hab noch ein paar Fehler gefunden - die C3 gibt es morgen.

Gruß Hayo

[Blue F. (blueflash)]

So hier die versprochene C3 in der ich keine Auffälligkeiten mehr finden 
konnte.

Gruß Hayo

[Luc (Gast)]

Hi Hayo and guys all!

Hayo W. schrieb:
>So hier die versprochene C3 in der ich keine Auffälligkeiten mehr finden
>konnte.

Hayo, as always you are right and all troubles are gone: RESPECT!!!!!!!
Really impressive, no words, W2012A and W2022A both works like a charm, 
I have not noticed any problems!
The oscilloscopes work fine, really fast and responsive.
Now I am little hurry, however thank you very much Hayo, Jörgs and all 
who are involve in the Welec project.
Last but no least, the logics trigger are awesome, really terrific!

Vielen Dank!!!!!!!

Mit freundlichen Grüßen,

Luc

[Blue F. (blueflash)]

Hier die C4 mit dem angepassten Timing für das USB-Host Interface.

Hayo

[Letschi (Gast)]

Hallo!

Muss man etwas spezielles beachten, wenn man die aktuelle Firmware an 
"unmodifizierten" Geräten im originalzustand verwendet?

Gruß
Letschi

[wailer (Gast)]

Hayo Sorry, but where I find the files Functions.txt Special?
Thanks so much for your work.

[Blue F. (blueflash)]

@Letschi

Nein, die Firmware unterstützt in erster Linie originale Geräte und 
zusätzlich auch noch einige Hardwaremodifikationen. Wenn Du ein normales 
W20xxA hast kannst Du das also problemlos draufspielen. Bitte beachten, 
dass das nicht mit dem originalen Firmwareloader von WELEC geht. Hierfür 
entweder den WELEC-Updater von Markus nehmen oder besser das 
Perl-Skript. Anleitung findet sich im "Docs" Verzeichnis.


@wailer

You will find it in the "Docs" directory!




Hayo

[wailer (Gast)]

Hayo Sorry I can not find the director: DOC
Why not post the link?

[Guido (Gast)]

wailer schrieb:
> Hayo Sorry I can not find the director: DOC
> Why not post the link?

Download the 1.2.BF.xy...zip above and unzip it. Then you will
find the doc-directory.

Link: http://www.mikrocontroller.net/attachment/131946/1.2.BF.5.1C4.zip

[wailer (Gast)]

Sorry .... I got other!

[Jörg H. (idc-dragon)]

Hallo,

ich hatte ja heute im Osoz-Thread von meinen gestrigen 
Forschungsergebnissen zu Thema Startup berichtet:
Beitrag "Re: made from scratch Firmware für Wittig/Welec Oszilloskop W20xxA"

Anbei daher hier nun eine Firmwareversion mit dem schnellen Loader, zum 
Ausprobieren. Das ist exakt Hayos Version 5.1C4, siehe ein paar Postings 
weiter oben, aber mit dem "Turbolader". Ich habe nur das Flashfile 
eingepackt, den Rest habt ihr ja schon.

Viel Spaß damit!
Jörg

[Michael H. (stronzo83)]

Toll was da alles ans Licht kommt und wenn das Oszi jetzt wirklich so 
schnell bootet - klasse! Werde ich am Wochenende gleich mal 
ausprobieren...

Gruß
Michael

[Blue F. (blueflash)]

Alter Schwede!

Die Neugier hat mir keine Ruhe gelassen...

Incl. reindrücken des Netzschalters braucht das Gerät 2 Sekunden zum 
Starten!!! Das nenn ich prompte Verfügbarkeit. Nicht übel, gefällt mir.

Gruß Hayo

[Jörg H. (idc-dragon)]

Hallo Hayo und interessierte,

Hier ein paar Updates für die "alte" Software.
Ich habe mich gestern an das Problem der Offset-Querbeeinflussung mit 
der neuen Eingangsstufe gesetzt. Ursache ist ein Überlauf der 4 
Variablen CHx_DAC_Offset. Ich habe nun zur Sicherheit in 
Hardware::SetDacOffset() den Wert mit 0xFFFF maskiert, sonst kann der in 
den Kommandoteil überlaufen.
Die Ursache warum das zu groß werden kann habe ich vermutlich noch nicht 
vollständig erfasst, verstehe die Software zu wenig. Vielleicht hast du 
da mehr Durchblick. Ich habe zumindest mal ein Clipping in den 
Drehregler-Code eingebaut, in die 4 Funktionen 
UserIF::ON_Zero_Channel_x()
Anbei die relevanten Dateien, ausgehend von deiner C4-Version.

Den Turbolader habe ich auch mit reingelegt, compiliert für die alte, 
willkürliche Kopierlänge. So hat das noch etwas Luft, kann den alten 1:1 
ersetzen. Der gestrige Code war maßgeschneidert, startet natürlich am 
schnellsten. Dafür müßte man sich noch einen Flow überlegen.
Ich habe den Code mit Absicht so geschrieben, daß die Länge am Anfang 
"im Klartext" drinsteht, 5.-8. Byte, byteweise rückwärts weil little 
endian. Da könnte man das zur Not reinpatchen, muß aber die Prüfsumme 
hinten in der Zeile auch korrigieren.

Den Quellcode des Loaders habe ich bei Osoz eingecheckt, unter 
platform/nios/sdk/startup. Im Quellcode steht auch wie man ihn per 
Kommandozeile einzeln compiliert.

Viele Grüße,
Jörg

[Luc (Gast)]

Gute Sonntag, Jörg H., Hayo und alle!

@Jörg H.
Jörg H. thanks You very much for the free time You provided generously 
to us and for this new great firmware's improvement!!!
Very impressive work, no words, really much terrific's speed: R E S P E 
C T ! ! ! ! ! ! !

@Hayo and/or anyone else who has an answer:
I was thinking on occasion could be useful inhibit quick measures' 
cursor marker leaving only the numerical values ​​of labels so that can 
be observed waveforms without the marker lines dancing on the screen 
that sometimes can be annoying.
On the other hand most of the DSO that I know do not show markers when 
performing automatic measurements unless this is not explicitly wanted 
by the user.
Perhaps it would be not difficult to add this feature, I'm wrong?
I hope I'm right, so the question is:
Would not be it possible to add a button that allows to view or not the 
markers when performing automatic measurements?

Ich danke Ihnen allen für Ihre Aufmerksamkeit.
Vielen Dank!!!!!!!

Mit freundlichen Grüßen,

Luc

[Blue F. (blueflash)]

Hi Luc,

yes Your idea is not bad. I thought about it the last weeks since I got 
my new OWON DSO. It does not have this QM-Cursors too. I think I could 
realize this in the next release.

Kind regards

Hayo

[branadic (Gast)]

Jörg H. schrieb:
> Ich habe mich gestern an das Problem der Offset-Querbeeinflussung mit
> der neuen Eingangsstufe gesetzt. Ursache ist ein Überlauf der 4
> Variablen CHx_DAC_Offset. Ich habe nun zur Sicherheit in
> Hardware::SetDacOffset() den Wert mit 0xFFFF maskiert, sonst kann der in
> den Kommandoteil überlaufen.

Die Querbeeinflussung ist leider nach wie vor vorhanden, die Maskierung 
funktioniert also nicht wie gewünscht, zumindest auf meinem Welec.

Darüber hinaus besteht nach wie vor das Problem, dass die 
Offset-Kalibrierung bei der Huckepackplatine nicht funktioniert. Dazu 
ist zunächst zu sagen, dass der Offset im Zusammenhang mit der 
Huckepackplatine für alle Vertikalablenkungen zu ermitteln ist, da 
jeweils andere Verstärkungsfaktoren (Dämpfungsfaktoren im LMH6518) 
eingestellt werden, d.h. die DAC-Werte für 5V/div können nicht für 500mV 
und 50mV usw. verwendet werden. Dazu möchte ich noch einmal auf die von 
mir erstellte Tabelle verweisen, die sämtliche Einstellungen enthält:

http://welecw2000a.sourceforge.net/docs/Hardware/Welec-Huckepack-Settings-ScaleFactors.xls

Daher wäre es gut, wenn das Ganze nicht mehr nur so kryptische 
Bezeichnungen wie "Voltage Range 9" besitzen würde, sondern der 
tatsächliche Spannungsbereich namentlich genannt würde, dann könnte man 
auch ohne im Sourcecode fit zu sein erkennen wo Probleme auftauchen.

Vielleicht erkennt ja jemand von euch, warum die Offset-Routine nicht 
mit der Huckepackplatine harmonieren will? Anbei die Ausgabe. Kanal 1 
ist derzeit bei mir nicht bestückt, da ja die Problematik mit der 
Spannungsversorgung bestand. Diese ist ja durch den anderen 
Spannungsregler behoben worden, daher sollte sie mal wieder eingebaut 
werden. Aber für den Moment bitte einfach Kanal 1 ignorieren.

outbuf5: 70000f10<\r><\n><\r><\n>
outbuf5: 50000010<\r><\n><\r><\n>
outbuf5: 10000010<\r><\n><\r><\n>
outbuf5: 30000010<\r><\n><\r><\n><\r><\n>
Channel 1 start calibrating ADC offsets<\r><\n>
ADC 1 Offset = 3<\r><\n>
ADC 2 Offset = 0<\r><\n>
ADC 3 Offset = 2<\r><\n>
ADC 4 Offset = 0<\r><\n><\r><\n>
Channel 2 start calibrating ADC offsets<\r><\n>A
DC 1 Offset = 0<\r><\n>
ADC 2 Offset = 0<\r><\n>
ADC 3 Offset = 1<\r><\n>
ADC 4 Offset = 1<\r><\n><\r><\n>
Channel 3 start calibrating ADC offsets<\r><\n>
ADC 1 Offset = 2<\r><\n>
ADC 2 Offset = 2<\r><\n>
ADC 3 Offset = 0<\r><\n>
ADC 4 Offset = 3<\r><\n><\r><\n>
Channel 4 start calibrating ADC offsets<\r><\n>
ADC 1 Offset = 3<\r><\n>
ADC 2 Offset = 1<\r><\n>
ADC 3 Offset = 1<\r><\n>
ADC 4 Offset = 0<\r><\n><\n><\r>
**************** Voltage Range 9 ********************<\n><\r>
outbuf5: 70000f10<\r><\n><\r><\n>
outbuf5: 50000010<\r><\n><\r><\n>
outbuf5: 10000010<\r><\n><\r><\n>
outbuf5: 30000010<\r><\n><\r><\n>
Calibration run 1<\n><\r>
Channel 1: ADC average value  = 126   Diff  = -2<\r><\n>
Channel 2: ADC average value  = 34   Diff  = -94<\r><\n>
Channel 3: ADC average value  = 0   Diff  = -128<\r><\n>
Channel 4: ADC average value  = 0   Diff  = -128<\r><\n>
Calibration run 2<\n><\r>
Channel 1: ADC average value  = 126   Diff  = -2<\r><\n>
Channel 2: ADC average value  = 42   Diff  = -86<\r><\n>
Channel 3: ADC average value  = 0   Diff  = -128<\r><\n>
Channel 4: ADC average value  = 0   Diff  = -128<\r><\n>
Calibration run 3<\n><\r>
Channel 1: ADC average value  = 126   Diff  = -2<\r><\n>
Channel 2: ADC average value  = 51   Diff  = -77<\r><\n>
Channel 3: ADC average value  = 0   Diff  = -128<\r><\n>
Channel 4: ADC average value  = 0   Diff  = -128<\r><\n>
Calibration run 4<\n><\r>
Channel 1: ADC average value  = 126   Diff  = -2<\r><\n>
Channel 2: ADC average value  = 65   Diff  = -63<\r><\n>
Channel 3: ADC average value  = 0   Diff  = -128<\r><\n>
Channel 4: ADC average value  = 0   Diff  = -128<\r><\n>
Calibration run 5<\n><\r>
Channel 1: ADC average value  = 126   Diff  = -2<\r><\n>
Channel 2: ADC average value  = 72   Diff  = -56<\r><\n>
Channel 3: ADC average value  = 0   Diff  = -128<\r><\n>
Channel 4: ADC average value  = 0   Diff  = -128<\r><\n>
Calibration run 6<\n><\r>
Channel 1: ADC average value  = 126   Diff  = -2<\r><\n>
Channel 2: ADC average value  = 71   Diff  = -57<\r><\n>
Channel 3: ADC average value  = 0   Diff  = -128<\r><\n>
Channel 4: ADC average value  = 0   Diff  = -128<\r><\n>
Calibration run 7<\n><\r>
Channel 1: ADC average value  = 126   Diff  = -2<\r><\n>
Channel 2: ADC average value  = 79   Diff  = -49<\r><\n>
Channel 3: ADC average value  = 0   Diff  = -128<\r><\n>
Channel 4: ADC average value  = 0   Diff  = -128<\r><\n>
Calibration run 8<\n><\r>
Channel 1: ADC average value  = 126   Diff  = -2<\r><\n>
Channel 2: ADC average value  = 83   Diff  = -45<\r><\n>
Channel 3: ADC average value  = 0   Diff  = -128<\r><\n>
Channel 4: ADC average value  = 0   Diff  = -128<\r><\n>
Calibration run 9<\n><\r>
Channel 1: ADC average value  = 126   Diff  = -2<\r><\n>
Channel 2: ADC average value  = 86   Diff  = -42<\r><\n>
Channel 3: ADC average value  = 0   Diff  = -128<\r><\n>
Channel 4: ADC average value  = 0   Diff  = -128<\r><\n>
Calibration run 10<\n><\r>
Channel 1: ADC average value  = 126   Diff  = -2<\r><\n>
Channel 2: ADC average value  = 87   Diff  = -41<\r><\n>
Channel 3: ADC average value  = 0   Diff  = -128<\r><\n>
Channel 4: ADC average value  = 0   Diff  = -128<\r><\n>
<\n><\r>**************** Voltage Range 10 ********************<\n><\r>
outbuf5: 70000f10<\r><\n><\r><\n>
outbuf5: 50000010<\r><\n><\r><\n>
outbuf5: 10000010<\r><\n><\r><\n>
outbuf5: 30000010<\r><\n><\r><\n>
Calibration run 1<\n><\r>
Channel 1: ADC average value  = 126   Diff  = -2<\r><\n>
Channel 2: ADC average value  = 79   Diff  = -49<\r><\n>
Channel 3: ADC average value  = 0   Diff  = -128<\r><\n>
Channel 4: ADC average value  = 0   Diff  = -128<\r><\n>
Calibration run 2<\n><\r>
Channel 1: ADC average value  = 126   Diff  = -2<\r><\n>
Channel 2: ADC average value  = 83   Diff  = -45<\r><\n>
Channel 3: ADC average value  = 0   Diff  = -128<\r><\n>
Channel 4: ADC average value  = 0   Diff  = -128<\r><\n>
Calibration run 3<\n><\r>
Channel 1: ADC average value  = 126   Diff  = -2<\r><\n>
Channel 2: ADC average value  = 91   Diff  = -37<\r><\n>
Channel 3: ADC average value  = 0   Diff  = -128<\r><\n>
Channel 4: ADC average value  = 0   Diff  = -128<\r><\n>
Calibration run 4<\n><\r>
Channel 1: ADC average value  = 126   Diff  = -2<\r><\n>
Channel 2: ADC average value  = 95   Diff  = -33<\r><\n>
Channel 3: ADC average value  = 0   Diff  = -128<\r><\n>
Channel 4: ADC average value  = 0   Diff  = -128<\r><\n>
Calibration run 5<\n><\r>
Channel 1: ADC average value  = 126   Diff  = -2<\r><\n>
Channel 2: ADC average value  = 100   Diff  = -28<\r><\n>
Channel 3: ADC average value  = 0   Diff  = -128<\r><\n>
Channel 4: ADC average value  = 0   Diff  = -128<\r><\n>
Calibration run 6<\n><\r>
Channel 1: ADC average value  = 126   Diff  = -2<\r><\n>
Channel 2: ADC average value  = 104   Diff  = -24<\r><\n>
Channel 3: ADC average value  = 0   Diff  = -128<\r><\n>
Channel 4: ADC average value  = 0   Diff  = -128<\r><\n>
Calibration run 7<\n><\r>
Channel 1: ADC average value  = 126   Diff  = -2<\r><\n>
Channel 2: ADC average value  = 103   Diff  = -25<\r><\n>
Channel 3: ADC average value  = 0   Diff  = -128<\r><\n>
Channel 4: ADC average value  = 0   Diff  = -128<\r><\n>
Calibration run 8<\n><\r>
Channel 1: ADC average value  = 126   Diff  = -2<\r><\n>
Channel 2: ADC average value  = 107   Diff  = -21<\r><\n>
Channel 3: ADC average value  = 0   Diff  = -128<\r><\n>
Channel 4: ADC average value  = 0   Diff  = -128<\r><\n>
Calibration run 9<\n><\r>
Channel 1: ADC average value  = 126   Diff  = -2<\r><\n>
Channel 2: ADC average value  = 110   Diff  = -18<\r><\n>
Channel 3: ADC average value  = 0   Diff  = -128<\r><\n>
Channel 4: ADC average value  = 0   Diff  = -128<\r><\n>
Calibration run 10<\n><\r>
Channel 1: ADC average value  = 126   Diff  = -2<\r><\n>
Channel 2: ADC average value  = 114   Diff  = -14<\r><\n>
Channel 3: ADC average value  = 0   Diff  = -128<\r><\n>
Channel 4: ADC average value  = 0   Diff  = -128<\r><\n><\n><\r>
**************** Voltage Range 11 ********************<\n><\r>
outbuf5: 70000f10<\r><\n><\r><\n>
outbuf5: 50000010<\r><\n><\r><\n>
outbuf5: 10000010<\r><\n><\r><\n>
outbuf5: 30000010<\r><\n><\r><\n>
Calibration run 1<\n><\r>
Channel 1: ADC average value  = 126   Diff  = -2<\r><\n>
Channel 2: ADC average value  = 106   Diff  = -22<\r><\n>
Channel 3: ADC average value  = 0   Diff  = -128<\r><\n>
Channel 4: ADC average value  = 0   Diff  = -128<\r><\n>
Calibration run 2<\n><\r>
Channel 1: ADC average value  = 126   Diff  = -2<\r><\n>
Channel 2: ADC average value  = 107   Diff  = -21<\r><\n>
Channel 3: ADC average value  = 0   Diff  = -128<\r><\n>
Channel 4: ADC average value  = 0   Diff  = -128<\r><\n>
Calibration run 3<\n><\r>
Channel 1: ADC average value  = 126   Diff  = -2<\r><\n>
Channel 2: ADC average value  = 110   Diff  = -18<\r><\n>
Channel 3: ADC average value  = 0   Diff  = -128<\r><\n>
Channel 4: ADC average value  = 0   Diff  = -128<\r><\n>
Calibration run 4<\n><\r>
Channel 1: ADC average value  = 126   Diff  = -2<\r><\n>
Channel 2: ADC average value  = 113   Diff  = -15<\r><\n>
Channel 3: ADC average value  = 0   Diff  = -128<\r><\n>
Channel 4: ADC average value  = 0   Diff  = -128<\r><\n>
Calibration run 5<\n><\r>
Channel 1: ADC average value  = 126   Diff  = -2<\r><\n>
Channel 2: ADC average value  = 115   Diff  = -13<\r><\n>
Channel 3: ADC average value  = 0   Diff  = -128<\r><\n>
Channel 4: ADC average value  = 6   Diff  = -122<\r><\n>
Calibration run 6<\n><\r>
Channel 1: ADC average value  = 126   Diff  = -2<\r><\n>
Channel 2: ADC average value  = 114   Diff  = -14<\r><\n>
Channel 3: ADC average value  = 0   Diff  = -128<\r><\n>
Channel 4: ADC average value  = 15   Diff  = -113<\r><\n>
Calibration run 7<\n><\r>
Channel 1: ADC average value  = 126   Diff  = -2<\r><\n>
Channel 2: ADC average value  = 116   Diff  = -12<\r><\n>
Channel 3: ADC average value  = 0   Diff  = -128<\r><\n>
Channel 4: ADC average value  = 26   Diff  = -102<\r><\n>
Calibration run 8<\n><\r>
Channel 1: ADC average value  = 126   Diff  = -2<\r><\n>
Channel 2: ADC average value  = 117   Diff  = -11<\r><\n>
Channel 3: ADC average value  = 4   Diff  = -124<\r><\n>
Channel 4: ADC average value  = 46   Diff  = -82<\r><\n>
Calibration run 9<\n><\r>
Channel 1: ADC average value  = 126   Diff  = -2<\r><\n>
Channel 2: ADC average value  = 118   Diff  = -10<\r><\n>
Channel 3: ADC average value  = 98   Diff  = -30<\r><\n>
Channel 4: ADC average value  = 94   Diff  = -34<\r><\n>
Calibration run 10<\n><\r>
Channel 1: ADC average value  = 126   Diff  = -2<\r><\n>
Channel 2: ADC average value  = 119   Diff  = -9<\r><\n>
Channel 3: ADC average value  = 185   Diff  = 57<\r><\n>
Channel 4: ADC average value  = 118   Diff  = -10<\r><\n>
outbuf5: 70000f10<\r><\n><\r><\n>
outbuf5: 50000010<\r><\n><\r><\n>
outbuf5: 10000010<\r><\n><\r><\n>
outbuf5: 30000010<\r><\n><\r><\n>
protected config written to flash<\r><\n>
protected config written to flash backup sector<\r><\n>

Nachdem sich bisher noch immer niemand anderes zu den besagten Problemen 
geäußert hat gehe ich davon aus, dass nach wie vor niemand die 
Huckepackplatine ins Welec gebaut hat? Leute, wozu habt ihr euch die 
Hardware dann gekauft?

branadic

[branadic (Gast)]

Okay, Jörg hat mir soeben einen ersten Hinweis geliefert. Derzeit folgt 
die gesamte Firmware auch mit Huckepackplatine der 1-2-5 - Mimik, soll 
heißen, dass stillschweigend davon ausgegangen wird, dass sich die 
Eingangsbeschaltung in allen Dekaden gleich verhält. Das ist bei einem 
Messgerät natürlich absolut sinnbefreit, denn allein die Eingangsoffsets 
der Operationsverstärker werden sich bei unterschiedlichen Dekaden 
vollkommen unterschiedlich auswirken. Noch schlimmer wirkt sich dies 
jedoch bei der Huckepackplatine aus. Genau aus diesem Grund hatte ich 
genannte Tabelle für unsere Hardware erstellt.
Um maximales SNR zu erzielen und das sollte ja das Ziel der Übung sein, 
sollten die Verstärkungsfaktoren der Huckepackplatine wie von mir 
erstellt umgesetzt werden. Das bedeutet gleichermaßen das eine ADC und 
DAC Kalibrierung in allen Vertikalablenkungen erforderlich ist. Jetzt 
erklärt sich auch, warum die "Kalibrationsroutine" so kurz ist. Zum 
Vergleich, bei dem Oszi bei mir auf Arbeit dauert die komplette 
Kalibration (Signalpfadkompensation) 10min.
In welche Dekade wird derzeit eigentlich die Kalibration durchgeführt? 
Bei 50mV/20mV/10mV oder bei 5V/2V/1V?
Im Hinblick auf Osoz sollten wir diesen Fehler nicht noch einmal so 
umsetzen.

branadic

[Blue F. (blueflash)]

Ok hier die 5.2 mit dem neuen Turboloader von Jörg incl. angepasster 
Ladelänge.

Weiterhin für Luc jetzt abschaltbare QM-Cursor (Display Setup)

Die Badewanne ruft...

Hayo

[ZwoCa (Gast)]

Hallo Hayo,
habe gerade geflasht, dabei ist mir noch ein kleiner, nicht wirklich 
störender Fehler aufgefallen:
Direkt nach Anschalten des Oszis wird der Drehregler (der mit dem Pfeil 
im Uhrzeigersinn) beleuchtet, obwohl man sich ja im Utility-Menü 
befindet, wo man nichts mit diesem Regler auswählen kann.

Gruß
ZwoCa

[Jochen R. (same2_de)]

Hi all, hallo Branadic!

....Leute, wozu habt ihr euch die
Hardware dann gekauft?

Das habe ich mir auch gedacht u. bin angefangen zu löten!
Zum warm werden Kurts USB-Host; das hat auch ganz gut geklappt u. ich 
bin mutig geworden.

Die Huckepackplatinen sind danach ins Welec(2022A) gewandert, was ich 
als außerordentlich sportliche Übung empfand - allerdings erfolglos.
Beide Kanäle haben in der Mitte des LCDs ihre 0-Linie abgebildet u. das 
wars auch schon, keine Messung möglich in keinem Bereich.
Fehler konnte ich auch keine entdecken, also erfolgte der Rückbau, 
schade eigentlich.

Erfahrungen anderer Huckepack-Besitzer würden mich an dieser Stelle aber 
auch interessieren - vielleicht bin ich ja nicht der einzige bei dem es 
nicht geklappt hat ;-)

Jochen

[Rainer W. (rawi)]

Hayo W. schrieb:
> Ok hier die 5.2 mit dem neuen Turboloader von Jörg incl. angepasster
> Ladelänge.

Ich bin schwer beeindruckt!
Da hat man ja schon fast Mühe, die Versions-Nr. im Startbildschirm zu 
erfassen. Bei mir landet das Scope (W2024A) nach einem Reset nicht fest 
im Utility-Menü.

Gruß
Rainer

[Luc (Gast)]

Hi Hayo, Branadic, Jörg H., Kurt Bohnen and guys all!

Hayo W. schrieb:
>Weiterhin für Luc jetzt abschaltbare QM-Cursor (Display Setup)
Oh man, Hayo you are really too fast!: thank You so much Hayo!
It is incredible, as always I am speechless: RESPECT!!!!!!!
Hayo, as speed You can compete with "Turbolader" implementation designed 
by Jorg H., both are fast, really much fast!
Congratulations to both: RESPECT!!!!!!!

branadic schrieb:
>Nachdem sich bisher noch immer niemand anderes zu den besagten Problemen
>geäußert hat gehe ich davon aus, dass nach wie vor niemand die
>Huckepackplatine ins Welec gebaut hat? Leute, wozu habt ihr euch die
>Hardware dann gekauft?
Really very sorry branadic, currently I can not help.
I bought the material from Kurt Bohnen (both Huckepackplatine and 
Vinculum) but I have not had time to assemble it.
I will do it as soon as possible.
Anyway, congratulations and thanks for your valuable contribution 
branadic: RESPECT!!!!!!!

Vielen Dank an alle!!!!!!!

Mit freundlichen Grüßen,

Luc

[Blue F. (blueflash)]

ZwoCa schrieb:
> Hallo Hayo,
> habe gerade geflasht, dabei ist mir noch ein kleiner, nicht wirklich
> störender Fehler aufgefallen:
> Direkt nach Anschalten des Oszis wird der Drehregler (der mit dem Pfeil
> im Uhrzeigersinn) beleuchtet, obwohl man sich ja im Utility-Menü
> befindet, wo man nichts mit diesem Regler auswählen kann.

Den Fehler kann ich leider nicht reproduzieren. Hast Du es mal mit 
Default Setup probiert, so wie in der Anleitung empfohlen?

Hayo

[Blue F. (blueflash)]

Wer an der Firmware selbst herumschrauben möchte sollte sich das 
aktualisierte SDK runterladen, in dem die Neuerungen von Jörg mit 
eingearbeitet sind (makefile, script etc.) und die neuen delay() 
Funktionen enthalten sind.

http://heanet.dl.sourceforge.net/project/welecw2000a/Development/SDK_BlueFlash_Build.zip

Gruß Hayo

[ZwoCa (Gast)]

Hallo Hayo,
ja habe ich gemacht. Schalte ich das Gerät ein bin ich immer direkt im 
Utility-Menü. Der Pfeil leuchtet.
Gehe ich in ein anderes Menü und wieder zurück zu Utility, dann ist er 
nicht beleuchtet, aber wenn ich dann nochmal das Default Setup lade oder 
das Gerät neu starte leuchtet er wieder.

Gruß
ZwoCa

[Blue F. (blueflash)]

Habs nochmal ausprobiert, Du hast recht, die LED wird nicht richtig 
gesetzt. Wird korrigiert, danke.

Hayo

[Blue F. (blueflash)]

Ok hier ist auch schon die Korrektur!

Bin dann mal weg zum Training und....Ihr wißt es natürlich....beim
Griechen :-)

Hayo

[Luc (Gast)]

Guten Abend Jörg H., und alle!

Jörg H. schrieb:
>Anbei daher hier nun eine Firmwareversion mit dem schnellen Loader
For its DSO series WaveAce, LeCroy claim fast power up under 10 seconds.
Now Welec DSO series W20xx are rated to start up themselves under 5 
seconds, half of WaveAce!
Thank You very much Jörg H., RESPECT!!!!!!!

Vielen Dank!!!!!!!

Mit freundlichen Grüßen,

Luc

[Luc (Gast)]

Guten Abend Hayo, und alle!

@Hayo.
Thank You very much for the new 1.2.BF.5.2C2 firmware's release!
I tried it and works like a charm.
Really great job: RESPECT!!!!!!!
I think now the DSO is very useful and fun to use!

Vielen Dank!!!!!!!

Mit freundlichen Grüßen,

Luc

[Blue F. (blueflash)]

So nach einigen Schwierigkeiten habe ich die Cygwin Umgebung auch 
angepasst an das neue Build. Wer also unter Windows selbst basteln 
möchte sollte sich diese hier runterladen:

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

Hayo

[Charly B. (charly)]

moin moin Hayo & Co.

nach dem verstellen des Triggerlevel, kurz bevor die Hilfslinie
verschwindet bleibt alles f. kurze Zeit stehen, koennt ihr das mal
pruefen ?, oder ist das nur bei mir so ?

vlG
Charly

[Blue F. (blueflash)]

Moin,

das ist korrekt, das liegt daran das der neue Triggerlevel ins Flash 
geschrieben wird. Der Flashschreibvorgang braucht immer einen kurzen 
Augenblick weil erst der ganze Sektor gelöscht und dann neu beschrieben 
werden muß.

Ich arbeite gerade im Rahmen der neuen Hardwaretreiber an einer 
Optimierung der Schreibgeschwindigkeit.

Gruß Hayo

[Johannes S. (demofreak)]

Hayo W. schrieb:
> das ist korrekt, das liegt daran das der neue Triggerlevel ins Flash
> geschrieben wird. Der Flashschreibvorgang braucht immer einen kurzen

wird eigentlich jede Bedienung des Geräts sofort ins Flash geschrieben? 
Wenn ja, ist das nicht der Lebenszeit des Flashs wenig zuträglich? Oder 
ist dort genug Platz, dass redundant gespeichert und fehlerhafte Zellen 
weggemittelt werden können?

[Blue F. (blueflash)]

Die Frage wird öfters mal gestellt, daher hier eine etwas ausführlichere 
Antwort.

Johannes S. schrieb:

> wird eigentlich jede Bedienung des Geräts sofort ins Flash geschrieben?
Nicht alle aber die wichtigsten, damit nach einem Neustart alles so ist 
wie vorher.

> Wenn ja, ist das nicht der Lebenszeit des Flashs wenig zuträglich? Oder
> ist dort genug Platz, dass redundant gespeichert und fehlerhafte Zellen
> weggemittelt werden können?

Eine solch aufwändige Sektorverwaltung ist bei uns  nicht notwendig, 
hier ein kleines Rechenbeispiel:

Der Hersteller garantiert eine Million Löschzyclen pro Sektor. Wenn Du 
das ganze Jahr lang das Gerät jeden Tag benutzt und dabei jeden Tag 100 
mal die Einstellungen änderst und ins Flash schreibst, bist Du nach 27 
Jahren immer noch nicht am spezifzierten Limit.

Erinnere mich in 27 Jahren daran, dass ich die Konfiguration in einen 
anderen Sektor schreibe...

Hayo

[Charly B. (charly)]

Danke Hayo f. die Erklaerung, Termin zur errinerung alle
27 Jahre hab ich gestzt :)
( i hoffe i erreich dich dann direkt & muss dich nitt
wieder beim Griechen suchen )

vlG
Charly

[Blue F. (blueflash)]

Das kann ich natürlich auf keinen Fall ausschließen ;-)

Was aber wahrscheinlicher ist, das ist das Deine Drehregler und 
Druckknöpfe bis dahin bei so häufiger Benutzung schon längst das 
Zeitliche gesegnet haben.

Hayo

[Sandro (Gast)]

Hi dso team,
also I checked last firmware and works very well.Enclosed a screenshot 
of a video signal,trigger
is stable ,better in normal trigger than video itself,may be cause there 
isn't a hardware filter at the input.
Only the sin interpolation like the other scope would be a 'cherry on 
the pie'. I  confirm some features are available only on our DSO.
Thanks Hayo,Jorg and Luc for fast response.
regards,
Sandro

[Mike (Gast)]

Hallo!

Ich bin ein ziemlicher Neuling was Oszis betrifft, habe aber ein 
Welec-Gerät mit eurer Firmware vor mir, wo ich meine ersten Erfahrungen 
sammeln darf. Ich hab nun etwas rumgespielt und dabei sind einige Fragen 
zur Bedienung, im speziellen zum Trigger aufgetaucht, die ihr mir 
vielleicht beantworten könnt. Mein "Testsignal" für meine Versuche ist 
die TX-Leitung einer RS232-Schnittstelle, über die im 
1-Sekunden-Intervall ein Zeichen geschickt wird.

Frage 1: Trigger im "Normal-Mode": Auf die steigende Flanke des 
Startbits wird immer zuverlässig getriggert, aber warum kann ich durch 
das aufgezeichnete Signal nicht scrollen?

Frage 2: Trigger im "Auto" oder im "Kombi-Mode": Auf die steigende 
Flanke des Startbits wird nicht getriggert, nur wenn ich einen 
"Single-Shot" mache, bekomme ich auch ein stehendes Bild, durch das ich 
dann erfreulicherweise auch scrollen kann. Warum bekomme ich nur bei 
einem Single-Shot ein stehendes Bild?

Vielen Dank für euere Antworten!

Gruß
Mike

[Blue F. (blueflash)]

Hallo Mike,

willkommen in der Gemeinde. Was ist es denn geworden (12er, 14er, 22iger 
oder gar ein 24iger)?

Bist Du ein Bastelwilliger oder eher ein normaler Benutzer der die Nase 
voll hatte von der originalen Firmware?

Für den ersten Fall sei Dir noch der Hardwarethread empfohlen.

http://www.mikrocontroller.net/topic/goto_post/2499418

Zu Deinen Fragen:

Dein Signal hat mit einer Periode von 1 Sekunde den quasi Status eines 
einzelnen Ereignis. Dafür sind Auto-Trigger und Combi-Trigger nicht 
geeignet, da diese nach bestimmten Timeouts einen künstlichen Trigger 
erzwingen. Dadurch wird Dein "Einzelereignis" quasi verschluckt.

Das einzige was da hilft wie Du schon gemerkt hast ist der Normaltrigger 
weil dieser bis in alle Ewigkeit wartet bis Dein Ereignis auftritt und 
danach auch wieder so lange stehen bleibt bis das nächste Ereignis 
kommt. Nachteil - Du kannst nicht scrollen, da er ja immer noch wartet 
und daher die weitere Bildschirmausgabe blockiert.

Lösung: Du hast es ja schon rausgefunden - der Single Shot. Was macht 
der eigentlich? Nun der schaltet "zwangsweise" in den 
Normal-Triggermodus und wartet auf das Ereignis. Danach bricht er aber 
die weitere Acquisition ab und gibt die Bildschirmausgabe frei, weswegen 
Du dann auch scrollen kannst.

Hoffe das war einigermaßen hilfreich und nicht zu umständlich erklärt.

Gruß Hayo

[Mike (Gast)]

Hallo Hayo!

Vielen Dank für die ausführliche Antwort - jetzt ist mir einiges klarer! 
Ich nenne ein W2022A mein Eigen. Prinzipiell bin ich auch bastelfreudig, 
aber im Moment bin ich noch damit beschäftigt, mich mit der generellen 
Funktionsweise des Oszis vertraut zu machen - dann schauen wir mal 
weiter... :o)

Danke und Gruß
Mike

[Blue F. (blueflash)]

Ein Solches (2022A) besitze ich auch. Wie Du beim Testen feststellen 
wirst, ist der Trigger eines unserer Sorgenkinder. Leider funktioniert 
nur der Flankentrigger recht zuverlässig.

Der Pulsweitentrigger ist hardwareseitig (FPGA) blöderweise schlecht 
implementiert und läßt sich nicht korrigieren, hier arbeite ich an einer 
Softwarelösung (so wie der Combi-Trigger ja auch).

Der externe Trigger hat ebenfalls ein Hardwareproblem, welches sich aber 
durch Auswechseln einiger weniger Bauteile leicht beheben läßt. 
Beschreibung findet sich im Hardwarethread.

Hayo

[Luc (Gast)]

Hayo W. schrieb:
>Der Pulsweitentrigger ist hardwareseitig (FPGA) blöderweise schlecht
>implementiert und läßt sich nicht korrigieren, hier arbeite ich an einer
>Softwarelösung (so wie der Combi-Trigger ja auch).
Hayo, this is really a very good news, thank you!
For me COMBI trigger works fine, however any improvement in our 
oscilloscope is always well come, so thank you again Hayo for the the 
effort also because it not be easy to implement, really a hard job!

Hayo W. schrieb:
>Der externe Trigger hat ebenfalls ein Hardwareproblem, welches sich aber
>durch Auswechseln einiger weniger Bauteile leicht beheben läßt.
>Beschreibung findet sich im Hardwarethread.
Hayo, you have done well to remember it!
I implemented the modify and I am very pleased, so many thanks to Jürgen 
who had the intuition and Jörg H. who improved it adding also a fix for 
the LINE trigger and course to you Hayo who instrumentally tested the 
changes and provided some screen shots: Jürgen, Jörg H., Hayo and all 
who are involved in the Welec project, RESPECT!!!
The modify is easy, simply change few components, swap two resistor and 
enjoy with a better DSO!
Follow the Hayo's advice and take a look at the Hardwarethread, you will 
not regret! ;-)
And while you're at Hardwarethread, my advice is least to implement 
changes in the two front end preamp input's line resistors from 0ohm 1% 
x 2 pieces case 0402 to 24,9ohm 1% x 2 pieces case 0402 and replace the 
MAXIM 1121 termination's impedance between ADC's pin 8 and 9 from 
original 150Kohm value case 0402 to the new 150ohm value case 0402, for 
each channel.
This modify improve both the linearity bandwidth and the noise and it is 
branadic's work who with collaboration of WMarton, Jörg H., Jürgen, Kurt 
Bohnen, Bruno We, alex008, Michael D., Guido and Michael H. studied the 
matter and finally provided a simple, easy and powerfull solution! 
(please, apologize me if I am forget somebody  related to this matter).
Also this modify is not so much difficult to implement and it is highly 
recommended expecially if you do not have Pickaback New Input Stage's 
board.
Pickaback is a new input stage's board for the Welec DSO's, it was 
designed by branadic and distributed by Kurt Bohnen and it is the state 
of the art for the Welec DSO's hardware improvement!
So, branadic, WMarton, Jörg H., Jürgen, Kurt Bohnen, Bruno We, alex008, 
Michael D., Guido and Michael H: RESPECT!!!
As always Hayo is right, so please go to take a look at the 
Hardwarethread, you will also find Vinculum by Kurt Bohnen! ;-)

@Sandro
My contribution to the welec project it is null, the real stars are the 
ones I listed, hoping not to have forgotten anyone, apologize me in the 
case.
Thank you to all!

Vielen Dank!!!!!!!

Mit freundlichen Grüßen,

Luc

[Björn F. (modes)]

Hallo Hayo,

ich habe mir das wegschreiben der Config ins Flash mal angesehen.

Das kurze "stottern" des Oszis beim Sichern der Config wird ja nicht vom 
Schreiben, sondern primär vom Löschen des Sektors im Flash verursacht. 
Die Config ist (aktuell) 1200byte groß, der Sektor ist 64K groß. Es ist 
doch also eigentlich nicht nötig, den Sektor vor jedem Schreibvorgang zu 
löschen, sondern nur alle 50 Speichervorgänge.

Ich habe das ganze mal auf meinen Scope eingebaut, Patch hänge ich hier 
mal an. Das Scope stottert damit nicht mehr nach jeder Änderung und 
fühlt sich so für mich etwas "runder" an. Und obwohl der Flash auch so 
fast ewig halten sollte, wird er mit dieser Methode noch ein wenig 
geschont.

Was meinst Du dazu? Hab ich was übersehen?

Gruß,
Björn

[Blue F. (blueflash)]

Hi Björn,

sorry - bin momentan etwas busy, daher die späte Antwort.


Björn F. schrieb:

> Das kurze "stottern" des Oszis beim Sichern der Config wird ja nicht vom
> Schreiben, sondern primär vom Löschen des Sektors im Flash verursacht.
Das ist richtig.

> Die Config ist (aktuell) 1200byte groß, der Sektor ist 64K groß. Es ist
> doch also eigentlich nicht nötig, den Sektor vor jedem Schreibvorgang zu
> löschen, sondern nur alle 50 Speichervorgänge.
Wenn ich Dein Coding richtig interpretiere (hab nur mal kurz 
drübergeschaut) dann springst Du in 1200byte Schritten durch den Sektor 
und löschst den Sektor erst wenn Du wieder von vorn anfängst.


> Und obwohl der Flash auch so fast ewig halten sollte, wird
> er mit dieser Methode noch ein wenig geschont.
Ja, geschätzte Lebensdauer 50 x 27 = 1350 Jahre -> erinnere mich also im 
Jahr 3362 daran, dass ich einen anderen Sektor verwende...


> Was meinst Du dazu? Hab ich was übersehen?
Das scheint mir eine gute Idee zu sein. Ich werde mir das mal ansehen 
und etwas testen. Wenn es da keine Probleme gibt werde ich das auf jeden 
Fall übernehmen. Allerdings werde ich wohl den Speicherbereich nach 
etwas vergrößern, damit wir noch Reserve für weitere Variablen haben. 
Auch für die neue OSOZ-Version dürfte das ein interessanter Ansatz sein.

Gruß Hayo

[Jörg H. (idc-dragon)]

Zum Thema Flash kann ich auch noch was sagen, bin mit meinem Bootloader 
gerade dran und finde so zwei-drei Sachen raus:

In zumindest meinem Gerät ist kein Flash-Chip von AMD (=Spansion), wie's 
im Wiki steht, sondern von Macronix. Das ist ein Unterschied, ich bin ja 
halb wahnsinnig geworden: Beim AMD-Chip ist es möglich, während des 
Löschens eines Sektors von anderen Teilen des Chips zu lesen, steht 
explizit im Datenblatt. Das wollte ich ausnutzen, um in der 
"Zwangspause" schon mal eine Prüfsumme mit den rückgelesenen Daten aus 
dem Vorgängersektor zu aktualisieren, um etwas Zeit zu sparen. Klappte 
nachhaltig nicht. Bis ich denn mal auf die Idee kam, meinen Chip in 
Augenschein zu nehmen...

Also das Datenblatt von Macronix gesucht. Dort schreiben sie nichts, ob 
Lesen während des Sektorlöschens möglich ist.

Was ferner im Datenblatt steht: Der Chip verkraftet deutlich weniger 
Schreibzugriffe als der von AMD, schon nach 100.000 Zyklen müssen wir 
Hayo beim Griechen rausziehen.

Ich baue das bei meinen Gerätschaften "immer" so, daß ich persistente 
Einstellungen nicht sofort ins (in meinem Fall) EEPROM schreibe, sondern 
erst nach einem Timeout, was durch jede Einstellung wieder hochgesetzt 
wird. So vermeide ich, das laufend neue Zwischenwerte geschrieben 
werden, und verlege das Schreiben in Ruhepausen wenn der Benutzer gerade 
nicht wild dranrumdreht. Bei Osoz täte ich das auch wieder so machen. 
Dort haben wir Softwaretimer, die quasi nichts kosten.

Noch eine Beobachtung:
Der GERMSloader schreibt ein Byte zu wenig ins Flash, das letzte kommt 
nicht an. Ich habe noch nicht probiert, ob das beim RAM-Upload auch so 
ist. Kann durchaus zu unerklärlichen Phänomänen führen, der Linker hängt 
ja keine Füllbytes an, hinten stehen die konstanten Daten.
(Mit meinem neuen Uploader hat sich das Problem aber demnächst 
erledigt.)

FYI, ich bin derzeit bei 23 Sekunden für das Flashen der Hayo-Firmware. 
Details siehe Osoz-Thread:
Beitrag "made from scratch Firmware für Wittig/Welec Oszilloskop W20xxA"

Jörg

[egberto (Gast)]

Hallo Jörg,

richtig flashen oder doch eher "rammen"??

Viele Grüße,

egberto

[Jörg H. (idc-dragon)]

egberto schrieb:
> richtig flashen oder doch eher "rammen"??

Schon richtig ins Flash, daran arbeite ich gerade. (In's RAM geht's ja 
in 16 Sekunden.)

Jörg

[egberto (Gast)]

o-ha tolle Sache.....für die Entwicklung bestimmt ein riesen Fortschritt 
(gerade zum testen).

Wie lange dauerten das packen (auf einer normalen Maschine)?

Die Zeit muss man ja eigentlich noch dazu rechnen.

Viele Grüße,

egberto

[Jörg H. (idc-dragon)]

egberto schrieb:
> Wie lange dauerten das packen (auf einer normalen Maschine)?

Definiere "normalen Maschine"...
Auf meinem gut 2 Jahre alten Arbeitspferd Core2 Duo 3GHz gerade gemessen 
0,4 Sekunden. (Wobei ihm das "Duo" hierfür nichts nützt)

Kannst du also gerne mit dazurechnen. ;-)
Mit Abstrichen bei der Kompressionsrate geht's auch deutlich schneller 
(z.B. auf mittlere Einstellung nur 4% größer, aber 4* schneller), das 
war jetzt die Maximaleinstellung.

Jörg

[egberto (Gast)]

ok, das ist wirklich nichts (hätte ja sein können, das das eine halbe 
Stunde dauert ;-))

Ich freue mich schon auf die erste OSOZ Version für den Endnutzer (also 
solche wie mich) zum testen.

Viel Erfolg und danke für die fleißige Arbeit.

egberto

[Luc (Gast)]

Guten Abend an alle.

@Hayo
Only for reference and example, because today I have played around with 
my logic analyzer.
So here are measurements on 3,3V LVTTL outputs when they are displayed 
on a Logic Analyzer and on a W2022A with the LVTTL 3,3V filter switched 
on.
As I already wrote time ago it's really very impressive, the W2022A 
works damn fine!
So if I am not wrong ultimately the W20xxA DSO's are a bit MSO.
Am I wrong?
I believe that I am right or at least it is not so wrong. ;-)
Thank You very much Hayo, You are great: RESPECT!!!!!!!

Vielen Dank!

Mit freundlichen Grüßen,

Luc

[Blue F. (blueflash)]

Hi Luc,

nice Screenshots. Unfortunately I had not the time to test the logic 
mode of our "MSO" very well. Due to this I'm glad to hear that it seems 
to work well.

In the moment I'm a little bit spare of time - that is the reason why 
You don't hear so much from me.

But don't worry, I'm still active on our project and I have some new 
Ideas which are growing in my head.

Also there  is the OSOZ project which I want to support further.

Greetings to all

Hayo

[Blue F. (blueflash)]

Hayo W. schrieb:
> In the moment I'm a little bit spare of time...

meant short of time...    :-)

Hayo

[R.P. (Gast)]

Hallo,

habe vor kurzem ein W2024 ersteigert und die aktuelle Software 
eingespielt. Mit den vorhanden Dokus hat das prima funktioniert.

Ich möchte mich bei allen Beteiligten herzlich bedanken, die das so 
ermöglicht haben.

Gruß  Ralf

[Blue F. (blueflash)]

Gerne doch. Und hier kommt auch schon Nachschlag. Die BF.5.3.

Neben einigen Fixes bringt sie hauptsächlich das Config Slot Writing von 
Björn, das wirklich gut funktioniert. Ich habe das nochmal etwas 
überarbeitet aber im Prinzip ist es genau so wie Björn es vorgeschlagen 
hat.

Ein wesentlicher Vorteil ist die viel flüssigere Bedienung der 
Timebase-Verstellung und auch einiger anderer Funktionen.

Auch erhältlich hier:

http://sourceforge.net/projects/welecw2000a/files/Open%20Source%20Firmware/1.2.BF.5.x/


Gruß Hayo

[Michael W. (slackman)]

Hallo hayo,
inzwischen sind wir in 2012 (Infoscreen).

Michel

[Blue F. (blueflash)]

Ja aber das (non) copyright ist schon älter...

[Rainer W. (rawi)]

Hayo W. schrieb:
> Gerne doch. Und hier kommt auch schon Nachschlag. Die BF.5.3.

Hallo Hayo und Björn,

ein dickes Lob an euch beide. Der neue Speicheralgorithmus ist ein 
klasse Fortschritt für die Performance bei der Bedienung.

Die andere Idee zur Speicherung in Bedienpausen lohnt es aber vielleicht 
trotzdem noch im Auge zu behalten, d.h. bei Veränderung einer 
Einstellung ein nachtriggerbares (Software-)Monoflop mit einer 
Zeitkonstante von ruhig ein paar zehn Sekunden (nach-)zutriggern und 
erst wenn die Zeit abläuft, die Speicherung anzugestoßen. Einstellungen 
die nur kurz bestehen, sind es eigentlich sowieso nicht wert, im Flash 
abgelegt zu werden.

Gruß und schönen Abend
Rainer

[Jörg H. (idc-dragon)]

Hier ist Hayos neuer Release mit meinem neuen Upload-Verfahren, dem 
Dekompressor. Ramload in 16 Sekunden, Flashen in 18 Sekunden. Bitte mal 
testen, unter Linux habe ich es noch nicht laufenlassen.

Hayo, könntest du auch in dein Makefile einbauen. Siehe Osoz.

Frohes Flashen,
Jörg

[Bernhard M. (boregard)]

Hmmm,

bei mir gehts unter Linux (Debian) nicht,

Ramloader:

bernhard@cork:$ ./ramloader.sh 
loading decompressor to RAM...

GERMSloader.pl Ver 1.1.2

*** No Warranty
***
*** This program is distributed in the hope that it will be useful,
*** but is provided AS IS with ABSOLUTELY NO WARRANTY;
*** The entire risk as to the quality and performance
*** of the program is with you. Should the program prove defective,
*** you assume the cost of all necessary servicing, repair or correction.
*** In no event will any of the developers, or any other party,
*** be liable to anyone for damages arising out of the use or inability
*** to use the program.

Writing line 000032 of 000032: S8 detected, end of GERMS transmission.
Successfully wrote firmware in 1 seconds!                    
Please reboot DSO if not already done.
READY!
Thanks for all the fish.
upload finshed.
loading compressed application...

GERMSloader.pl Ver 1.1.2

*** No Warranty
***
*** This program is distributed in the hope that it will be useful,
*** but is provided AS IS with ABSOLUTELY NO WARRANTY;
*** The entire risk as to the quality and performance
*** of the program is with you. Should the program prove defective,
*** you assume the cost of all necessary servicing, repair or correction.
*** In no event will any of the developers, or any other party,
*** be liable to anyone for damages arising out of the use or inability
*** to use the program.

Writing chunk 10 of 10
Error: Timeout while reading response from DSO!
Firmware update was NOT successful!
Please fix the connection issue and retry!

Flashloader genauso:

bernhard@cork:$ ./flashloader.sh 
loading decompressor to RAM...

GERMSloader.pl Ver 1.1.2

*** No Warranty
***
*** This program is distributed in the hope that it will be useful,
*** but is provided AS IS with ABSOLUTELY NO WARRANTY;
*** The entire risk as to the quality and performance
*** of the program is with you. Should the program prove defective,
*** you assume the cost of all necessary servicing, repair or correction.
*** In no event will any of the developers, or any other party,
*** be liable to anyone for damages arising out of the use or inability
*** to use the program.

Writing line 000040 of 000040: S8 detected, end of GERMS transmission.
Successfully wrote firmware in 1 seconds!                    
Please reboot DSO if not already done.
READY!
Thanks for all the fish.
upload finished.
flashing compressed application...

GERMSloader.pl Ver 1.1.2

*** No Warranty
***
*** This program is distributed in the hope that it will be useful,
*** but is provided AS IS with ABSOLUTELY NO WARRANTY;
*** The entire risk as to the quality and performance
*** of the program is with you. Should the program prove defective,
*** you assume the cost of all necessary servicing, repair or correction.
*** In no event will any of the developers, or any other party,
*** be liable to anyone for damages arising out of the use or inability
*** to use the program.

Writing chunk 10 of 10
Error: Timeout while reading response from DSO!
Firmware update was NOT successful!
Please fix the connection issue and retry!

Gruß,
Bernhard

[Johannes S. (demofreak)]

Hat es denn wirklich nicht geklappt, oder bringt dich nur die 
Fehlermeldung durcheinander?
Jörg hat das Skript nur um das Pushen der komprimierten Daten erweitert, 
ich habe aber wegen akutem Zeitmangel noch nicht "aufgeräumt" darin, 
oder anders gesagt: es geht vermutlich trotzdem und sagt nur, dass es 
nicht klappt.

[Bernhard M. (boregard)]

Hallo,

es hat wirklich nicht geklappt.
Nach dem Upload bleibt das Oszilloskop "hängen", nach einem Neustart 
läuft es auch nicht mehr (Bildschirm bleibt "schwarz" und Run/Stop 
leuchtet).

Gruß,
Bernhard

[Jörg H. (idc-dragon)]

Es sollte keine Fehlermeldung kommen. Der Dekompressor sendet nach 
Abschluß seiner Tätigkeit ein einzelnes Zeichen, eine Ziffer. 0 für 
Erfolg, andere Fehlercodes für Mißerfolg. Das Perl-Script wartet darauf, 
bei Bernhard anscheinend vergeblich.

Bei der Flash-Variante kann es worst-case ein bischen dauern, bis die 
Bestätigung kommt, je nachdem wie ausgelutscht das Flash schon ist. 
Eventuell muß das Timeout im Script verlängert werden. Bei Ramload kommt 
es aber sofort, da darf es kein Problem geben.

Ich habe es (erfolgreich) mit Cygwin getestet, weil das Oszi an mein 
Windows-Notebook angeschlossen ist. Linux gibt's nur im Keller...  ;-)

Was man auch noch ausprobieren könnte: Vielleicht ist dein Rechner so 
viel schneller als meiner, und sendet die Binärdatei bevor der Loader 
bereit ist. Mal ein "sleep 1" zwischen die beiden Perl-Aufrufe 
probieren?

Jörg

[Jörg H. (idc-dragon)]

Jörg H. schrieb:
> Ich habe es (erfolgreich) mit Cygwin getestet,

Edit: Blödsinn, nicht Cygwin sondern ganz normal Windows, das Batchfile 
und Perl von ActiveState.

Das kaum vorhandene Protokoll zwischen Dekompressor und Script ist 
zugegeben noch ausbaufähig. Im Moment krankt es daran, das ich nichts 
senden kann ohne meinen eigenen Datenempfang zu stören. Sprich, 
Vollduplex klappt nicht. Das muß noch untersucht werden. Sonst könnte 
ich z.B. nach erfolgreich empfangenem Header was sagen oder nach jedem 
geschriebenen Sektor einen Punkt senden.

Jörg

[ZwoCa (Gast)]

Hallo Jörg,
habe deinen Uploader gerade mal getestet.

Funktioniert hier einwandfrei (sowohl die RAM- als auch die 
Flash-Variante), keine Fehlermeldungen und geht wirklich brutal schnell. 
(Windows 7 x64, FTDI USB-zu-seriell-Adapter)

Gruß
ZwoCa

[Bernhard M. (boregard)]

Jörg H. schrieb:
> Was man auch noch ausprobieren könnte: Vielleicht ist dein Rechner so
> viel schneller als meiner, und sendet die Binärdatei bevor der Loader
> bereit ist. Mal ein "sleep 1" zwischen die beiden Perl-Aufrufe
> probieren?
>
> Jörg

Hm, ein sleep 5 hilft auch nichts...

[Jörg H. (idc-dragon)]

Dann ist unter Linux wohl noch was im Argen. Hab' ich ja auch nicht 
getestet, und laut Definition Softwareentwicklung ist alles was nicht 
getestet ist kaputt...  ;-)

Mit vereinten Kräften werden wir das aber rausfinden, denke ich.

Derweil fröhliches Flashen an die Windows-User,
Jörg

[Bernhard M. (boregard)]

Hi,

es liegt an der Gewschwindigkeit und vielleicht an der 
chunksize...entweder das Oszilloskop, oder die serielle (USB-V24) wird 
überfahren, vermutlich die serielle Schnittstelle (getestet mit 2 
verschiedenen Adaptern, einen "Billigwandler" und einem FTDI).

mit

  $count = 100; # how many fractions
  my $filesize = -s $filename;
  my $chunk = ($filesize / $count) + 1;
  open($filehnd, $filename) or die "Error: File '$filename' not found.\n";
  binmode $filehnd;
  my $buffer;

  printf "File %s is %u Bytes big, chunk-size is %u\n", $filename, $filesize, $chunk;

  while (read ($filehnd, $buffer, $chunk)) # exit if read fails
  {
    $cur++;
    printf "Writing chunk %u of %u\r", $cur, $count;
    $serial->write($buffer);
    select(undef, undef, undef, 0.6);
  }
  close($filehnd);

  # waiting for response: a single character when done
  printf "Wrote everything, waiting for response\n";

geht es, ist aber wiedr langsam.
Leider ist mein Perl nicht so gut, deshalb geht das basteln langsam; in 
C wüsste das vorgehen, in Perl muß ich es mir ergooglen...

Gruß,
Bernhard

[Jörg H. (idc-dragon)]

Interessant. Das Oszilloskop wird auf keinen Fall überfahren, empfängt 
im Interrupt, hat Puffer ohne Ende, das ist nicht das Problem. (Unter 
Windows messe ich auch einen lückenlosen Stream der Bytes.)

Also die serielle unter Linux. Windows puffert da anscheinend mehr. Ich 
hätte erwartet, daß das "write" ggf. blockiert bis seine Daten raus oder 
zumindest in einem Puffer sind.

Jörg

[Johannes S. (demofreak)]

Bernhard M. schrieb:
> Leider ist mein Perl nicht so gut, deshalb geht das basteln langsam; in
> C wüsste das vorgehen, in Perl muß ich es mir ergooglen...

Ehe ich mir erst mühsam heraussuchen muss, was du da änderst: kannst du 
mir ein diff gegen das Skript von Jörg schicken, damit ich es in mein 
Repository reinbekomme? Ich bin nämlich gerade dabei, das grundlegend 
aufzuräumen (entweder so, dass die Binärdaten gleich mit dem 
Dekompressor zusammen im selben File stehen, aber auf jeden Fall so, das 
der Skript nur einmal aufgerufen werden muss, damit es auch ohne das 
umgebende Shellscript funktioniert) und würde dabei gleich deine 
Erkenntnisse einbauen wollen.

[Bernhard M. (boregard)]

Johannes S. schrieb:
> Bernhard M. schrieb:
>> Leider ist mein Perl nicht so gut, deshalb geht das basteln langsam; in
>> C wüsste das vorgehen, in Perl muß ich es mir ergooglen...
>
> Ehe ich mir erst mühsam heraussuchen muss, was du da änderst: kannst du
> mir ein diff gegen das Skript von Jörg schicken, damit ich es in mein
> Repository reinbekomme? Ich bin nämlich gerade dabei, das grundlegend
> aufzuräumen (entweder so, dass die Binärdaten gleich mit dem
> Dekompressor zusammen im selben File stehen, aber auf jeden Fall so, das
> der Skript nur einmal aufgerufen werden muss, damit es auch ohne das
> umgebende Shellscript funktioniert) und würde dabei gleich deine
> Erkenntnisse einbauen wollen.

Mach ich, wenn es geht.
Ich habe den Verdacht, daß "non-blocking" gesendet wird...

Gruß,
Bernhard

[Johannes S. (demofreak)]

Bernhard M. schrieb:
> Mach ich, wenn es geht.
> Ich habe den Verdacht, daß "non-blocking" gesendet wird...

Ja, das tut es, allerdings war das nicht das Problem.
Ich glaube, ich hab's ;-)

Melde mich dann gleich, wenn es geht.

[Johannes S. (demofreak)]

Also, es scheint eine Verbindung von zwei Problemen zu sein:

- das serial->write blockt unter Linux nicht (stünde auch in der Doku, 
aber sowas lese ich ja nur, wenn's brennt :-D)
- die Puffergröße ist unter POSIX fest auf 4096, das ist für Jörgs 
Chunks zu klein

Ich berechne jetzt die Chunkgröße aus der Dateigröße und blocke unter 
Linux "zu Fuß", so geht es zumindestens bei mir, und das auch sehr 
akzeptabel schnell.

Kann das bitte a) mal jemand unter Windows testen, ob ich das jetzt 
nicht kaputtgemacht habe, und b) unter Linux einer bestätigen, dass es 
da jetzt auch bei ihm geht?

Wenn das so fluppt, werde ich mich ans Zusammenfassen der 
Schreibfunktion machen.

[Bernhard M. (boregard)]

Bei mir jetzt damit:

bernhard@cork:$ ./ramloader.sh 
loading decompressor to RAM...

GERMSloader.pl Ver 1.2.0

*** No Warranty
***
*** This program is distributed in the hope that it will be useful,
*** but is provided AS IS with ABSOLUTELY NO WARRANTY;
*** The entire risk as to the quality and performance
*** of the program is with you. Should the program prove defective,
*** you assume the cost of all necessary servicing, repair or correction.
*** In no event will any of the developers, or any other party,
*** be liable to anyone for damages arising out of the use or inability
*** to use the program.

Writing line 000032 of 000032: S8 detected, end of GERMS transmission.
Successfully wrote firmware in 0.4 seconds!                    
Please reboot DSO if not already done.
READY!
Thanks for all the fish.
upload finshed.
loading compressed application...

GERMSloader.pl Ver 1.2.0

*** No Warranty
***
*** This program is distributed in the hope that it will be useful,
*** but is provided AS IS with ABSOLUTELY NO WARRANTY;
*** The entire risk as to the quality and performance
*** of the program is with you. Should the program prove defective,
*** you assume the cost of all necessary servicing, repair or correction.
*** In no event will any of the developers, or any other party,
*** be liable to anyone for damages arising out of the use or inability
*** to use the program.

Successfully wrote firmware in 14.8 seconds!                    
Please reboot DSO if not already done.
READY!
Thanks for all the fish.
binary upload done.

also voller Erfolg unter Linux!!

Glückwunsch!

[Johannes S. (demofreak)]

Schön. :-)

Dann brauche ich jetzt nur noch den Gegentest unter Windows.

[Bernhard M. (boregard)]

Die:

    $serial->write_drain unless $ostype =~ /Win/;  # waiting for buffer draining, as Linux serial->write doesn't block

hatte ich nicht gefunden, unter C heisst das tcdrain()...

[Jörg H. (idc-dragon)]

Sehr schön, vielen Dank Johannes!
(Ist ja echt spannend hier)

Ich habe es nicht ausprobiert, gucke nur interessiert auf den Code.
Könnte da ein Rundungsproblem sein, oder rechnet Perl immer mit float?

$count = $filesize / $buffersize

Wenn es Integer ist wird count abgerundet, und die Chunks in Folge 
wieder leicht zu groß. Zwei Zeilen tiefer ist auch noch eine +1, die 
sorgte bei mir dafür daß es auch mindestens 10 Chunks werden, kann nun 
raus.

Die Meldung "Please Restart..." könnten wir für meinen Loader 
rausnehmen, der macht das von sich aus (im Erfolgsfall).

Von wegen fusionierte Lösung mit 1*Script:
Finde ich wie gesagt gut. Ich würde es aber bei 2 Dateien belassen, das 
macht das Kompilieren einfacher und schneller. Das in eine Datei zu 
basteln wäre ein Extra-Schritt, den das Perl-Script dann wieder 
rückgängig machen muß.
Ich weiß, ich war vor ein paar Tagen selbst noch anderer Meinung, wollte 
das Komprimat an's Loader-Hexfile hintendran"hexen".

Jörg

[Johannes S. (demofreak)]

Ja, das mit dem Runden ist mir schon aufgefallen, wollte nur sehen, ob 
es prinzipiell geht. Ich mach das dann gleich "heile"...

Zum Thema "Trennen der Dateien": das Zusammenpappen erledigt ja das 
Makefile, da hat man (theoretisch) keinen Stress. Für mich ist es aber 
im Perlskript wiederum einfacher, wenn ich nicht erst mehrere Dateien 
mit einem normierten Endungs- bzw. Dateinamensschema öffnen muss, 
sondern statt dessen an einer festen Markierung den GERMS- vom Binärteil 
trenne. Dann muss sich auch niemand an Benennungsschemata halten, 
sondern der Dateiname kann weiter frei gewählt werden.

[Jörg H. (idc-dragon)]

Johannes S. schrieb:
> Kann das bitte a) mal jemand unter Windows testen, ob ich das jetzt
> nicht kaputtgemacht habe,

Funktioniert noch. Ich habe diese Version jetzt bei Osoz eingecheckt, 
nun ist dort alles funktionsfähig beisammen.

Jörg

[Luc (Gast)]

Guten Sonntag, Hayo, Jörg H., Björn F. und alle!

@Hayo @Björn F.
Right now I am testing the new 1.2.BF.5.3 release.
Seems to me it works great even thanks to introduction of the Björn F.'s 
suggestions.
So Hayo as usual I have to thanks You very much for the free time You 
provided generously to us and for this new great firmware's release, no 
words: RESPECT!!!!!!!
Of course I have also to thanks very much Björn F. for his contribution 
in the firmware's improvement: RESPECT!!!!!!!
In this occasion I have to thanks all people who are involved in the 
Welec Project, thank all You: RESPECT!!!!!!

@Jörg H.
Thank You very much for the FastFlash5.3 firmware version!
It's very impressive and fast, really no words:RESPECT!!!!!!
Jörg H., as usual You prove to be faster than the comic book's superhero 
Flash!
Really You are the master of the Time, you command it and it obeys at 
you!

I take this opportunity to show something about of X-Y rapresentation, 
so I added some pics of ASA (Analog Signature Analysis) or 
current/voltage electronic components' signature shown using vertical 
deflection for current and horizontal deflection for voltage.
In the X-Y mode the Time Base is excluded, the pics show ASA signature 
of some electronics component when they are subjected to a 50Hz's 
sinusoidal voltage and then referred to a 680ohm sense resistor so that 
we have a circle on the screen for 4,7uF and 2,1H and a 45 degree line 
for 680ohm.
ASA's signature shown in the pics are for a 10uF's electrolytic 
capacitor, for a 4,3V zener diode, for 10kohm and 90ohm resistors and 
for a 220Vac's transformer input, even combining components among their.
So the Welec DSO are also a Huntron Tracker clone for sure!
Vielen Dank!

Mit freundlichen Grüßen,

Luc

[Blue F. (blueflash)]

nice pics :-)

[Johannes S. (demofreak)]

So,

ich habe nun den Perl-Flasher mal zusammengefasst, (hoffentlich) 
verbessert und warte jetzt auf Kommentare.

Änderungen:

- man kann alle bisher verwendbaren Modi (Backup, GERMS-Flash, 
UCL-Flash) nunmehr auf einmal ausführen, also gern auch Backup, gleich 
darauf Flash und dann hinterher das komprimierte Binary.

- daher musste leider das Parameterformat etwas geändert werden, das 
serielle Device ist jetzt mit -d anzugeben, eventuelle Start- und 
Endadresse beim Backup mit -s und -e

- alle wichtigen Parameter können direkt im Skript vorverdrahtet und 
dann auf der Befehlszeile weggelassen werden, bisher ist das nur mit dem 
Device so (/dev/ttyUSB0 ist Standard), falls das Anklang findet, lagere 
ich das gern noch in eine Configdatei aus.

Ein Aufruf könnte also z.B. so lauten:

GERMSloader.pl -d COM1 -r Firmware_Backup.flash -s 0x40000 -e 0x7FFFF -w 
dekompressor_flash.germs -b TomCat_flash.ucl

(verwendet COM1, liest erst ein Backup des Bereichs 0x40000-0x7FFFF in 
Firmware_Backup.flash, schreibt dann den Dekompressor und startet ihn, 
und schiebt anschliessend gleich das gepackte Binary hinterher)

oder aber

GERMSloader.pl -w TomCat.ram

(verwendet /dev/ttyUSB0 und schreibt TomCat.ram ins Gerät)

Hoffe, soweit alle Klarheiten beseitigt zu haben. ;-)

/Hannes

[Johannes S. (demofreak)]

Und auf nachdrücklichen Wunsch eines einzelnen Herrn hier noch zwei 
kleine Änderungen:

- die Vorbelegung des seriellen Ports ist jetzt OS-abhängig, COM1 unter 
Win, /dev/ttyUSB0 unter allen anderen
- die Chunksize des UCL-Writers ist jetzt 4096 statt eines etwas krummen 
Wertes, weil es "so schöner aussieht" ;-)


Weitere Ideen sind erwünscht.
Bisher steht noch das Auswerten eines Kommentars 
(#UCL"TomCat_flash.ucl") im Dekompressor-GERMS-File auf der Agenda, 
welcher dann ein automatisches "Chaining" des UCL-Files ermöglicht, man 
will ja schliesslich auf der Befehlszeile so tippfaul als möglich 
sein... ;-)

[Johannes S. (demofreak)]

Johannes S. schrieb:
> Bisher steht noch das Auswerten eines Kommentars
> (#UCL"TomCat_flash.ucl") im Dekompressor-GERMS-File auf der Agenda,

Und weil es gerade so schön war, habe ich das jetzt auch noch 
nachgerüstet.
Wenn ein Kommentar der Form

#UCL"TomCat_ram.ucl"

bzw.

# UCL"TomCat_ram.ucl"

in der GERMS-Datei des Dekompressors gefunden wird, wird die zwischen 
den "" stehende Datei so behandelt, als wäre sie mittels des Parameters 
-b angegeben worden.

/Hannes

[Jörg H. (idc-dragon)]

Gut, danke, habe ich im SVN nachgezogen.

Man könnte deine Ergänzung doch so verallgemeinern, daß generell die 
Parameter auch in der Datei angegeben werden können?
Die Kommandozeile sollte aber Priorität haben, um das übersteuern zu 
können, sonst müßte man im Bedarfsfall ja die Datei ändern.

Jörg

[Johannes S. (demofreak)]

Welche weiteren Parameter stehen so in direktem Zusammenhang mit dem 
GERMS-File, dass sie ebenfalls darin Platz finden sollten, weil sie 
bereits im Buildprozess bekannt sind?

Nein, ich denke, der Rest sollte in ein Configfile ausgelagert werden, 
welches die benutzerdefinierten Parameter wie den Port beherbergt, damit 
man das nur einmal anpassen und nicht jedesmal beim Herunterladen einer 
neuen Firmware in einer Datei rumeditiert werden muss (wie es jetzt mit 
den Shellskripten noch ist). Priorität wäre dann Befehlszeile > 
Configdatei > UCL-Kommentar.

Und das muss ich allerdings jetzt noch anpassen, bisher übersteuert der 
UCL-Kommentar die Befehlszeile.

[Michael D. (mike0815)]

Hallo Hannes,
die Germsloader1.2.0 vom 16.02.2012 funzt einwandfrei mit Profilic
USB- Com-Adapter(COM4), WinXP-SP4
In ca. 16sek ist alles erledigt! Wahnsinn...

Die Germsloader die du danach gepostet hast, laufen nicht. Habe jetzt 
alle getestet! Die DOS-Fenster bleiben gefühlte 500ms offen und gehen 
gleich wieder zu, also keine Chance zum lesen.

Gruß Michael

EDIT: Waren die letzten jetzt nur für die RAM gedacht? Hatte nur die 
Flash getestet.

[Johannes S. (demofreak)]

Michael D. schrieb:
> Die Germsloader die du danach gepostet hast, laufen nicht. Habe jetzt
> alle getestet! Die DOS-Fenster bleiben gefühlte 500ms offen und gehen
> gleich wieder zu, also keine Chance zum lesen.

Klar, denn:

Johannes S. schrieb:
> - daher musste leider das Parameterformat etwas geändert werden, das
> serielle Device ist jetzt mit -d anzugeben, eventuelle Start- und
> Endadresse beim Backup mit -s und -e

und die flashloader.bat bzw. ramloader.bat, welche du da doppelklickst, 
sind bisher noch nicht angepasst auf das geänderte Parameterformat. Das 
wird sicher in einem der nächsten Builds passieren.

Deswegen ist das hehre Ziel, dass diese Shellscripte irgendwann gar 
nicht mehr benötigt werden, um solche Fehlerquellen zu beseitigen.

> EDIT: Waren die letzten jetzt nur für die RAM gedacht? Hatte nur die
> Flash getestet.

Nö, da besteht kein Unterschied.

/Hannes

[Blue F. (blueflash)]

Johannes!

Deine Hilfe wird gebraucht - Linux ist in Not. Das Perlskript 
funktioniert leider nur unter Windows. Unter Linux wird die komprimierte 
Datei nicht eingelesen (siehe auch OSOZ-Thread -> 
Beitrag "Re: made from scratch Firmware für Wittig/Welec Oszilloskop W20xxA")

Kannst Du da helfen?

Gruß Hayo

[Johannes S. (demofreak)]

Siehe den anderen Thread, das hab ich gleich...

/Hannes

[Johannes S. (demofreak)]

So,

das hab ich jetzt mal geklärt. Normalerweise dürften die Shellskripte 
eigentlich gar nicht funktionieren, wenn da DOS line-endings dran sind, 
aber wie auch immer, ich werf die überschüssigen <#13>s jetzt weg.

Ausprobieren, sollte klappen.

/Hannes

[Blue F. (blueflash)]

Ok,

der Hinweis mit den DOS Endings war richtig. Wenn ich die aus den 
Skripten entferne wird die Datei gefunden und gestartet. Hab auch das 
neue Perlskript ausprobiert, damit läuft es auch.

Aber:

Das Update ist nicht erfolgreich. Folgende Meldung:

--- Writing compressed firmware (25457 bytes / 7 chunks of 4096 
bytes)...
Writing chunk 7 of 7 - 100.0% - 3.2 sec / 0 sec left
Error: bad response from DSO!
Error response was: '5'
Firmware update was NOT successful!
done.


So ich teste nochmal unter Windows.

Hayo

[Jörg H. (idc-dragon)]

Fehlercode 5 heißt, die Dekompression hat nicht hingehauen. Die Anzahl 
der dekomprimierten Bytes stimmt nicht mit der Erwartung überein. Könnte 
ein Übertragungsfehler sein.

Dabei fällt mir auf, daß die Ausgabe des Perl-Scripts differenzierter 
sein könnte, z.B.: "bad response" für eine nicht erwartete Antwort 
(Müll), "error response" für einen gültigen Fehlercode.

Jörg

[Blue F. (blueflash)]

So hab noch mal den Gegentest gemacht unter Win XP (gleicher Rechner).

Läuft ohne Probleme und startet die Firmware gleich nach dem Upload.
Was läuft denn da unter Linux schief?

Hayo

[Johannes S. (demofreak)]

Hayo W. schrieb:
> --- Writing compressed firmware (25457 bytes / 7 chunks of 4096
> bytes)...

Hab ich da was nicht mitbekommen? Warum ist das so klein?

Jörg H. schrieb:
> Dabei fällt mir auf, daß die Ausgabe des Perl-Scripts differenzierter
> sein könnte, z.B.: "bad response" für eine nicht erwartete Antwort
> (Müll), "error response" für einen gültigen Fehlercode.

Ja gern, dazu müsste mir der Autor des Dekompressors mal die Errorcodes 
verklickern... :-D

[Johannes S. (demofreak)]

Hayo W. schrieb:
> Läuft ohne Probleme und startet die Firmware gleich nach dem Upload.
> Was läuft denn da unter Linux schief?

Das lässt sich nur herausfinden, indem du mir das gesamte Verzeichnis 
mal herschickst, damit ich mir das anschauen kann. Bei mir klappt unter 
Linux jedenfalls alles bestens, also muss es etwas mit den bei dir 
vorhandenen Dateien zu tun haben.

[Blue F. (blueflash)]

Ok, ich hau das gleich mal als neues Release raus. Ich hatte ohnehin nur 
damit gewartet um den Turbo-Loader mit dazuzupacken.

Gruß Hayo

[Blue F. (blueflash)]

Und hier ist sie die BF.5.4

Wieder etwas schneller und besser. Highlights sind die schnelle 
ADC-Routine und es wird jetzt ein neuer Config-Sektor verwendet. d.h. 
die Uhr tickt jetzt wieder von vorn, und dank Slot Writing halt das 
Flash ca. 50 Mal länger.

Die Kompressor-Loader Dateien befinden sich im ucl-Verzeichnis. Im 
Root-Verzeichnis sind die normalen Flash und Ram-Dateien wie immer. 
Nicht erschrecken, der Ladevorgang dauert wirklich nur 15 Sekunden!

Auch erhältlich hier:

http://netcologne.dl.sourceforge.net/project/welecw2000a/Open%20Source%20Firmware/1.2.BF.5.x/1.2.BF.5.4.zip


@Johannes

Die Dateien sind 1:1 aus dem Entwicklungsverzeichnis kopiert.

Gruß Hayo

[Blue F. (blueflash)]

Für alle die selbst entwickeln:

Das angepasste SDK mit neuem Linkerskript und Makefile gibt es hier:

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

Hayo

[Rainer H. (rha)]

Hallo zusammen,
erstmal möchte ich Euch Entwicklern für den langjährigen Einsatz für die 
Welecs danken.
Und wenn schon alles schön werden soll und auf dem Prüfstand steht, 
möchte ich eine Beobachtung melden, die mglw. mit der ADC-Auslesung zu 
tun hat:

Wenn man ein Rechteck einspeist (z.B. Probe Comp.) werden immer wieder 
einzelne falsche Abtastungen angezeigt. D.h. einzelne Low Abtastungen im 
High-Signal. Am besten sieht man den Effekt, wenn das Display auf 
"persist" steht. Aufgrund der Logik vermute ich eher ein SW- als einen 
HW-Defekt. Vielleicht ist das bei Euch ja auch nicht nachvollziehbar?

Screeshots anbei.

Viele Grüße,
Rainer

PS: Ich hatte das schonmal gemeldet, scheint untergegangen zu sein.

[Blue F. (blueflash)]

Hallo Rainer,

untergegangen ist das nicht, sondern nur nicht nachvollziehbar. Ich habe 
mit genau Deinen Einstellungen 15 Min lang gewartet, da war kein 
einziger Spike (siehe Bilder). Auf beiden Geräten wohlgemerkt. FW ist 
die aktuelle BF.5.4.

Ich habe sowohl Factory Hardwareeinstellung als auch Highspeed getestet. 
Diese Spikes weisen eigentlich auf falsch gesetzte Register hin. Die 
hatte ich wenn ich in den Hardwareeinstellungen auf die jetzt 
ausgeblendeten Testeinstellungen gegangen bin.

Starte doch mal ein Terminal (mit den bekannten Einstellungen) und drück 
dann > , <. Du bekommst dann diverse Variablen aufgelistet. Unter 
Anderem folgende:


* channel_Adr_add12   :  5f0a     * channel_Adr_add34    :  5f5f    *

* adc_change12_reg    :  2020f00  * adc_change34_reg     :  200000a *

Das entspricht bei mir der "Factory" Einstellung. Wie sieht das bei Dir 
aus?

Gruß Hayo

[Blue F. (blueflash)]

Bin heute abend noch mal an die ADC-Routine rangegangen und  - wer hätte 
es gedacht - ich hab da nochmal ordentlich was an Geschwindigkeit 
rausgequetscht.

Aktuelle Framerate ist 1581/1613 FPM was 26,35/26,88 FPS entspricht. 
Falls Ihr Euch erinnert, mit den (WELEC) Assemblerroutinen lag das bei 
müden 969/583 FPM. Das ist jetzt mehr als ein Drittel schneller!

Wie geht das? Ich habe den Umweg über den Zwischenpuffer weggelassen und 
schreibe jetzt in einem Arbeitsgang die korrigierten Werte direkt aus 
dem FPGA-Register in den Signalspeicher. Die nächste Version kommt also 
bald.
Mir schwirrt da noch was im Kopf rum, aber dazu später...

Das dürfte für die OSOZ Treiber auch ein interessanter Ansatz sein, denn 
schneller geht es wohl nimmer!

Gruß Hayo

[Jörg H. (idc-dragon)]

Hallo Hayo,

mit loop unrolling geht vermutlich noch was. Damit habe ich aber auch 
bei Osoz absichtlich noch nicht angefangen. Ist nicht wirklich 
platformunabhängig, denn eine CPU mit Cache könnte je nach Umfeld besser 
ohne laufen.

Was du völlig unabhängig davon noch "heben" könntest: Ich habe doch mal 
schnelle 16*16bit auf 32bit Multiplikationsroutinen gebaut, die kannst 
du vermutlich für deine FFT und vielleicht auch sonstige 
Signalverarbeitung benutzen?
Heißen nr_smul16() und nr_umul16(), für signed und unsigned, ich würde 
zur Platformunabhängigkeit noch ein Makro drumherum bauen, das wahlweise 
auch eine normale Multiplikation verwenden könnte.

Branadic brachte mich gestern drauf, welchen Stand hat eigentlich die 
neue Eingangsstufe bei dir? Die braucht in der alten Firmware ja noch 
etwas Debugging. Ich mag da ehrlich gesagt nicht gerne beigehen.

Der gestrige Release war ja noch ohne Linux-UCL Support. Hast du da noch 
etwas weiter getestet, das Perl-Script mal per Hand aufgerufen? In den 
Shellscripten waren noch Fehler, du hattest wohl nicht die aktuellen von 
Osoz. (Ob die jetzt gehen weiß ich allerdings selbst nicht.)

Jörg

[Rainer W. (rawi)]

Hallo Hayo,

bei meinem W2024 sieht es genauso wie bei Rainer H. auf. Die Spikes 
treten anscheinend nur bei 5 MSa/s auf und auch nur in einem gewissen 
Abstand hinter dem Triggerzeitpunkt. Wie der Abstand von 
Horizontalposition und Pretrigger abhängt, ist mir nicht klar. Ich hänge 
einfach mal ein bisschen Daumenkino ran. Vielleicht hat ja jemand eine 
Idee.

Bei mir habe ich folgende Variablenwerte:
* channel_Adr_add12   :  5f0a     * channel_Adr_add34    :   a0a    *
* adc_change12_reg    :  1020000  * adc_change34_reg     :  200000a *

FW ist die 5.4 - der komprimierte Upload ist schwer beeindruckend!!!

Gruß
Rainer

[Blue F. (blueflash)]

Bei Dir werden werksseitig die Register aus dem Protected Flash nicht 
richtig gesetzt. Probiere doch bitte diese 5.5 Pre Version aus. Ich 
erzwinge da die richtigen Registerwerte. Würd mich mal interessieren ob 
es hilft.

Nebenbei darfst Du auch noch als Erster die schnelle Datenerfassung 
"genießen".

Gruß Hayo

[Blue F. (blueflash)]

@Jörg

Ich sehe gerade, dass Dein Beitrag hier und meiner im OSOZ-Thread sich 
überschnitten haben.

Ich vermute Du hast recht mit der Beschleunigung bei der FFT. Allerdings 
wollte ich da eigentlich nicht mehr allzu viel Schmalz in den 
Application Layer der BF-Version stecken. Die einzigen Sachen die ich 
hier noch machen wollte sind die Hardwarenahen Sachen die wir auch für 
OSOZ verwerten können. Quasi als Technologieträger und Testplattform.

Wie siehst Du das?

Eine Neuerung wollte ich der BF 5.5 noch angedeihen lassen im Bereich 
Trigger. Details später.


Gruß Hayo

[Jörg H. (idc-dragon)]

Hayo W. schrieb:
> Ich vermute Du hast recht mit der Beschleunigung bei der FFT. Allerdings
> wollte ich da eigentlich nicht mehr allzu viel Schmalz in den
> Application Layer der BF-Version stecken. Die einzigen Sachen die ich
> hier noch machen wollte sind die Hardwarenahen Sachen die wir auch für
> OSOZ verwerten können. Quasi als Technologieträger und Testplattform.
>
> Wie siehst Du das?

Ich weiß nicht wie du die FFT geschrieben hast. Als Rechenalgorithmus 
wäre sie je erstmal völlig unabhängig von der Umgebung, könnte man 1:1 
rausnehmen. Na gut, vielleicht die Datentypen noch gemäß stdint.h 
umbenennen.

Jörg

[Rainer W. (rawi)]

Hayo W. schrieb:
> Probiere doch bitte diese 5.5 Pre Version aus.

Leider sieht das Verhalten bezüglich Spikes mit der 5.5 unverändert aus, 
sowohl Bildschirm als auch angezeigt Variablenwerte - nur schnelle ;-(

Gruß
Rainer

[Charly B. (charly)]

@Hayo

Stocken nach dem Triggerverstellen weg, und schoen schnell, Kompliment!,
Danke!

den Efekt von Rainer mit den falschen Abtastungen kann i nicht
feststellen

(getestet mit 5.5Pre)

vlG Charly

[branadic (Gast)]

Jörg H. schrieb:
> Branadic brachte mich gestern drauf, welchen Stand hat eigentlich die
> neue Eingangsstufe bei dir? Die braucht in der alten Firmware ja noch
> etwas Debugging. Ich mag da ehrlich gesagt nicht gerne beigehen.

Stimmt es Hayo, dass du mit der Umrüstung deines 2-Kanälers begonnen 
hattest? Wie weit ist das gediegen? Sind die Huckepackplatinen jetzt 
drin?

branadic

Das Thema scheint entweder unangenehm zu sein, sodass man nicht darauf 
reagiert oder es wird bewusst ignoriert um nicht reagieren zu müssen. 
Zumindest ist auffällig, dass bei Nachfragen entsprechende Post immer 
wieder übergangen werden.

[Blue F. (blueflash)]

@Charly

Dann werden bei Dir von Werk aus die richtigen Registerwerte gesetzt. 
Anscheinend sind daovon nur Einige betroffen.


@Rainer

Hab gestern leider vergessen noch eine Anleitung beizufügen - 
Beipackzettel sozusagen.

Also beim Start oder Reset werden weiterhin die Werkseinstellungen aus 
dem Protected Flash geladen. Um die korrekten Registerwerte zu erzwingen 
mußt Du ins Hardwaresetup wechseln, dort einmal kurz die High Speed 
Einstellung wählen und dann wieder zurück auf die Factory Einstellung. 
Danach sollten die Registerwerte stimmen - bis zum nächsten Neustart.

Wenn es das wirklich ist kann ich in der Firmware dafür sorgen, dass die 
richtigen Werte voreingestellt sind.

Gruß Hayo

[Blue F. (blueflash)]

branadic schrieb:
> Sind die Huckepackplatinen jetzt drin?

Nein, sind sie nicht, ich konnte mich noch nicht dazu durchringen. 
Andere Sachen schienen mir wichtiger oder interessanter zu sein. Aber 
das sollte doch kein Problem sein, da Jörg doch hier den Support leistet 
und die BF-FW dank Jörgs Zutun die Eingangssufe unterstützt.

Dafür arbeite ich gerade an einer Triggererweiterung die sicher sehr 
nützlich sein wird.

Gruß Hayo

[Rainer H. (rha)]

Hallo zusammen,
nachdem Ihr das "Spike-Problem" nicht alle nachvollziehen könnt, noch 
einige weiter Infos:
- Es ist ein 2-Kanal W2022, ohne HW-Mods (bisher noch nicht mal 
aufgeschraubt...)
- Ich bekommt die Spikes nur im 1 Kanal erzeugt, Triggerkanal ist 
unabhängig
- Nur bei 50 µs Zeitauflösung
- In der "Delay"-Anzeige werden die Spikes mit angezeigt, sogar mehr als 
in der "Main"-Anzeige.

Jetzt wirds spannend...
Wenn ich im ADC-Setup die "High-Freq" Einstellung wähle, ändert sich an 
den Erscheinungen nichts.
Gehe ich wieder zurück auf "Factory" sieht es aus wie auf dem 2. Bild.


Viele Grüße,
Rainer

[Blue F. (blueflash)]

welche Registerwerte werden über das Terminal angezeigt?

Evtl. nach der Registerumstellung mal die Timebase hin und her ändern 
oder den Memoryausschnitt verändern.

Hayo

[branadic (Gast)]

Hayo W. schrieb:
> Nein, sind sie nicht, ich konnte mich noch nicht dazu durchringen.

Ganz realistisch wirst du dich auch in den nächsten Jahren nicht dazu 
durchringen können.

Hayo W. schrieb:
> Aber
> das sollte doch kein Problem sein, da Jörg doch hier den Support leistet
> und die BF-FW dank Jörgs Zutun die Eingangssufe unterstützt.

Ein theoretisches "das sollte kein Problem sein" nützt aber leider 
herzlich wenig.
Fakt ist, mit der derzeitigen Implementierung kann man nicht viel 
anfangen, weil sie noch zu viele Fehler enthält. Witzigerweise fühlt 
sich aber niemand mehr dazu berufen den Part anzugehen, zu 
vervollständigen und die Fehler zu beseitigen.
Wenn ich überlege wie laut das Geschrei ganz am Anfang auf Seite der 
Softwarefraktion war, davon ist heute nichts mehr über.

Aus heutiger Sicht wird das Welec wohl immer eine Baustelle oder 
Spielwiese für Programmierer bleiben.
Als Mitentwickler der Huckepkackplatine muss man die Leute ausdrücklich 
davor warnen den Umbau auf die neue Eingangsstufe vorzunehmen, weil die 
Softwarefraktion sich nicht dazu hinreißen lässt die anfänglich 
zugesagte Implementierung umzusetzen. Unter Zusammenarbeit verstehe ich 
etwas anders!

Ich bin mehr als enttäuscht!

branadic

[Rainer H. (rha)]

Hallo Hayo,
die Registerwerte liegen bei.

Komischerweise ändert jetzt auch ein Ändern der Timebase wenig, d.h. 
mind. bis 100µs tauchen die Spikes weiterhin auf.

Viele Grüße,
Rainer

[Blue F. (blueflash)]

So ich hab da mal was für Dich (Euch) vorbereitet.

Die Factory-Einstellung ist wieder wie früher, aber ich habe im Menü 
diverse Testeinstellungen eingeblendet. Da könnt Ihr mal durchprobieren 
ob eine davon passt.

Diese Registereinstellungen sind leider unterschiedlich von 
Hardwarerevision zu HW-Rev.. Meine Geräte sind einmal 8C7.0G und 8C7.0L 
- auf den Bildern kann man sehen was passiert wenn man die 
Factoryregisterwerte der beiden Geräte vertauscht.

Welche HW-Rev. hast Du bzw. Ihr?

Wenn die Testeinstellungen nicht funktionieren können wir nur eines 
machen: Jemanden suchen mit der gleichen HW-Rev. bei dem die Spikes 
nicht auftauchen und dann die Registerwerte übernehmen.

Leider sind die Registerfunktionen völlig undokumentiert und scheinen 
sich auch noch je nach HW-Rev. zu unterscheiden.

Gruß Hayo

[Rainer H. (rha)]

Hallo,
ich hab HW 1C9.C(.)9.
Die Einstellungen Test 1..5 sind alle ähnlich schlecht (häufige Spikes). 
Am wenigsten Störungen gibt es "Factory" und "High Freq.".
Jetzt komischerweise wieder nur auf Kanal 1...

Viele Grüße,
Rainer

[Blue F. (blueflash)]

Das ist eine neuere Version. Anscheinend haben die da noch Änderungen am 
FPGA vorgenommen und Einiges verschlimmbessert.

Wer von den werten Mitlesern hier im Forum hat denn auch ein neueres 
Gerät mit HW-Rev. > 8C7 und hat keine Probleme mit Spikes?

Wir brauchen die Registerwerte - wer hilft?

Gruß Hayo

[Thomas (kosmos)]

woran erkennt man das? Platinenaufdruck?

[Blue F. (blueflash)]

Nein viel einfacher.

Utility -> About Oscilloscope

Dort die zweite Zeile. Dann Terminal starten, die Einstellungen findet 
man in "How to use a Terminal" (siehe Anhang).

Hayo

[Stefan V. (vollmars)]

Hi Hayo,

hab seit langem mal wieder mein Welec ausgepackt und wollt gerade die 
ADC-Testeinstellungen in der 1.2.BF.5.5Pre2 ausprobieren.
Alle Einträge im ADC-Setup außer Factory und High FRQ sind grau und 
lassen sich nicht anwählen, mach ich da was falsch?
HW-Version ist: 8C7.0G

Gruß
Stefan

[Luc (Gast)]

Hi Stefan V. and guys all!

@Stefan V.
Maybe it is because You are using turbo version that You have in the 
>ucl< folder.
Plesase, tray the classic version, it is much slowest but You will 
solve.
I hope You can fix your problem.

Best regards,

Luc

[Stefan V. (vollmars)]

Thanks Luc,

you are right!

@Hayo
Ich hab Spikes nur auf Kanal 1 bei den Einstellungen: Factory, 1, 3, und 
4
HW-Rev ist 8C7.0G

Gruß
Stefan

[Rainer W. (rawi)]

Hayo W. schrieb:
> Hab gestern leider vergessen noch eine Anleitung beizufügen -
> Beipackzettel sozusagen.

Hallo Hayo,
danke für den Beipackzettel. Danach (FW 5.5 Pre 1) treten die Spikes 
woanders auf und gefühlsmäßig sogar stärker.

Dafür habe ich festgestellt, dass bei frei laufendem Bild (i.e. Signal 
wird nicht getriggert) nur ein einzelner Spike synchron auf Ch1 und 2 
(2,5 und 5 MSa/s) 418 µs bzw. 209 µs nach der Triggermarke bzw. bei 10 
MSa/s zwei gegensinnige Spikes nur auf Ch1 60µs vor bzw. 145µs nach der 
Triggermarke auftreten.

W2024A Hardware Vers. ist 1C9.0L

Gruß Rainer

[Rainer W. (rawi)]

P.S.

Korrektur:
Ch 3+4 sind genauso betroffen wie Ch 1+2  *** User error 0. Ordnung :-(

Hayo,

wie ist das mit den Test-Einstellungen gemeint? Ich habe jetzt die 5.5 
Pre2 eingespielt (incl. Default Setup), aber über Utility  Hardware  
ADC Setup wird das níchts. "Factory Setup" und "High Frequ" lassen sich 
anwählen, aber Test1 .. Test5 weigern sich und sind disabled (grau).
Habe ich da was nicht mitbekommen?

Bei freilaufendem Bild habe ich jetzt einen anderen Abstand zwischen 
Triggermarke und Spike.

Gruß
Rainer

[Luc (Gast)]

Hi Hayo, Jörg H., Björn F., Branadic, Rainer H., Rainer W.,Charly B. and 
guys all!

@Hayo
I am testing the new 1.2.BF.5.5Pre2 firmware release.
It is surprisingly fast, the waveforms shown on the screen seem to be 
drawn in real time, almost as on an analog oscilloscope!
As usually I am speechless but in this occasion I even believe no to my 
eyes.
It is as I am watching at another DSO, a really fast one, no to my 
Welecs!
So Hayo thank You very much!: RESPECT!!!!!!!

Talking of something else, I would not be rude and I do not know if I 
can interject, but not to do the evil advocate, I think Branadic is 
right.
I mean that would be nice to be able to manage the Huckepackplatinen 
also for the hard work behind it who Branadic did.
I know there are priorities, some things are easier and more immediate 
to do than other.
Ok to the effort to further improve the trigger, it is certainly a great 
thing, but I hope one day or another we will manage to see the 
Huckepackplatinen at work in the Welec DSO.
I understand that it is not so easy because Huckepackplatinen have to be 
installed also and that it is not simple to do, but I hope soon we can 
see something, I am sure!
I also know that here all who are involved in the Welec Project use 
their free time and their resources for the comunity and they have 
already given so much, so I can not compel them to do more, I hope that 
the meaning of my words can be understood.
I repeat, I would not be rude or polemic but this is my thoughts.
Perhaps I have not used the right words but I do not know how else to 
express myself, so I am not sure to have expressed myself well but I 
hope I was understandable.
Hayo and all apologize me for this digression.

@Jörg H.
Thank You very much for your turbo implementation, it is very fast and I 
believe the actual DSO's speed is also for your idea, intuition and 
work, so RESPECT!!!!!!!

Returning to the new firmware release, here some consideration.
It is really incredibly fast and quick either as commands response than 
as waveforms drawn, but spikes are unfortunately come back.
As reported by Rainer H., Rainer W.,Charly B. and perhaps other, seems 
to me spikes appear mainly in the pretrigger area, the next it is devoid 
and the waveforms are clean.
I have experienced spike either on CH1 than CH2 and on both the W2012A 
and the W2022A.
My DSOs are modified, I have changed the front-end and terminations 
resistors in the input stage and now I have to set hardware for 24,9ohm.
Hardware Version is 8C7.0B for the W2012A and 8C7.0C W2022A so I can not 
help exporting the configuration parameters from the terminal, I am 
sorry.
Maybe there are spikes because of some conflict with the implementation 
of Jörg H. and Björn F.
I wonder why they appear only in the pretrigger area but I have not the 
right answer, maybe it might just be a software incompatibility.
We will see.

Vielen Dank an alle Unterstützer des Projekts Welec!

Mit freundlichen Grüßen,

Luc

[Rainer W. (rawi)]

Luc schrieb:
> I wonder why they appear only in the pretrigger

Hi Luc,
nice observation. If the horizontal position is set to the right part of 
the trace, i.e. the end is completely visible, it is possible to follow 
the spike while turning the PreTrig time towards 0. The PreTrigger 
setting seems to be equivalent to the time between the spike and the 
right end of the trace. (trigger set to combi, not trigger due to level 
setting below signal)

Rainer

[Blue F. (blueflash)]

Wie Ihr schon bemerkt habt sind die UCL-Dateien der 5.5Pre2 leider nicht 
aktuell. Das kommt daher, dass ich diese unter Linux leider noch nicht 
verwenden kann und daher auch nicht prüfen kann.

Verwendet also bitte die normalen .flash und .ram Dateien -> sorry.


Momemtan sieht es wohl so aus, dass alle mit den 8C7.xx Versionen Glück 
gehabt haben und die Kollegen mit den 1C9.xx Versionen gekniffen sind.

Aber vielleicht findet sich ja doch jemand der eine 1C9.xx ohne Spikes 
hat.

Was nicht ganz klar ist, das ist ob es eine neuere oder eine ältere 
Version ist. Die Nummerierung läßt zwar eine ältere Version vermuten, 
aber da diese Versionen erst in letzter Zeit aufgetaucht sind denke ich 
es sind neuere Versionen.


Gruß Hayo

[Jörg H. (idc-dragon)]

Hayo W. schrieb:
> Wie Ihr schon bemerkt habt sind die UCL-Dateien der 5.5Pre2 leider nicht
> aktuell. Das kommt daher, dass ich diese unter Linux leider noch nicht
> verwenden kann und daher auch nicht prüfen kann.

Magst du das nicht mal genauer untersuchen? Gerade für uns Entwickler 
ist das mit dem .ucl-Download doch sowas von dermaßen eine 
Arbeitserleichterung, daß es mich wundert das du noch nicht sabbernd 
davorliegst.  ;-)

Ich verwende das nur noch, ausschließlich, auch beim kleinen Osoz ist 
das eine prima Sache.

Johannes und ich sind fast durchgängig im Skype-Gruppenchat zu 
erreichen, da kann man das auf kurzem Wege klären.

Jörg

[Blue F. (blueflash)]

Hi Jörg,

ich hab einen ganzen Tag lang dran rumgedoktort - ohne Erfolg. Ich 
stecke weder im UCL noch im Perlthema tief genug drin um da wirklich 
weiterzukommen. Daher hoffe ich hier auf Johannes und Dich.

In der Tat wäre das extrem hilfreich.

Gruß Hayo

[Jörg H. (idc-dragon)]

Dazu müßten wir aber wissen, was bei dir nicht klappt, und natürlich 
sicherstellen daß du die aktuellen Versionen der Scripte verwendest.
Im Passiv-Modus wird das nix...

Siehe Osoz-Thread, was passiert bei dir wenn du das Perl-Script direkt 
aufrufst?

Jörg

[Blue F. (blueflash)]

Sorry bin eben erst wieder zu hause.

Also wenn ich das Shellskript abfahre kommt die schon bekannte Meldung


Device         : /dev/ttyS0
Flash filename : ramloader.germs
UCL filename   : TomCat_ram.ucl

--- Writing GERMS firmware...
Writing line 000025 of 000025: S8 detected, end of GERMS transmission.
Successfully wrote GERMS firmware in 0.3 seconds!

--- Writing compressed firmware (168433 bytes / 42 chunks of 4096 
bytes)...
Writing chunk 42 of 42 - 100.0% - 15.7 sec / 0 sec left
Error: bad response from DSO!
Error response was: '5'
Firmware update was NOT successful!
done.


Wenn ich den Befehl direkt eingebe bekomme ich diese Meldung:


Device         : /dev/ttyS0
UCL filename   : TomCat_ram.ucl

--- Writing compressed firmware (168433 bytes / 42 chunks of 4096 
bytes)...
Writing chunk 42 of 42 - 100.0% - 14.7 sec / 0 sec left
Error: Timeout while reading response from DSO!
Firmware update was NOT successful!
Please fix the connection issue and retry!


Gruß Hayo

[Johannes S. (demofreak)]

Hayo W. schrieb:
> Wenn ich den Befehl direkt eingebe bekomme ich diese Meldung:

Wenn Du welchen Befehl direkt eingibst? Nach der Ausgabe zu urteilen 
lässt du das Schreiben des Dekompressors weg. Dann läufst du freilich in 
ein Timeout.
Bitte gib doch mal deine Befehlszeile mit an, das kannst du doch mit 
Copy'n'paste direkt hier einfügen.

[Rainer W. (rawi)]

Hayo W. schrieb:
> Was nicht ganz klar ist, das ist ob es eine neuere oder eine ältere
> Version ist.

Kommt drauf an, wie man den Zeitbalken für  "neuer" oder "älter" legt.
Mein W2024 mit HW 1C9.0L habe ich im Jan 2009 von T. Wittig erhalten. Da 
nicht klar ist, in welcher Reihenfolge die Geräte aus dem Regal genommen 
wurden, sagt das natürlich nicht allzu viel.

Gruß Rainer

[Luc (Gast)]

Guten Morgen an alle!

Hayo W. schrieb:
> Was nicht ganz klar ist, das ist ob es eine neuere oder eine ältere
> Version ist.

Because it is probable that the DSOs sold by Mr. Wittig were inventories 
and that among the material on sale there were also some returns and 
refurbished DSOs, perhaps there is no a real chronological order.
It is probably that the firsts DSO sold by Wittig were the most recent, 
expecially those sold directly.
Then as time goes Mr. Wittig also put them on eBay and among those that 
were sold there surely some were returned and other else were 
refurbished material returned as repair and this break the temporal 
chronological order.
I believe that production was stopped, ie, DSOs were no longer in 
production at the time when Mr. Wittig sold them.
So talking about the hardware release, I think it is difficult to 
determine which are new and which old.
Not necessarily the DSOs with a specified number release would surely be 
the most recent, I believe only Mr. Wittig could confirm it and say how 
things really are.
However, here my two cents:
W2012A number 09850712C9, hardware 8C7.0B purchased on December 20, 
2009.
W2012A number 78002031D0, hardware 8C7.0C purchased on January 15, 2010.

Vielen Dank an alle Unterstützer des Projekts Welec!

Mit freundlichen Grüßen,

Luc

[Luc (Gast)]

Noch einen guten Morgen an alle!

Luc. schrieb:
>However, here my two cents:
>W2012A number 09850712C9, hardware 8C7.0B purchased on December 20,
>2009.
>W2012A number 78002031D0, hardware 8C7.0C purchased on January 15, 2010.

Ich entschuldige mich, ich vertippt.
unter den richtigen Text.

W2012A number 09850712C9, hardware 8C7.0B purchased on December 20, 
2009.
W2022A number 78002031D0, hardware 8C7.0C purchased on January 15, 2010.

Ich für diesen Fehler zu entschuldigen
Vielen Dank an alle Unterstützer des Projekts Welec!

Mit freundlichen Grüßen,

Luc

[Rainer W. (rawi)]

In Bezug auf die Versionsentwicklung wäre es evtl. gut, die Geräteliste 
auf SourceForge um Seriennr. und Kaufdatum zu erweitern. Möglicherweise 
ist die SN erkennbar fortlaufend vergeben und ein Hinweis auf die 
Entwicklungsfolge.
http://sourceforge.net/apps/trac/welecw2000a/wiki/usersinstrument

Gruß
Rainer

[Blue F. (blueflash)]

Johannes S. schrieb:
> Wenn Du welchen Befehl direkt eingibst?

Den von Jörg geposteten Befehl.

perl GERMSloader.pl -d /dev/ttyS0 -b TomCat_ram.ucl




Rainer W. schrieb:
> In Bezug auf die Versionsentwicklung wäre es evtl. gut, die Geräteliste
> auf SourceForge um Seriennr. und Kaufdatum zu erweitern.
Ja das ist eine gute Idee. Die Möglichkeiten von OSOZ sind natürlich 
begrenzt wenn die Hardware so unterschiedlich reagiert, dass wir nicht 
alle Varianten korrekt bedienen können.

So Mittagspause ist vorbei - muß wieder los.

Tschüß Hayo

[Jörg H. (idc-dragon)]

Hayo W. schrieb:
>> Wenn Du welchen Befehl direkt eingibst?
>
> Den von Jörg geposteten Befehl.
>
> perl GERMSloader.pl -d /dev/ttyS0 -b TomCat_ram.ucl

De war aber nur zum Test, ob bei dir überhaupt Daten rausgeschoben 
werden. Für einen Download braucht es vorn noch den Loader, der Aufruf 
sieht dann so aus:

perl GERMSloader.pl -d /dev/ttyS0 -w ramloader.germs -b TomCat_ram.ucl

(Wie man mit einem Blick in das Shellscript leicht erkennen kann.)

Weil das Script ja fast nix tut gibt das dann vermutlich keinen 
Unterschied und du kriegst wieder den Fehler 5, merkwürdigerweise. Da 
wäre dann mal ein Vergleich interessant, aber bitte mit allen 
beteiligten Dateien: Shellscript, Perlscript, ramloader.germs, 
TomCat_ram.ucl.

Jörg

[Blue F. (blueflash)]

Sorry 1: Bin gerade erst zurück und hab noch schnell nen Blick ins Forum 
geworfen. Bin Momentan ziemlich eingespannt...


Sorry 2: Hatte den Befehl nur schnell kopiert und ausprobiert und dann 
wieder los zum nächsten Termin. Nix mit nachdenken oder so...

Hast natürlich recht. Hätte man einfach aus der Shell-Datei kopieren 
können.

Ergebnis ist wie erwartet:

Device         : /dev/ttyS0
Flash filename : ramloader.germs
UCL filename   : TomCat_ram.ucl

--- Writing GERMS firmware...
Writing line 000025 of 000025: S8 detected, end of GERMS transmission.
Successfully wrote GERMS firmware in 0.3 seconds!

--- Writing compressed firmware (168437 bytes / 42 chunks of 4096 
bytes)...
Writing chunk 42 of 42 - 100.0% - 15.7 sec / 0 sec left
Error: bad response from DSO!
Error response was: '5'
Firmware update was NOT successful!


Liegt also nicht an der Shell-Datei sondern entweder an der Perlversion 
oder an irgendeiner anderen Sache.

Gruß Hayo

p.s. bin morgen auch nur zwischendurch mal für kurze Zeit online

[Johannes S. (demofreak)]

Hayo W. schrieb:
> --- Writing compressed firmware (168437 bytes / 42 chunks of 4096
> bytes)...

Warum sind das bei dir 40 Byte mehr als bei mir (s.u.)?

hannes@gurkenkiste:~/Workspace/Welec/FW1.2.BF.5.5Pre2/ucl> perl GERMSloader.pl -w ramloader.germs -b TomCat_ram.ucl 

GERMSloader.pl Ver 1.2.0

*** No Warranty
***
*** This program is distributed in the hope that it will be useful,
*** but is provided AS IS with ABSOLUTELY NO WARRANTY;
*** The entire risk as to the quality and performance
*** of the program is with you. Should the program prove defective,
*** you assume the cost of all necessary servicing, repair or correction.
*** In no event will any of the developers, or any other party,
*** be liable to anyone for damages arising out of the use or inability
*** to use the program.

Device         : /dev/ttyUSB0
Flash filename : ramloader.germs
UCL filename   : TomCat_ram.ucl

--- Writing GERMS firmware...
Writing line 000025 of 000025: S8 detected, end of GERMS transmission.
Successfully wrote GERMS firmware in 0.3 seconds!                    

--- Writing compressed firmware (168397 bytes / 42 chunks of 4096 bytes)...
Successfully wrote compressed firmware in 15.9 seconds!                    
Please reboot DSO if it didn't restart automatically.

READY!
Thanks for all the fish.
hannes@gurkenkiste:~/Workspace/Welec/FW1.2.BF.5.5Pre2/ucl>

[Jörg H. (idc-dragon)]

Also, ohne das ihr mal die beteiligten Files austauscht wird das nix, 
imho...
Sprich, Hayo veröffentlicht mal genau die 4 Files mit denen es bei ihm 
nicht klappt, und/oder Johannes die Files mit denen es klappt?

Jörg

[Johannes S. (demofreak)]

Jörg H. schrieb:
> Sprich, Hayo veröffentlicht mal genau die 4 Files mit denen es bei ihm
> nicht klappt, und/oder Johannes die Files mit denen es klappt?

Darum bitte ich ja seit Tagen, weil ich irgendwie nie Dateien finde, die 
der (vom Perlskript ausgegebenen) Größe entsprechen, welche Hayo dort 
flasht.

Ich habe gestern abend das hier
> Hayo W. schrieb:
> > So ich hab da mal was für Dich (Euch) vorbereitet.
gepostete Prerelease heruntergeladen, ausgepackt und es aus dem 
Unterordner ucl wie in meinem Posting ersichtlich geflasht. Geht aus 
dem Stand.

Johannes S. schrieb:

hannes@gurkenkiste:~/Workspace/Welec/FW1.2.BF.5.5Pre2/ucl> perl GERMSloader.pl -w ramloader.germs -b TomCat_ram.ucl

(Bei allen, die ein anderes Device als /dev/ttyUSB0 verwenden, muss noch 
der Parameter -d <device name> ergänzt werden.)

/Hannes

[Blue F. (blueflash)]

Hallo ,

die Dateien waren doch schon längst im Umlauf - und zwar die 5.5Pre, 
also die erste Pre Version.

Ich kann aber gerne noch mal eine Version als Referenz raustun.

Grundsätzlich ist zu sagen, dass es bei mir unter Windows funktioniert 
und unter Linux nicht.

Gruß Hayo

[Johannes S. (demofreak)]

Hayo, woher kommt dann diese Dateigröße?

Hayo W. schrieb:
> --- Writing compressed firmware (168433 bytes / 42 chunks of 4096
> bytes)..

Ich habe beide 5.5Pre-Versionen runtergeladen, diese Datei ist bei 
beiden akkurat gleich groß:

hannes@gurkenkiste:~/Workspace/Welec> l FW1.2.BF.5.5Pre*/ucl/TomCat_ram.ucl
-rw-r--r-- 1 hannes users 168397 22. Feb 23:12 FW1.2.BF.5.5Pre2/ucl/TomCat_ram.ucl
-rw-r--r-- 1 hannes users 168397 22. Feb 23:12 FW1.2.BF.5.5Pre/ucl/TomCat_ram.ucl

Also, was flashst du dort?

EDIT: Ich sehe jetzt erst, dass du bei den beiden geposteten Logs der 
Fehlversuche unterschiedliche Dateigrößen schreibst, einmal 168433 und 
einmal 168437 Byte, und beides passt nicht zur Dateigröße. Die Frage 
wird nicht kleiner.

[Rudolf Z. (atmelwelec)]

Liebe großartig arbeitenden Welec/Wittig Mit-Leidensgenossen,

bitte verweist mich an den richtigen Thread, falls ihr mir hier nicht 
mit wenigen Zeilen helfen könnt, oder löscht meinen Text nach 2-3 Tagen:

Habe ein DSO W2022A mit Originalsoftware, 2007 oder 2008 gekauft.
War bis vor 1 Jahr "brauchbar".

Auf einmal: Bildschirm leer (eher dunkel).

Usache unbekannt und unklar, ob jemand "falsche" Tasten gedrückt hat.
Auch Neu-Einstecken und Neu-Einschalten hilft nicht, keine Anzeige am 
Bildschirm. Run/Stop leuchtet aber grün.
Habe durch zufälliges Drücken von Tasten festgestellt, dass nach Drücken 
der 2 linken Tasten unterm Bildschirm dieser die Farbe wechselt (also 
noch funktionert), wobei nach jedem Versuch andere Tastenkombinationen 
(bunt) aufleuchten, darunter auch (beim W2022A nicht vorhandene) Tasten, 
die dem 3. und 4. Kanal entsprechen würden.

Habe auch schon versucht, das Problem durch Aufspielen eurer 1.2.BF.5.4 
zu beheben, doch gelingt mir die Kommunikation über euren WelecUpdater 
ebenfalls nicht. Mögliche Gründe:
a) W2022A hat sich so aufgehängt, dass das auch nicht möglich ist.
b) Ich habe die Verbindung falsch zusammengesteckt.
c) Die Schnittstelle arbeitet nicht richtig, z.B. weil normalerweise ein 
Modem dranhängt.

Fragen:

zu a)
Hat das DSO eine Batterie oder dgl., die leer sein könnte und ohne die 
es nicht funktioniert?
Hat jemand das beschriebene Verhalten schon einmal gehabt?
Falls ja, wie lässt sich dieses beenden?

zu b)
Mein rel. billiger Rechner (von HP, Bj.2007od.2008, Windows XP voll 
gepatcht) hat eine 25-polige und eine 9-polige Schnittstelle, im 
Gerätemanager aber COM1, COM2 und LPT1 betriebsbereit. Heißt das, dass 
die 25-polige (LPT1?) als COM2 fungiert oder fungieren kann? (Beide 
haben IRQ3, COM1 mit dem Modem hat IRQ4).
Wie kann ich prüfen, ob das Verbindungskabel bzw. die 
Kabel-Adapter-Kombination für die serielle Verbindung richtig verdrahtet 
ist?

zu c)
Kann ich das Modem bei eingeschaltetem Rechner abstecken, das W2022A 
anstecken und dann mit dem WelecUpdater die Firmware auslesen, oder sind 
davor weitere Maßnahmen nötig?

Wichtig:
Muss ich die beiden Tasten links unterhalb des Bildschirms drücken, 
bevor WelecUpdater den Verbindungsaufbau versucht, oder 
währenddessen?
Und muss ich die linke oder die rechte Taste zuerst loslassen? (die 
beiden Möglichkeiten führen jeweils zu anderen aufleuchtenden 
Tastenkombinationen!)

Ich hoffe, dass ich alle Fragen so genau gestellt habe, dass ihr mir 
rasch und helfen könnt und eure wertvolle Arbeit möglichst nicht 
unterbrochen wird - es tut mir ohnehin so leid, dass ich selbst nicht 
die Fähigkeit zur Mithilfe am Projekt habe. Deshalb besonderen Dank im 
Voraus.

Rudolf

[Guido B. (guido-b)]

Rudolf,

ich mache für dich und dein Problem mal einen neuen Thread auf,
damit das hier nicht zu unübersichtlich wird.

So, jetzt kann es hier

Beitrag "Wittig- Oszi meldet sich nicht mehr"

weitergehen.

[Blue F. (blueflash)]

@Johannes

Tut mir leid, bin momentan die meiste Zeit unterwegs und komme zu nix.
Da scheinen wohl die Dateien durcheinander gekommen zu sein. Hier also 
noch mal eine konsolidierte Version zum Abgleich.

Meldung unter Linux ist:


Device         : /dev/ttyS0
Flash filename : ramloader.germs
UCL filename   : TomCat_ram.ucl

--- Writing GERMS firmware...
Writing line 000025 of 000025: S8 detected, end of GERMS transmission.
Successfully wrote GERMS firmware in 0.3 seconds!

--- Writing compressed firmware (168437 bytes / 42 chunks of 4096 
bytes)...
Writing chunk 42 of 42 - 100.0% - 15.7 sec / 0 sec left
Error: bad response from DSO!
Error response was: '5'
Firmware update was NOT successful!
done.

Meldung unter Windows kommt gleich nach. Nicht wundern, im "About" steht 
noch Pev 2, hatte ich noch nicht geändert.

Hayo

[Blue F. (blueflash)]

Und so sieht das unter Windows aus...


Device         : COM1
Flash filename : ramloader.germs
UCL filename   : TomCat_ram.ucl

--- Writing GERMS firmware...
Writing line 000025 of 000025: S8 detected, end of GERMS transmission.
Successfully wrote GERMS firmware in 0.3 seconds!

--- Writing compressed firmware (168437 bytes / 42 chunks of 4096 
bytes)...
Successfully wrote compressed firmware in 14.7 seconds!
Please reboot DSO if it didn't restart automatically.

READY!
Thanks for all the fish.


Gruß Hayo

[Johannes S. (demofreak)]

hannes@gurkenkiste:~/Workspace/Welec/FW1.2.BF.5.5Pre3/ucl> ./ramloader.sh                                                                                                          
loading firmware to RAM...                                                                                                                                                         
                                                                                                                                                                                   
GERMSloader.pl Ver 1.2.0                                                                                                                                                           
                                                                                                                                                                                   
*** No Warranty                                                                                                                                                                    
***                                                                                                                                                                                
*** This program is distributed in the hope that it will be useful,
*** but is provided AS IS with ABSOLUTELY NO WARRANTY;
*** The entire risk as to the quality and performance
*** of the program is with you. Should the program prove defective,
*** you assume the cost of all necessary servicing, repair or correction.
*** In no event will any of the developers, or any other party,
*** be liable to anyone for damages arising out of the use or inability
*** to use the program.

Device         : /dev/ttyUSB0
Flash filename : ramloader.germs
UCL filename   : TomCat_ram.ucl

--- Writing GERMS firmware...
Writing line 000025 of 000025: S8 detected, end of GERMS transmission.
Successfully wrote GERMS firmware in 0.3 seconds!                    

--- Writing compressed firmware (168437 bytes / 42 chunks of 4096 bytes)...
Successfully wrote compressed firmware in 15.9 seconds!                    
Please reboot DSO if it didn't restart automatically.

READY!
Thanks for all the fish.
done.

Und nun?

/Hannes

[Johannes S. (demofreak)]

@Hayo

Was sagen folgende Befehle bei dir?

hannes@gurkenkiste:~/Workspace/Welec/FW1.2.BF.5.5Pre3/ucl> perl -v|grep version
This is perl 5, version 14, subversion 2 (v5.14.2) built for x86_64-linux-thread-multi
hannes@gurkenkiste:~/Workspace/Welec/FW1.2.BF.5.5Pre3/ucl> perl -MDevice::SerialPort -e 'print "$Device::SerialPort::VERSION\n"'
1.04

/Hannes

[Blue F. (blueflash)]

Hi Hannes,

bin grad (wie kann es anders sein) vom Griechen zurück und schon etwas 
zu duselig um hier noch was vernünftig auf die Reihe zu kriegen.

Ich check das mal morgen und poste dann das Ergebnis.

Gruß Hayo

[Michael W. (slackman)]

Hi Leute,
falls noch Interesse an einem W2024 besteht:
ich möchte mein Gerät verkaufen, da ich auf ein Owon umgestiegen bin.

Hier die Eckdaten meiner Anpassungen:
- neuer Lüfter eingebaut
- Schirmblech eingebaut
- Drehknöpfe aus Alu gefertigt, schraubbar (Madenschrauben)
- 4 unbestückte AddOn Platinen für die Erweiterung der Eingangsstufen
(mir waren die Lötungen zu filigran) lege ich bei

Ansonsten ist das Teil im Originalzustand mit der aktuellen Blueflash
Firmware und 4 Messleitungen.

Bitte nur ernstgemeinte Angebote an michel-werner[at]gmx[dot]de.

Michel

[Blue F. (blueflash)]

Hallo Hannes,

so sieht das aus bei mir:


perl -v|grep version
This is perl 5, version 14, subversion 2 (v5.14.2) built for 
i586-linux-thread-multi


perl -MDevice::SerialPort -e 'print "$Device::SerialPort::VERSION\n"' 
1.04


Gruß Hayo

[Blue F. (blueflash)]

So heute ist mal wieder Download-Day.


Die BF.5.5 final ist fertig. Ich habe da zwei neue Guties eingebaut und 
noch ein bisschen an der Geschwindigkeitschraube gedreht.

Auch erhältlich hier:

http://sourceforge.net/projects/welecw2000a/files/Open%20Source%20Firmware/1.2.BF.5.x/1.2.BF.5.5.zip/download


Was gibt's Neues?

Eine Auslesefunktion für die Flash Manufacturer ID und Device ID. Diese 
wird jetzt angezeigt in Utility->About Oscilloscope.

Bei mir steht bei beiden Geräten C293.

So jetzt muß man nur noch wissen was das heißt. Also die ersten beiden 
Zeichen sind die Manufacturer ID. Wenn wie zuerst vermutet ein AMD-Chip 
drin wäre, dann stünde da eine 01xx. Macronix hat die ID C2xx. Diese IDs 
sind in einer Tabelle (von Jedec) gelistet die ich bei Bedarf zur 
Verfügung stellen kann.

Interessant ist auch, ob noch weitere Hers teller verwendet wurden. Also 
postet mal Eure IDs hierr damit wir ein Gefühl dafür kriegen welche 
Hardware (variationen) wir mit OSOZ berücksichtigen müssen.

Und den Alternating Trigger dazu im nächsten Beitrag mehr...

[Blue F. (blueflash)]

Also wozu braucht man diesen komischen ALT-Trigger und wie komm ich 
darauf?

Die Inspiration kommt vom OWON, da hatte ich doch tatsächlich mal die 
Gelegenheit von den China-Men zu klauen ;-)

Die Funktion gefiel mir so gut, dass ich die auf jeden Fall auch in 
unsere Büchse einbauen wollte.

Also, wir haben zwei Signale die absolut asynchron sind, wollen diese 
aber direkt miteinander vergleichen und brauchen die Flanken daher 
direkt übereinander. Mit Trigger Source 1 sieht das dann aus wie in Bild 
1 und mit Trigger Source 2 wie in Bild 2.

Und jetzt kommt der ALT-Trigger ins Spiel, dann sieht das aus wie in 
Bild 3.

Nett, oder?

Und das funktioniert nicht nur mit zwei Kanälen sondern auf allen 
aktiven Kanälen gleichzeitig (in Wirklichkeit natürlich im 
Multiplexverfahren)

Gruß Hayo

[Jochen R. (same2_de)]

Sehr brauchbar, respect!
Werde ich gleich mal testen...