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

[Johannes S. (demofreak)]

Hayo W. schrieb:
> This is perl 5, version 14, subversion 2 (v5.14.2) built for
> i586-linux-thread-multi
> 1.04

Dort liegt der Hase schon mal nicht im Pfeffer, weil es akkurat wie 
meine Versionen ist, mal abgesehen von dem Umstand, dass ich die 
64bit-Version verwende.

Kannst du das Ganze an einem anderen Rechner mit einer anderen 
Linuxinstallation und v.a. einem anderen RS232-Adapter testen?

/Hannes

[Sebastian S. (sebastian_s47)]

Hallo Hayo,
habe die Firmware mal geflasht und die ID ausgelesen.

Mein Oszi ist ein W2022A, dass ich September 2011 bei einer eBay Auktion 
von Welec erstanden habe. Flash ID ist die 0193 - also scheinbar der AMD 
Flash Chip.

Gruß
Sebastian

[Blue F. (blueflash)]

@Sebastian

Du Glücklicher, dann hält dein Chip 10x so lange wie meiner...



@Hannes

Mein Port ist kein Adapter sondern ein echter Port. Ja ich habe noch 
meine alte Suse-Installation auf einem Backup-Rechner. Da könnte ich 
drangehen. Weitere Möglichkeit ist ein Ubuntu (glaube ich) das ich auf 
einer virtuellen Maschine auf meinem aktuellen Rechner laufen habe.

Mal sehen wann ich dazu komme, bin heute Abend wieder unterwegs.

Gruß Hayo

[Blue F. (blueflash)]

@Sebastian

btw. Deine Hardware ID wäre für unsere Statistik auch interessant, 
kannst Du die auch noch mal posten, und evtl. die Seriennummer?

Gruß Hayo

[Robert (Gast)]

Endlich habe ich den Perl Updater hier zum Laufen bekommen.
Mein Fehler: ich hatte die 64bit Version runtergeladen und da funzt der 
Win32-SerialPort-0.22 halt nicht. Hätte ich eher drauf kommen können :)
Nachdem ich nun auf meiner W764bit Maschinedie Perl32 Version 
installiert habe... ist das Updaten ein Traum. Thx!


Mit der 1.2.BF.5.5 ist die Darstellung nun irgendwie auffällig 
'zappeliger' geworden, eben deutlich mehr als vorher.
Von 10mV- bis zum 5V-Bereich ist das durchgehend auf beiden Spuren zu 
erkennen.

Default Setup und Calibrate Offsets habe ich durchgeführt.
ADC Setup und PreGain Einstellungen verändern daran nichts.

Kann ich, ausser nun die alte Version wieder aufzuspielen, evtl. noch 
was versuchen um das Gezappel vielleicht wegzubekommen?

Ausgelesene Werte:

Modell: W2022A
Hardware Version: 8C7.0E
Software Version: 1.2.BF.5.5
Serial Number: 07060106C8
Flash ID: C293

Gruß
Robert

[Rainer W. (rawi)]

Die Geräteliste auf SF habe ich mal um die Flash-ID erweitert und deine 
Daten, Robert, gleich mit aufgenommen.
https://sourceforge.net/apps/trac/welecw2000a/wiki/usersinstrument

Gruß
Rainer

[Blue F. (blueflash)]

Robert schrieb:
> Mit der 1.2.BF.5.5 ist die Darstellung nun irgendwie auffällig
> 'zappeliger' geworden, eben deutlich mehr als vorher.

Das Gezappel liegt an der deutlich höheren Wiederholrate und ist 
eigentlich gewollt.

Wenn Dir das zu schnell ist einfach Quick Measure und Filter anmachen, 
dann wird es wieder langsamer.

Zum ALT-Trigger: Kanäle auf denen kein Signal anliegt sollte man 
ausschalten, weil sonst der ALT-Trigger ausgebremst wird und das Signal 
hin und herzuckt.

Gruß Hayo

[Sebastian S. (sebastian_s47)]

Hallo,
klar, dass ist kein Problem:

Modell: W2022A
Hardware-Version: 8C7.0E
Seriennummer: 00129602C7
Flash ID: 0193
gekauft: September 2011

Die Probleme mit den Signal-Flanken habe ich auf keinem meiner 2 Kanäle.

Wäre schön wenn's jemand in das Wiki mit aufnimmt, ich habe keinen 
Sourceforge-Account.

Gruß
Sebastian

[Johannes S. (demofreak)]

@Hayo

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

Im "Hauptverzeichnis" steht noch die alte Version des Perl-Skripts, 
dafür gibt es keinen sinnvollen Grund. Die neue Version des Skripts ist 
für UCL und non-UCL tauglich.

Ansonsten:

W2024A
8C7.0H
04092701C9
C293
ca. Mitte 2009 gekauft

/Hannes

[Johannes S. (demofreak)]

Hm,

ich hatte gerade ein sehr seltsames Phänomen nach dem Flashen der 5.5:

- geflasht
- Default Setup
- Zeitbasis hin- und hergedreht
- Calibrate Offsets

Soweit alles hübsch, bis auf dass Kanal 4 ein geringfügig höheres 
Rauschen bzw. kleine Spikes in negativer Richtung aufweist, was vorher 
nicht so war.

- alle Kanäle nacheinander aktiviert und "Center Channel X" gedrückt

Auf einmal hatte Kanal 4 Rauschen in Höhe von ca. 1.5-2 div. Das blieb 
auch, als ich alle anderen Kanäle testweise deaktiviert habe. Sobald ich 
den Kanal auch nur wenige Pixel nach oben oder unten aus der Mitte 
gedreht habe, war das Rauschen weg bzw. auf Normalniveau. Wieder in die 
Mitte gedreht bzw. gedrückt und es rauscht.

Als ich alles für ein paar hübsche Screenshots vorbereiten wollte und 
nochmal alles durchgeschaltet habe, verschwand der Effekt urplötzlich.

Ich hau jetzt nochmal die 5.4 drauf und guck mir das genauer an.

/Hannes

[Johannes S. (demofreak)]

Johannes S. schrieb:
> Soweit alles hübsch, bis auf dass Kanal 4 ein geringfügig höheres
> Rauschen bzw. kleine Spikes in negativer Richtung aufweist, was vorher
> nicht so war.

Zu den Spikes siehe Bild 0003, da sind sie zu sehen, weil ich das Noise 
Filter abgeschaltet habe. Ist mir mit den älteren Versionen nur nicht 
aufgefallen, weil ich sonst als erstes das Filter vom Typ "Smooth" 
einschalte, und das bügelt diese Spikes weg.

> Ich hau jetzt nochmal die 5.4 drauf und guck mir das genauer an.

Ich habe das Problem nicht mehr provozieren können, aber weil ich einmal 
dabei war: die Verschiebung der Kanäle erzeugt nach wie vor ein Offset 
der Nulllinie. In Bild 0000 sieht man eine leichte Verschiebung von 
Kanal 1 nach oben, während nach Druck auf "Center Channel 1" dieses 
Offset nicht mehr vorhanden ist (Bild 0001).

Gibt es dagegen schon ein Mittel, welches ich nur überlesen habe?

/Hannes

[Rainer H. (rha)]

Hallo,
ich möchte nochmal was zum "Spike-Problem" beitragen. Das Bild oben 
ergibt sich bei mir, wenn ich längere Zeit den "Edge ok" Test mache. Ich 
finde es auffällig, dass die Fehler immer das Niveau des anderen Pegels 
haben. Kann das evtl. auch an der RAM-Adressierung liegen, d.h. die 
Soft-CPU greift an falsche Adressen bzw. ist der RAM-Zugriff vom Timing 
her nicht optimal (zu schnell)?

@Hayo: Gibt es die Möglichkeit testweise langsamer aufs RAM zuzugreifen? 
Oder bietet Osoz eine RAM-Testmöglichkeit?

Viele Grüße,
Rainer

[Michael W. (slackman)]

Hi,
durch den neuen Schwung in diesem und den anderen W20xx Threads ist das 
Interesse an dem Scope größer als ich dachte.
Kurzum - das W2024 ist weg.

Michel

[Jetzt Welec-Fan (Gast)]

Hallo,

Vorgeschichte: Hatte mir vor einigen Jahren ein W2022 zugelegt und war 
von der Kiste überhaupt nicht überzeugt. Also lag das Teil in den Jahren 
nur so unbenutzt im Schrank rum.

Aber gestern hatte ich hier mal so zufällig rumgeschüffelt und war von 
den Iniziativen überwältigt. Die ganzen Threads hatte ich nicht lesen 
können, das hätte sicher Tage gedauert.

Welec also geholt, geflasht (1.2.BF.5.5) und  U N G L A U B L I C H...

Wahnsinn, was hier geleistet wurde! Wenn ich es richtig verstanden habe 
hauptsächlich vom Hajo (Blueflash). Seine Fähigkeiten möchte ich haben, 
oder wenigstens 5% davon. Aus dem Welec ist ja nun ein für mich 
brauchbares Scope geworden. Leider kann ich selbst mangels 
Fachkenntnissen nichts zur Weiterentwicklung beitragen, bin also nur 
"Trittbrettfahrer".

Es bleibt für mich also nur übrig ganz laut  D A N K E S C H Ö N
zu schreiben und jetzt liebe ich mein Welec!

Träum: Wenn jetzt noch ein Komponententester softmässig machbar wäre 
(habe mich so daran gewöhnt), dann wäre der Traumgipfel erreicht.

Thomas, der sich über sein Welec nun freut.

[Kruno (Gast)]

Ein Komponententester ist ein Signalgenerator mit Auswertung. Unser 
Wellec hat nur Eingänge.
Dein Traum wird wohl Traum bleiben müssen.
Gruß

[elecBlu (Gast)]

Rainer H. schrieb:
> ich möchte nochmal was zum "Spike-Problem" beitragen. Das Bild oben
> ergibt sich bei mir, wenn ich längere Zeit den "Edge ok" Test mache.

das kann ich so bei meinem Gerät bestätigen, HW 8C7.0C
Tritt also nicht nur bei den 50µS auf (bzw. dort konnte ich es bisher 
noch nicht reproduzieren), wohl aber auf 10ns.

[Rainer W. (rawi)]

Rainer H. schrieb:
> Ich finde es auffällig, dass die Fehler immer das Niveau des anderen
> Pegels haben.

Die Idee mit der falschen Adressierung hatte ich auch schon. Für eine 
Zuordnung könnte man es mal mit einem Sägezahn füttern.

Ich habe die Beobachtung gemacht, dass wenn das Scope frei läuft (d.h. 
Auto Trigger mit Trig.-Level außerhalb des Signals) der Peak um die als 
PreTrigger eingestellte Zeit vor dem rechten Ende des Trace-Speichers 
auftaucht (Horizontalposition ganz nach recht).

Gruß
Rainer W.

[Blue F. (blueflash)]

Hallo Jungs, bin mal wieder grad vom Griechen zurück (wir sind quasi 
schon adoptiert).

Also die Idee mit der Adressierung geht schon in die richtige Richtung. 
Es ist im wesentlichen ein Timingproblem beim Auslesen/Synchronisieren 
der vier einzelnen ADC. Diese müssen ja Ihre Werte abwechselnd ins 
schnelle RAM schreiben. Wie uns der frühere Entwickler (mit dem Jörg 
Kontakt aufgenommen hat) bestätigt hat, gab es von Anfang an 
Timingprobleme in diesem Bereich, die die Wittigs (die den VHDL-Teil 
entwickelt haben) nie so richtig in den Griff bekommen haben.

Das Ganze ist also ein FPGA-internes Problem, an dem wir mit der 
Firmware wenig ändern können. Einzige Möglichkeit ist, ein wenig die 
Registereinstellungen zu variieren oder Softwarefilter nachzuschieben.

Allerdings ergeben sich im Gespräch mit diesem Entwickler gerade neue 
Perspektiven, aber da möchte ich Jörg jetzt nicht vorgreifen. Sagen wir 
mal so, ich bin optimistisch und gespannt was sich da so ergibt.

Gruß Hayo

[Blue F. (blueflash)]

Jetzt Welec-Fan schrieb:
> Thomas, der sich über sein Welec nun freut.

Ach ja, bevor ich es vergesse, danke für die Blumen und willkommen im 
Club!

Übrigens möchte ich auch noch mal auf die vielen anderen unermüdlichen 
Tester, Ideenspender und Mitentwickler hier im Kreise hinweisen die 
durch Ihr Zutun das Projekt vorangebracht haben.

Einen schönen Abend

Hayo

[Guido (Gast)]

Jetzt wollte ich auch mal wieder testen, irre Framerate aber auch
böse Spikes. Das kann aber auch an den Einstellungen gelegen haben,
ich konnte es wg. dem Netzschalter nicht mehr weiter probieren.

Da muss ich mak ran. Michael, bist du noch da?

Grüße, Guido

[Blue F. (blueflash)]

Noch mal Nachschlag.

Ich habe im Hardwaremenu die Möglichkeit eingebaut den ADC-Treiber 
selbst auszusuchen. Standard (default) ist der etwas langsamere Treiber 
mit Byte overflow protection. Der zweite ist der schnelle (Quick + 
Dirty) Treiber ohne byte overflow protection. Ich hatte mit dem 
schnellen Treiber bislang noch keine Probleme.

Weitere Treiber (z.B. aus dem OSOZ-Projekt) können jederzeit zur Auswahl 
hinzugefügt werden. Das erleichtert das Testen und Vergleichen.

Wer die Frameraten selber messen will startet ein Terminal und greift 
sich eine Uhr mit Sekundenanzeige. Mit shift + K resettet man den 
Counter. Nach genau einer Minute macht man das noch einmal. Der 
Angezeigte Wert ist dann die Anzahl Frames per Minute (FPM).

Weiterhin habe ich den invertierten Modus beim USTB repariert, der durch 
die neuen Treiber nicht mehr funktionierte.

Der Download ist auch über diesen Link erreichbar:

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

Gruß Hayo

[Blue F. (blueflash)]

Ach ja noch zum Edge-Test. Kanal 3 + 4 sind bei mir auch ausgefranst. 
Leider läßt sich das auch mit diversen Registervariationen nicht 
beseitigen.


@Johannes

Bin noch nicht dazu gekommen meinen Backuprechner aus dem Rack zu ziehen 
um damit den Pearlloader zu testen - kommt aber noch.

Gruß Hayo

[Luc (Gast)]

Hi there Jetzt Welec-Fan, Hayo and all guys!

Jetzt Welec-Fan schrieb:
>Träum: Wenn jetzt noch ein Komponententester softmässig machbar wäre
>(habe mich so daran gewöhnt), dann wäre der Traumgipfel erreicht.

Willkommen bei Jetzt Welec-Fan!
A simple components' tester to be coupled to the Welec DSO may be this:
h t t p :   s n i p u r l . c o m / 2 2 g 4 r b 2
Here a simple guide to understand how it works and how to use it:
h t t p :   s n i p u r l . c o m / 2 2 g 4 s 7 g
Simple but powerful.
However You find more detail on any search engine using the query 
"Octopus oscilloscope tester" or "Analog Signature Analysis".
Have fun and joy with your Welec DSO and this simple curve tracer!

@Hayo
Vielen Dank für die neue Firmware und neue Features alternate Trigger!
Wir sehen uns morgen für meine Rezension. ;-)

Hayo W. schrieb:
>Der zweite ist der schnelle (Quick + Dirty)
>Treiber ohne byte overflow protection.
>Ich hatte mit dem schnellen Treiber
>bislang noch keine Probleme.

Selbst ich, mit dem gleichen Setup habe ich keine Probleme bemerkt.
Es scheint mir, dass das Spikes Problem hat sich verbessert, oder 
vielleicht ist es mein Eindruck.
This time I tried to write in German, I hope I was understandable. ;-)

Mit freundlichen Grüßen,

Luc

[Guido (Gast)]

Hi Luc, dein deutsch wird von Post zu Post besser. Gratulation, wenn
du damit etwas anfangen kannst;-).

@ Hayo: mal ne blöde Frage: Gibt es im Menü Utility schon den Punkt
Firmware-Update? Damit könnten wir uns mal vom GERMS-Monitor 
verabschieden
und ihn als Fallback betrachten.

Grüße, Guido

[Blue F. (blueflash)]

Nein noch nicht, aber Deine Frage bringt mich auf eine Idee. Anstatt den 
Dekompressor jedesmal mit dem Germsloader hochzuladen, kann man ihn 
natürlich auch in der Firmware verankern genauso wie den weiteren Upload 
der Firmware.

Remotebefehle nimmt das DSO ja schon über RS232 entgegen, da könnte man 
natürlich auch ein Firmwareupdate implementieren. Über USB läuft das 
auch nicht anders.

@Luc

Respect, Your german is really good. I'm looking forward to Your 
recension...

Gruß Hayo

[Luc (Gast)]

Hi there Hayo, Guido and all guys!

As promised here my review of the new 1.2.BF.5.6 firmware.
As always are not a criticism but only for knowledge and reference.
I tested it on my W2012A setting it both Normal and Fast the ADC 
configuration.

1)External Trigger selection do not works, when You push its button 
trying to select between Ext and TV then Ext is stuck on >LF Reject< and 
TV on >TV Vert Sync<, the respective buttons do not work.

2)After I tried to use Ext Trigger even if CH1 or CH2 are set, then 
trigger do not works and the waveforms dance back and forth on the 
screen a little bit as when ALT Trigger is set.
Sometime this fact it is also if formerly it is used ALT Trigger.
Only way to fix it is to performing a reset, after this all it is OK and 
trigger resumes its operation.
No matter what is trigger mode (Auto, Normal or Combi), it happens 
regardless their.

3)When there are changes on the bottom labels (i.e. using Cursors or 
Quick Measure), I get corruption on the bottom of the screen, sometimes 
even in upper and middle parts.
This is even using USTB.
Please take a look at my screenshots, thanks.

4) Sometime I noticed freeze, especially after I used slow time base 
range.

Also as in former releases, amplitude of a slow sinusoidal waveform 
changes it with setting AC or DC coupling: when DC is set the amplitude 
is right but when the choice it is AC then amplitude it is wrong (little 
than before with the DC setting).
Even when I test pulse behavior, as I already wrote with the previous 
firmwares release, the signal amplitude change with the Volt/Div choice, 
so passing from 2V/Div to 500mV/Div the waveforms drawn on the screen 
decreases instead of increasing.
For both the anomalies please look at my screenshots, thanks.

ALT Trigger seem to me to be useful and that it works great, a really 
excellent implementation, thank You very much Hayo: RESPECT!!!!!!!

Talking about improvements.
Now we can choose to show or hide markers' line when Quick Measure are 
switched on, but I believe that could be useful to have the cursors 
visible in Quick Measure.
Let me explain better.
I mean set the cursors in the Cursors screen, not necessarily 
simultaneously Time and Voltage cursors but even only one type at a 
time, then keep them visible on the Quick Measure screen to be use them 
as reference (example performing a bandwidth measure).
I do not mean to have functioning cursors on the Quick Measure screen 
but only set them in the Cursors screen and then keep them visible on 
that of Quick Measure.
Practically this would to superimpose some static references (cursors 
lines) on the Quick Measure screen, not necessarily that cursor lines 
are to be adjustable when Quick Measure it is selected
Many DSOs allow it, for example the TDS220 do it, not Time and Voltage 
cursors at same time but only one at a time but it is however useful in 
my opinion.
I hope I was understandable.
I know anything is put on the DSO's screen then there is a speed 
decrease but now the DSO is very fast and responsive and perhaps it is 
no a problem in these circumstances and in any case could be turned off 
if necessary.
I would like to have your opinion.

@Guido und Hayo
Danke für die Ermutigung! ;-)

Vielen Dank an alle Unterstützer des Projekts Welec!

Mit freundlichen Grüßen,

Luc

[Luc (Gast)]

Guten Abend an alle.

Eine notwendige Klarstellung.
Luc schrieb:
>Also as in former releases, amplitude of a slow sinusoidal waveform
>changes it with setting AC or DC coupling: when DC is set the amplitude
>is right but when the choice it is AC then amplitude it is wrong (little
>than before with the DC setting).
I think I expressed myself badly so I could be misunderstood.
What I wanted to write it was related to the the AC behavior in the low 
frequencies range about few Hz, I did not want to mean a software or 
hardware problem.
I just wanted to describe the AC behavior when inputs are affected by 
low frequency signals.
I know when AC coupling is selected then signal passes through a 
capacitor to reach input stage.
This capacitor's value is 61nF, so its impedance is 2,2Mohm @1,2Hz 
(261kohm @10Hz), nothing strange if there is attenuation with so low 
frequencies.
As I am already wrote, I am interested about the Welec's bandwidth so I 
wrote about the low frequencies behavior when AC coupling is set because 
other DSOs do not show it.
I am here only for this little clarification because I would not anyone 
thought that the cause is in the open source firmware, my clarification 
it is necessary.
See You later.
Please, apologize me for the imprecision.
Ich entschuldige mich für das Missverständnis.

Mit freundlichen Grüßen,

Luc

[Blue F. (blueflash)]

Hi Luc and all others,

thanks for testing and reporting.

Ext. trigger should be ok now. Freezing can normaly be solved by using 
Run/Stop button - I'm just searching for the reason...

AC coupling is only good for higher frequencies! For lower frquencies 
the input capacitors are working as high pass filters. So You have to 
choose DC coupling for lower frequencies.

kind regards

Hayo

[Blue F. (blueflash)]

Luc schrieb:
> 3)When there are changes on the bottom labels (i.e. using Cursors or
> Quick Measure), I get corruption on the bottom of the screen, sometimes
> even in upper and middle parts.
> This is even using USTB.

I'm checking this. Hope I can solve this soon.

Hayo

[Blue F. (blueflash)]

@Johannes

Ich habe den Linuxserver noch nicht aus dem Rack gezogen, aber ich habe 
mal einen weiteren Test unter Windows absolviert.

Hardware:
- Samsung Netbook NC10
- USB-RS232 Adapter

OS:
- WinXP Home 32bit

FW:
- BF.5.7

Der ungepackte Upload funktioniert einwandfrei, der UCL-Upload endet mit 
dem gleichen Fehler wie unter Linux. Kann das ein Timingproblem sein? 
Das Netbook ist natürlich langsamer. Der normale Upload dauert 250 
Sekunden gegenüber 160 Sekunden auf dem Fest-PC.

Gruß Hayo

[Johannes S. (demofreak)]

Naja, aktuell schreibe ich die Chunks grußlos ins DSO, weil der 
Dekompressor bisher keine Rückmeldung nach jedem Chunk liefert, könnte 
also durchaus sein.

Man könnte versuchshalber die Chunkgröße verringern bzw. nach jedem 
Chunk eine Pause einlegen, oder auch die Baudrate verkleinern.

Du kannst mal

- in Zeile 98 die Baudrate halbieren und damit testen, oder
- in Zeile 284 die Chunkgröße verkleinern, oder (bzw. und)
- vor Zeile 307 eine Zeile mit 'sleep 1;' hinzufügen.

Wenn eins davon anschlägt, haben wir schon mal eine Spur.

/Hannes

[Blue F. (blueflash)]

Johannes S. schrieb:
> Du kannst mal
>
> - in Zeile 98 die Baudrate halbieren und damit testen, oder
Das hat erwartungsgemäß nicht funktioniert, da keine Verbindung 
aufgebaut wird.

> - in Zeile 284 die Chunkgröße verkleinern, oder (bzw. und)
Damit bekomme ich das Ganze unter Linux zum Laufen. Ich habe mich von 
2048 bis 4095 nach oben gearbeitet. Alle Chunkgrößen laufen unter Linux 
bei mir. Nur 4096 mag er nicht.

Anders mit dem Netbook und dem RS232 Adapter (WinXP32). Hier bekomme ich 
den komprimierten Upload auch mit kleineren Chunkgrößen nicht zum 
Laufen. Bis 1024 habe ich getestet.

> - vor Zeile 307 eine Zeile mit 'sleep 1;' hinzufügen.
noch ungetestet


> Wenn eins davon anschlägt, haben wir schon mal eine Spur.
Ich würde sagen das ist eine heiße Spur. Ich habe bei mir unter Linux 
jetzt 4095 eingestellt. Nun muß ich beim Entwickeln nicht mehr so lange 
warten, da kommt man doch schneller voran.

Jörgs neuer Assembler-Dekompressor arbeitet dabei genauso gut wie die 
alten Routinen. Nur mit dem Assembler Dekompressor aber der Chunkgröße 
von 4096 geht es auch nicht. Die Chunkgröße ist hier also anscheinend 
der Schlüssel zum Erfolg.

Gruß Hayo

[Andreas W. (andiiiy)]

Hallo Ihr,

ich freu(t)e mich auch ein stolzer Besitzer eines W2024A zu sein.

Vielen Dank allen und besonders an blueflash für die letzte Version ich 
gerade aufgespielt hatte. GENIAL ....

Nun aber meine peinlichste Frage ...

Ich "D..." habe leider die Urdaten des Hersteller gelöscht. Wisst Ihr an 
welchen Stellen die Daten der Hardwarerevision und SN stehen??? Gibt es 
noch andere wichtige Parameter die gerätespezifisch sind???

Hat jemand eine Sicherung dieser Daten mit der Hardwarerevisionsnummer 
1C9, Softwareversion V1.4 und dem Oszityp W2024A?

Ich wäre dem Retter zu tiefstem Dank verpflichtet ...

Gruß Andreas

[Blue F. (blueflash)]

Andreas W. schrieb:
> Hallo Ihr,
>
> ich freu(t)e mich auch ein stolzer Besitzer eines W2024A zu sein.
Willkommen im Club.
>
> Nun aber meine peinlichste Frage ...
>
> Ich "D..." habe leider die Urdaten des Hersteller gelöscht.
Wie hast Du das denn gemacht?

> Wisst Ihr an
> welchen Stellen die Daten der Hardwarerevision und SN stehen???
Das ist eigentlich im FPGA fest eingebrannt - zumindest nach meinen 
Erkenntnissen.

> Gibt es noch andere wichtige Parameter die gerätespezifisch sind???
Ja, die Registerwerte im Protected Flash. Aber auch die sind nicht so 
leicht zu löschen. Wenn Du das geschafft hast wüßte ich gerne wie!

> Hat jemand eine Sicherung dieser Daten mit der Hardwarerevisionsnummer
> 1C9, Softwareversion V1.4 und dem Oszityp W2024A?
Eine kleine Übersicht von verschiedenen Revisionen und deren Besitzer 
findest Du hier:

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


> Ich wäre dem Retter zu tiefstem Dank verpflichtet ...
Das sollte kein Problem sein.

Meine beiden sind leider 8C7 Geräte bei denen die Register anders 
gesetzt werden. Die Registersettings der 1C9 Geräte ist mir aber 
bekannt. Zur Not kann man die erzwingen. So oder so kriegen wir das 
schon hin.

Gruß Hayo


p.s. ich sehe gerade, dass Crazor eines seiner Geräte in der Bucht 
anbietet. Wer also noch aufspringen möchte...

[Jürgen (Gast)]

Hayo W. schrieb:
>> Wisst Ihr an
>> welchen Stellen die Daten der Hardwarerevision und SN stehen???
> Das ist eigentlich im FPGA fest eingebrannt - zumindest nach meinen
> Erkenntnissen.

Hallo Hayo, hallo Andreas W.,

ich erinnere mich dunkel, daß ich schon mal diesbezüglich geforscht 
hatte. Habe auch das betreffende Dateifragment gefunden. Es war fast 
exakt vor 3 Jahren :-) Damals hatte ich den Welec-Updater-Abzug meines 
W2024A zur Verfügung gestellt und irgendwie durch Vergleich zwischen 
W2012A und W2024A herausgefunden, wo der Unterschied liegt:
Offenbar ist das auch im Flash gespeichert und nicht nur im FPGA. 
Beiliegend eine kurze Datei zum Löschen der Seriennummer. Kann 
allerdings im Moment nicht nachvollziehen wie das exakt funktionierte. 
Die Datei stammt aus dem alten Backup. Anhand der Adressen sollte sich 
herausfinden lassen wo die Daten liegen. Das müsste ich mir morgen 
nochmal ansehen, falls Interesse besteht.

Gruß
Jürgen

[Blue F. (blueflash)]

Hast Recht,

ich habe das mit der Hardwareversion verwechselt. Seriennummer und auch 
die anderen Herstellerdaten liegen im Protected Flash. Sollte man das 
löschen ist das unwiederbringlich weg.

Hört sich schlimm an, ist es aber nicht. Dei Seriennummer braucht man 
für nix (wenn man die irgendwo aufgeschrieben hat kann man sie auch 
wieder reinbrennen), das Modell kennt man ja bzw. wird beim Start selbst 
ermittelt und die Registerwerte sind bekannt und können restauriert 
werden.

Sollte also bei jemandem das Protected Flash defekt sein (gelöscht oder 
falsch restauriert) gibt es zwei Möglichkeiten. Entweder ein 
Komplettbackup eines identischen Gerätes einspielen oder(und) ich kann 
eine spezielle FW-Version zusammenbauen die diese Werte individuell 
wiederherstellt (mit Seriennummer nach Wunsch).

Gruß Hayo

[Andreas W. (andiiiy)]

Hallo Hajo, hallo Jürgen,

ich freue mich über die schnellen Antworten.

Bitte fragt lieber nicht wie ich das geschafft habe ... meine Frau lacht 
schon, da sie Ihren Perfektionisten noch nie so gesehen hat.
Ich glaube das ist das erste Gerät wo ich nur die hälfte des 
Flash-Speichers ausgelesen habe ... mit einer großen Rachekeule.

Löschen war ganz einfach ... e00040000 bis e7F0000 ... nun ist alles 
leer ;-)  (schön wenn man noch selbst lachen kann)

Mit der Seriennummer habe ich gestern auch noch einmal die Quellen 
durchforstet:

void AMDFlash::Write_Protected_Flash(void)
...
Flash_Protect_Buffer[0] = 0xFF2332FF;              // Kennung
Flash_Protect_Buffer[1] = tc_model;                // model 2012, 2022 
...
Flash_Protect_Buffer[2] = tc_serial;               // serial nr (1 = 
0x0)

wobei
#define protected_Config_Flash    (unsigned long *)  0x000F0000
unsigned long tc_hw_sw_version =    0x00000000;    // Type     0 = W2012 
1 = W2014 2 = W2022 3 = W2024


Ich denke ich werde jetzt mal auf die Besitzer der Hardware 1C9 hoffen 
und dann noch einmal alles zurückspielen.

[Andreas W. (andiiiy)]

Hallo Hajo,

das wäre ja die beste Idee.

Gibt es denn noch andere geräteabhängige Einstellungen?

Logisch wären mir z.B.:
* Anzahl der Kanäle also Typ
* Seriennummer (meine war mal 1305)
* Production Lot 1 und 2 (sieht aus als wenn diese nur angezeigt und 
gesendet wird)
* shipment date (genauso)

Was wäre denn noch wichtig zu wissen?

Gruß Andreas

[Andreas W. (andiiiy)]

Hayo natürlich mit "y" ... Tschuldigung

[Rainer W. (rawi)]

Hallo Andreas,

ich habe hier ein W2024A mit HW 1C9.0L. Mein Backup ist tief verkramt, 
aber ich könnte dir den relevanten Speicherbereich runterziehen. Was 
hättest du denn gerne?

[Andreas W. (andiiiy)]

Hallo Rainer,

um sicher zu gehen, wäre ich über den ganzen Inhalt sehr dankbar.

Da ich den komplette Inhalt zerstört habe, vermute ich noch wichtige 
andere Teile an die ich jetzt noch nicht denke. Wenn Du Hayo's letztes 
Flash drauf hast, könntest Du diesen Bereich weglassen.

Ich wäre Dir absolut dankbar und ich könnte bald dieses gute Stück 
wieder nutzen.

Gruß Andreas

[Blue F. (blueflash)]

Ja, spiel ein Komplettbackup ein. In einem anderen Teil des Flashs 
liegen auch noch die Bitmaps für das WELEC-Logo. Die werden sonst beim 
Start nicht angezeigt, was nicht schlimm ist, aber es soll ja alles 
korrekt sein ;-).

Wenn noch was klemmt können wir das dann Stück für Stück aus dem Weg 
räumen.

Gruß Hayo

p.s. ...und wenn es Dich tröstet, bei mir (und einigen Anderen) hat es 
auch so angefangen. Ich hab mir beim Upload das Flash zerschossen - nur 
war damals dieses ganze Projekt nicht soweit. Da hat mir dann auch 
jemend mit einem Backup weitergeholfen und für mich war es der Ansporn 
dieses Projekt ins Leben zu rufen.

[Rainer W. (rawi)]

Hallo Andreas,

nach dem letzten von Hayo beigelegten W2000A Programmers Reference V8.06 
müßten nach meinem Verständnis die folgenden drei Bereiche ausreichen:
000F0000 .. 000FFFFF
006C0000 .. 006EFFFF
007D0000 .. 007FFFFF

Probier's doch erstmal damit.

Hayo, vielleicht kannst du zu den relevanten Speicherbereichen sonst 
noch was sagen.

Gruß
Rainer

[Andreas W. (andiiiy)]

Hallo Rainer,

vielen Dank.

Ich werde mal alle Bereiche löschen und dann die von Dir zur Verfügung 
gestellten Quellen einspielen.

Danach Hayo's letzte Version...

Ich hoffe so ...

Gruß Andreas

[Blue F. (blueflash)]

Die ersten beiden würden schon reichen. Der letzte Teil ist nicht 
zwingend notwendig da diese Werte durch Defaultwerte beim Start versorgt 
werden wenn nichts Vernünftiges gefunden wird.

Hayo

[Rainer W. (rawi)]

Andreas W. schrieb:
> Ich werde mal alle Bereiche löschen und dann die von Dir zur Verfügung
> gestellten Quellen einspielen.

@Andreas
Der Löschbefehl steht vorne schon mit drin.
Viel Erfolg.

@Hayo
Das gibt dann ja einen sehr handlichen Wiederbelebungs-Kit.
Danke für die Info.

Gruß
Rainer

[Andreas W. (andiiiy)]

Die Daten werden gerade geschrieben...

Leider habe ich ab und zu einen Timeoutfehler und muß den Teil noch 
einmal schreiben.

Ich melde mich wieder wenn alles geschrieben ist!

Danke und Gruß Andreas

[Blue F. (blueflash)]

Ich verschwinde mal wieder in den Keller - Renovierung steht an. Schau 
nachher nochmal rein.

Hayo

[Andreas W. (andiiiy)]

Es gab ein kurzes Lebenszeichen nach folgendem Vorgehen:

1. alle Bereiche noch einmal gelöscht
2. vom Rainer alle 3 Dateien eingespielt (obwohl die Teilbereiche noch 
einmal gelöscht wurden)
3. vom Hayo die letzte Version eingespielt
4. Reboot

... Startbildschirm und danach Wechsel in den normalen Screen (mit 
Fehlern).
Dann waren in Abständen einige undefinierte Streifen zu sehen und es war 
keine Bedienung mehr möglich. Nach einem Reboot bleibt der Bildschirm 
schwarz mit aktiver Hindergrundbeleuchtung.

Zum Timeoutfehler kann ich sagen, dass dieser nur unter Win7 kommt. 
Deswegen habe bin ich auf meine XP-Partition gewechselt.

Alles noch einmal durchgeführt ... aber ohne Erfolg (diesmal mit einem 
Foto in der Hand - brachte nur nichts).

Ich würde den Rainer noch einmal um ein komplettes Backup bitten. Evtl. 
ist da noch etwas was ich(wir) übersehe(n).

Gibt es einen Ort auf der Platine wo die Hardwarerevision steht - nur um 
noch einmal sicher zu gehen?? Gesehe habe ich derzeit nur solche Angaben 
wie beim Rainer ... V1.03 2006  10C6 (2DS54L 0022 W2024).

Gruß Andreas

[Rainer W. (rawi)]

Andreas W. schrieb:
> Nach einem Reboot bleibt der Bildschirm
> schwarz mit aktiver Hindergrundbeleuchtung.

Das ist ja sehr bedauerlich.

Andreas W. schrieb:
> Ich würde den Rainer noch einmal um ein komplettes Backup bitten. Evtl.
> ist da noch etwas was ich(wir) übersehe(n).

Ich habe den Sauger mal angeschmissen, soll noch 40 Minuten dauern, 
falls die Anzeige stimmt.

[Andreas W. (andiiiy)]

VIELEN DANK ... ich bin dann mal gespannt.

Gruß Andreas

[Rainer W. (rawi)]

Das ist das komplette Backup incl. Firmware 1.2 BF 5.6.
Bin gespannt, ob das was nützt. Drück dir die Daumen. Eigentlich kennt 
Hayo den Flash ganz gut ;-)

Gruß
Rainer

[Andreas W. (andiiiy)]

Ich werde Euch informieren ... oder ich bin dann auch im Keller mit 
Oszi-Überreste ;-)

Gruß

[Blue F. (blueflash)]

Womit flashst Du?

Perl Skript komprimiert/unkomprimiert?

Gruß Hayo

[Andreas W. (andiiiy)]

OH OH ... 2 Stunden und 28 Minuten

... leider ohne Erfolg.

Kann ich überhaupt eine Flash-Datei mit Perl-Script erstellt mit dem 
Welec Updater V0.4.8A22 verwenden ???

Gruß Andi

[Andreas W. (andiiiy)]

Wenn ich mir die zurück gelesenen Daten (nur mal ein kleiner Teil) 
ansehe, dann kann ich keinen Unterschied erkennen. Mich wundert, dass 
die Hardware beim Booten nicht richtig angesprochen wird (schalten der 
Relais).

Noch mal meine Frage zur Hardwareversion. Kann man das auf dem Mainboard 
auch erkennen?

Gibt es evtl. noch Ideen?

Gruß Andi

[Martin H. (martin_h85)]

Hallo Andreas,

ich hatte vor kurzem das gleiche Problem mit meinem W2014. Ich habe dann 
das Backup von brandiac aus dem Thread :

http://sourceforge.net/apps/phpbb/welecw2000a/viewtopic.php?f=5&t=53

geflasht. Dabei habe ich es über USB  mit dem USBBlaster per JTAG 
geflasht. Leider kenne ich den Unterschied zwischen dem 2014 und dem 
2024 nicht aber bei mit lief es danach wieder.

Ich hoffe das es bei dir genauso funktioniert.

Gruß,
Martin

[Andreas W. (andiiiy)]

@Hayo,

Hayo W. schrieb:
> Womit flashst Du?

jetzt auch mit dem Perl-Script ... (superschnelle 2400 sek. für alles)

> Perl Skript komprimiert/unkomprimiert?

perl GERMSloader.pl -d COM1 -w XYZ.backup

Gruß Andi

[Andreas W. (andiiiy)]

Hallo Martin, hallo Hayo,

ja auch mit dem Perl-Script gibt es kein Erwachen mehr. Die neue 
Updatedauer mit dem Script liegt bei 1163.2 Sekunden.

@Matin
Die beiden Geräte unterscheiden sich nur in der Bandbreite ...
2014 ... 4 Kanal mit 100 MHz
2024 ... 4 Kanal mit 200 MHz

Ich frage mich nur wie die FW des FPGA's teilweise weg sein soll. Ich 
hatte auch das originale Welec-Update-Tool per USB verwendet. Das war 
vermutlich mein Fehler ...

Da kann ich jetzt nur noch auf die Suche nach dem Abbild des FPGA's 
machen. Oh wie bitter ... ich glaube da brauche ich noch weitere Hilfe.

Gruß Andi

[Martin H. (martin_h85)]

Hallo Andreas,

Ist der Unterschied eigentlich nur die FW oder ist auch die HW anders 
bei der 200Mhz Version als bei dem 100Mhz Modell ?


Gruß,
Martin

[Andreas W. (andiiiy)]

Martin H. schrieb:

> Ist der Unterschied eigentlich nur die FW oder ist auch die HW anders
> bei der 200Mhz Version als bei dem 100Mhz Modell ?

"Das würde drauf hindeuten, dass der HW-Unterschied zwischen W2014 und
W2024 nur in der Bestückung(Bauteilauswahl) liegt."
@ Beitrag "Wittig(welec) DSO W20xxA Hardware"

Ich denke Hayo hat bestimmt die bessere Antwort!

@Hayo,

Da ich mir nun mit nichts mehr sicher bin, möchte ich noch einmal die 
Frage nach der Hardwareversion stellen. Kann ich diese auf dem Board 
erkennen?

Nicht das ich schon so viel geflasht habe, dass ich völlig auf dem 
Holzweg bin. Was natürlich dagegen spricht ist das kurze Laden des 
Startbildschirmes nach den ersten Quellen vom Rainer.

FPGA muss die allerletze Option sein. Wobei mir der Eintrag vom Martin 
wieder etwas Mut macht...

Gruß Andi

[Blue F. (blueflash)]

Hi Andi,

bin grad erst vom Griechen zurück (die Anderen kennen das ja schon) und 
muß jetzt dringend in die Badewanne ne Runde rauspaddeln ;-).

Ich melde mich morgen noch mal dazu.

Guats Nächtle
Hayo

[Michael D. (mike0815)]

Martin H. schrieb:

Hallo Martin,
>
> Dabei habe ich es über USB  mit dem USBBlaster per JTAG
> geflasht. Leider kenne ich den Unterschied zwischen dem 2014 und dem
> 2024 nicht aber bei mit lief es danach wieder.

Ist ja interessant, das du über USB flashen konntest!
Der USB-Blaster-Treiber ist ja klar. Was heißt per JTAG geflasht???
Über USB-Kabel mit dem Quartus-Programmer, oder wie? Weil der 
JTAG-Hesder ist ja auf dem Mutterbrett vom DSO.
>
Gruß Michael

[Martin H. (martin_h85)]

Hallo Michael,

Ja genau. Ich habe erst mit dem HID-Inf Treiber das gerät in den Nios 
Dev Board Modus versetzt und danach die Treiber aus dem Quartus 
Programmer genommen.

Danach kann man das Oszi mit dem Quartus Programmer flashen. Die 
Beschreibung dazu steht auch im Wiki bei dem Upgrade von W2000 zum 
W2000A.


Gruß Martin

[Michael D. (mike0815)]

Martin H. schrieb:
> Hallo Michael,
>
> Ja genau. Ich habe erst mit dem HID-Inf Treiber das gerät in den Nios
> Dev Board Modus versetzt und danach die Treiber aus dem Quartus
> Programmer genommen.
das geht ja klar! Mit dem Treiber geht dann halt die Software vom Welec 
nicht mehr, aber die ist ja eh' für die Füsse!
Mit dem Quartus habe ich das Leon3 immer mal aufgespielt.
Leider geht die Entwicklung nicht mehr weiter, schade auch...
>
> Danach kann man das Oszi mit dem Quartus Programmer flashen. Die
> Beschreibung dazu steht auch im Wiki bei dem Upgrade von W2000 zum
> W2000A.
Entweder bin ich zu doof, ich finde das nicht. Hast du einen Link dafür?

Gruß Michael

[Martin H. (martin_h85)]

Nabend Michael,

hier der Link :

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

dort steht eigentlich fast alles, außer die Bedienung der Quartus 
Programmer.


Gruß,
Martin

[Michael D. (mike0815)]

Martin H. schrieb:
> Nabend Michael,
nabend Martin,
>
> hier der Link :
>
> http://sourceforge.net/apps/trac/welecw2000a/wiki/Upgrade
>
den kenne ich ja schon...
> dort steht eigentlich fast alles, außer die Bedienung der Quartus
> Programmer.
Ja, eben.
Wie ich das Leon in das RAM bekomme, weiß ich ja.
Nur wie die Soft bzw. FW per Quatus über USB ins Flash kriege, wäre eine 
Hilfestellung sehr hilfreich, bevor man Mist baut.

Könntest du vielleicht eine kurze Anleitung dazu geben, vielleicht mit 
ein paar Pics?
Also z.B. Quartusoberfläche, welche Häkchen gesetzt werden müssen, etc.

Die Installation vom Blaster usw. kann aussen vor bleiben, steht ja zu 
genüge, unter Anderem auch von mir, hier im Thread!

Es wäre auch für die anderen User, vorallem "Hayo", von Interesse!
Da es sehr oft in der Vergangenheit, Probleme mit der RS232 gab und man 
eine Alternative zur Verfügung hätte.

Gruß Michael

[Martin H. (martin_h85)]

Nabend,

Leider musste ich das auch durch testen herausfinden :)

Aber hier die Liste:

1. Unter dem Installationspfad folgendes Programm Starten 
qprogrammer\bin\quartus_pgmw.exe
Du solltest dann den Quartus 2 Programmer vor dir haben

2. In der linken oberen Ecke gibt es einen Button "Hardware Setup" den 
anklicken und unter  "Current selected Hardware" das Nios Dev Board 
auswählen, dann auf close

3. Anschließend gehst du auf "Add File" und wählst die .jic Datei aus 
die du flashen möchtest, jetzt sollte in dem oberen Feld der FPGA und 
das Flash angezeigt werden

4. Hinter den neuen Daten gibt es nun Checkboxen, Programm und Verify, 
die aktivierst du nun, ausgegraute kannst du ignorieren.

5. Dann auf Start und abwarten bis oben nur noch 100 % und Sucessfull 
steht

6. Fertig :)


Gruß,
Martin

[Michael D. (mike0815)]

Martin H. schrieb:
> Nabend,
>
> Leider musste ich das auch durch testen herausfinden :)
Sonst wird's ja langweilig...  ;-)
>
> Aber hier die Liste:
>
> 1. Unter dem Installationspfad folgendes Programm Starten
> qprogrammer\bin\quartus_pgmw.exe
> Du solltest dann den Quartus 2 Programmer vor dir haben
Ist klar.
>
> 2. In der linken oberen Ecke gibt es einen Button "Hardware Setup" den
> anklicken und unter  "Current selected Hardware" das Nios Dev Board
> auswählen, dann auf close
Ist auch klar.
>
> 3. Anschließend gehst du auf "Add File" und wählst die .jic Datei aus
> die du flashen möchtest, jetzt sollte in dem oberen Feld der FPGA und
> das Flash angezeigt werden
Und da hängts! Quartus frist ja nur: pof, sof, jam, jbc, ekp, usw.

Woher bekommst du denn eine ".jic" ???
Konvertierst du voher die .flash, oder wie komst du dazu?
Jetzt wird's spannend, solange bleibe ich noch wach. :-)
>
> 4. Hinter den neuen Daten gibt es nun Checkboxen, Programm und Verify,
> die aktivierst du nun, ausgegraute kannst du ignorieren.
Die Checkboxen gehen auch klar.
Anzumerken wäre noch, das wenn "Auto-Detect" gedrückt ist, das dann das 
Device angezeigt wird, in unserem Fall wäre es: EP2C35
Soweit ich weiß, sollte das vorher aus dem Fenster entfernt werden.
>
> 5. Dann auf Start und abwarten bis oben nur noch 100 % und Sucessfull
> steht
So sollte es dann sein...
>
Gruß Michael

[Martin H. (martin_h85)]

Guten Morgen Michael,

ich war dann doch mal schlafen gegangen.

das .jic File habe ich aus einem Backup das jemand mit dem Quartus 
Programmer gemacht hat.

Bei dem Auto Detect wird der Flash Chip nicht mit erkannt, den muss man 
um ein Backup zu machen noch selbst hinzufügen.
Wenn man allerdings ein fertiges .jic File hat weis er automatisch das 
dort ein Flash ist.

Wie man nun aus den Flash Dumps ein .jic File baut weis ich leider 
nicht, ich arbeite auch erst seit 2 Wochen mit Quartus :)

Es gibt im Sourceforge Forum einige Backups in dem Format. daher hatte 
ich meins auch.


Gruß,
Martin

[Michael D. (mike0815)]

Moin Martin,
das Quartus ist schon sehr umfangreich, konnte es nicht lassen und habe 
das gestern noch mal unter die Lupe genommen.

@Hayo
Wäre auch für dich interessant, da kann man dem Altera bis in die 
Gedärme glotzen, wahrscheinlich auch unter Anderem zu reparaturzwecken. 
Bekommst du es mittlerweile zum laufen?

Ich hatte mal die Möglichkeit mit dem Quartus das Flash zu konvertieren, 
ist leider beim Update und "Supergau" einer meiner Festplatten mit weg 
geflogen! Du weißt nicht zufällig welches Altera-Tool das war?

Was heisst einige Backups? Ein Link dahin, wäre schick!
Sind denn da auch die Aktuellen FW's ausgestellt?

Gruß Michael

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

Ihr macht ja abgefahrene Sachen!
Das muß ich bei Gelegenheit auch mal lernen, wenn's in Richtung FPGA 
geht.
Könnt ihr dem Rest der Welt den Gefallen tun und ggf. die Anleitung im 
Wiki pflegen?

Viele Dank
Jörg

[Martin H. (martin_h85)]

Guten Tag Jörg,

Das kann ich gerne machen. Habe nur leider selbst erst ein begrenztes 
Wissen über das Thema.

Gruß,
Martin

[Blue F. (blueflash)]

@Andi

Sorry, bin heute zu nichts gekommen - habe aber Deine Notlage nicht 
vergessen.

Also zum Flaschen - wenn Du mit einem der Upload Tools geflasht hast 
kann Dein FPGA eigentlich nicht beschädigt sein. Das schafft man nur mit 
dem Altera Programmer. Dass das Rückspielen des Flash nicht gleich beim 
ersten Mal erfolgreich ist, ist auch nicht ungewöhnlich - ich hab mir 
das auch schon öfters zerschossen bei meinen Experimenten und dann erst 
nach einigen Anläufen wieder hingekriegt.  Grundsätzlich kannst Du 
Backups aller Hardwareversionen einspielen um Dein Gerät 
wiederzubeleben. Wenn die Registereinstellungen dann nicht passen, kann 
es aber sein, dass Du Spikes auf dem Signal hast, das ist aber auch 
schon alles. Wenigstens läuft es dann wieder.

Interessant wäre noch, ob es an Deinem seriellen Port liegen könnte. 
Hast Du die Möglichkeit das auf einem anderen Rechner zu probieren? Die 
Serielle kann da unter Umständen etwas bockig sein.

Ich habe gerade eine Mail von Klaus erhalten der neu zu unserer Gemeinde 
gestoßen ist und sich anbietet ein Komplettbackup seiner 1C9 Version zur 
Verfügung zu stellen. Da hättest Du dann eine zweite Möglichkeit ein 
frisches Backup einzuspielen.

Gruß Hayo

[Michael D. (mike0815)]

Hallo Andreas.

Ich habejetzt ein wenig mit dem Quartus-Programmer herum experimentiert.
Dabei habe ich natürlich mein Welec quasi "abgeschossen", na toll...
@Martin
...das war dein Original.jic
Das Teil ist 2049kB groß, was ein Quartus-Dump ja auch ist, nur konnte 
ich danach nicht mehr die FW's aufspielen, da der Germsmonitor per 
Tasten, nicht mehr zu aktivieren war!  :-(((
Ebenfalls geht das auch nicht, wenn der Quartus-Programmer das DSO per 
USB in den Programmiermodus versetzt hat. Es lässt sich die RS232 nicht 
mehr ansprechen, keine Ahnung warum das so ist, vielleicht wird die 
dadurch blockiert?!?

Eigentlich wollte ich ins Bett, hat mir aber keine Ruhe gelassen und das 
Teil wieder zum Leben erweckt!

Also, Festplatte durchsucht und einen originalen Dump von meinem DSO 
(2009) im .jic Format gefunden, den ich damals mal gezogen hatte.
Das Teil geladen, benötigte Haken gesetzt und in einer Minute war der 
Dump im Device EP2C35 mit EPCS16 .

Anbei mal ein Shot

Morgen Abend kann ich, wenn Interesse besteht, eine kurze Anleitung 
geben, wie man einen kompletten Dump mit dem Quartus-Programmer über USB 
zieht, hab's gerade heraus gefunden. ;-)

Gruß Michael

[Martin H. (martin_h85)]

Guten Tag,

@Michael
Entschuldige, ich wollte dir damit nur helfen. Das Backup konnte ich 
leider nie testen da ich ein 4 Kanal Oszi habe, und es für das 2-Kanal 
ist.
Wenn ich dir bei der Anleitung helfen kann sag bescheid, ich war noch 
nicht dazu gekommen selbst eine zu schreiben. Irgendwo im Wiki habe ich 
glaube ich auch schon eine gesehen, es fehlten blos ein paar Punkte.


Vielleicht sollten wir einfach mal eine Backup DB im Wiki machen, ich 
weis nur nicht ob es da rechtlich irgendwelche Bedenken gibt.
Aber das Würde sicher einigen hier weiterhelfen.


Gruß,
Martin

[Andreas W. (andiiiy)]

Oh ja ;-)

@Hayo,

ich versuche gerade noch einmal das Backup mit einem anderen USB/RS232 
Wandler (mit FTDI-Chip) einzuspielen. Wenn das nicht gelingt, wäre ich 
über die Backup-Alternative sehr begeistert.

Die angezeigte Übertragungszeit ist mit diesem Wandler deutlich höher 
... ca. 4000 Sekunden!

Das Thema mit dem FPGA habe ich mir auch so gedacht. Kennst Du einen 
Fall wo die RS232 erreichbar (inkl.Loader) und die FPGA-FW nicht in 
Ordnung war?

Danke erst einmal für das Mut machen ... wir hören uns nach der 
Einspielung ...

Gruß Andi

[Andreas W. (andiiiy)]

@Hayo,

nach 3000 Sekunden erfolglos ...

Gruß Andi

[Klaus H. (klausmh)]

Hallo,

wie Hayo schon weiter oben beschrieben habe ich seit einer Woche auch 
ein W2024 bei Welecgmbh "geschossen".

Nach kurzem Einschalten und an allen Knöpfen gedreht gleich mal ein 
Vollbackup gezogen und Hayos neuste SW (--.5.6C2) eingespielt - welch 
ein Unterschied.

DANKE HAYO!!!

Zur Zeit habe ich es wieder zerlegt und warte bis ich eine ruhige Hand 
habe um die 0603er SMDs (24,9 u. 150 Ohm) einzulöten.

Fotos des Umbaus kommen später im HW-Thread.

Bis dahin ein weiteres Vollbackup - vielleicht hilft es einigen.


Daten:
W2024A
HW: 1C9.0E
SW: 1.4



Bis dann Gruß
Klaus

[Blue F. (blueflash)]

Um es noch mal deutlich zu sagen für alle die noch so mitlesen und 
überlegen ob sie die Open Source Firmware einspielen sollen:

- Das original WELEC-Updateprogramm welches über USB die WELEC Firmware
  flasht, ist nicht geeignet für die OS-Firmware!

- Das Hochladen der Open Source Firmware geschieht über die
  RS232-Schnittstelle und das mitgelieferte 1:1 RS232 Kabel.

  Als Uploadsoftware kann man den alten WELEC-Updater von Markus nehmen,
  dieser ist aber extrem langsam.

  Empfehlenswert ist die Installation von Perl und dem WIN32:Serial 
Port.
  Damit kann das beigelegte Perlsktipt verwendet werden, dass schnell
  und sicher arbeitet.

Der Uploadvorgang wird immer eingeleitet durch das Aktivieren
des GERMS-Monitors. Das geschieht durch das Drücken der beiden linken 
Funktionstasten (erst die ganz linke und halten, dann die zweite). Der 
Bildschirm leuchtet dann kurz weiß auf und wird dann schwarz. Wenn das 
nicht funktioniert ist etwas an der FPGA-Konfiguration nicht in Ordnung.

Gruß Hayo

[Andreas W. (andiiiy)]

@Hayo,

der 2. Versuch per Perl-Script mit dem vom Klaus freundlicherweise zur 
Verfügung gestellten Download war auch NICHT erfolgreich (per RS232!!!).

Nach einem Neustart zuckt das Gerät überhaupt nicht. Es leuchtet die 
Hintergrundbeleuchtung und mehr nicht!!!

Gruß Andreas

[Blue F. (blueflash)]

Das ist aber sehr ungewöhnlich. Ist die RS232 bei Dir in Ordnung? 
Welches Perl hast Du installiert?

Hast Du evtl. mit dem Altera-Programmer vorher rumgespiuelt und dabei 
die FPGA-Konfiguration abgeschossen?

Gruß Hayo

[Andreas W. (andiiiy)]

Erste Lebenszeichen ...
Start der Version vom Klaus ... aber nur im geöffneten Zustand ohne 
Lüfter ohne sichtbare Darstellungsfehler und mit 4 Kanälen!

So ein Mist ... also könnte es noch ein Hardwareproblem zusätzlich sein!

ABER ... es sind die Eingänge mit sehr großen Signalen zu sehen bzw. 
füllen die Signale die komplette Bildschirmoberfläche!
Leider hatte es wieder zusammengeschraubt um ein Foto zu machen ... aber 
nun startet das Gerät wieder nicht.

@Hayo,
Hättest Du eine Erklärung für diese Signaldarstellung?

Gruß Andi

[Andreas W. (andiiiy)]

@Hayo,

ich hatte noch KEINEN Altera am Gerät!!!

Grüße Andi

[Blue F. (blueflash)]

Also nach Deinen Schilderungen ist ein Hardwareproblem nicht 
auszuschließen. Beliebt sind schlechte Lötverbindungen an den RAM 
Bausteinen. Diverse Berichte zu dem Thema sind im Hardwareforum zu 
finden.

Die hartnäckige Weigerung Wiederbelebungsmaßnahmen anzunehmen könnte 
darauf hindeuten. Das Zusammentreffen mit dem Löschen des Flashs ist 
aber schon sehr ungewöhnlich.

Wenn es vor dem Zusammenbau funktionierte und danach nicht mehr deutet 
das auf jeden Fall darauf hin, dass es nicht nur das Flash ist. Stecken 
alle Steckverbindungen richtig zusammen? Man kann da auch schnell um 
eine Pinreihe verrutschen ohne es zu merken.

Andreas W. schrieb:
> ich hatte noch KEINEN Altera am Gerät!!!

Das ist die Windows Software zum Programmieren des FPGA und der 
Peripherie.
Also kein externes Gerät. Aber dann sollte es irgendwie hinzukriegen 
sein. Man kann also davon ausgehen, dass das FPGA und die Peripherie in 
Ordnung sind.

Als Erstes muß dann das Flash in einen stabilen Zustand gebracht werden. 
Dafür ist das Backup von Klaus sicher am Besten geignet. Alternativ kann 
ich auch noch Backups zur Verfügung stellen.

Probiere doch mal Folgendes:

- spiele das Backup von Klaus ein
- dann das protected Flash von Rainer drüber
- und zum Schluß die aktuelle Firmware

So ähnlich bin ich bei meiner Kiste auch vorgegangen als sie nicht mehr 
wollte.

Gruß Hayo

[Andreas W. (andiiiy)]

Hayo W. schrieb:
> Also nach Deinen Schilderungen ist ein Hardwareproblem nicht
> auszuschließen. Beliebt sind schlechte Lötverbindungen an den RAM
> Bausteinen. Diverse Berichte zu dem Thema sind im Hardwareforum zu
> finden.

Ja, die habe ich mit einer Reflow-Lötstation nachbearbeitet ...

> Wenn es vor dem Zusammenbau funktionierte und danach nicht mehr deutet
> das auf jeden Fall darauf hin, dass es nicht nur das Flash ist. Stecken
> alle Steckverbindungen richtig zusammen? Man kann da auch schnell um
> eine Pinreihe verrutschen ohne es zu merken.

Nee ...

> Probiere doch mal Folgendes:
>
> - spiele das Backup von Klaus ein
> - dann das protected Flash von Rainer drüber
> - und zum Schluß die aktuelle Firmware

erledigt ... ohne Erfolg ...

Alle Spannungen im Oszi nachgemessen ... i.O.

Gruß

[Michael H. (stronzo83)]

Hallo Andreas,
mein Oszi ist seit kurzem auch tot und ich weiß biser auch noch nicht 
was das Problem ist. Die Geschichte: Oszi ging nicht mehr, Fehlersuche 
brachte einen defekten MAX1967(Step-Down Regler) und einen kaputten 
FDS-6990A (Doppen n-FET) zu Tage. Kein Problem: die Teile getauscht, 
Oszi startete wieder. Also habe ich es glücklich wieder zusammengebaut 
und seitdem geht nichts mehr. LCD Backlight leuchtet, Run/Stop Button 
leuchtet. Germsmonitor scheint sich starten zu lassen, jedenfalls lädt 
das Perl Script nach wie vor die Firmware runter.

Die Spannungen habe ich bei mir auch nachgemessen. Dazu ein Zitat von 
mir aus nem anderen Thread 
(Beitrag "Re: Wittig- Oszi meldet sich nicht mehr"), in 
dem ich dazu gepostet habe:

"
Die Kernspannung des
1. FPGA liegt bei mir knapp unterhalb der zulässigen Untergrenze von
1,15V, beim zweiten messe ich sogar nur 1,07V. Gemessen direkt unter den
FPGAs an den Abblockkondensatoren für den Kern. Hier wieder die Frage:
hat jemand Vergleichswerte? Da es auf jeden Fall zu wenig ist, werde ich
die Versorgung mal überarbeiten und sehen, was passiert. Dasselbe
Problem ist übrigens auch bei den ADCs vorhanden: die digitale
Versorgung liegt direkt an der Grenze des Erlaubten (die werden direkt
aus dem 1.8V Schaltregler versorgt, der eine halbe Meile weit entfernt
sitzt...). Eventuell könnte das bei den Vierkanalgeräten die Probleme
auf Kanal 3/4 verursachen, würde mich jedenfalls nicht wundern.
"

Sind deine Kernspannungen auch zu niedrig?

Gerade wollte ich mein Original Dump File ins Oszi laden. Leider scheint 
das nicht zu klappen, der Welec Updater erkennt weder Seriennummer noch 
Hardware Revision des Gerätes. Wer ist so nett und sagt mir, wo die 
Daten hinterlegt sind? Im Protected Flash Bereich? Welches IC?
Im Logfile trägt das Programm in endloser Folge ein:
"14.03.2012 18:21:34 : Step : 0/67516 Timer redo the step"

Falls irgendjemand Ideen zur Reanimierung hat: hier habt ihr einen 
dankbaren Empfänger! Wie ist eigentlich der Germsmonitor realisiert? 
Soweit ich weiß ist er ja unabhängig vom Nios, wer kann mir mehr dazu 
sagen?

Gruß
Michael

[Andreas W. (andiiiy)]

Hallo Leidensgenosse ...

Michael H. schrieb:
> Hallo Andreas,
> mein Oszi ist seit kurzem auch tot und ich weiß biser auch noch nicht
> was das Problem ist. Die Geschichte: Oszi ging nicht mehr, Fehlersuche
> brachte einen defekten MAX1967(Step-Down Regler) und einen kaputten
> FDS-6990A (Doppen n-FET) zu Tage. Kein Problem: die Teile getauscht,
> Oszi startete wieder. Also habe ich es glücklich wieder zusammengebaut
> und seitdem geht nichts mehr.LCD Backlight leuchtet, Run/Stop Button
> leuchtet.

... genau wie bei mir!!!

Germsmonitor scheint sich starten zu lassen, jedenfalls lädt
> das Perl Script nach wie vor die Firmware runter.

... genau wie bei mir!!!

> Die Spannungen habe ich bei mir auch nachgemessen. Dazu ein Zitat von
> mir aus nem anderen Thread
> (Beitrag "Re: Wittig- Oszi meldet sich nicht mehr"), in
> dem ich dazu gepostet habe:
>
> "
> Die Kernspannung des
> 1. FPGA liegt bei mir knapp unterhalb der zulässigen Untergrenze von
> 1,15V, beim zweiten messe ich sogar nur 1,07V. Gemessen direkt unter den
> FPGAs an den Abblockkondensatoren für den Kern. Hier wieder die Frage:
> hat jemand Vergleichswerte? Da es auf jeden Fall zu wenig ist, werde ich
> die Versorgung mal überarbeiten und sehen, was passiert. Dasselbe
> Problem ist übrigens auch bei den ADCs vorhanden: die digitale
> Versorgung liegt direkt an der Grenze des Erlaubten (die werden direkt
> aus dem 1.8V Schaltregler versorgt, der eine halbe Meile weit entfernt
> sitzt...). Eventuell könnte das bei den Vierkanalgeräten die Probleme
> auf Kanal 3/4 verursachen, würde mich jedenfalls nicht wundern.
> "
>
> Sind deine Kernspannungen auch zu niedrig?

Ich werde die auch mal an der FPGA messen!

> Gerade wollte ich mein Original Dump File ins Oszi laden. Leider scheint
> das nicht zu klappen, der Welec Updater erkennt weder Seriennummer noch
> Hardware Revision des Gerätes. Wer ist so nett und sagt mir, wo die
> Daten hinterlegt sind? Im Protected Flash Bereich? Welches IC?
> Im Logfile trägt das Programm in endloser Folge ein:
> "14.03.2012 18:21:34 : Step : 0/67516 Timer redo the step"

Nee das geht nicht mehr mit dem originalen FW-Loader von Welec. Bitte 
mal die Anleitung in Hayo's aktueller Flash-Version und "Doc" nutzen. 
Dort ist der alternative Welec-Updater beschrieben.

Viel besser und schneller läuft das Perl-Script. Siehe ...
[[http://sourceforge.net/apps/trac/welecw2000a/wiki/FWupload]]

> Falls irgendjemand Ideen zur Reanimierung hat: hier habt ihr einen
> dankbaren Empfänger! Wie ist eigentlich der Germsmonitor realisiert?
> Soweit ich weiß ist er ja unabhängig vom Nios, wer kann mir mehr dazu
> sagen?
>
> Gruß
> Michael

Gruß Andi

[Andreas W. (andiiiy)]

@Hayo,

da ich ja nun nichts mehr so direkt falsch machen kann, würde ich noch 
einmal ein komplettes Backup von Dir nutzen wollen. Wäre das OK?

So jetzt versuche ich es erst einmal mit dem Selbstheilungseffekt ;-)

Gruß Andi

[Michael H. (stronzo83)]

Den Germsloader kenne ich, irgendwie hatte ich wohl das irrationale 
Bedürfnis, das Backup mit dem Welec Tool zu flashen...

Vorhin habe ich versucht, ein Backup hier aus dem Forum zu flashen. Der 
Flashvorgang lief erfolgreich durch aber es hat sich nichts geändert.
Mistding.

Morgen löte ich mal das Flash nach, vielleicht liegts ja daran - optisch 
sieht die Lötung aber gut aus.

Wenn das nichts bringt (wovon ich ausgehe) was dann?
Zunächst müssen ja die FPGAs konfiguriert werden, danach kann der NIOS 
seine Firmware aus dem Flash laden. Man müsste also einen Weg finden, zu 
bestätigen, dass die FPGAs korrekt konfiguriert werden, um das Problem 
auf den NIOS einzugrenzen.
Wenn der Flashspeicher des Nios das Problem ist, könnte man den ja auch 
tauschen...nur wüsste ich nicht warum er so plötzlich gestorben sein 
sollte.

Hast du schon versucht, ob du den Flashinhalt korrekt zurücklesen 
kannst? Meine Kiste ist gerade in sämtliche Einzelteile zerlegt, darum 
kann ich es selbst momentan nicht testen.

Gruß
Michael

[Andreas W. (andiiiy)]

@Michael,

ich hatte den Inhalt auszugsweise mal zurückgespielt.
Der Inhalt war gleich ...

Welche Hardwareversion ist Dein Modell? Welches Modell hast Du (wenn ich 
richtig gelesen habe einen 4-Kanal)?

Gruß Andi

[Blue F. (blueflash)]

Ich lade mal ein Backup von mir hoch, dauert aber ein wenig...

[Michael H. (stronzo83)]

Hm. Wenn der Inhalt des Flashs korrekt ist, dann müsste der Nios ja 
laufen...der NIOS selbst verwendet ja keine externen RAMs, richtig? 
Insofern müsste dann ja etwas an der FPGA Konfiguration schiefgehen oder 
es gibt ein Lötproblem an den FPGAs. Siehst jemand andere sinnvolle 
Ansatzpunkte?

Vielleicht schaffe ich es am Wochenende mal, eine Version des LEON 
Designs zu testen...so sollte sich doch herausfinden lassen, ob die 
FPGAs das tun was sie sollen.
So oder so werde ich aber auch die 1.2V Versorgung erneuern.

Gruß
Michael

[Michael H. (stronzo83)]

Achso, mein Oszi ist ein W2024A, die Hardwarerevision kann ich dir 
leider nicht nennen oder steht die auch irgendwo auf der Hardware?

Michael

[Blue F. (blueflash)]

Das ist von meinem 4 Kanaler ein Komplettdump mit der originalen 
Firmware 1.4 - ich benutze das immer wenn ich mal wieder sehen möchte 
was wir so geschafft haben. Man weiß ja schon gar nicht mehr was für 
Entbehrungen man früher auf sich genommen hat...   :-)

Wenn das bei Dir läuft brauchst Du nur den Protected Dump von Rainer 
drüberzubügeln, dann ist alles wieder im Originalzustand.

Drücke die Daumen

Hayo

[Blue F. (blueflash)]

Um sicher zu gehen habe ich den Dump mal eben bei mir eingespielt.

Erschreckend! So langsam und sooo schlecht hatte ich das gar nicht mehr 
in Erinnerung. Erschütternd...

Aber zum Upload. Also das funktionierte sofort.

Der Upload dauerte 411 Sekunden mit dem alten Perlskript 1.1.2 und das 
Gerät startete nach einem Reset sofort ohne Probleme. Der Dump ist also 
in Ordnung.

Gruß Hayo

[Blue F. (blueflash)]

Was noch von Interesse wäre - wenn das Gerät angeschaltet wird, gibt es 
da auf dem Terminal Meldungen aus? wenn ja welche -> bitte posten!

Gruß Hayo

[Michael H. (stronzo83)]

Hallo Hayo,
ich werde dein Dump mal testen, danke dafür. Muss ich dafür dem 
Perlscript besondere Parameter übergeben (Adressbereich o.ä.)?
Auf der seriellen tut sich beim Booten gar nichts, nur wenn man den 
Germsmonitor startet gibt es ein paar kümmerliche Lebenszeichen wie im 
anderen Thread von Rudolf und mir beschrieben. Schätze bei Andreas wird 
es das selbe sein...

Gruß
Michael

[Blue F. (blueflash)]

Nein, keine Parameter nötig. Die Adressen ergeben sich aus dem Inhalt 
des Dumps automatisch. Einfach die Batchdatei die Du sonst für den 
Upload benutzt auf den Dateinamen des Dumps anpassen und fertig.

Hayo

[Andreas W. (andiiiy)]

@Hayo,

ja auch bei mir wird nichts im Terminalmodus übergeben (beim normalen 
Start). Starte ich den GERMS-Modus kommt +C CPU3048 ...

Ich spiele jetzt mal Dein Update ein ... mal sehen.

Gruß

[charly (Gast)]

@Hayo

FW = 5.6C2
hab noch einen fehler gefunden, versuch mal:
X=2ns
nur Ch1 aktiv
und dann dreh mal Y nach unten, ganz viel, oder nach oben ganz viel,
oben kommt mann dann gar nicht mehr raus ;(

i hoff i hab das nachvollziehbar erklaert...

vlG
Charly

ps. koennen die anderen Mitleser es event. auch mal versuchen
nitt das es bei mir ein 'dummy' fehler ist

[Andreas W. (andiiiy)]

@Hayo, Michael,

ich muss mich verbessern - im Germsmodus ist nun nichts mehr zu sehen 
(Flash kann ich aber noch laden).
Das war mal ... scheint schon länger her zu sein. Ich hatte mir diese 
Meldung mal aufgeschrieben.

Gruß

[Michael H. (stronzo83)]

Hallo,
ich habe Hayos Dump gerade geflasht - nach wie vor kein Mucks von der 
Kiste.
D.h. bei Andreas wird es nicht anders aussehen.
Flash habe ich heute nachgelötet, natürlich auch hier keine Änderung. 
Auch sonst kann ich noch keine Probleme an der Hardware finden, 
abgesehen von der wie erwähnt zu niedrigen Kernspannung der FPGAs. Wenn 
nur endlich die Post mein Zeug bringen würde, dann könnte ich das 
endlich umbauen und entweder jubeln oder wieder einen Punkt abhaken.
Danach werde ich mir dann mal die FPGAs vornehmen, dann sehen wir mal 
weiter.

Gruß
Michael

[Andreas W. (andiiiy)]

Micha hat recht.
NIX geht ... ausser "RUN/STOP" LED ... ist ja schon mal was ;-)

Gruß

[Michael H. (stronzo83)]

Ich möchte mich jetzt mal daran machen, das FPGA Config Flash 
auszulesen,
mal sehen ob das klappt. Falls ich es auslesen kann, würde sich jemand 
finden, der meine Datei mit seinem Readout vergleicht? Oder hat jemand 
ein Dump seines W2024A Config Flashs zur Hand, das ich testweise 
reinladen könnte?

Schonmal danke für eure Hilfe!

Michael

[Blue F. (blueflash)]

Bei meinem Dump war auch Config und Protected Config dabei. Ist zwar für 
8C7, aber laufen tun die 1C9 auch damit. Haben nur einige Spikes auf dem 
Signal.

Wenn ich das richtig verstanden habe habt Ihr aber eigentlich 
unterschiedliche Probleme oder?

Andi -> Irgendwie das Flash zerschossen und beim Auseinandernehmen 
irgendwas ausgelöst.

Stronzo -> mit dem Altera Programmer was weggeschossen...

Richtig?


Gruß Hayo

[Michael H. (stronzo83)]

Hallo Hayo,
den Altera habe ich noch nie verwendet. Bei mir ist ein Teil des 
Schaltnetzteiles gestorben (warum weiß wohl nur Wittig), nach Tausch der 
defekten Teile lief die Kiste in offenem Zustand aber nach Zusammenbau 
nicht mehr.
Die Vorgeschichte ist also eine andere als bei Andreas, aber die 
Symptome sind komplett identisch. Bei Rudolf ebenfalls exakt die gleiche 
Situation.

Gruß
Michael

[Blue F. (blueflash)]

Ach so, dann hatte ich die Posts über den Altera Programmer wohl 
mißverstanden. Aber dann ist das Problem doch zumindest eher 
einschätzbar.

Ich komme da noch mal auf die Pfostenleiste zurück die das Netzteil mit 
dem Mainboard verbindet. Da kann man beim Zusammenbau leicht um einen 
Pin oder eine Reihe verrutschen, was u.U. den Defekt von Teilen im 
Netzteil und oder dem Mainboard zur Folge haben kann.

Gruß Hayo

[Andreas W. (andiiiy)]

@Hayo

leider muss ich Dich enttäuschen - der Flashspeicher ist in Ordnung. Ich 
habe das komplette Programm geladen, Oszi ausgeschalten und Flash 
komplett gelesen.

Der einzige Unterschied lag wie erwartet in der Datumszeile ... siehe 
Bild.

Als nächstes versuche ich mal einen Speichertest durchzuführen. Hattes 
Du evtl. schon mal ein kleines Programm geschrieben??? Das wäre jetzt 
sehr hilfreich. Alternativ werde ich über den Germsloader auch den 
Speicher (RAM) beschreiben und gleich wieder lesen ... mal sehen was da 
raus kommt.

Gruß Andi

[Charly B. (charly)]

@Hayo

haste das mal versucht:

Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil5)"

oder ist es hier 'untergegangen' ?

vlG
Charly

[Blue F. (blueflash)]

@Andii

Jörg hat glaube ich für das OSOZ-Projekt einige kleine Testroutinen 
geschrieben die man dafür mißbrauchen könnte. Am besten Jörg direkt 
drauf ansprechen da er hier den besseren Überblick hat. Damit kann man 
gezielt bestimmte Funktionen des Oszis ansteuern. Notfalls kann ich das 
auch raussuchen, das dauert aber etwas weil ich momentan kaum Zeit habe.


@Charly

Nein ist nicht untergegangen. In der neuen Version die ich gleich 
rausgebe (mit neuem Treiber) konnte ich das nicht mehr feststellen.


Gruß Hayo

[Blue F. (blueflash)]

Da ich momentan nicht viel zum Programmieren komme, hier der aktuelle 
Stand in Sachen ADC-Treiber. Ich habe den ADC-Treiber neu handoptimiert 
in Assembler geschrieben. Er läuft jetzt stabil und schnell. Im 
Gegensatz zum ultraschnellen Quick and Dirty Treiber hat der Assembler 
Treiber Overflow Protection und Limiter für den oberen und unteren 
Grenzwert.

Neu ist ebenfalls, dass ich das Invertieren und Averaging wieder in den 
ADC-Treiber zurückverlegt habe allerdings optimiert in Assembler und 
dadurch richtig schnell. Der Averaging Mode wurde auch noch von der 
Wirkung her verbessert.

Der Standard C-Code Treiber und der Quick and Dirty Treiber stehen 
momentan nicht zur Verfügung, da beide den Averaging Mode noch nicht 
unterstützen - kommt aber noch. Ansonsten habe ich noch einige 
Kleinigkeiten aus dem OSOZ-Projekt übernommen.

Gruß Hayo

p.s. Die Assembler Treiberroutinen werde ich bei nächster Gelegenheit 
bei OSOZ einpflegen, bin nur momentan noch nicht dazu gekommen.

Download auch hier:

http://sourceforge.net/projects/welecw2000a/files/Open%20Source%20Firmware/

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

Hayo W. schrieb:
> Jörg hat glaube ich für das OSOZ-Projekt einige kleine Testroutinen
> geschrieben die man dafür mißbrauchen könnte. Am besten Jörg direkt
> drauf ansprechen da er hier den besseren Überblick hat.

Einen Speichertest habe ich nicht im Programm.
"Man" könnte einen schreiben, aber soo einfach ist das nicht. Das 
Programm steht ja normalerweise auch im RAM, sowie der Stack und die 
Interruptvektoren. Entweder man testet nur einen freien Bereich, oder 
das Programm muß sich umlagern (Stack?) oder es ist ein kleines 
Assemblerprogramm ohne Stack und Variablen, was rein im Flash läuft.

Ich glaube ehrlich gesagt nicht, daß das RAM das Problem ist. So aus dem 
Bauch raus, weil ich bisher viel zu wenig Ramdefekte gesehen habe.

Hayo W. schrieb:
> hier der aktuelle
> Stand in Sachen ADC-Treiber. Ich habe den ADC-Treiber neu handoptimiert
> in Assembler geschrieben. Er läuft jetzt stabil und schnell.

Könnte noch schneller laufen. ;-)
Ich habe bisher nur flüchtig draufgeschaut, mir fiel auf daß du die 
Delay Slots nicht nutzt, da steht immer(?) ein NOP drin.
Noch ein Trick: wenn's geht (meist geht's leider nicht) zwischen einen 
Ladebefehl und die Verwendung des geladenen Registers einen unabhängigen 
Befehl packen. Dann kann die CPU den während des Ladens ausführen, 
ansonsten gibt es hier einen Pipeline Stall. Das Alignment des Codes im 
Speicher kann auch eine Rolle spielen. Es passen ja immer 2 Befehle in 
ein 32-Bit Speicherwort, die CPU muß also nur für jeden 2. einen 
Buszyklus machen.

Dann sind mir die vielen Sign Extends aufgefallen. Die ADCs können wir 
mit einer SPI-Leitung umschalten, ob sie ihr Ergebnis als signed oder 
unsigned ausgeben sollen. Vielleicht ist die andere Betriebsart für die 
Numerik besser? Vielleicht verwirren wir dann das FPGA aber vollends, 
weil es auch bereits damit rumrechnet und den Triggerpegel überwacht?

Jörg

[Luc (Gast)]

Guten Abend Hayo und alle.

@Hayo
Hayo, danke für die neue Version 1.2.BF.5.7!!!!!!!
Now I am in a bit of a hurry, so quickly only a pair of things:
1)I upgraded both my W2022A and W2012A, the first one works great while 
the second show abnormal noise on CH1 expecially on 5uS and 50nS range 
of the Time Base.
2)Performing Calibrate Offset procedures on W2012A, which shows noisy on 
the CH1, fails.
Instead all it is OK with the W2022A which works like a charm.
I tried both STANDARD and ASSEMBLER of the ADC configuration but nothing 
changes.
(W2012A number 09850712C9, hardware 8C7.0B purchased on December 20, 
2009 and W2022A number 78002031D0, hardware 8C7.0C purchased on January 
15, 2010)
As always this report is only for knowledge and no as criticism

Going to ahead, quick glance to the new AVERAGE implementation, seems to 
me it works really well, as always really impressive, I have no words!: 
thank You Hayo.
The rest will follow, see you later. ;-)

Vielen Dank!

Mit freundlichen Grüßen,

Luc

[Blue F. (blueflash)]

So, grad erst wieder zuhause aufgeschlagen. Bevor ich abtauche und die 
Matratze abhorche noch kurze Antworten.


@Jörg

Ich hatte schon vermutet, dass da noch nicht das Ende der Fahnenstange 
erreicht ist. Die Delay Slots hatte ich bislang unbenutzt gelassen da 
mir da keine gute Idee kam wie ich das nutzen könnte. Das 
Optimierungspotential ist wohl nur noch minimal denke ich. Die übelsten 
Designfehler unseres Welec-Programmierers habe ich jedenfalls beseitigt 
bzw. beim Neudesign weiträumig umfahren :-).
Vielleicht läßt sich da ja noch mit einigen Tricks was rausquetschen. 
Quetschwillige sind herzlich eimgeladen...  ;-)

Ich habe der Übersichtlichkeits halber und weil mehr als 6 
Übergabeparameter etwas aufwändig sind, die Funktionen in kleine 
Einzelfunktionen aufgespalten. Soll ich das so mal bei Gelegenheit bei 
OSOZ einpflegen? Wenn Du da Optimierungsideen hast kannst Du das ja dann 
noch nachtunen bzw. rausschmeißen was nicht so optimal ist.


@Luc

Hi there, thanks again for reporting. I can't imagine why there is the 
noise on Your Device. On my DSOs I had no problems. Nevertheless I will 
check it and try to solve it.

Regards/Grüße
Hayo

[Luc (Gast)]

Guten Abend Hayo und alle.

Hayo W. schrieb:
>Hi there, thanks again for reporting. I can't imagine why there is the
>noise on Your Device.

Hayo, vielen Dank für Ihr Zinsen.
Perhaps I have a suspicion about this strange behaviour.
I upgraded the W2012A and since the beginning the traces on the screen 
were abnormally noisy.
Then I performed Default Setup and only the CH1 was noisy, CH2 was as 
usual.
Immediately after when I was in the Utility menu I seen all related 
records setted to default, I had to reset them as well as display 
setting (background colours, graticule and so).
Playing a bit around I noticed that although the W2012A was correctly 
warmed up, Calibrate Offset procedures fail when performed on it.
Accidentally I went in the SAVE/RECALL menu and I recalled some memories 
(strangely the memories 1,2 and 3 were not empty, seems to me they still 
contain the waveforms I had memorized before the upgrade, though I had 
filled more than three memory), at this point CH1 took the usual form 
and the abnormal noise is gone!
So I tried to perform Default Setup noting that some parameters (as CH 
delay setting for example) were changed it taking the values 
​​previously stored in the DSO.
I performed the Default Setup in order to follow it with Calibrate 
Offset and CH1 turn noisy again!
Perhaps a memory conflict issue?
It is from a little time that I wanted to ask a question because often 
when I run the Default Setup then the entries in the Hardware menu do 
not return to default setting but remain as setted before, so: is this 
behavior correct?
And performing Default Setup then are the memories in SAVE/RECALL 
erased?
As I already wrote time ago I happen to have problems recalling the 
waveforms stored in the DSO but not for hardware problem: happens the 
same way on the W2022A and W2012A and returning to a old firmware 
release the problem disappears, so for me it is not an hardware problem 
(defective RAM for example).

Hayo W. schrieb:
>On my DSOs I had no problems.
Of course, also my W2022A do not shows any problem: Calibrate Offset 
works and no abnormal noise on any channel.
Maybe it is really a memory conflict issue, this explain why it is 
random depending it from the memory usage.

Hayo W. schrieb:
>Nevertheless I will check it and try to solve it.

Thank You very much Hayo!
I know this is a hard job due to the randomly nature of the problem.
For now I fix downgrading the DSO to an old firmware release, so no 
problem, however even with older firmware DSO works much better than 
with the original Welec/Wittig firmware!
With a similar philosophy I have overcome the spikes simply setting 
Pretrigger Left Edge: they are still there but are hidden. ;-)

Vielen Dank!

Mit freundlichen Grüßen,

Luc

[Blue F. (blueflash)]

Hi Luc,

please try this special version I made for You. It would be interesting 
to see if the noise disappears.

Please make a default setup, change to the assembler driver and 
calibrate the device.

I'm tight awaiting Your report

Hayo

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

Hayo W. schrieb:
> Soll ich das so mal bei Gelegenheit bei
> OSOZ einpflegen? Wenn Du da Optimierungsideen hast kannst Du das ja dann
> noch nachtunen bzw. rausschmeißen was nicht so optimal ist.

Klar, gern!
Osoz braucht von Grund auf einen Treiber für Capture+Trigger, da muß 
also auch noch die API definiert werden.

Was ganz anderes:
Es gab hier so Diskussionen um FPGA-Uploads. Haben wir das Wissen und 
die Mittel beisammen, um zwischen FPGA-Versionen hin- und herzuflashen? 
Wenn ja, kann mir mal jemand erklären wie? Wie fertigt man einen Dump 
vom Bitstream-Flash an?

Ich habe Hardware-Version "8C7.0E". Laut Sourcecode ist vor dem Punkt 
die FPGA-Version, dahinter zwei aus dem Flash gelesene Ziffern des 
Produktionsloses. Laut Wiki-Tabelle gibt es nur 2 FPGA-Versionen, 
"meine" 8C7 und die 1C9. Welche Hardware ist denn die neueste/bessere?
Ich würde z.B. gern mal ausprobieren, wie sich die ominösen 
User-Instructions mit anderer Hardware verhalten, ob da vielleicht schon 
mehr drin ist.

Wer kann einen Dump von der 1C9 bereitstellen?

Jörg

[Guido (Gast)]

Hallo Jörg,

du musst den FPGA nicht flashen, sondern kannst seine Konfiguration
direkt in ihn laden. Nach dem Ausschalten ist dann alles wie vorher.
Zunächst muss mittels USB der EasyUSB mit slogs Firmware zum Altera-
Developement-Board umgewandelt werden. Das geht temporär (RAM) oder
endgültig  ins EEPROM.

Die FPGA-Konfiguration kann wohl nur mit der Quartus-Software von
Altera aufgespielt werden. Ich habe es mal mit urjtag probiert, bin
da aber nicht sehr weit gekommen (FPGA wurde erkannt).

Gruß, Guido

[Andreas W. (andiiiy)]

@Jörg,

da ich nun so hilflos war, hab ich mich auch mit dem EPCS16 beschäftigen 
müssen und wollen. Tatkräftig stand mir Michael (mike0815) zur 
Verfügung.


1. Quartus installieren

2. Wenn der Treiber installiert ist ...
http://sourceforge.net/apps/trac/welecw2000a/wiki/USBBlaster

Schau zusätzlich mal in den Eintrag vom Michael bezüglich vollständigen 
Treiber...
Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil5)"

3. Die Brücke geschlossen ist ... (Derzeit kann ich nur für die W2024A 
User sprechen) ... siehe Bild auf dem Link vorher im Kapitel "Notes for 
Welec 20X4 users"

4. "Auto Detect" im Quartus drücken ... sollte einen EP2C35 anzeigen!

5. Der folgenden Anleitung folgen ...
http://sourceforge.net/apps/trac/welecw2000a/wiki/FPGAConfigFlash

siehe angehangenes Bild ...


FERTIG

Ich habe mal meinen Dump angehangen. Was mich wundert ist die Checksumme 
die kein anderes Gerät unter ...
http://sourceforge.net/apps/trac/welecw2000a/wiki/usersinstrument
... aufzeigt. Diese lautet: 071612A5

Ob dieser Dump funktioniert kann ich leider nicht sagen, da mein Gerät 
mich nicht ansehen will ;-)

Welches Gerät hast Du? Kannst Du Deinen Dump danach auch mal zur 
Verfügung stellen?

@All

Hat jemand mit einem 4-kanaligen Gerät auch mal mit dem Quartus versucht 
einen Dump zu erstellen??? Seht Ihr 2 EP2C35??? Es sind ja auch 2 Stück 
bei dem W2024A verbaut ...

Ich wäre über einen alternativen Dump für ein W2024A auch dankbar ...


Gruß Andi

[Jürgen (Gast)]

Hayo W. schrieb:
> Hi Luc,
>
> please try this special version I made for You. It would be interesting
> to see if the noise disappears.

Hi Hayo, Hi Luc,

I had the same problem and this 5.7_Luc version is much more better with 
respect to the noise.

Thanks,
Jürgen

[Thomas (kosmos)]

ich habe nochmal eine Frage zu einem anderem Thema.Die Übertragung für 
die Firmware geht ja jetzt richtig flott vonstatten, die Übertragung 
eines Screenshots ist aber noch gemächlich, läßt sich hier och etwas 
optimieren?

Was ist der Unterscheid zw. BMP und PPM da sich von der Dateigröße 
nichts ändert.

[Jürgen (Gast)]

Ach ja, der Hayo ist daran schuld! ;-)

Da hat er sich doch einfach mit einem #define TRIG_ALT zwischen die 
anderen, älteren Definitionen gedrängt und vergessen diese verschobenen 
Definitionen im Code entsprechend zu korrigieren. Und siehe da, schon 
geht die Triggerverstellung für den externen Trigger nicht mehr (z.B. 
siehe On-Trigger_Level()).

Gruß Jürgen

[Blue F. (blueflash)]

@Andi

Mein Kumpel hat unter anderem ein 2024A (wenn ich das richtig in 
Erinnerung habe). Notfalls könnte ich da mal anfragen, kann aber etwas 
dauern. Ich selbst habe ein 2014A. Die FPGAs und die Peripherie sollten 
eigentlich identisch sein, der einzige Unterschied scheint da die 
selektion der Analogbauteile zu sein die in einer etwas beseren 
Bandbreite resultiert. Meine Versuche mit Quartus verliefen aber aus 
irgendeinem Grund erfolglos. Im nachherein bin ich mir nicht ganz sicher 
mit welchem Gerät ich das versucht hatte. Möglicherweise hatte ich das 
2014A verwendet und da aber keine Brücke eingesetzt - was dann den 
Mißerfolg wohl erklären würde.


@Jürgen (+ Luc)

> I had the same problem and this 5.7_Luc version is much more better
So this confirmed my suspicion what the problem could be. I changed the 
ADC-Offset format from unsigned to signed to be able to shift the offset 
compensation into negative range. But this seems not to work in all 
cases (I think depending on the offset values). So I will return to the 
old unsigned format in the next version (as in this "Luc-Version"). All 
with the same problem I would recommend to use this version until I can 
provide a corrected Version.

Hayo

[Blue F. (blueflash)]

Jürgen schrieb:
> Ach ja, der Hayo ist daran schuld!

Oh, wo hab ich da was verbockt? Das Define ist relativ neu, stimmt. Wo 
hatte ich da vergessen das zu ergänzen?

Gruß Hayo

[Andreas W. (andiiiy)]

@Hayo


> Möglicherweise hatte ich das
> 2014A verwendet und da aber keine Brücke eingesetzt - was dann den
> Mißerfolg wohl erklären würde.

ja ohne der Brücke konnte ich keinen FPGA entdecken (per Quartus). Diese 
war bei mir ein muss ...

Gruß

[Blue F. (blueflash)]

@Jürgen

Ok hab's schon, wie konnte ich das übersehen ;-) - danke für den 
Hinweis. Hab zwar eigentlich keine Zeit, aber dann hau ich gleich noch 
eine Korrektur raus, kann man ja so nicht lassen...


@Andi

Dann müßte das mit dem 2022A aber ja ohne Brücke funktionieren. Muß wohl 
noch mal ran da.

Hayo

[Blue F. (blueflash)]

Thomas O. schrieb:
> Die Übertragung für
> die Firmware geht ja jetzt richtig flott vonstatten, die Übertragung
> eines Screenshots ist aber noch gemächlich, läßt sich hier och etwas
> optimieren?

evtl. ja, allerdings sind die Anforderungen bei der Bildkomprimierrung 
anders als bei normalen Daten. Der verwendete Lauflängenalgorithmus ist 
auch nicht unbedingt das Ende der Fahnenstange.


> Was ist der Unterscheid zw. BMP und PPM da sich von der Dateigröße
> nichts ändert.

Die Reihenfolge in der die Werte in der Datei abgelegt werden ist bei 
den beidemn Formaten genau entgegengesetzt. Ansonsten sind sie 
identisch. Findet man per Googlesuche im Wiki.

Hayo

[Thomas (kosmos)]

ok die beiden Formate sind anscheinend am einfachsten zu programmieren. 
Oder haben wir hier jemanden der sich mit soetwas auskennt und für PNG 
etwas schreiben kann, bei der geringen Farbpalette wäre das sehr 
platzsparend und würde das Übertragen aufgrund der geringen Datenmenge 
extrem verkürzen.

[Blue F. (blueflash)]

Ich muß zugeben, dass ich mich da erst einarbeiten müßte. Wenn sich da 
jemand auskennt ist er herzlich eingeladen sich einzubringen.

Gruß Hayo

[Blue F. (blueflash)]

Ok, hier die Korrektur.

Dran denken, neue Kalibrierung durchführen!

Gruß Hayo

[Jürgen (Gast)]

Hayo W. schrieb:
> Ok, hier die Korrektur.

Danke, aber ich hoffe Du hattest wirklich keine Zeit und hast nicht 
inzwischen weitere Änderungen an den Dateien eingebracht :-)
Ich habe mal alle TRIG-#defines von 137 bis 143 eingepflegt und hoffe, 
ich habe alle "erwischt".
Hier die Dateien die ich geändert habe. Kannst sie ja nochmal gegen 
5.7C2 vergleichen, um zu sehen was sich geändert hat.

Wie kann ich vom S-Record "tomcat.flash" die "tomcat.ucl" erzeugen?

Ich will nach der ext.Trig Hardware-Mod. nach Jörg an meinen Oszis noch 
mal die Pegel nachmessen und denke, daß da noch beim Umschalten zum 
Linetrigger ein bestimmter PWM-Wert gesetzt werden muss.

Gruß Jürgen

[Jürgen (Gast)]

Andreas W. schrieb:
> Ich wäre über einen alternativen Dump für ein W2024A auch dankbar ...

Bitteschön! Ich hoffe, auch dieses Format lässt sich programmieren.. Ist 
schon zu lange her. Jedenfalls habe ich es so abgezogen.

Gruß Jürgen

[Luc (Gast)]

Guten Abend Hayo, Jürgen an und alle Unterstützer des Projekts Welec!

Hayo W. schrieb:
>please try this special version I made for You. It would be interesting
>to see if the noise disappears.
Hayo Bitte entschuldigen Sie mich für meine Verspätung.
Oh, I really have no words, thank You very much for the aid: klasse!
Und dann, was eine große Ehre für mich, meinen Nick-Namen auf dem 
Startbildschirm haben: Hayo du bist wirklich klasse!!!!!!!
Es ist eine Ehre, die ich nicht verdient, jedoch dank Hayo!

Hayo W. schrieb:
>Please make a default setup, change to the assembler driver and
>calibrate the device.
Hayo as usual You are right!
I followed your instructions and now the abnormal noise is gone on all 
the Time Base's range, I think even that noise in general has fallen, 
but I might confuse me although I do not think so.
However everything is OK now, repeat I am speechless, I have no words: 
RESPECT and KLASSE!!!!!!!
Only one question Hayo, You wrote "change to the assembler driver" but 
only that entry is present in the menu, the other two are deactivated 
(grey): this is not a real problem but rather a my curiosity

Hayo W. schrieb:
>I'm tight awaiting Your report
Hayo thanks You very much for the free time You provided generously to 
me (us) and for this new great firmware's improvement!!!
Very impressive and fast work, no words, Hayo You are the best one, the 
big one, the number one!: KLASSE!!!!!!!
Hayo as usual You are very kind, many thanks for your help.
I really much regret for the workload that You had to play to fix my 
problem and I am very sorry for the time that You lost to fulfill it, 
thank You very, very much Hayo!: KLASSE.

Jürgen schrieb:
>I had the same problem and this 5.7_Luc version is much more better with
>respect to the noise.
Guten Abend Jürgen und danke für eure Hilfe.
You have been faster than me but I also confirm that with the new 
1.2.BF.5.7_Luc firmware the problems about abnormal noise disappear.
So thank You Hayo!
Ah, hätte ich fast vergessen, Und natürlich vielen Dank Jurgen für Ihre 
Anregung in Bezug auf den TRIGGER!

Hayo W. schrieb:
>[1.2.BF.5.7C2]
>Ok, hier die Korrektur.
>Dran denken, neue Kalibrierung durchführen!
Oh boys, Hayo You are too fast then I'll try to be I too, so I 
immediately run to try this new firmware version.
Thank You again Hayo: RESPECT and KLASSE!!!!!!!
Keep in touch! ;-)

Jürgen schrieb:
>[geaenderte_src_5.7c2] and [my_w2024A]
>Hier die Dateien die ich geändert habe. Kannst sie ja nochmal gegen
>5.7C2 vergleichen, um zu sehen was sich geändert hat.
Jürgen, Danke nochmal für die praktische Hilfe: KLASSE!!!!!!!

Vielen Dank an alle Unterstützer des Projekts Welec!

Mit freundlichen Grüßen,

Luc

[Luc (Gast)]

Guten Abend Hayo an und alle Unterstützer des Projekts Welec!

Hayo W. schrieb:
>[1.2.BF.5.7C2]
>Ok, hier die Korrektur.
>Dran denken, neue Kalibrierung durchführen!
Schnell.
I just tried the new 1.2.BF.5.7C2 version and seems to me as regards the 
noise it works even better than the previous 1.2.BF.5.7_Luc version!
Now for me it is perfect and my W2012A works like a charm, as usual I 
have no words: KLASSE!!!!!!!
I play it a bit 'and then report back on it.
For now, once again many thanks Hayo!
Keep in touch!

Vielen Dank an alle Unterstützer des Projekts Welec!

Mit freundlichen Grüßen,

Luc

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

Oh, viel los, ich schreibe mal eine Sammelantwort:

Andreas W. schrieb:
> Hat jemand mit einem 4-kanaligen Gerät auch mal mit dem Quartus versucht
> einen Dump zu erstellen??? Seht Ihr 2 EP2C35??? Es sind ja auch 2 Stück
> bei dem W2024A verbaut ...
>
> Ich wäre über einen alternativen Dump für ein W2024A auch dankbar ...

Ich habe ein W2024, ohne 'A'. Ist das auch interessant? Der Unterschied 
ist mir zugegeben nicht geläufig.
Dank für den Bitstream. Ich versuche mal, deiner Beschreibung zu folgen. 
Hinter so harmlosen Halbsätzen wie "Quartus installieren" verbirgt sich 
bestimmt eine mehrstündige Aktion?


Thomas O. schrieb:
> ich habe nochmal eine Frage zu einem anderem Thema.Die Übertragung für
> die Firmware geht ja jetzt richtig flott vonstatten, die Übertragung
> eines Screenshots ist aber noch gemächlich, läßt sich hier och etwas
> optimieren?

Ohne draufgeschaut zu haben wie's jetzt gemacht wird kann ich noch 
nichts zu sagen, aber gefühlsmäßig vermutlich schon.
Bildkompression ist (u.A.) mein Beruf, zu gegebener Zeit kann ich da mal 
ran.
OK, nun habe ich draufgeschaut. Der Kompressor ist extrem primitiv, kann 
nur direkte Bytewiederholungen, kodiert sie recht ineffizient. Sowas wie 
LZO dürfte da mehr bringen.

(Lauflängen)kodierung ist das eine, Prädiktion das andere. Wir könnten 
einen der Fax-Algorithmen ausprobieren. Im einfachen Falle jede Zeile 
mit der drüberliegenden verXodern. Das dürfte viel mehr Nullbytes 
erzeugen.


Jürgen schrieb:
> Ach ja, der Hayo ist daran schuld! ;-)
>
> Da hat er sich doch einfach mit einem #define TRIG_ALT zwischen die
> anderen, älteren Definitionen gedrängt und vergessen diese verschobenen
> Definitionen im Code entsprechend zu korrigieren.

Der Jürgen erstaunt mich mitunter. Da haut der solche Dinger raus und 
kennt sich auf einmal mindestens so gut wie Hayo in der BF-Firmware aus. 
Jürgen, magst du vielleicht auch mal Osoz angucken?  ;-)


Jürgen schrieb:
> Wie kann ich vom S-Record "tomcat.flash" die "tomcat.ucl" erzeugen?

Das macht "heutzutage" der Build-Flow, das Makefile kümmert sich drum. 
Nachträglich zu Fuß ist das ziemlich blöd. Aber weil du gefragt hast:
srec_cat TomCat.flash -Output bloat.bin -Binary
dd if=bloat.bin of=loader.bin bs=1 skip=256K count=256
dd if=bloat.bin of=app.bin bs=8M skip=1
cat loader.bin app.bin > flash.bin
uclpack --best --2e -b8000000 flash.bin TomCat_flash.ucl

Die Tools "srec_cat" und "uclpack" brauchst du. Ersteres kommt aus dem 
Paket "srecord", letzteres von Oberhumer, hatte ich hier oder bei Osoz 
mal gepostet.


Jörg

[Thomas (kosmos)]

Jörg H. Super da sitzt ja der richtige Man an Board. .PNG wäre eine 
Überlegung wert ist Lizenzfrei und vielleicht gibts ja nen fertigen 
Quelltext zum implementieren. Für unseren Anwendungsfall ziehe ich das 
dem verlustbehaftetem .JPG absolut vor. Man beachte die Dateigröße.

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

Thomas O. schrieb:
> .PNG wäre eine
> Überlegung wert ist Lizenzfrei und vielleicht gibts ja nen fertigen
> Quelltext zum implementieren. Für unseren Anwendungsfall ziehe ich das
> dem verlustbehaftetem .JPG absolut vor. Man beachte die Dateigröße.

Das ist Sache des PC-Programms. Diese komplexen Formate werden 
(hoffentlich) nie auf dem Scope erzeugt. Das Scope soll nur seine 
Bitplanes mit effizienter aber trotzdem schneller Kompression über die 
Leitung pusten. Auf dem PC werden dann die Bitplanes zusammengesetzt, 
die auf dem Scope fest eingestellten Farben und Z-Order berücksichtigt, 
und dann das zu speichernde Bildformat erzeugt. Für letzteres gibt es 
Bibliotheken.

Jörg

[Thomas (kosmos)]

und wie schätz du den möglichen Kompressionsfaktor ein, also im 
Vergleich zu den jetzigen 900 kBytes der BMP/PPM Bilder

[Jürgen (Gast)]

Jörg H. schrieb:
> Der Jürgen erstaunt mich mitunter. Da haut der solche Dinger raus und
> kennt sich auf einmal mindestens so gut wie Hayo in der BF-Firmware aus.
> Jürgen, magst du vielleicht auch mal Osoz angucken?  ;-)

Danke für die Blumen! Von dem "mindestens so gut auskennen" bin ich aber 
trotzdem weit entfernt! Aber ich habe mich erstens schon mal in die 
Geschichte externer Trigger und Pulse Width Trigger eingearbeitet und 
zweitens war die Änderung nun nicht so doll: Die Funktion Search in 
files im Editor ist Dein Freund! :-)

Die Komprimierung schaue ich mir mal an, da seeehr hilfreich beim 
Testen. Ich bin aber meist unter Windof unterwegs...

Gruß,
Jürgen

[Blue F. (blueflash)]

Thomas, Du kriegst da was durcheinander. Die BMP/PPM Bilder werden so 
nicht über die Schnittstelle übertragen. Wie Jörg schon schrieb sind das 
nur die komprimierten Rohdaten, die auf dem PC wieder dekomprimiert 
werden und dann erst in das entsprechende Bildformat konvertiert werden. 
Das kann auch PNG oder JPG sein. Auf dem Oszi wird für die Kompression 
ein eigener Algorithmus verwendet.

Den Kompressionsfaktor zeigt das Programm übrigens beim Erzeugen der 
Screenshots an (liegt so rund bei 20 - 25%).

Gruß Hayo

[Thomas (kosmos)]

Achso ich dachte das BMPs werden unkomprimiert als Rohdaten zum PC 
geschickt. Ok so lange dauert die Übertragung nun auch wieder nicht aber 
eine Konvertierung ins platzsparende PNG Format auf PC Seite wäre 
interessant. Ich schaue mal ob ich einen Kommandozeilen-Konverter finde 
den ich in meine Batch Datei einbinden kann so das ich gleich PNG 
erhalte und die BMP danach gleich entsorge.

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

Jürgen schrieb:
> Die Komprimierung schaue ich mir mal an, da seeehr hilfreich beim
> Testen. Ich bin aber meist unter Windof unterwegs...

Gibt es genauso auch für Cygwin, siehe Anhang. Ich habe die Tools unter 
usr/local/bin.


Andreas W. schrieb:
> 1. Quartus installieren
>
> 2. Wenn der Treiber installiert ist ...
> http://sourceforge.net/apps/trac/welecw2000a/wiki/USBBlaster
>
> Schau zusätzlich mal in den Eintrag vom Michael bezüglich vollständigen
> Treiber...
> Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil5)"

Quartus habe ich installiert, aber mit dem USB-Teil hapert es noch. Geht 
das unter Windows 7 überhaupt? Da habe ich den ganzen Morgen dran 
rumgewürgt, ohne Erfolg. Erstmal ist das Scope ein HID-Device und mit 
dem Standardtreiber von Microsoft so glücklich, daß er keine neuen 
Treiber haben will, unsere .inf lockt ihn nicht. ("...befindet sich 
bereits auf dem neuesten Stand...")
Nach Web-Recherche habe ich das Gerät deinstalliert, per Policy in den 
Systemrichtlinien die Automatik verboten und es nochmal versucht. Dann 
fängt er zwar an zu installieren, aber bricht ab, eine Datei fehlt, 
Windows sagt aber nicht welche, grr.
Mit dem SysInternals ProcessMonitor habe ich hinter die Kulissen geguckt 
und die Datei CyUsb.spt auch nach Drivers kopiert, wo sie anscheinend 
gesucht wurde.
Zwischenzeitlich sah ich ein Gerät "Nios II Evaluation Board", aber mit 
gelbem Ausrufezeichen. Es hat die PID 0x6003, die in der .inf Datei 
auskommentiert ist ("W2000 from slog")? Die habe ich probehalber wieder 
einkommentiert, dann ging das USB-Gerät in eine Art 
Endlos-Disconnect-Reconnect, machte alle 2 Sekunden Bing und die 
Geräteansicht aktualisierte sich, ich konnte da nichts mehr anklicken. 
Den Spuk wurde ich durch Löschen der Treiberdateien wieder los.
Jetzt ist alles wieder wie am Anfang, mit HID-Treiber...

[Michael D. (mike0815)]

Hallo Jörg,

hast du die Treiber von dem Link hier benutzt?
http://www.mikrocontroller.net/topic/goto_post/2389642
Die im SF, vergesse erst mal...

Wenn du genau nach meiner Beschreibung gehst, muß das hinhauen!
Also erst die angegebenen Files in die richtigen Verzeichnisse kopieren, 
dann den USB-Blaster gegen das HID-Interface ersetzen. Das zickt unter 
XP auch ein wenig, haut aber hin.
Wenn der Blaster erkannt wurde, bzw. das DSO eingeschaltet wird, dann 
darf sich das DSO maximal 2x an u. wieder anmelden(so ist das bei 
mir)also 2x Pingen, bei dir loopt das?

> Zwischenzeitlich sah ich ein Gerät "Nios II Evaluation Board"
Das ist absolut korrekt!
Vergleiche doch mal die Treiberdetails im Anhang.

Kann natürlich auch sein, das es an Windoof7 liegt, hast du die 32 oder 
64bit Version?

Gruß Michael

EDIT:
@Hayo
Der ADC-Treiber "Standart" ist ausgegraut, Absicht?

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

Michael D. schrieb:
> hast du die Treiber von dem Link hier benutzt?
> http://www.mikrocontroller.net/topic/goto_post/2389642
Ja, habe ich.

> Die im SF, vergesse erst mal...
Ist aber das gleiche drin.

> Wenn der Blaster erkannt wurde, bzw. das DSO eingeschaltet wird, dann
> darf sich das DSO maximal 2x an u. wieder anmelden(so ist das bei
> mir)also 2x Pingen, bei dir loopt das?
Ja. Ich kann nachher mal meinen Installationsverlauf genauer 
dokumentieren, das war jetzt aus der Erinnerung.

> Kann natürlich auch sein, das es an Windoof7 liegt, hast du die 32 oder
> 64bit Version?
32 Bit.

Du hast XP?

Ich habe quch noch ein XP-Notebook, mit dem ich es testweise probieren 
könnte. Das wäre aber keine endgültige Lösung.

Jörg

[Michael D. (mike0815)]

Jörg H. schrieb:

>> Die im SF, vergesse erst mal...
> Ist aber das gleiche drin.
Irgendwas war da nicht vollständig oder wie auch immer, ist ja wurscht.
>
> Ja. Ich kann nachher mal meinen Installationsverlauf genauer
> dokumentieren, das war jetzt aus der Erinnerung.
dann kann man das ja mal vergleichen. Der Andreas hat die gleiche 
Winkonf. wie ich...
>
>> Kann natürlich auch sein, das es an Windoof7 liegt, hast du die 32 oder
>> 64bit Version?
> 32 Bit.
>
> Du hast XP?
Jo, XP-Sp3 und auf dem aktuellsten Stand
>
> Ich habe quch noch ein XP-Notebook, mit dem ich es testweise probieren
> könnte. Das wäre aber keine endgültige Lösung.
Auf meinem Notebook (Packard Bell) läuft das auch mit XP ohne Probleme.
Den Treiber kann man zwar rückgängig machen, weil dann die mitgelieferte 
Soft von Welec nicht funktioniert, Diese ist aber eh für die Füsse...

> Jörg
Gruß Michael

[Blue F. (blueflash)]

Michael D. schrieb:
> Der ADC-Treiber "Standart" ist ausgegraut, Absicht?

Ja hatte ich auch schon erklärt. Hast Du wohl übersehen. Also nochmal 
ausführlich.

Die Averagefunktion war vorher als separate Routine ausgeführt und daher 
unabhängig vom ADC-Treiber, ebenso die Invert-Funktion. Um 
Geschwindigkeit herauszukitzeln mußte ich die Speicherzugriffe 
minimieren. Das ging aber nur durch Integration in den ADC-Treiber.

Daher habe ich die externe Routine rausgeschmissen. Der Assemblertreiber 
hat die neuen Funktionen schon an Bord, die anderen Beiden nicht. Daher 
habe ich die erstmal deaktiviert.

Die Nachrüstung soll aber noch erfolgen. Weiterhin will ich auch 
versuchen den C-Code Treiber so weit zu optimieren dass er an die 
Performance des Assemblertreibers heran kommt. Im Zweifelsfalle ist das 
C-Coding wartungsfreundlicher und besser lesbar.

Gruß Hayo

EDIT: in einzelnen Fällen kam es in der 5.6 vor, dass der 
Standardtreiber noch auswählbar war weil die Initialisierung nicht ganz 
korrekt war. Das sollte aber in der aktuellen Version abgestellt sein

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

@Michael D. et al:

Immer noch kein Erfolg mit dem USB-Gebläse. Auch unter XP drängelt sich 
der eingebaute HID-Treiber vor, von dem anderen will er dann nix mehr 
wissen. Im Unterschied zu Win7 weiß ich noch nicht, wie ich das unter XP 
verhindere. Ein Kollege meinte was von Shift/Ctrl festhalten beim 
reinstöpseln, das muß ich mal versuchen.

Unabhängig davon habe ich mir jetzt in der Firma was "originales" zu dem 
Thema suchen lassen. Fand sich in einer hinteren Schrankecke...
Nun habe ich einen original Byteblaster mit Parallelport, sowie 
anscheinend 2 Clone mit USB-Anschluß. Beide melden sich mit VID:PID 
09fb:6001. Kommen jeweils 10polige Kabel raus. Auf dem Welec-Board sind 
ja gleich 2 solche Anschlüsse, ist bekannt welcher wofür ist? Muß ich 
irgendwas wieder auslöten, um den onboard-Cypress abzutrennen?

Jörg

[Michael H. (stronzo83)]

Hi Jörg,
ich habe diese Woche auch schon mehrere Stunden mit meinem W2024A 
herumgekämpft. Windows 7 beharrt nach wie vor auf dem verdammten HID 
Device, bisher haben alle Tricks nicht weitergeholfen. Achja die 
Lötbrücke ist natürlich gesetzt. Mal sehen ob ich am Wochenende dazu 
komme, da weiterzumachen... wenn ich es hinbekomme poste ich es 
natürlich sofort.

Gruß
Michael

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

Nur ganz kurz, zu angenehmerer Zeit mehr:

Ich habe das mit dem USB-Treiber jetzt hinbekommen, Quartus spricht mit 
mir. Der Durchbruch war, die HID-Treiber erst zu löschen, automatische 
Treiberinstallation zu verbieten (mehr dazu später), nicht am 
.inf-File herumzufummeln, es darf sich nicht für PID 6003 zuständig 
fühlen, nach neuem Auftauchen mit PID 6003 dann auf die Altera-Treiber 
im Qartus-Verzeichnis lenken.

Ich sehe nur ein FPGA, scheint aber immer so zu sein?
Das (bzw. das Config-Flash) habe ich nun mit dem Inhalt von Andreas W. 
(Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil5)") beschrieben.
Nach einem Reboot meldet es sich nun mit Hardwareversion 1C9, und 
funktioniert augenscheinlich soweit.

Später werde ich dann mal die User-Instructions neu testen, ob sich da 
was verändert hat.

Jörg

[Rainer W. (rawi)]

Thomas O. schrieb:
> Ich schaue mal ob ich einen Kommandozeilen-Konverter finde
> den ich in meine Batch Datei einbinden kann so das ich gleich PNG
> erhalte und die BMP danach gleich entsorge.

Für die Konvertierung der PPMs in PNGs tut bei mir das Tool pnmtopng 
unter Windows seit Urzeiten seinen Dienst. Eingebaut in eine Batch-Datei 
läßt es sich per Drag und Drop benutzen
http://netpbm.sourceforge.net/doc/pnmtopng.html

w2000a-screenshot.exe -a -f <folder>

liefert die Bilder in einem festen Ordner ab
und eine Batchdatei mit

pnmtopng %1 >%1.png

übernimmt die Konvertierung.

Gruß
Rainer

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

Hier ein paar "Komponenten", wie man die automatische HID-Installation 
unter Windows 7 unterbindet:
http://www.windows-7-forum.net/windows-7-treiber-hardware/3046-automatische-geraete-treiberinstallation-deaktivieren.html#post20932
Das habe ich temporär aktiviert und nach dem Anstöpseln wieder 
zurückgenommen, dann blieb das Gerät "unbetreibert" und ließ sich von 
Hand versorgen. Zuvor hatte ich die HID-Geräte deinstalliert. 
"gpedit.msc" existiert bei den Home-Varianten von Win7 glaube ich nicht. 
Vielleicht läßt sich ähnliches mit irgendwelchen Registry-Keys 
hinbekommen? Das hier ist jedenfalls der bei mir zwingende Schlüssel zum 
Erfolg.

Bei vermurksten .inf-Dateien hilft Löschen der Cachedatei "INFCACHE.1":
http://answers.microsoft.com/de-de/windows/forum/windows_7-hardware/windows-7-erkennt-usb-anschl%C3%BCsse-nicht-mehr/e6b391c4-e100-4a11-b5a3-78721b7c8267
(Die Antwort von Nadine, Neustart ist nicht nötig.)

Gegen automatische Treiberwahl hilft ferner das hier, ist vermutlich 
nicht nötig:
http://forum.chip.de/windows-7/automatische-treibersuche-internet-abstellen-1449048.html#post8778613

Irgendwas mit Ctrl/Shift festhalten beim Einstöpseln bringt nichts. Das 
hat der Kollege wohl mit Autoplay verwechselt.

Ich bin noch auf der Suche nach dem zweiten FPGA. Habe jetzt mal das 
echte Blaster-Kästchen in Betrieb gesetzt. An die linke Stiftleiste 
angeschlossen kann ich damit genau das gleiche bewirken wie mit dem 
Slog-Treiber und dem onboard-USB. Die rechte Stiftleiste ist merkwürdig. 
Es wird nix JTAG-artiges gefunden. Stattdessen macht das Scope aber 
einen Reset.

Jörg

[Bruno W. (brunowe)]

Hallo Jörg,

Wegen der zweiten Stiftleiste hab ich dir mal nen Uralt- Link 
rausgesucht, evtl hilft dir das etwas weiter... Wir haben uns schon vor 
über 3 Jahren mit Quartus und JTAG beim WELEC beschäftigt... ein echt 
spannendes Thema!



http://groups.google.com/group/welec-dso/browse_thread/thread/e7240b9f13f0e254#


Gruß, Brunowe

[alex008 (Gast)]

Hallo,

nach langer Zeit gebe ich wieder einmal meinen Senf dazu.
Das Problem mit dem JTAG Treiber hatte ich auch eine Zeit lange, wie ich 
das damals unter dem XP endgültig löste, weis ich heute nicht mehr. 
Möglicherweise hilft das Deaktivieren des komischen 
Treibererweiterungsprozesses.
Vielleicht war es auch die Firewall mit der ich die 
Treiberidentitätsüberprüfung abgewürgt habe:
(Programm X möchte Programm Y aufrufen. Zulassen?) Mit der richtigen 
Kombination aus zulassen und verweigern ging es dann irgendwann.

Sollte sich der Treiber installiert haben lassen und Quartus erkennt die 
Schnittstelle am PC und kann trotzdem nichts runterladen, dann liegt es 
warscheinlich an einem Timeout verursacht durch einen USB-Hub (intern!!! 
oder extern).
PC(USB-Host)<->USB-Hub<->Slogs Treiber verträgt sich nicht.
PC(USB-Host)<->Slogs Treiber sollte gehen.

@Jörg
Das mit dem Reset hört sich schon gut an. Vielleicht lift dir das Errata 
Sheet weiter. Altera hatte irgendwann mal aus versehen in der 
Dokumentation die JTAG Pins vertauscht.

MfG
Alexander

[Andreas W. (andiiiy)]

Jörg H. schrieb:
> Das (bzw. das Config-Flash) habe ich nun mit dem Inhalt von Andreas W.
> (Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil5)") 
beschrieben.
> Nach einem Reboot meldet es sich nun mit Hardwareversion 1C9, und
> funktioniert augenscheinlich soweit.

Hallo Jörg,

das freut mich, dass die EPCS16 Version bei Dir läuft ... d.h. bei mir 
ist der Inhalt der FPGA's in Ordnung. Flash ist auch in Ordnung ... na 
was soll das dann noch sein?

Frage: Wenn das Display einen Fehler hätte, würde dann das Oszi starten 
??? Kommt dann evtl. nur die grüne LED der RUN/STOP-Taste???

Gruß Andi

[Thomas (kosmos)]

ich hätte da noch einen Wunsch an die Firmware wenn man ins Menü geht um 
einen Screenshot abzuspeichern, könnte man beim Wählen des 
Speicherplatzes das dort gespeicherte Bild anzeigen lassen? So sieht man 
ob der Speicherplatz frei ist bzw. ob dort ein älteres Bild liegt das 
man gerne überschreiben könnte.
Oder aber eine fortlaufende Erhöhung des Speicherplatzes, angenommen ich 
speichere etwas auf Platz 1 nehme ein neues Bild auf wechsle in diese 
Menü mit der Speicherfunktion könnte doch automatisch Speicherplatz 2 
angezeigt werden.

Zu dem NETPBM muss ich mir noch anschauen

[Thomas (kosmos)]

zur Konvertierung BMP ins PNG Format habe ich gerade eine Freeware 
gefunden 24 kByte großes Tool (benötigt keine Installation zumindestens 
DOS/WIN), das könnte man doch mit ins Firmwarepaket stecken.

http://cetus.sakura.ne.jp/softlab/b2p-home/
DOS/WIN32/Unix inkl. Quelltexte und Makefile für Linux

Könnte mir bitte jemand mal ein BMP aus dem Oszi zuschicken, bin gerade 
nicht zu hause, würde es aber gerne mal probieren.
mayn.de@kosmos (einfach vertauschen)

[Michael D. (mike0815)]

hallo Thomas...

Das Ding ist klasse! Konvertiert die BMP in einer Sekunde!
Jetzt wollte ich das mit in die Batch aufnehmen, will aber nicht so 
recht, kann das mal einer bauen, wahrscheinlich war ich heute zu lange 
in der Sonne... :-)))

Hier die  Batch von der screenshot-0.97os C3
---------------------------------------------------------------------
rem
rem Change -c argument to whatever COM port your DSO is connected to.
rem Invoke "%~n0 -h" for a list of command line options.
rem

"%~dp0\w2000a-screenshot.exe" -c 3 -b -a %*

bmp2png  [-6] *.bmp

rem png-conf.bat
--------------------------------------------------------------------
das mit dem Schalter "-6" bedeutet die Namensvergabe fortlaufend.
Konvertiert dann alle vorhandene BMP's.
Wenn ich die separate Batch von bmp2png mit Schalter starte, dann klappt 
das.
Man bräuchte so eine Art Warteschleife, wenn das BMP geschrieben ist, 
das danach konvertiert wird, wie macht man das am dümmsten?
Früher war ich in DOS auch mal fitter, Windows verwöhnt...tztztz

@Rainer
Mit deinem Prog. hatte ich gestern ein wenig experimentiert, irgendwie 
bin ich da auch nicht so klar gekommen

Gruß Michael

[Thomas (kosmos)]

nach dem konvertieren vielleicht noch die BMPs löschen, damit das Tool 
das nächste mal nicht wieder alle BMPs abklappern muss ob die schon 
konvertiert worden sind.

@Programmers: Könnt ihr mit den Quellcode etwas anfängen um vielleicht 
bei der neuen Firmware gleich PNGs zu übertragen, das würde die 
Datenübertragung um einiges Beschleunigen wenn man statt 900 kByte nur 
noch 20 kByte übertragen müsste, auch könnte man sehr viel mehr Bilder 
auf dem Flash speichern.

[Rainer W. (rawi)]

Michael D. schrieb:
> Mit deinem Prog. hatte ich gestern ein wenig experimentiert, irgendwie
> bin ich da auch nicht so klar gekommen

Wo drückt's denn?
Wenn ich mich recht entsinne, war es ein bisschen Fummelei, die 
Batch-Datei so hinzubauen, dass man Programme/Library, Bilder und konv. 
Bilder verzeichnismäßig vernünftig getrennt hat.

Gruß
Rainer

[Rainer W. (rawi)]

Hayo W. schrieb:
> Den Kompressionsfaktor zeigt das Programm übrigens beim Erzeugen der
> Screenshots an (liegt so rund bei 20 - 25%).

Thomas O. schrieb:
> ... das würde die Datenübertragung um einiges Beschleunigen wenn
> man statt 900 kByte nur ...

Keine Bange, die Daten werden komprimiert übertragen (z.B. leerer Screen 
mit 4 Linien -> 26k Byte Übertragung mit 17% Kompressionsfaktor) und 
w2000a-screenshot.exe zeigt am Ende der Übertragung die Datenmenge, wie 
Hayo schon schrieb, auch an. Das ist schon etwas schlechter kompremiert 
als PNG (6kByte), aber weit von 900 kByte entfernt.

Gruß
Rainer

[Thomas (kosmos)]

ja ok die Daten werden schon komprimiert übertragen und dann erst nach 
BMP umgesetzt, es kommt aber einem trotz Komprimierung doch sehr lange 
vor. 115.200 bps sind doch knapp 14 kByte/Sek.

Geht es mit dem USB-Host eigentlich schneller oder ist das auch eher so 
ein RS232 Adapter?

[Kurt B. (kurt)]

Der begrenzende Faktor sind die 115.200 bps die das Welec liefert. Erst 
wenn die Komprimierung bei gleichem Rechenaufwand verbessert werden kann 
wird es schneller.

[Thomas (kosmos)]

also ist die Komprimierung noch der bremsende Faktor.

kurze Frage mit welchen Programm kann ich die Speicherplätze das Oszi 
über USB auslesen bzw. zum PC übertragen oder geht das nur per RS232 und 
Screenshot.exe?

[Michael H. (stronzo83)]

Hallo zusammen,
die Frage von Andreas finde ich ebenfalls interessant - könnte einer von 
euch uns den Gefallen tun und mal testen, ob das Oszi bootet wenn das 
Display abgesteckt ist? Das wäre klasse!

Mich wundert es ein wenig, dass es von niemandem einen Aufschrei gab, 
als ich die zu niedrigen Kernspannungen verkündet habe... entweder hat 
hier noch keiner mit FPGAs gearbeitet oder es ging einfach unter?

Also nochmal:
Bei mir habe ich bei beiden FPGAs zu niedrige Kernspannungen gemessen! 
Bei FPGA1 knapp unter Soll, bei FPGA2 relativ deutlich. Eine aus dem 
spezifizierten Bereich fallende Kernspannung kann alle möglichen Effekte 
haben und kann durchaus ein Grund für die Spikes auf den Kanälen drei 
und vier sein.
Man kann die 1,2V auf Soll hieven, indem man dem Spannungsregler eine 
Sense-Leitung verpasst, so dass er die Spannung an der Last (den FPGAs) 
und nicht an seinem Ausgang regelt (dazu muss man natürich noch die 
Feedback Leiterbahn am Regler auftrennen). Auch die 2,5V sind deutlich 
unter Soll, die 1,8V ebenfalls leicht (jeweils an der Last gemessen, 
nicht am Regler!). Beides könnte Probleme verursachen(ADCS und SRAM).

Leider streikt meine Kiste ja, deswegen kann ich nicht testen, ob sich 
damit Verbesserungen erzielen lassen - leider geht auch mit korrekten 
Spannungen bei mir zur Zeit gar nichts. Aber es gibt hier doch einige 
Leute die keine Berührungsängste in Sachen Hardware haben - vielleicht 
findet sich jemand der es testen möchte? Vor Anlegen der Spannung sollte 
man aber sicherstellen, dass die Senseleitung wirklich korrekt 
angeschlossen ist, sonst würde der Spannungsregler bis auf fast 12V 
rauffahren.

Michael

[Thomas (kosmos)]

wäre es nicht einfacher zum testen ein Poti zu nehmen und mit dem 
Mittenabgriff die Spannung am FPGA etwas anzuheben. Passt die Spannung 
nach dem Spannungsregler und fällt evtl. nur zum FPGA hin so arg ab?

Vielleicht ist das wegen der Thermik gemacht worden oder sind das eher 
die ADC die gut warm werden?

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

Hallo, das wird wieder eine Sammelantwort, entschuldigt das 
Kuddelmuddel.

Michael H. schrieb:
> die Frage von Andreas finde ich ebenfalls interessant - könnte einer von
> euch uns den Gefallen tun und mal testen, ob das Oszi bootet wenn das
> Display abgesteckt ist? Das wäre klasse!

Der Displayanschluß ist unidirektional, das Display passiv. Es kriegt 
Clock, Daten, uns Syncs ab, wird laufend gescannt. Daher hat es keine 
Auswirkung auf den Rest, ob es gesteckt ist oder nicht.

> Mich wundert es ein wenig, dass es von niemandem einen Aufschrei gab,
> als ich die zu niedrigen Kernspannungen verkündet habe... entweder hat
> hier noch keiner mit FPGAs gearbeitet oder es ging einfach unter?

Ich dachte es ging um die Fehlersuche in einem defekten Gerät, nicht um 
einen generellen Mangel.

Bruno We schrieb:
> Wegen der zweiten Stiftleiste hab ich dir mal nen Uralt- Link
> rausgesucht, evtl hilft dir das etwas weiter...

Danke, hilft ehrlich gesagt nicht. In dem Bild ging es um die gleiche 
Schnittstelle die auch bei mir funktioniert, die ich links genannt habe. 
Im Bild ist nur die Platine auf den Kopf gedreht.
Ich kann mir nicht recht vorstellen, daß Wittig diesen JTAG-Anschluß 
richtig hat und beim zweiten irgendwas verdreht ist. Nochmal gefragt: 
Hat noch nie jemand Kontakt mit dem zweiten FPGA aufgenommen?

Thomas O. schrieb:
> Geht es mit dem USB-Host eigentlich schneller oder ist das auch eher so
> ein RS232 Adapter?

Das Thema hatten wir schon. Derzeit ginge es damit langsamer, die 
USB-Firmware macht nur 57600 Baud. Man bräuchte eine eigene Firmware für 
den USB-Controller, und passende Treiber am PC. Ist also kein kleines 
Thema. Wir suchen noch FX1-Entwickler...

Jörg

[Michael D. (mike0815)]

@Rainer
> Wo drückt's denn?
> Wenn ich mich recht entsinne, war es ein bisschen Fummelei, die
> Batch-Datei so hinzubauen, dass man Programme/Library, Bilder und konv.
> Bilder verzeichnismäßig vernünftig getrennt hat.
ja eben...auf dem Link habe ich ettliche Sachen runter geladen,ist aber 
irgendwie keine Executive dabei, die da so recht funzen will. Ansonsten 
finde ich da nur die Quellcodes?!?
BtW. Ist die Konvertierung da auch so schnell, wie die "bmp2png.exe?
Dann lade doch mal deine komplette Conf. inkl.Programm hier hoch, ist ja 
open Source, so wie ich das sehe!?!

> Keine Bange, die Daten werden komprimiert übertragen...
Also findet ja die Komprimierung im DSO statt, das ist dann wohl der 
Flaschenhals! Ich kann damit jetzt leben, ist ja keine Ewigkeit

@Michael H.
> Also nochmal:
> Bei mir habe ich bei beiden FPGAs zu niedrige Kernspannungen gemessen!
> Bei FPGA1 knapp unter Soll, bei FPGA2 relativ deutlich. Eine aus dem
> spezifizierten Bereich fallende Kernspannung kann alle möglichen Effekte
> haben und kann durchaus ein Grund für die Spikes auf den Kanälen drei
> und vier sein.
Das ist ja hoch interessant und klingt irgendwie plausible. Wenn du mal 
die genauen Messstellen fotografieren könntest, würde ich diese Woche 
das auch mal nachmessen und dann berichten. Bei mir sind extreme Spikes, 
wenn das DSO gerade eingeschaltet ist und nimmt dann während der 
Aufwärmphase etwas ab, (bilde ich mir ein) evtl. gibt es hier einen 
Temp-Drift in der Spannungsversorgung?
Ich habe nur ein FPGA, da hält sich die Temp. in Grenzen. Was ordentlich 
Temparatur bekommt, sind die ADC's, daher habe ich denen auch ein paar 
Kühlkörper verpasst.

Gruß Michael

[Michael H. (stronzo83)]

Hallo Thomas,
bitte nimm auf gar keinen Fall ein Poti für diesen Zweck!
Da gibt es verschiedene Probleme:
a) beim Einschalten steht das Poti irgendwo, die Spannung entsprechend 
auch => bis du es einstellst hat es längst bumm gemacht

b) der Schleifer eines normalen Potis prellt bei Betätigung => die 
Reglerspannung kann extreme Sprünge machen => wieder bumm


@Michael

Ich habe mal ein Foto aus dem Wiki kopiert und markiert, wo du messen 
kannst.
Es sollte sich leicht finden lassen: gemessen wird an den Kondensatoren 
der jeweiligen Last, bei den FPGAs also direkt unterhalb an den etwas 
größeren Keramikkondensatoren.

Das Problem ist, dass die Spannungsregler ewig weit weg sitzen und die 
Leiterbahnführung doch recht sparsam ausgefallen ist. Bei den niedrigen 
Spannungen fließen natürlich recht hohe Ströme zur Versorgung, daher 
gibt es einen recht beachtlichen Spannungsabfall entlang der Leitungen 
und des Steckverbinders. Oder auf deutsch: Pfusch.
Das Datenblatt des FPGAs spezifiziert 1,15-1,25V. Am besten lötet man 
sich an die Kondensatoren kurze Drähtchen und schaut dann im Betrieb die 
Spannung mit einem Oszi an, da jede Spitze die den zulässigen Bereich 
verletzt zu Problemen führen kann. Wenn schon der Gleichspannungswert 
nicht stimmt kann man sich das natürlich sparen...


Gruß
Michael

[Michael H. (stronzo83)]

@ Jörg

Danke für die Auskunft zum LCD - damit ist wieder eine mögliche Ursache 
ausgeschlossen.

[Michael D. (mike0815)]

@Michael H.

> Das Problem ist, dass die Spannungsregler ewig weit weg sitzen und die
> Leiterbahnführung doch recht sparsam ausgefallen ist. Bei den niedrigen
> Spannungen fließen natürlich recht hohe Ströme zur Versorgung, daher
> gibt es einen recht beachtlichen Spannungsabfall entlang der Leitungen
> und des Steckverbinders. Oder auf deutsch: Pfusch.
> Das Datenblatt des FPGAs spezifiziert 1,15-1,25V.
...genau das wollte ich losslassen und konnte es mir noch gerade so 
verkneifen. Deine Aussage hat das aber bestätigt. Interessant wäre noch 
zu wissen, ob denn die Spannung bei längerem Laufen stabil bleibt, oder 
schwankt.
Wenn man bedenkt, das die Pc-CPU's eine genaue u. absolut stabile 
Spannung mit 3 Stellen nach dem Komma benötigen um anständig zu 
funktionieren...mehr brauch man wohl nicht dazu sagen!
Deine Markierungen sind sehr Hilfreich, ich will mal schauen, ob ich die 
nächste Zeit dazu komme und werde dann berichten.

Gruß Michael

[Michael H. (stronzo83)]

Guten Morgen,
noch ein kleiner Nachtrag zur Spannungsmessung.
Wenn man nicht nur den DC Fall betrachtetn möchte, sondern auch den 
Ripple auf der Versorgung, dann braucht man natürlich ein Oszi dazu. Die 
Messung ist aber nicht einfach mit dem Tastkopf und der Masseklemme 
durchführbar - die Masseklemme ist zum einen eine wirksame Antenne, zum 
anderen bildet sie eine relativ große Leiterschleife in die Magnetfelder 
wunderbar einkopplen können.
Deshalb kann man den Ripple mit einem passiven Tastkopf nur so messen 
wie in dem Bildchen illustriert! Also einen blanken Draht um den 
Massekontakt des Tastkopfes wickeln, so erhält man die kürzestmögliche 
Masseanbindung. Wem das neu ist, der sollte sich den Spaß machen und 
einen Vergleich anstellen (Messung mit Masseklemme vs. Messung mit 
Drähtchen) - der Aha-Effekt ist garantiert.


Ich wäre sehr interessiert wie die Spannungn bei dir aussehen, Michael 
(und bei jedem anderen).
Ich habe wie gesagt DC Werte von ca. 1,15V und 1,07V bei den beiden 
FPGAs. Damit FPGA2 bei 1,2V liegt muss der Regler bei mir an seinem 
Ausgang ca. 1,3V liefern.
Die Vierkanalgeräte sind hier klar im Nachteil, weil die Wittigs die 
FPGAs offensichtlich mit sehr dünner Leiterbahn versorgen, über der 
natürlich bei zwei FPGAs durch den doppelten Betriebsstrom die doppelte 
Spannung abfällt wie bei einem.

Gruß
Michael

[Jürgen (Gast)]

Hallo Jörg,

Jörg H. schrieb:
> Ich kann mir nicht recht vorstellen, daß Wittig diesen JTAG-Anschluß
> richtig hat und beim zweiten irgendwas verdreht ist. Nochmal gefragt:
> Hat noch nie jemand Kontakt mit dem zweiten FPGA aufgenommen?

Warum auch? Da gibt es ja nach wie vor nichts Neues, was man da 
hineinladen könnte. Eben auch nicht vom LEON3! :-)
Im Datenblatt oder App.-Note von Altera findet man 2 oder 3 
Möglichkeiten, wie mehrere FPGA's ihre Konfig.-Daten aus einem EPCS16 
laden können. ES gibt nur ein EPCS16. Also muss man erstmal herausfinden 
nach welcher Methode die 2 FPGA's ihre Daten holen. Hatte ich zunächst 
auf "Todo" geschoben, da nicht nutzbar.

Gruß,
Jürgen

[Thomas (kosmos)]

@Michael H: Ich würde das Poti nicht an 12V Klemmen, sondern eine 
niedrigere Spannung im Oszi abgreifen und dann erst mal auf die 
gewünschte Soll-Spannung am Mittenabgriff einstellen. Klar sollte es 
nicht das billigste Poti sein, aber jedes Poti das für Audio geeignet 
macht keine solchen Sprünge wie du es beschreibst. Ich würde jetzt mal 
so blind(ohne das Datenblatt des FPGA zu kennen), ein 100 Ohm Poti 
nehmen, da kann also gar nicht soviel Strom fließen, die Spannung am 
Mittenabgriff auf die Sollspannung des FPGAs einstellen und dann erst 
auf die Stromversorgung des FPGA geben. Die Spannung des FPGAs kann also 
bestenfalls auf die Sollspannung angehoben werden, wenn ihm der Strom 
von knapp 15mA reichen.

PS. Gestern habe ich festgestellt das das eingeschaltete Oszi neben 
meinem Laptop die WLAN-Verbindung stört. War mit einem Hotspot in etwa 
150 Metern Verbindung nicht so schnell aber stabil, beim Einschalten war 
dann reproduzierbar die Verbindung weg. Die AVR Steckbrett daneben mit 
Nullpunkterkennung und Zündimpuls verursachte hingegen keine Störungen 
die die WLAN-Verbindung unterbrachen.

Meint ihr es würde etwas bringen das Gehäuse innen mit Kupferspray oder 
ähnlichen ein zu sprühen und mit auf den Schutzleiter zu legen?

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

Jürgen schrieb:
> ES gibt nur ein EPCS16.

Ah so, das ist doch mal eine Aussage. ;-)
Dann haben wir nach dem Auslesen/Umprogrogrammieren ja höchstvermutlich 
beides in einem Rutsch.

Ich habe noch etwas mit den USR-Instructions rumgespielt, aber noch 
nichts Interessantes gefunden.  :-(

Jörg

[Martin H. (martin_h85)]

Guten Tag,

hasst du dir mal die Kontakte auf der Stiftleiste vom Netzteil Board zum 
Logic Board angeschaut ?

Ich kann mir gut vorstellen das die qualitativ auch nicht die besten 
sind und schon dadurch eine größere Spannungsdifferenz entsteht.

Wenn dort auch etwas abfällt könnte man es durch den Austausch der 
Kontakte ja leicht beheben.


Gruß,
Martin

[Bruno W. (brunowe)]

Hallo,

Thomas O. schrieb:
> Gestern habe ich festgestellt das das eingeschaltete Oszi neben
> meinem Laptop die WLAN-Verbindung stört. War mit einem Hotspot in etwa
> 150 Metern Verbindung nicht so schnell aber stabil, beim Einschalten war
> dann reproduzierbar die Verbindung weg. Die AVR Steckbrett daneben mit
> Nullpunkterkennung und Zündimpuls verursachte hingegen keine Störungen
> die die WLAN-Verbindung unterbrachen.-

Da ich in einem akkreditierten EMV- Prüflabor arbeite und mir das 
entsprechende Equipment zur Verfügung steht, hatte ich eh vor die 
Abstrahlungen unseres Oszilloskops zu messen(Radiate Emission). Das 
lässt nicht nur Rückschlüsse zu wie sehr das WELEC andere Geräte stört, 
sondern auch welche Frequenzen besonders stark vertreten sind und ggf. 
geräteintern zu Problemen führen können.

Gruß

[Sebastian S. (sebastian_s47)]

@Bruno: Das wäre wirklich mal interessant. Wenn du dann Ergebnis hast, 
lass sie uns bitte zukommen.

Ich kann dir schon mal mehr oder weniger versprechen, dass um die 50kHz 
viel los sein wird - wer seinen Tastkopf schon mal über dem internen 
Schaltnetzteil abgelegt hat wird wissen was ich meine ;)

[Blue F. (blueflash)]

Jo, das seh ich auch so. Da dürfte im Diagramm eine ziemliche Spitze 
sein.
Wobei ich meine dass die Hauptfrequenz eher zwischen 12 und 16KHz liegt.

Aber mal abwarten was die Profis so rausfinden.

Gruß Hayo
(der leider im Augenblick wenig Zeit hat aber einige gute Ideen)

[Rainer W. (rawi)]

Hallo Michael,

Michael D. schrieb:
> BtW. Ist die Konvertierung da auch so schnell, wie die "bmp2png.exe?
> ...
> Dann lade doch mal deine komplette Conf. inkl.Programm hier hoch

Die Konvertierung der PPM in PNG geht "gut zügig".
Meine angehängte Konfiguration sollte direkt funktionsfähig sein, wenn 
du sie nach C:\ entpackst. Sonst müssen in den beiden Batch-Dateien die 
Pfade angepaßt werden.

Gruß
Rainer

[Roberto (Gast)]

Hallo
Kurze off Topic Frage :
@Bruno We
>Da ich in einem akkreditierten EMV- Prüflabor arbeite
Hast Du vielleicht einen Link, wo steht, wo die Grenzwerte bei einer 
EMV-Messung sind.. (finde da nix im Netz :-(  )
Hätte da ein anderes Gerät, dass ich diesbezüglich mal testen will.
Danke und l.G. Roberto

[Bruno W. (brunowe)]

Hallo Roberto,

natürlich kann ich dir helfen. Meine AW findest du im HW Thread, passt 
da einfach besser hin!

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


Gruß, Brunowe

[charly (Gast)]

@Hayo

eine gute Idee hab i auch noch:

Bei eingeschaltetem Quick Meas wird das Oszi ja viel langsamer,
meine idee: die QM routine wird erst nach einem Trigger Event
angesprungen denn sonst macht es keinen sinn ausser man braucht
einen Lottozahlengenerator ;)
Dadurch sollte sich doch sie Geschwindigkeit wieder etwas ehoehen,
was meinste dazu ?

vlG
Charly

[Timo R. (timo_r)]

Hallo,
ich hoffe ich bin hier richtig und es kann mir jemand helfen.
Ich habe mein Welec W2022A kaum benutzt. Das stand jetzt über ein Jahr 
im Schrank, da ich keine Zeit hatte. Jetzt habe ich es mal wieder 
herausgeholt und es Bootet leider nicht mehr. Mit dem WelecUpdater 
konnte ich einen Dump ziehen. Habe dann mal versucht die Open Source 
Firmware (1.2.BF.2.10) aufzuspielen, aber leider ohne Erfolg.
Wenn ich mit dem W2000-Update von der Welec Seite auf das DSO zugreife, 
bekomme ich keine Daten angezeigt (Seriennummer, Hardware Version ...). 
Über Google habe ich gefunden, das hier im Forum auch schon mal so ein 
Fehler nach einem erfolglosen Firmware update aufgetaucht ist und 
behoben werden konnte. Hänge den Dump am besten gleich mal an.
Gruß und danke schon mal
Timo

[Blue F. (blueflash)]

Hallo Timo,

Du bist definitiv richtig hier. Was zu klären wäre:

- ist Dein Gerät ein W2000 oder ein W2000A. Das läßt sich leider nicht 
aus der Gehäuseaufschrift ableiten. Daher die nächste Frage ->

- mit welcher Firmwareversion wurde das Gerät ausgeliefert bzw. welche 
FW war zuletzt drauf?

- Wenn Dein Gerät ein W2000 (ohne A) ist must Du erst diverse Änderungen 
vornehmen - Anleitung auf der Wikiseite verfügbar.

- welche Hardwareversion wurde angezeigt? (evtl. Kaufdatum noch 
bekannt?)

- Kam der Blackout erst nach dem Update? Lief das Gerät nach der 
Schrankrettung noch?

- warum hast Du versucht eine so alte FW-Version draufzuspielen? 
Aktueller Stand ist 1.2.BF.5.7C2

- Du solltest unbedingt Active Perl installieren (und den Win32 Serial 
Port) und dann den Upload mit dem Perlskript versuchen. Wenn der Upload 
mit dem Kompressor (16s) nicht funktioniert nimm den unkomprimierten 
Modus (180s).

Gruß Hayo

(der leider zur Zeit in Seeschiffahrtsvorschriften versinkt und deshalb 
nicht zum Programmieren kommt)

[Timo R. (timo_r)]

Halo Hayo,
danke für die schnelle Antwort.

Welche FW als letztes auf dem Gerät war kann ich leider nicht mehr 
sagen. Alles was ich noch ziehen konnte ist in der flash Datei.

Kann ich irgendwo sehen, ob es die Serie mit oder ohne A ist?  Welche 
Wiki-Seite meinst du? Habe den Beitrag 
Beitrag "W2000 Serie nach W2000A Serie aufrüsten" gefunden. Werde ihm mir mal 
durchlesen.

An die Hardwareversion kann ich mich nicht mehr erinnern. Ich habe es am 
20.05.2011 über Ebay gekauft (Verkäufer war „Wittig Electronics GmbH“ 
tek4you.eu ). Kann ich die HW-Version auf der Platine sehen?

Der Blackout war da, als ich das Gerät wieder aus seinem „Winterschlaf“ 
geholt habe. Das Update war ein Rettungsversuch, da sich von Wittig 
keiner auf meine EMail gemeldet hat. (Exististiert die Firma überhaupt 
noch?)

Sorry, bei der Angabe der FW-Version habe ich mich vertan. Ich habe die 
1.2.BF.5.7C2 aufgespielt. Die alte hatte ich zuerst versehentlich runter 
geladen, aber nicht installiert.

Active Perl habe ich mir gestern geladen und installiert. Damit will ich 
heute mein Glück versuchen.

Gruß
Timo

[Errico (Gast)]

Hello everyone!
I read often the interesting posts on this forum.
I would like to submit my problem arose 2 days ago.
I have a Welec W2022A about a year, I made the upgrade with firmware up 
to version written by Hayo 5.6C2 using the script from linux.
Two weeks ago I also made hardware changes using the  24.9 ohm and 150 
ohm resistors  instead of 0 ohm and 150 Kohm.

After I noticed a good improvement in performance in noise and 
linearity. The oscilloscope was switched on several hours these days 
without any problem.
Yesterday there was the ugly fact, I tried to turn the DSO and no longer 
boot, meaning that lights only the green button RUN / STOP.

I've done several tests since then
1) Apparently you activate the "germsmonitor" mode using the usual two 
buttons, the screen turns gray and after black normally.
I tried to reload the firmware (5.7C2) with GERMSloader, took about 180 
seconds instead of the usual 160sec  or so, either in RAM or in FLASH, 
but without success.
2) I also tried the ucl mode (16 seconds) but gives error in the phase 2 
of the firmware upload.
3) I tried to use the utility Welecupdater.exe with the original 
firmware 1.3, apparently is loaded after 30 minutes, but the scope does 
not boot anyway.
4) Apparently GERMSloader manages to read the contents of flash memory.
5) If I connect the USB port, the DSO is regularly recognized in 
windows.
6) If I press the two buttons of germsmonitor sometimes random LEDs are 
lit. (Normally I would have to get the instrument reboot.)

At this point I fear that there may be a hardware failure, even though I 
can not understand if it is random problem or is related to the mods 
made 2 weeks ago.  And after the mods, the oscilloscope worked indeed 
regularly on the first try and for several hours.
I am very sorry for what happened, because I'm very "attached" to the 
little "guy" who now works very well thanks to your work :-(
Thanks for your kind attention.

Errico

[Blue F. (blueflash)]

Ok, jetzt haben wir schon zwei Geräte die ins Koma gefallen sind. Woll'n 
mal sehen ob ich da im Parallelflug helfen kann.

timo r. schrieb:
> Active Perl habe ich mir gestern geladen und installiert. Damit will ich
> heute mein Glück versuchen.

Das ist schon mal ein guiter Ansatz. Als nächstes solltest Du ein 
Terminal mit den bekannten Einstellungen (stehen in der Datei How to use 
a Terminal) starten und mal gucken ob beim Booten was ausgegeben wird - 
wenn ja was.



Errico schrieb:
> At this point I fear that there may be a hardware failure, even though I
> can not understand if it is random problem or is related to the mods
> made 2 weeks ago.

Hi Errico, this makes the analysis a little bit more difficult. First 
try (as Timo) to check the boot messages. Start a Terminal (settings in 
"how to use a Terminal") and then start the DSO. It might be 
interresting if the DSO tries to start the firmware or not.

Hayo

[Andreas W. (andiiiy)]

@Hayo

dieses Fehlerbild kommt mir auch sehr bekannt vor. Leider habe ich noch 
keine Abhilfe für mein und die vielen anderen defekten Geräte (trotz 
allmöglicher Tests ... und Quartus ;-)!

Mein Trost ist, dass ich mir noch ein Neues gekauft habe ...

HW: 8C7.0E
FW: V1.4

Grüße Andi

[Timo R. (timo_r)]

Hallo Hayo,
das Perl-Script ist erfolgreich durch gelaufen.

Habe Putty eingestellt und das DSO gebootet, empfange aber nichts. Auch 
auf „h“ oder “,“ kommt keine Reaktion.

Was macht der „USB_Blaster“ genau? Ich habe gelesen, dass man diesen für 
das Upgrade bracht. Könnte der etwas helfen oder bringt der das DSO noch 
mehr durcheinander?

Gruß Timo

[Blue F. (blueflash)]

Der Blaster ist zum Programmieren des/der FPGAs vorgesehen und hat mit 
unserer Firmware nichts direkt zu tun.

Wenn die Firmware nicht mal startet könnte es das bekannte Problem mit 
den kalten Lötstellen am RAM sein. Das Screiben ins Flash scheint ja zu 
funktionieren. Da könnte generelles Nachlöten helfen, oder mal bei 
geöffnetem laufenden Gerät aufs RAM drücken. Generell scheinen die 
Verlötungen nicht die beste Qualität zu sein.

Gruß Hayo

[Timo R. (timo_r)]

Habe das Gerät jetzt mal aufgeschraub. Wo sitzt das RAM?

[Errico (Gast)]

Hello Dear Hayo, thanks for the answer!

I used Teraterm, do not I see anything when I turn on the DSO, "h" and 
"," give no answer.

If I go into "germsmonitor" I get this on the terminal

+
 ‚š
Í048
TC CPU
+
#0000: FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
#0010: FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
#0020: FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
#0030: FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
+
#0040: FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
#0050: FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
#0060: FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
#0070: FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
+l
?
+h
?
+

I have upload latest 5.7C2 firmware :


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 : TomCat.flash


--- Writing GERMS firmware...

Writing line 027233 of 027233: S8 detected, end of GERMS transmission.

Successfully wrote GERMS firmware in 218.8 seconds!

Please reboot DSO if it didn't restart automatically.


READY!
Thanks for all the fish.upload finshed



I think that firmware does not start at all. :-(

[Blue F. (blueflash)]

I think also...

Maybe it is the RAM soldering. See Picture in the next post.

[Blue F. (blueflash)]

One RAM is on the ADC side of the PCB (see picture) and one is directly 
on the other Side same position.


@Timo

die Lage des einen RAM siehst Du im Bild markiert. Das andere ist direkt 
darunter auf der anderen Platinenseite. Da kommt man nur ran wenn man 
die Platine abbaut.

Hayo

[Blue F. (blueflash)]

Ach ja, Timo, da Dein Gerät 2011 gekauft wurde, ist auf jeden Fall davon 
auszugehen, dass Du ein W2000A hast.

Als nächsten Schritt könntest Du die Spannungen am Netzteil nachmessen. 
Es könnte evtl. sein, dass da vielleicht was abgeraucht ist. Allerdings 
ist das Netzteil eigentlich recht zuverlässig, da nicht von Wittig 
selbst hergestellt sondern zugekauft. Aber das läßt sich recht schnell 
und einfach überprüfen. Die Spannungen an den einzelnen Pads hatte auch 
schon mal jemend hier gepostet (bzw. im W2000 Hardwarethread). Muß mal 
sehen ob ich das noch finde.

Hayo

[Errico (Gast)]

Hayo OK, now I open the DSO and I go to see the chips with the 
magnifying glass.
Then let you know

Errico

[Blue F. (blueflash)]

@Timo

Hier der Link zur Wiki-Seite

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

Da findet man schon Einiges.

Ansonsten mal im Hardware Thread (im alten) stöbern, da finden sich 
ähnliche Probleme.

Beitrag "Wittig(welec) DSO W20xxA Hardware"

Gruß Hayo

[Michael H. (stronzo83)]

Hm interessant, dass sich dieser Fehler bei immer mehr Leuten zeigt. 
Leider habe ich bisher auch noch keine Lösung gefunden, die meine Kiste 
wieder flott gemacht hätte...aber je mehr dasselbe Problem haben, desto 
größer ist die Wahrscheinlichkeit, dass jemand eine Lösung findet :)

Gruß
Michael

[Blue F. (blueflash)]

Also entweder ist es ein Bauteil das schlecht ausgelegt ist und öfters 
kaputt geht (glaube ich eher nicht) oder es sind kalte Lötstellen - was 
mein Favorit ist. Ich denke bei der Herstellung wurde schlampig 
gearbeitet und gerade kalte Lötstellen sind eine üble Sache weil sie 
sich nicht sofort auswirken müssen und schwer zu finden sind.

Gruß Hayo

p.s. so ich tauche jetzt ab - morgen bin ich wieder online