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
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
@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
@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
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
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
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
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
@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
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. 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
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
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
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.
Ein Komponententester ist ein Signalgenerator mit Auswertung. Unser Wellec hat nur Eingänge. Dein Traum wird wohl Traum bleiben müssen. Gruß
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 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.
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
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
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
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
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
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
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
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
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
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
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
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
@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
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
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
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
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...
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
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
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.
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
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?
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
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.
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
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
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
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
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
Ich verschwinde mal wieder in den Keller - Renovierung steht an. Schau nachher nochmal rein. Hayo
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
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.
VIELEN DANK ... ich bin dann mal gespannt. Gruß Andreas
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
Ich werde Euch informieren ... oder ich bin dann auch im Keller mit Oszi-Überreste ;-) Gruß
Womit flashst Du? Perl Skript komprimiert/unkomprimiert? Gruß Hayo
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
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
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
@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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Guten Tag Jörg, Das kann ich gerne machen. Habe nur leider selbst erst ein begrenztes Wissen über das Thema. Gruß, Martin
@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
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
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
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
@Hayo, nach 3000 Sekunden erfolglos ... Gruß Andi
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
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
@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
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
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
@Hayo, ich hatte noch KEINEN Altera am Gerät!!! Grüße Andi
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
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ß
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
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
@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
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
@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
Ich lade mal ein Backup von mir hoch, dauert aber ein wenig...
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
Achso, mein Oszi ist ein W2024A, die Hardwarerevision kann ich dir leider nicht nennen oder steht die auch irgendwo auf der Hardware? Michael
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
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
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
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
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
@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ß
@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
@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ß
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
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
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
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
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
@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
@Hayo haste das mal versucht: Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil5)" oder ist es hier 'untergegangen' ? vlG Charly
@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
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/
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
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
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
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
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
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
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
@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
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
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.
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
@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
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
@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ß
@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
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
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.
Ich muß zugeben, dass ich mich da erst einarbeiten müßte. Wenn sich da jemand auskennt ist er herzlich eingeladen sich einzubringen. Gruß Hayo
Ok, hier die Korrektur. Dran denken, neue Kalibrierung durchführen! Gruß Hayo
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
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
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
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
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
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.
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
und wie schätz du den möglichen Kompressionsfaktor ein, also im Vergleich zu den jetzigen 900 kBytes der BMP/PPM Bilder
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
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
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ü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...
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?
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
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
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
@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
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
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
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
1 | w2000a-screenshot.exe -a -f <folder> |
liefert die Bilder in einem festen Ordner ab und eine Batchdatei mit
1 | pnmtopng %1 >%1.png |
übernimmt die Konvertierung. Gruß Rainer
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
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
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
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
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
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)
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
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.
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
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
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?
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.
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?
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
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?
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
@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
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
@ Jörg Danke für die Auskunft zum LCD - damit ist wieder eine mögliche Ursache ausgeschlossen.
@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
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
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
@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ü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
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
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ß
@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 ;)
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)
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
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
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
@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
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
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)
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
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
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
@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
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
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
Habe das Gerät jetzt mal aufgeschraub. Wo sitzt das RAM?
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. :-(
I think also... Maybe it is the RAM soldering. See Picture in the next post.
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
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
Hayo OK, now I open the DSO and I go to see the chips with the magnifying glass. Then let you know Errico
@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
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
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
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.