Ok danke, ich schau mir das mal an. Gruß Hayo
Aktueller Zwischenstand, - Du hast Recht Jürgen, die Einstellroutinen für den Pulsweitentrigger sind zum Teil noch auf dem alten Stand von Wittigs ursprünglicher FW. Ich habe das jetzt mal gründlich überarbeitet. Jürgen K. schrieb: >>> Die Scalierung des externen Triggerlevels ist ebenfalls unvollständig. >> Was fehlt noch? Habe ich was übersehen? > > Der wird verstellt mittels Triggerlevel, Mainwheel und mittels > F5-Button. Ich konnte hier keine Unregelmäßigkeiten erkennen. Bei mir skalierte der Triggerlevel sauber mit den Probe-Faktoren. Bei welcher genauen Einstellung/Kombination hat es denn bei Dir nicht funktioniert? Beim Trigger habe ich Deine Signale auf die Schnelle nicht genau so reproduzieren können, habe aber mit etlichen verschiedenen "normalen" Signalen getestet und konnte keine Probleme beim Triggerr feststellen. Beim PW-Trigger war ich sogar überrascht, dass dieser trotz der vermurksten Hardwareimplementierung doch recht gut funktioniert. Gruß Hayo
Hallo Hayo, Hayo W. schrieb: >> Der wird verstellt mittels Triggerlevel, Mainwheel und mittels >> F5-Button. > > Ich konnte hier keine Unregelmäßigkeiten erkennen. Bei mir skalierte der > Triggerlevel sauber mit den Probe-Faktoren. Bei welcher genauen > Einstellung/Kombination hat es denn bei Dir nicht funktioniert? > Ich habe das eben nochmal versucht durchzuspielen. Es scheint doch so zu funktionieren. Kann sein, ich hatte nur die Quellen verglichen. Aber bekanntlich führen viele Wege nach Rom :-) > Beim Trigger habe ich Deine Signale auf die Schnelle nicht genau so > reproduzieren können, habe aber mit etlichen verschiedenen "normalen" > Signalen getestet und konnte keine Probleme beim Triggerr feststellen. > Beim PW-Trigger war ich sogar überrascht, dass dieser trotz der > vermurksten Hardwareimplementierung doch recht gut funktioniert. Na ich bin gespannt und wir werden sehen... Grüße
Und hier ist die neue Version. Auch verfügbar auf SFN - wie immer. Die Drucktastensteuerung der Pulseweitenwerte hat jetzt neue Steps und eine Begrenzung auf 524µs, ebenso die Mainwheelsteuerung. Ich habe noch mal alles geprüft und es lief bei mir alles schön stabil. Der Teufel steckt aber bekanntlich im Detail und deshalb sind Hinweise auf Fehler jederzeit willkommen. Gruß Hayo
:
Bearbeitet durch User
Hallo Hayo, Hayo W. schrieb: > Der Teufel steckt > aber bekanntlich im Detail und deshalb sind Hinweise auf Fehler > jederzeit willkommen. also los geht's: Ich komme zuerst mal auf den Pretrigger zurück. Mit dem oben genannten Edge Trigger Signal mit ca. 1s Abstand sieht man in der 1.2BF.7.13: Bei Timebase <= 250kSa/s wird der Triggerpunkt richtig angezeigt. Teilweise ab 500kSa/s oder ab 2,5MSa/s wird ein falsches Signal angezeigt. Dabei sieht es so aus, als ob zweimal ein Signal angezeigt wird. Zum Schluss aber der falsche Ausschnitt. Wenn man auf Single umschaltet, stimmt dann die Anzeige wieder nach dem Triggern. Als Referenz nehme ich jetzt mal die V1.4 :-) Dort funktioniert die Anzeige mit dem richtigen Triggerzeitpunkt (z.B. triggern auf fallende Flanke) in allen Timebase. Dazwischen habe ich weitere Versionen daraufhin getestet: BF6.3 und BF6.4C6 OK - ab BF6.5 falsche Darstellung Gruß Jürgen
Hallo zusammen, auf meinem W2024A war noch eine sehr alte Software. Jetzt habe ich die 7.13 eingespielt und habe folgendes Problem: In Y Richtung wird die Spannung falsch angezeigt. Statt 5V wird nur 4V angezeigt (Sprich: 0,8*Wert). Ich habe bereits gesucht wo ich die Kalibrierung verändern könnte aber habe nichts richtiges gefunden. Ich hoffe jemand kann mir hier weiter helfen. Danke. Gruß Stefan
Hi Stefan, erstmal die Frage ob Dein Gerät irgendwie modifiziert ist oder die originale Factory-Bestückung hat? Die entsprechende Einstellung nimmst Du im Hardwaremenü vor: Utility -> More -> Hardware - ADC Setup erstmal auf Factory - Pre Gain je nach Modifikation oder wenn nicht modifiziert dann Factory - Gain kann zur Feinabstimmung benutzt werden (default 1.000) - ADC-Driver würde ich Assembler nehmen, Standard geht aber auch Dann wieder zurück und Default Setup machen. Danach kalibrieren wenn das Gerät etwas warm geworden ist. Dann sollten die Amplituden eigentlich stimmen. Gruß Hayo
Hi Hayo, Danke für die schnelle Antwort. Mein Gerät ist Factory. Habe versucht ADC Setup auf Factory zu stellen und jetzt ist das Oszi eingeschlafen. Bildschirm leicht grün und keine Taste geht mehr. Aus- und einschalten bringt nichts ebenso reset (F2 + F1) es landet immer wieder an dieser Stelle. Gruß Stefan PS: Habe die alte FW eingespielt und anschließend wieder auf 7.13. -> Oszi läuft. Habe nur preGain auf Factory gesetzt und die Volt Kalibrierung stimmt. Danke. -> Das mit dem ADC Setup müsste ein Bug in der FW sein.
:
Bearbeitet durch User
Hi Stefan, nein ein FW-Bug in dem Sinne ist es nicht. Aber wenn Du von einer sehr frühen Version upgradest kann es vorkommen, dass noch alte Werte im Flash an Stellen stehen, die jetzt eine andere Funktion haben. Daher wie in der Anleitung beschrieben immer ein Default Setup machen nach dem Flashen wenn man größere Versionssprünge macht. Wenn das erst mal in Betrieb ist sollte man keine Probleme mehr haben. Wenn Du da jetzt was verstellst müsste das ohne Probleme auch wieder zurückzustellen sein. Wenn nicht, dann bitte noch mal Bescheid sagen. Gruß Hayo
Jürgen K. schrieb: > Bei Timebase <= 250kSa/s wird der Triggerpunkt richtig angezeigt. > Teilweise ab 500kSa/s oder ab 2,5MSa/s wird ein falsches Signal > angezeigt. Hi Jürgen, ich habe versucht das nachzustellen. Versuchsaufbau mit drei Oszis - Owon SDS8102 - WELEC W2022A mit OPA653 Mod und FW 7.13 - WELEC W2014A mit LowBudget Mod und FW 6.3 Am Signalgenerator habe ich Pulse eingestellt und den Start manuell getriggert um eine gewisse Ähnlichkeit zu Deinen Signalen zu erreichen. Spannungsbereich am Oszi war auf 2V/Div 90% ausgesteuert (also ca. 12V). Ich konnte keine Unterschiede zwischen den Oszis feststellen. Es wurde bei allen korrekt getriggert. Dein Signal scheint ja sehr speziell zu sein wenn es da Probleme gibt. Gruß Hayo
Hi, Hayo W. schrieb: > Dein Signal scheint ja sehr speziell zu > sein wenn es da Probleme gibt. da ist aber überhaupt nichts spezielles an dem Signal. Ist einfach ein Stück serielle Comm (9600,8,N,1 oder so) im ca. 1 s Abstand gesendet und aufgezeichnet. Ich vermute Dein Signal ist zu kurz und löst kein erneutes Triggern aus. Wie schon geschrieben, sieht es so aus, als ob das richtige Bild zuerst angezeigt wird und danach im RUN gleich überschrieben wird. Ich habe mal drei Screenshots angehängt. Vielleicht wird es damit besser sichtbar. Gesamt.bmp zeigt das gesamte Signal :-) Die zwei anderen eben Richtig und Falsch. Die Bilder hab ich wegen der Größe besser gezipt. Die Screenshots sind vom W2024A, 8C7.0H, BF7.13 und was auf den Bildern für Einstellungen zu sehen sind. Falls Du unter Windows unterwegs bist, kann ich Dir gern das kleine Progrämmchen zusenden, was die Signale ausgibt. Gruß Jürgen
Jürgen K. schrieb: > Die Bilder hab ich wegen der Größe besser gezipt. Probier doch mal, die in PNG zu wandeln. Das wirkt Wunder ;-) http://cetus.sakura.ne.jp/softlab/b2p-home/
Wolfgang A. schrieb: > Probier doch mal, die in PNG zu wandeln. Das wirkt Wunder ;-) Danke für den Hinweis!
Oho, da hab ich mich wohl geirrt :-( Ich habe wahrscheinlich die Antwort schon in der Frage mitgeschrieben: >> Ich vermute Dein Signal ist zu kurz und löst kein erneutes Triggern aus. >> Wie schon geschrieben, sieht es so aus, als ob das richtige Bild zuerst >> angezeigt wird und danach im RUN gleich überschrieben wird. Das wäre ja auch das beabsichtigte Verhalten: Im RUN so viel wie möglich Frames anzeigen, damit man kein Signal verpasst. Eben blos schlecht, wenn weitere Triggerereignisse im zu untersuchenden Signal folgen. Damit können durchaus je nach Länge des Signales verschiedene Darstellungen angezeigt werden. Je schneller die Anzeige ist und um so kürzer der Puffer im Verhältnis der Signallänge ist, umso mehr verschiedene Darstellungen des Signales können angezeigt werden. Nur war das eben nicht das von mir erwartete Signal "Triggern auf die ERSTE negative Flanke und Anzeige des ersten Teiles des Signals". Beim Single wird deshalb auch das erwartete Signal angezeigt, da nach dem Füllen des Samplespeichers nicht auf ein neues Triggerereignis getriggert wird. >> Die zwei anderen eben Richtig und Falsch. Das sollte also besser "Erwartet" und "Nicht erwartet" heissen. Bei langsamen Sampleraten dauert es eben länger bis der Samplebuffer gefüllt ist und eventuell passt das gesamte Signal in den Samplespeicher. Dadurch ergibt sich nicht die Möglichkeit einer erneuten Triggerung (hier bei 1s Impulsabstand und ca. 22,2ms Impulsfolgedauer). Also muss man hier besser SINGLE einstellen, um genau das Erwartete zu sehen. Sorry, man lernt eben nie aus :-) Beste Grüße und ein schönes WE Jürgen
Hallo Jürgen, ja das ist allgemein ein Systembedingtes Problem bei Oszilloskopen. Auch bei den alten analogen Geräten. Man hat immer eine gewisse Zeit in der das Gerät "blind" ist. Wenn es ungünstig läuft kommt das nächste Triggerereignis (Signalanfang) ausgerechnet in dieser Zeit. Da die Konstrukteure von Oszis dieses Problem auch schon recht früh erkannt haben gibt es die Holdoff-Time. Die kann man so einstellen, dass die "blinde Zeit" etwas länger wird, nämlich idealerweise so lang, dass der Trigger erst wieder nach dem letzten Signalteil scharf wird. So kann er dann wieder auf den nächsten echten Signalanfang triggern. Ob das bei unserem DSO so gut funktioniert wäre zu testen. Vielleicht kannst Du uns dazu Infos liefern? Dein Signal wäre ja der ideale Testprobant. Gruß Hayo
Hallo Hayo, genau in diese Richtung hatte ich gedacht. Ich werde die Holdoff Funktion etwas genauer mit dem Signal untersuchen. Gruß Jürgen
Hallo Hayo, die Holdoff Geschichte funktioniert bei unserem DSO so wie es sein soll! Du kannst nur in der Hardware Beschreibung mal korrigieren, daß das Holdoff Register doch nur 24 bit breit ist. Da ist es noch 32 bit breit. Damit ergibt sich bei 8ns Increment eine maximale Holdoff Zeit von 134,217 ms. Diese Begrenzung ist ja auch im User Interface so eingebaut (134,000 ms). Da gibts noch eine kleine Reserve :-) Der Pretrigger und die Anzeige ist ebenfalls ok. Schön wäre, wenn auch die Triggerpositionsauswahl "Fixed" oder "Constant" gespeichert würde und nach dem Einschalten entsprechend gesetzt wird. Gruß Jürgen
Ah ja, danke. Ich schau mir das mal an und korrigiere das. Gruß Hayo
Merry Christmas and happy 2016 to all Hayo and the dso team Let's hope that the new year will bring all the best and a new firmware! Sandro
And from me also a happy new year 2016 to all. The support for the hardware-mods and the BF-Firmware is still alive! If there are any questions or problems or maybe new ideas - post it here... Kind regards Hayo
Hallo liebe Freunde des Welec! Ich bin Besitzer eines W2024 und bis jetzt sehr zufrieden und finde euer Engagement bezüglich FW Erweiterungen bemerkenswert! Ich dachte nun, dass ich nach langem mal meine FW aktualisiere und bin von 1.2.BF.2.7 direkt auf die neueste 1.2.BF.7.13 umgestiegen. Folgendes Problem ist aufgetreten, die Nullpunkte stimmen nicht mehr, bzw. nur mehr auf der Null-Linie. Also verschiebe ich einen Kanal, dann verschiebt sich der Nullpunkt (wie wenn eine Skalierung nicht stimmen würde) - Kalibrieren hilft nichts. Habe dann verschiedene FW Versionen ausprobiert und bin da zu stehen gekommen, dass es bei meinem Gerät bis 1.2.BF.6.5 funktioniert, ab der Version 1.2.BF.6.6 aber nicht mehr. Ist das ev. wegen meiner HW-Version (8C7.0F), oder mach ich was falsch. Danke im Voraus für alle Antworten. LG Alfons
Nochmal Alfons! Vergesst bitte den obigen Beitrag, Hayo hats bereits oben beantwortet. Bin durch die vielen Beiträge erst jetzt drauf gestoßen. Pre Gain -> Factory war bei mir das Schlüsselwort. Danke
:
Bearbeitet durch User
Hi Alfons, ja das ist dem Einen oder Anderen auch schon passiert. Im erstem Moment nach dem Update denkt man nicht an die Hardwareeinstellungen... :-) Aber Du hast es ja selbst gefunden. Noch viel Spass Hayo
Hi, i have one question about sampling memory. Is there any way for using other memory on board like SDRAM to extend sampling memory buffer for slow speed (like 1MSps) or direct usb continuos reading to PC. Thanks a lot for best work firmware :)
Hi Sladjan, unfortunately the fast memory is limited to 4K for each ADC. This memory is directly coupled to the ADC (inside the FPGA). In Fast sampling Mode all four ADC are used in interleave mode - so there are 16K memory available. In slow sampling mode only one ADC is used, so there are only 4K memory available. Only in very slow sampling mode (USTB - ultra slow time bases) the samples are stored in the main memory and so there is a little bit more space. Without new FPGA-design there is no possibility to change this :-( Haye a nice week Hayo
Hayo W. schrieb: > Der Teufel steckt > aber bekanntlich im Detail und deshalb sind Hinweise auf Fehler > jederzeit willkommen. Moinmoin Hayo & CO. hab seit laengerem nun wieder in Hardware zu tun und hab die 7.13 aufgespielt weil die 7.1 massive Probleme im Single mode hat, leider sind die geblieben nur geht der Quick Mess jetzt auch nicht mehr (Freq. messung) die Cursors haengen links am 'Anschlag'; (oder hab i die bedienung vergessen), vllcht kann das auch noch jemand hier mit der 7.13 testen, danke Hayo koenntest du bitte zumindest nach dem Single mode schauen, ist f. mich sehr wichtig vlG Charly *EDIT*: hab eben die FW nochmal geflascht, def.setup und jetzt geht die Freq. messung im Quickmess, was da vorher war, KA...... der Single mode ist aber immer noch nicht OK, was genau kann i noch nicht genau beschreiben, ein Problem ist zb. falls trigger auf auto steht u. man aktiviert den Single dann Triggert er wenn man die TB aendert.... nochmals vlG Charly
:
Bearbeitet durch User
Hi Charly, also aktueller Stand bei Dir ist, dass der Single Mode irgendwie Probleme bereitet - korrekt? Du weißt aber noch, dass es ein Submenü gibt in dem Du einige Einstellungen zum Trigger vornehmen kannst? Hast Du die Einstellungen mal gecheckt? Gruß Hayo
Nice to heard you again, Hayo!! :-) Have you some good surprise for us, about new version of firmware? Thanks again for your great work... Regards, Paolo
Hi Paolo, at the moment there is no active development of the firmware from my side. This is because the actual version is running fairly stable and as second reason I'm deeply committed in some Raspberry Pi projects - for example RPi as ADS-B flight radar or RPi as media player build in a JVC boom blaster and so on. But nevertheless I'm giving support for bugs or problems in the firmware or hardware. So if you have trouble with one of these - don't hesitate to report your problems here. I will try to help you with a new FW version or some new hardware hints. Kind regards to you and all WELEC owners Hayo
Hello guys, for me it's time for a dumb question: how is it possible to forecast the sample rate at a given time base? For Welec's DSO the related formula should be sample rate = memory depth/(time per division*12) that doesn't match though. On my W2012A I read sample rate | time base 50Sa/s | 1s/div 1kSa/s | 200ms/div 100kSa/s | 2ms/div 250kSa/s | 1ms/div 500kSa/s | 500us/div 1MSa/s | 200us/div 25MSa/s | 10us/div 500MSa/s | 2us/div 1GSa/s | 20ns/div 1GSa/s | 5ns/div and so on which doesen't fit. What's the trick? Thanks, Pico
Hi Pico, the trick is to use oversampling. That means, that we read more samples than we need - except 50ns (which is 1:1) and 20ns/10ns/5ns/2ns (which is undersampling with interpolation). For example when we have 4 x oversampling - we are only using every fourth sample in the memory to display it on the screen. That gives us the possibility to "zoom in" in Stop-Mode or in Delay-Mode. Also this is the only possibility to get all needed timebases in spite of the very poor implemented ADC controlling unit in the FPGA. Hope that helps Hayo
Hello Hayo, honestly I don't understand. I meant the sample rate shown on the top of the screen. I thought it was related to something calculated by the firmware. For instance there is: sample rate | time base 50Sa/s | 1s/div 1kSa/s | 200ms/div 100kSa/s | 2ms/div 250kSa/s | 1ms/div 500kSa/s | 500us/div 1MSa/s | 200us/div 25MSa/s | 10us/div 500MSa/s | 2us/div 1GSa/s | 20ns/div 1GSa/s | 5ns/div Why by setting the time base for 200ms/div is shown 1kSa/s like sample rate on the top of the screen? Why 250kSa/s with 1ms/div? Why is 1GSa/s by setting for 5ns/div and still with 20ns/div? I guess that the firmware derives the sample rate from a formula, but I don't know what formula. Thanks, Pico
The Sample rate gives the number of samples per second, while the time base gives the horizontal scaling of the waveform on the screen. These are different things. If you activate the "Delayed" presentation of the signal, you even can have two different time bases for a signale aquired with an identical sample rate. Tom
Hello Tom, I agree. But i think in the firmware have to be a formula that ties sample rate with the setting of the time base, that is what I'm talking about. I set the time base for 200us/div and so on the top of the screen it's shown 1MSa/s, I set for 20ns/div and it's 1GSa/s, still the same value for 5ns/div, while by setting time base for 1s/div it's instead 50Sa/s and so on. How the firmware choose the sample rate shown on the top of the screen? For me by a formula that I don't know. Thanks, Pico
Hello guys, just another question. I know it's already been discussed but I'm not sure of the right answer because it has been provided differently from time to time. About the FPGA revision in some occasions have been told that 8C7 is better than 1C9, in other ones that 1C9 is better than 8C7. Which of the two is more resistant to spurious spikes? Thanks, Pico
Hi Pico, there is no formula inside of the firmware. This is controlled by table entries. Here a piece of the code: - the register values const unsigned long tb_value[36] = { /*-------16Kb--------*/ 0xFFFFFFFF, // 0 -> 2 ns 0xFFFFFFFF, // 1 -> 5 ns 0xFFFFFFFF, // 2 -> 10 ns 0xFFFFFFFF, // 3 -> 20 ns 0xFFFFFFFF, // 4 -> 50 ns 0xFFFFFFFF, // 5 -> 100 ns 0xFFFFFFFF, // 6 -> 200 ns 0xFFFFFFFF, // 7 -> 500 ns 0xFFFFFFFF, // 8 -> 1 µs 0xFFFFFFFE, // 9 -> 2 µs (500MSa/S) 0xFFFFFFFD, // 10 -> 5 µs (250MSa/S) /*-------4Kb--------*/ 0xFFFFFFFB, // 11 -> 10 µs (25MSa/S) 0xFFFFFFF3, // 12 -> 20 µs 0xFFFFFFE7, // 13 -> 50 µs 0xFFFFFFCE, // 14 -> 100 µs 0xFFFFFF83, // 15 -> 200 µs 0xFFFFFF06, // 16 -> 500 µs 0xFFFFFE0C, // 17 -> 1 ms 0xFFFFFB1E, // 18 -> 2 ms 0xFFFFF63C, // 19 -> 5 ms 0xFFFFEC78, // 20 -> 10 ms 0xFFFFCF2C, // 21 -> 20 ms 0xFFFF9E58, // 22 -> 50 ms 0xFFFF3CB0, // 23 -> 100 ms 0xFFFE17B8, // 24 -> 200 ms 0xFFFC2F70, // 25 -> 500 ms /*------- USTB -----*/ 0xFFFFFFFF, // 26 -> 1 s [USTB] 0xFFFFFFFF, // 27 -> 2 s [USTB] 0xFFFFFFFF, // 28 -> 5 s [USTB] 0xFFFFFFFF, // 29 -> 10 s [USTB] 0xFFFFFFFF, // 30 -> 20 s [USTB] 0xFFFFFFFF, // 31 -> 50 s [USTB] 0xFFFFFFFF, // 32 -> 100 s [USTB] 0xFFFFFFFF, // 33 -> 200 s [USTB] 0xFFFFFFFF, // 34 -> 500 s [USTB] 0xFFFFFFFF // 35 -> 1000 s [USTB] }; - and the text output unsigned char SampleRateData[36][11] = {{"1 GSa/s "}, {"1 GSa/s "}, {"1 GSa/s "}, {"1 GSa/s "}, {"1 GSa/s "}, {"1 GSa/s "}, {"1 GSa/s "}, {"1 GSa/s "}, //interpolated / normal {"1 GSa/s "}, {"500 MSa/s "}, {"250 MSa/s "}, {"25 MSa/s "}, {"10 MSa/s "}, {"5 MSa/s "}, {"2.5 MSa/s "}, {"1 MSa/s "}, //normal {"500 kSa/s "}, {"250 kSa/s "}, {"100 kSa/s "}, {"50 kSa/s "}, {"25 kSa/s "}, {"10 kSa/s "}, {"5 kSa/s "}, {"2.5 kSa/s "}, //normal {"1 kSa/s "}, {"500 Sa/s "}, {"50 Sa/s "}, {"25 Sa/s "}, {"10 Sa/s "}, {"5 Sa/s "}, {"2.5 Sa/s "}, {"1 Sa/s "}, {"1 Sa/2s "},//USTB {"1 Sa/4s "}, {"1 Sa/10s "}, {"1 Sa/20s "}};
And to your question about the FPGA version - 8C7 is the better choice. If someone have problems with his 1C9, there is the possibilty to change the version to 8C7. All you need is an Altera byte blaster clone (for < 10€) and the Altera programming software. Hayo
Hello Hayo, thanks, finally I get it! So ultimately it's a parameter taken from a table that decides the label on the top of the screen for the sample rate versus the time base. For me it's a useful thing to know. Thanks also for your reply about the better anti-spikes FPGA design. Honestly by reading the forum sometimes it's said that 1C9 is better than 8C7 and other times the reverse. Your post clarifies the issue once and for all, even if actually it isn't exactly what I was hoping for because my oscilloscope has the 8C7 and it isn't so resistant to the spikes. Pico
Yes the 8C7 also can have some problems with spikes. This seems to be a thermal problem. The 2 channel version has less problems than the 4 channel version. Optimizing the thermal design (like in my mod guides) can help to minimize these problems. The original build in fan has nearly no cooling effect. So it is recommended to change it against a better one. Doku and all other stuff can be found here: https://sourceforge.net/projects/welecw2000a/files/ Hayo
Hallo Hayo, bezüglich Sampleraten ist die alte Hardware meine ich noch nicht ausgereizt. In meinen Experimenten mit OSOZ auf dem alten FPGA habe ich keinen solchen Sprung von 250 MSa/s auf 25 MSa/s beobachtet. Die Werte dazwischen sind zugegeben aber recht krumm. Siehe CaptureSetTimebase() in osoz/platform/nios/capture.c Die Hardware hat erstmal einen "exponentiellen" Einstellbereich, wo sich bei jedem Registerschritt die Abtastrate halbiert. Ergibt 1GSa, 500MSa, 250MSa, 125MSa, 62.5MSa/s. Alle 4 ADCs und die volle Speichertiefe gibt es nur bei den beiden schnellsten Raten. Dann kommt ein schier endloser "linearer" Einstellbereich wo sich der Teiler mit jedem Registerschritt um 8 erhöht. Das ergibt Abtastraten von 31,25MSa, 25MSa, 20,83MSa, 17,86MSa, 15,625MSa, 13,89MSa, 12,5MSa, ... Mit dem neuen FPGA wird das besser. Vor allem steht immer die volle Speichertiefe zur Verfügung, bei Nichtbenutzung des anderen Kanals kriegt man dessen Speicher sogar noch hinzu. Für die Abtastraten siehe die Schwesterdatei osoz/platform/nios2/capture.c, gleichnamige Funktion, sowie die Tabelle gDecimations[]. Grüße Jörg
Hello Hayo, my DSO already has the thermal improvements described in the forum but spikes are a pain in the back because you never can know if they are real or artifacts. Pico
Hello Jörg, this means that somewhere there is an alternative design? Where? Thanks, Pico
I shoudn't advertise it, since it's kind of abandoned. I haven't worked on it since almost 3 years (just checked), no free time in sight. This is the thread about it: Beitrag "made from scratch Firmware für Wittig/Welec Oszilloskop W20xxA" Originally started as just a new software, then on mid 2012 it turned into a new FPGA design, too. Some coverage in the hardware thread, too: Beitrag "Wittig(welec) DSO W20xxA Hardware (Teil 2)" Jörg
Hi Jörg, ja das Thema mit der Samplerate hatten wir schon mal vor einiger Zeit. Ich hatte daraufhin das OSOZ-Coding geprüft und festgestellt, dass die 125 und 62,5 nur softwaremässig implementiert waren. Für diese Samplingraten gibt es aber (meines Wissens) keine Registerwerte die die ADC auf diese Rate einstellen. Falls ich mich da täuschen sollte bitte ich unbedingt um Hinweise. Dann würde ich da nochmal was nachrüsten. Aber - wo Du das alternative Design ansprichst - wie ist den der Stand der Dinge? Bist Du da noch dran? Oder ist das in Dauerparkposition? Ohh, sehe gerade dass sich das mit Deiner Antwort überschneidet. Du warst ja schon mal an einem sehr vielversprechenden Punkt... Schon dieser Stand wäre mit etwas zusätzlicher Peripherie um Lichtjahre weiter als das derzeitige Factory-Design. Hayo
:
Bearbeitet durch User
Hi Pico, did you adjust the settings in the hardware setup? There are factory and highspeed settings that may cause different behavior. Do you own a 4 channel version? Hayo
Hi Hayo, I did but still the problem is there. As suggested in the forum I have to put time for trigger out of the viewable area of the screen even if me I don't like it much. It's known that most likely spikes are near trigger event. Pico
Hi Pico, can you upload a screenshot with an example? That may help to identify the problem. Preferred a typical situation of measuring with this spikes. Hayo
Hello folks. It is a long time that I didn't set foot here. Lately I'm debugging a device for a friend of mine so I want to show how a Welec DSO can be used as MSO oscilloscope. So here you go a couple of pictures showing my W2012A_OPA653_MOD when compared with a logic analyzer while it's acquired the ATR response of a 4442 chip card using digital and analog trigger on Welec. As it's possible to see it works great. I did notice a little problem though. In my W2012A is installed the latest firmware 1.2.BF.7.13C2 and when using zoom by DELAYED button with some time base's values I get garbage on the screen. It seems that something is wrong with the memory used for the captured waveforms. Hardware is good, any fault, being that the problem only emerges using DELAYED feature. Could it be a firmware issue? Thanks! mark
Hi Mark, yes indeed I think you are right and this is a firmware issue. The digital mode function seems to be tested not so good as the other parts. I think it is used not so often - especially the delayed function. Due to that this failure has not been detected yet. If I find some time for that I will try to fix it. Thanks for reporting Hayo
Hello Hayo, thanks! In my opinion digital mode function works great, the only problem is in DELAYED function, in fact the garbage appears with both digital and analog representation. I don't want to abuse your time but I have some questions that I'd like to have an answer from you as soon as the time will allow it to you. 1) Are EXT Trigger working while using DIGITAL mode function? I'm not able to use it even by setting the trigger to NORMAL. 2) Are SINGLE mode trigger working while using DIGITAL mode function? I'm not able to use it even by setting the trigger to NORMAL. I guess due the well known issue of noise that plagues the Welec DSO's I have many random trigger acquisitions even when real one isn't present. 3)Would be possible add a new DIGITAL function that allows for the same rappresentation on the screen as the usual ones togheter with the chance to adjust the thresholds of the triggering action? I understand that make no sense because DIGITAL trigger have their own levels. I mean rappresntation of the waveforms on the screen though, something like FILTERS in AQUIRE menu, don't a real DIGITAL trigger as those already allowed in the firmware. Course I'm not in a hurry either for this questions than for the fix of the issue I have written, answers well when you have the time and mood, I repeat there is no rush. Thanks. mark
Hi to all , I confirm that the last firmware is good for spike triggering with CAN automotive signal, as enclosed image, but that improvements for digital may help. Let's wait for Hayo and the team amazing news. Best 2017 to all of you. Sandro
Hallo, ich hatte bereits 2010 ein W2014A von Michael Wittig über ebay ersteigert. Hardwareversion 1c9.0d, Softwareversion 1.4. Wegen der bekannten Probleme stand es bei mir jahrelang nahezu ungenutzt herum. Nun bin ich endlich dazu gekommen, die neueste BlueFlash Firmware 1.2.BF.7.13C2 zu flashen und auch den External Trigger Mod und den LB-Mod vorzunehmen. Das Gerät ist jetzt wirklich brauchbar! Vielen Dank an alle Beteiligten für die große Mühe! Leider zeigen sich zuweilen immer noch die lästigen Spikes. Eine Einstellung im ADC Setup auf HighFreq 1 bringt schon einiges. Im Forum habe ich gelesen, dass unter Umständen ein Umflashen des FPGA auf Version 8C7.0L Besserung versprechen könnte. Leider finde ich nirgendwo das benötigte File für diese Version. Könnte mir jemand einen Link benennen? Vielen Dank! Dietmar
Hallo Dietmar, das File kann sicher einer unserer FPGA Spezialisten hier zur Verfügung stellen. Notfalls müsste ich mal meine Archive durchstöbern oder von meinen Geräten eine Kopie runterziehen. Evtl. die Anfrage nochmal im Hardware- Thread wiederholen. Wenn keiner der Anderen helfen kann, sag noch mal Bescheid, dann muss ich mich mit dem Altera-Programm noch mal beschäftigen - ist schon etwas her, dass ich das benutzt habe. Gruß Hayo
Ich habe die Version, kann ich einem "Gast" aber nicht schicken. Bitte anmelden/einloggen. Ist ein ByteBlaster vorhanden? Man kann auch den USB-Chip mit einer entsprechende Firmware ausstatten. Jörg
Hi, auf die Schnelle habe ich folgendes File für den EP2C35 gefunden. Das könnte es sein, soweit ich mich erinnere. Im Hardwarethread hatte glaube ich auch mal jemand etwas hochgeladen. edit: Oh hallo Jörg, Du warst schneller als ich...
:
Bearbeitet durch User
Hallo Jörg, vielen Dank für dein Angebot. Ich habe mich gerade am Forum angemeldet und es wäre nett, wenn du mir das File zur Verfügung stellen könntest. Ein Altera USB-Blaster incl. Quartus-Software ist vorhanden. Grüße Dietmar
Hallo Hayo, auch dir vielen Dank! Ich werde von meinen Versuchen berichten. Grüße Dietmar
Hallo Hayo, darf ich mich anschließen, mit den Files. Ich besitze aus einem Nachlass auch jetzt auch noch ein W20xx ohne A. Nach den ersten Test war die Freude dann schnell am Ende. Ich fand dann den Thread hier, leider sind viele Links doch schon offline. Hast du noch die Files local bei dir ? Ich muss ja erstmal ein A aus dem DSO machen. Würde mich sehr über Hilfe freuen. VG Chris
Hi Chris, bin gerade aus dem Urlaub zurück und muss mich hier erstmal etwas sortieren. Aber ich schau mal was ich für Dich tun kann. Wegen der Files am Besten noch mal bei Jörg anfragen, seine Files sind auf jeden Fall die richtigen und er kann Dir auch in Sachen FPGA-Programmierung am Besten weiterhelfen wenn Du da Fragen haben solltest. @Jörg vielleicht kannst Du die Files ja im SF-Repository unter https://sourceforge.net/projects/welecw2000a/files/ ablegen? Dann hätten wir die an einer zentralen Stelle verfügbar. Gruß Hayo
:
Bearbeitet durch User
Vielen Dank, ja ich bin ein blutiger Anfänger. Habe nur soviel verstanden das man den Treiber bei Windows irgendwie trauschen muss. Dann tut der Wittig so als wäre er ein Programmer und dann dann sollte man das FPGA Programmieren können. Alles andere geht ja dann über den GERM und dem Welecupdater. Habe ich das soweit richtig verstanden? Chris
Ja ist soweit korrekt. Für die FPGA-Programmierung hab ich mir für unter 10,- einen Blasternachbau in der E-Bucht gekauft da der Treiber bei meinem Windows einfach nicht funktionieren wollte. Damit geht es auf jeden Fall - auch unter Linux. Dann brauchst Du eine Altera Installation um das FPGA (bzw. den Speicher) zu programmieren. Kann man kostenfrei runterladen. Die Anleitung zum Upgrade auf den A Typ muss ich noch mal raussuchen. Bist Du wirklich sicher, dass Dein Teil kein A ist? Auf dem Gehäuse steht das nämlich nirgends drauf - da steht immer nur W20xx ohne A. Gruß Hayo
Vielen Dank, den Blasternachbau habe ich mir jetzt für 3€ gekauft. Weil ich die treiber auch auf teufel komm raus weder unter Windows XP noch unter Windows 7 schaffe zu wechseln. Ja es ist eines ohne A, W2012 Software 1.00.08 / Hardware 3C7.0H Wird wohl eines der ersten sein. Chris
Ok, ich habe auf SF hochgeladen was ich so in Kürze finden konnte: https://sourceforge.net/projects/welecw2000a/files/Hardware/ Hier findest Du im Verzeichnis "Original" einiges an Doku und darin im Verzeichnis "FPGA" auch einige Altera Source Files. Auch dokumentiert ist die JTAG Steckleiste (es sind nämlich zwei identisch aussehende Steckleiseten vorhanden. Weiterhin ein Bild mit der Überbrückung am JTAG - wobei ich mir nicht mehr sicher bin ob man das für den Hardwareblaster auch braucht oder nur für den Softwareblaster. Vielleicht weiß das noch jemand. Notfalls schau ich bei mir noch mal rein. Im "Modification" Verzeichnis habe ich die Anleitung zum Upgrade auf "A" hinzugefügt. Ansonsten einfach hier nachfragen. Hayo
Vielen Dank, nun muss ich noch warten bis er aus China bei mir ankommt. Dann kann ich starten :-)
Morgen Hayo, demnach lade ich dann die W2022A.jic datei in den 2012 und danach mit dem welecupdater die Firmware ? Habe ich das so richtig verstanden ?
Ja, nach dem Umschießen des FPGA sollte der GERMSloader funktionieren und Du kannst dann mit dem beiligenden WelecUpdate.exe die Firmware reinladen. Die Prozedur mit den beiden F-Buttons kennst Du? Die ist ansonsten auch im Doku-Verzeichnis der Firmware beschrieben. Hast Du in der Anleitung zum Update auf "A" gesehen, dass Du auch noch einige Kleinigkeiten auf dem Mainboard umlöten musst? Ansonsten gibt es einige kleine ungefährliche Fehlfunktionen. Du kannst aber trotzdem erst das Firmwareupdate machen bevor Du da was umlötest. Dann kannst Du das Ergebnis besser checken - der nutzbare Screenbereich ist nämlich in der BF-Firmware größer. Hayo
Ja, das mit dem Löten habe ich in der Anleitung das ist ja wirklich sehr entspannt. Warte jetzt auf den Flashe und wenn es noch Probleme gibt melde ich mich, kann ich den Wittig eigentlich bricken oder ist es mit dem Blaster nicht möglich ?
Meines Wissens kein Problem, natürlich erstmal eine Sicherung vom Original ziehen bevor man loslegt - aber eigentlich kann man nix kaputt machen. Wenn das neue Build nicht läuft - einfach das Backup wieder einspielen, dann ist man wieder am Anfang. Allerdings muss man sagen, dass der Originalzustand nicht allzuweit von "kaputt" entfernt ist... Daher ist alles was einen irgendwie davon weg bringt ein Fortschritt :-) Hayo
:
Bearbeitet durch User
Ja Hayo, da gebe ich dir recht, schlimmer kann es nicht sein. Dann warte ich jetzt auf den Blaster und hoffe das es nicht zu lange dauert, jucken tun schon die Finger.
Sitze noch ein bisschen am Wittig, hat jemand ein tip wie man die Treiber wechseln vom Wittig. Es wird immer nur der HID Installiert ein aktualsieren endet mit der Meldung das der beste Treiber schon Installiert ist.
Das ist ja ein nicht ganz neues Problem... Schau mal im Hardware Thread im ersten oder zweiten Teil nach. Hier geht es z.B. auch um das Thema Beitrag "Re: Wittig(welec) DSO W20xxA Hardware (Teil 2)"
Vielen Dank, bevor ich alles zerlege wollte ich noch wissen wo ich U21 bzw. U23 finde. Ich habe keine Beschriftung auf der Platine finden können. Grüße Chris
Hi Chris, lade Dir das Dokument - Analog-Input-Part_assignment_V3_4.pdf - aus dem Sourceforge Verzeichnis herunter. Dort ist sowohl der Schaltplan als auch ein Bild mit der Position enthalten. Du musst dazu die Hauptplatine ausbauen, da die Teile auf der Rückseite liegen. Anleitungen zum Zerlegen gibt es in einer der Modifikations-Anleitungen - ebenfalls im SF-Verzeichnis. Gruß Hayo
:
Bearbeitet durch User
Ich wollte noch wissen, wenn ich den Blaster an den JTAG Port vom Wittig hänge, muss das Wittig dann eingeschaltet werden oder versorgt der Blaster den FPGA mit dem entsprechenden Strom? Als Treiber für den Blaster nutze ich dann den "USB_Blaster_for_W2000_v1.1" oder habe ich das falsch verstanden ? Chris P.S. den Treiber habe ich bisher weder unter Windows XP noch unter Windows 7 geschafft zu tauschen. Warte jetzt auf den Blaster.
Hi Chris, die FPGA müssen über die eigene Stromversorgung versorgt werden - also einschalten. Wenn Du einen Hardware-Blasternachbau verwendest brauchst Du diesen Treiber nicht, der emuliert nur den Altera-Blaster über die USB-Schnittstelle. Wenn Du den Blasternachbau verwendest, musst Du den Treiber für den Blaster in der Altera Software auswählen. Die Software steuert den Blaster dann direkt an. Gruß Hayo
Danke, aber heute habe ich nun geschafft den Treiber in WIndows XP zu wechseln so das der Wittig jetzt als Altera USB-Blaster erkannt. Soweit so gut nun suche ich den Altera Programmer, auf der Altera Seite habe habe mehre Versionen vom Quartus Programmer gefunden, leider laufen die nicht auf Windows XP. Gibt es ein Link oder hat jemand noch eine Version welche unter XP läuft. Grüße Chris
Bin jetzt weitergekommen, den Quartus II 10.1 Web Edition habe ich im Programmer kann ich auch den Nios II Ev. Board an USB-0 auswählen. Wobei im Geräte Manager steht ja Altera USB-Blaster. Ich habe auch ein Backup versucht aber es kommt "Error : Can't access JTAG chain". Habe ich da jetzt noch etwas übersehen ? Grüße Chris
Nein, dachte das brauch ich nur wenn ich den Blaster nutze. Habe es jetzt per USB direkt am Wittig probiert, also USB Kabel am Wittig, Treiber Installiert und dann mit dem Quartus II probiert. Der USB-Blaster wird ja leider noch dauern bis er auch China da ist.
Beim Stöbern bin ich auf den Originalbeitrag getstoßen - da sind die Details noch etwas besser nachvollziehbar: Beitrag "Re: Wittig(welec) DSO W20xxA Hardware" Hayo
Danke für den Link, leider könnte ich da nichts finden was mein Problem beschreibt :-( oder ich stehe da noch mächtig auf dem Schlauch. Dann werde ich wohl noch einige Wochen warten müssen bis der USB Blaster kommt :-( oder hast du da noche in Tip. Denke soweit bin ich vom Ziel noch nicht entfernt.
Hallo Hayo, jetzt hab ich es geschafft das es geht, lag am USB Switch. Direkt läuft das flaschen gut. Habe dein File "W2022A.jic"was du hochgeladen hast rein geflasht. Sollte beom booten jetzt nicht 2012a stehen? chris
Entscheidend ist die angezeigte Hardwareversion - hier sollte optimalerweise 8C7.xx erscheinen. Nicht so gut wäre 1C9.xx - aber beides sind W2000A Versionen. Wenn beim Booten weiterhin Deine alte Hardwareversion angezeigt wird, ist was schiefgelaufen. Gruß Hayo
Hallo Hayo, wollte gerade rückmeldung machen, alles gekappt jetzt läuft die neue Firmware. Danke für deine Hilfe.
Aber immer gerne :-) Viel Spass mit der neuen Firmware - da gibt es viel zu entdecken... Hayo
Da hast du recht, schon einiges gesehen und sehr überrascht. Kann man eigentlich auch daa DSO mit dem Computer bedienen bzw. ist dieses geplant ? Chris
Aber klar doch! Du brauchst dazu ein Terminalprogramm (so wie Teraterm oder Hyperterminal) das sich über die RS232 seriell mit einem anderen Gerät unterhalten kann. Näheres zu den Einstellungen findest Du im Doc Verzeichnis der Firmware. Beim Starten des DSO siehst Du dann schon die Textausgaben. Mit den entsprechenden Tastendrücken lässt sich alles Mögliche an und abschalten. Es gibt auch ein Screenshotprogramm, das den Screeninhalt auf den PC überträgt. Alles natürlich über RS232. Hayo
Hallo zusammen, wie hier Beitrag "Oszilloskop Wittig/Welec W2024A vs. Rigol DS1054Z" schon erwähnt, habe ich mir jetzt auch die aktuelle Firmware auf mein W2024A geflasht. Das ganze habe ich am Mac unter OS X (10.11) durchgeführt, deshalb hier etwas ausführlicher was dazu nötig ist - vielleicht hilft es jemand anderem auch. Benötigt wird ein USB-Seriell Interface; ich hatte noch ein Keyspan USA-19HS und musste lediglich die Treibersoftware installieren. Das Keyspan hat direkt eine Male DB9 Buchse und könnte damit direkt angesteckt werden, klappt aber wegen den versenkten Buchsen nicht. Habe dann mit zwei hintereinander gesteckten Gender-Changern verlängert. Für einen ersten Kommunikationstest noch mit der Original Firmware habe ich CoolTerm verwendet. Gibt's als Freeware. Passenden Seriellen Port ausgewählt, Parameter auf 115200, 8 N 1 - connect und hoffnungsvoll ein 'h' gedrückt. Erfolg, die Kommunikation klappt. Dann kann ja die Firmwareinstallation auch nicht mehr so schwer sein. Das Terminal gestartet, und erst mal mit # sudo cpan Device::SerialPort das fehlende Perl Modul nachinstalliert. (Muss als root gemacht werden) Dann alle erforderlichen Files - GERMSloader.pl - TomCat.flash - TomCat.ram in ein Verzeichnis kopiert und mit cd dorthin wechseln. # ls /dev/{tty,cu}.* zeigt an, auf welchem Device das serielle Interface hängt, bei mir /dev/tty.KeySerial1. Als Angsthase habe ich dann erst mal die Original Firmware gesichert: # perl ./GERMSloader.pl -d /dev/tty.KeySerial1 -r ./Backup_Welec2024A_Orginal Script läuft los und zeigt an, dass es wohl einige tausend Sekunden dauern wird. - Also, frischen Kaffee machen und abwarten. - Zum Schluss dann diese Meldung: * --- Backing up firmware from 00040000 to 007fffff... * Successfully read out firmware in 2473.1 seconds! * Writing firmware to ./Backup_Welec2024A_Orginal... und im Verzeichnis das File mit 4,7 MB Größe. Na wenn das klappt, könnte ich ja mal die neue Firmware wenigstens in den RAM schreiben: # perl ./GERMSloader.pl -d /dev/tty.KeySerial1 -w ./TomCat.ram * --- Writing GERMS firmware... * Writing line 029946 of 029946: S8 detected, end of GERMS transmission. * Successfully wrote GERMS firmware in 210.6 seconds! * Please reboot DSO if it didn't restart automatically. * * READY! * Thanks for all the fish. Ohne Reboot des Welec wurde nach kurzen Flackern ein Laufbalken angezeigt, das verschiedene Werte neu geschrieben werden müssen. Hat rund 10 Minuten gedauert und danach konnte ich die neue Firmware ausprobieren. Macht einen wesentlich besseren und bedienbareren Eindruck; die Kommunikation per seriellem Interface und Terminalprogramm klappt auch. Nachdem bis hier keine Probleme aufgetreten sind dann gleich Nägel mit Köpfen gemacht: # perl ./GERMSloader.pl -d /dev/tty.KeySerial1 -w ./TomCat.flash Ging auch gut und nach einem Reboot habe ich jetzt die aktuellste Firmware am Start. Vielen Dank an Hayo und alle anderen die das alles ermöglicht haben. Ein schönes Ostergeschenk! :-) Werde mich dann mal intensiver mit dem „neuen“ Oszilloskop befassen und bei auftretenden Fragen zurückmelden. Viele Grüße aus Franken NormalZeit
:
Bearbeitet durch User
Vielen Dank für die Info. PS: Nach dem Firmwareupdate hatte ich Probleme mit einen scheinbaren GND-Offset. Check mal ob Utility -> More -> Hardware -> Pre Gain Factory auf Factory steht. das steht bei einigen fälschlicherweise auf OPA653 o.ä.. Auch so lohnt es sich mal die Setups nach dem Firmware zu erkunden.
Ja, der Ground Offset hat mich zuerst auch irritiert. Nach dem Check aller Setups hat sich das aber schnell geklärt. Aktuell versuche ich noch vernünftig einen Screenshot hinzubekommen. Das Unix Programm im entsprechenden Verzeichnis läuft unter OS X nicht, Fehlermeldung "cannot execute binary file" und neu kompilieren mit dem Makefile klappt auch nicht. Da muss ich am Wochenende nochmal ran.
Gerhard J. schrieb: > Aktuell versuche ich noch vernünftig einen Screenshot hinzubekommen. Das > Unix Programm im entsprechenden Verzeichnis läuft unter OS X nicht, > Fehlermeldung "cannot execute binary file" und neu kompilieren mit dem > Makefile klappt auch nicht. Da muss ich am Wochenende nochmal ran. Zum Screenshot kann ich leider nichts sagen, ich bin inzwischen dazu übergangen den Screen mit dem Smartphone abzufotogtafieren und dank Dropbox etc ist der Ausdruck 1-2-3 auf dem PC und wo ich ihn sonst brauche. Da geht mir einfache von der Hand als mit USB-Stick etc.. Allerdings muss das Bild nach nachgearbeitet (beschnitten) werden.
Nicht, wenn Du es mit der App CamScanner mit dem Smartphone abfotografierst. Die App schneidet es automatisch auf den Bildschirm! Anschließend kannst es als jpg abspeichern und mit Share auf die Dropbox laden. Mach ich seit langem so, geht genial einfach, nur so als Tipp.
Gerhard J. schrieb: > Ja, der Ground Offset hat mich zuerst auch irritiert. Nach dem Check > aller Setups hat sich das aber schnell geklärt. Hallo Gerhard, wie Du schon herausgefunden hast, müssen die Einstellungen im Hardwaresetup erst korrekt eingestellt werden und dann eine Kalibrierung durchgeführt werden. > Aktuell versuche ich noch vernünftig einen Screenshot hinzubekommen. Das > Unix Programm im entsprechenden Verzeichnis läuft unter OS X nicht, > Fehlermeldung "cannot execute binary file" und neu kompilieren mit dem > Makefile klappt auch nicht. Da muss ich am Wochenende nochmal ran. Das Screenshotprogramm ist aktuell nur für Windows und Linux ausgelegt. Ich vermute, dass es aber auch ohne viel Aufwand auch für den Apple angepasst werden kann. Falls es Dir gelingt, wäre es nett wenn Du es hier zur Verfügung stellst. Gruß aus Südamerika Hayo
Hello folks. Simply as reference, I spotted that the 20MHz bandwidth limit function doesn't works into the latest firmware 1.2.BF.7.13C2. My DSO is a W2012A_OPA653_MOD and I tested the thing by measuring a sine wave signal of about 90MHz with and without inserting 20MHz bandwidth limit. When 20MHz bandwith limit is selected I espect some attenuaton on the signal drawn on the screen because of the 20MHz reduced bandwidth while measuring a 90MHz signal, but the signal drawn on the screen doesn't change not even a bit, it's the same as for full bandwidth. No any filters applied in "Aquire" menu. Thanks! mark
Hi Mark, thank you for reporting. Did you check this on an older firmware version also? I will try to find out if this is an original WELEC hardwarebug or if the switch is not working correctly due to firmware changes. Regards Hayo
Hi Hayo and Mark, I checked with firmware 1.2BF7.10 C2 and works properly. But some bugs with this version, changing the probe settings from 1:1 to 10:1 doesn't effect the level reading. Also, the deltaY cursors readings are always zero. Regards, Sandro
mark schrieb: > Hello folks. > Simply as reference, I spotted that the 20MHz bandwidth limit function > doesn't works into the latest firmware 1.2.BF.7.13C2. Hi Mark, I found some minutes time to check your reported problem today. I checked with 2 channels 653-Mod and 4 channel LB-Mod both with latest firmware. I measured on channel 1 only. Frequencies are 20MHz (as reference) and 100MHz with a Leader 3216 signal generator as source. Hardware setting is on "High Frequency 1". Find attached the screenshots I made. As you can see it works as it should and there is only a little attenuation at 20MHZ. At 100MHz there is a great attenuation - as it should be. So the question is what's going wrong with your DSO? Maybe something with your mod? Regards Hayo
Hello Hayo. Thanks for having spent some of your free time on it. Maybe it's really the OPA653_MOD I did, even if it would be weird since all is good with it, unless some garbage on the screen while using DELAYED function and ZOOM, but the 20MHz bandwidth limit function doesn't works. I spotted the issue by measuring an about 90MHz signal a bit dirty, so I thought to clean up inserting the 20MHz bandwidth. I'll dig the matter and if I'll find something wrong I'll post Thank you very much. mark
Hi Mark, if the noise you may want to reduce,like a modulation, is within 20 MHz BW inserting the filter don't effect the signal quality. Please see the enclosed photo using a spectrum analyzer. I made the OPA mod and works good up to 250 MHz, also tried others ic's OPA from TI , but this is the hardware limit. So I'm thinking another HW improvement, meanwhile may be Hayo like to update the firmware. Regards, Sandro
Hello Sandro. Thank you for your hint. I had the need to attenuate some high frequency spurious signals while measuring low speed enable signal. As reference something like measuring a 100 kHz square wave which turn on/off continuously a 100MHz sine wave, insertion of the 20MHz bandwidth limit doesn't works there. I have to dig further because could be even possible that in some circumstances it does works correctly just like Hayo wrote. Me too I made the OPA653_MOD. Interesting what you wrote, from my side i can't exceed 180MHz within 3dB bandwidth. Surely I can reach 250MHz like you wrote but in my case attenuation is much more than 3dB. With OPA653_MOD I have a 3dB bandwidth limit up 180MHz, going up the attenuation increases fast over 3dB. Where you wrote 250MHz do you mean the 3dB flatness limit or simply triggered signals shown on the screen without regards the bandwidth within 3dB? What hardware improvement are you thinking about? Thanks! mark
Hi Sandro, hi Mark, if there is the need of firmeware adjustment due to a hardware improvement I will do it! So if you have any idea to make things better - let's see how we can work together. Hayo
Hello Hayo. Thank you for the support. Hardware side I don't know. In my opinion Low budget mod and better OPA653_MOD are good enough and very simple to do without any need for something else. Of course if something new will be provided it will be carefully evaluated as always it has been, so any new idea there it's wellcome. Still for the hardware side I think that rather than work for improving bandwidth it would be better put the eyes on the trigger stability and steady waveforms shown on the screen. It's useless reach high value for the megahertz bandwidth if then trigger ability doesn't allow to acquire correctly the waveforms under measure. The 150MHz bandwidth offered by Low budget Mod and OPA653_MOD (actually about 180MHz as I measured with OPA653_MOD) are enough based on the weakness of the trigger and the instability of the waveforms displayed on the video which sadly are always dancing over the screen. It's even to consider that anyway on the screen the waveforms representation is rather crude compared to other DSO of the same kind especially for high frequencies and hence by using fast time bases. By the software side as first step it might be useful to try to correct the memory problem where some garbage appears on the screen while using zoom in DELAYED mode with some ranges of time base. Then, being dreaming I would suggest some things already asked by others in the past: 1) Maybe simple to do, put a warning on the screen in order to signaling when persistence is on. 2) Maybe hard to do, allow for uncalibrated VOLTS/DIV knob in order to fine scale waveforms on the screen instead of the only normal coarse scale. Since into hardware menu it's possible to adjust the gain of the input stage the matter would be to put the same function in the VOLTS/DIV management. 3) Perhaps even harder to do, set overlay function so that it acts just like the pass/fail mask testing from LeCroy. An easy way or better a simplified version of it could be allow for fine vertical and horizontal positioning of the overlay waveform so that it's possible overimposed it exactly anywhere on the screen that anyway it would be very hard to reach. That's all, but I'm just dreaming. mark
Hi Mark, unfortunately I have restricted access to internet until end of next week. I will answer in detail later. Hayo
Hi Hayo and Mark, yes I confirm the level is correct -3dB and trigger stable at 250 MHz,picture enclosed.But 180 is also good. I tested the trigger from 50 MHz to 250 and sometimes could be better as Mark reports.Hayo can say if is plan. I'm glad to partecipate to HW improvements,now is early will discuss later. Frequency flatness is tested with 50 ohms termination and synth. generator. Regards, Sandro
Hello Sandro. Thank you for the pictures. I agree 180MHz is good but your 250MHz @-3dB is terrific. It means the starting signal from the output of the leveled sine wave generator was -10dBm (0,20Vpp) while your Welec captured it as -13dBm (0,14Vpp). Really excellent result, congratulations Sandro. No, mine isn't so good. Me too at job I have a leveled sine wave generator and 50ohm terminations but I reach only about 180MHz within 3dB bandwidth flatness. Anyway I confirm that 250MHz are possible for sure with OPA653_MOD because with my Welec I could capture signals similar to yours, of course with greater attenuation though. Next days I'll take some picture and I'll put it here. @Hayo OK, thanks. I'll waiting for your answers mark
Hello Sandro. Sandro schrieb: > I checked with firmware 1.2BF7.10 C2 and works properly. > But some bugs with this version, changing the probe settings from 1:1 to > 10:1 doesn't effect the level reading. Maybe the latest 1.2.BF.7.13 already has the fix for the issues you wrote, cause I don't see them. @Hayo Anyway about what I wrote about the 20MHz reduced bandwidth feature, I'm totally wrong, my fault, sorry. The fact is that I expected roughly 100MHz sine wave when actually due an hardware failure there were only roughly 20MHz! This explain because the button for 20MHz bandwidth limit apparently doesn't work while actually it does!!! I'm really very, very sorry expecially for Hayo. mark
Hello folks. Today I spent the afternoon doing measures in order to document the bandwidth of my Welec and some other things. Well, or it should be better write bad, I had took a bunch of pictures directly storing them into the DSO but now I noticed that none of them has been correcly stored, it isn't possible recall not even one of them all. On my Welec there is the latest firmware 1.2.BF.7.13C2 and seems that memory function doesn't works as expected. I had also noticed that the label for linear interpolation or sin (x)/x in some case doesn't appears so that it's difficult know which of the two options is selected. By using the leveled signal generator I evaluated precise bandwidth of my W2012A_OPA653_MOD which it's resulted to be about 220MHz rather than 180MHz. The fact is that the representation of the signals on the screen it's very crude so that isn't simple evaluate their amplitude, honestly it's even much difficult understand their real shape even knowing that on the output of the leveled signals generator there are only sinusoidal waveforms. I also could see a 250MHz sine wave even if it was quite attenuated. Anyway strangely enough 230MHz sine wave was much easy than 240MHz, 230MHz and so on. The shape of the 250MHz sine wave was pretty good ,while going down to 245MHz or less it worsened it becoming very hard to recognize. Shape of the waveforms is however barely recognizable unless they are quite low frequencies and in any case always they are dancing on the screen. Thing are better by inserting filters in aquire menu but still not firm enough. one important thing I wanted to check it out is the right value of the Vrms quick measure but sadly all my pictures have gone missing. Quick measure on the screen were frequency, Vpeak-peak and Vrms, the leveled sine waves generator was set for -10dBm (0,20Vpek-peak, 71mVrms). Maybe next time. 20MHz bandwidth limit works fine as expected, no issue there. mark
Hi mark, what do you expect sampling a 250-MHz-Signal with 1 GS/s, as long as the Welecs sampling is far from perfect? So, what you see is ok.
Hello Guido. I'm expecting nothing, in fact I wrote my W2012A_OPA653_MOD stops very soon than 250MHz. Talking about -3dB flatness bandwidth my unit reach 220MHz but actually the usable limit is about 160-180MHz due poor trigger and crude rappresentations of the acquired waveforms and their stability. When the actual shape of waveforms are barely recognizable then bandwidth limit is the last of the problems, flying over the trigger's weakness, and I was already aware of all that, nothing new. That isn't the point. Since Sandro's statements I thought my DSO has some faults, perhaps something is wrong with how I made OPA653_MOD, so I wanted to compare it with Sandro's pictures. I'm pretty sure nothing is bad with how I made the modify and I already knew that my device wouldn't have reached same performances like that of Sandro, but in any case I wanted to try. Despite its many limitations I'm happy with my Welec that I even use for my daily work, however if it's possible to improve it well come. Even considering that there will also be a reason why my unit behaves in one way and as example that of Sandro in a different one. Here is because as reference I used -10dBm sine wave at 250MHz same as Sandro who I have to consider he enjoys the same performance throughout the whole bandwidth range without any gaps, doesn't matter if 250MHz, 245MHz, 217MHz, 83MHz, 1MHz, 11kHz, 34Hz or something else. Why normally does Sandro's DSO do that and my no? This is the question. Actually I think the real performances are those described and documented by Hayo in the manuals he wrote. I'm not doubting any of the other's claims, I just think that performance by somebody's devices, that of Sandro for example, falls in extraordinary cases, that anyway it would be useful to investigate. Surely there are some tolerances to take into account but this gap seems weird to me. It would be useful to have many more users able to do measures and sharing them, but I'm aware of how only very few of them they have the right equipments needed in order to do it. However for me the most important thing was to evaluate how much it was the accuracy of some readouts, precisely Vpeak-peak and Vrms. That was my primary goal but sadly all my photos are gone missed. I'll try to repeat it by saving pictures directly into a PC. To avoid misunderstanding I'm not saying that I think Vpeak-peak and Vrms don't work as they should, I'm just trying to exclude the possibility that my Welec actually has problems. I use it for work and I'm trying to be sure all it's ok with it. mark
Hello folks. This afternoon I had to do extra work, so in meanwhile I collected some pictures. DSO was Welec 2012A_OPA653_MOD using latest firmware 1.2.BF.7.13C2, the leveled sine wave generator was set for -10dBm (200mVpeak-peak / 71mVrms). Vrms and Vpeak-peak are right and consistent. I didn't manage to save and recall the acquired waveforms, I just managed to use the OVERLAY feature. In order to deeper the matter I did reset the DSO and via terminal program I did rewrite the trigonometric's tables without joy though. Next time I'll try reflashing the whole firmware. By playing with the terminal I spot this errors but I don't know what it means: ********************************************** BlueFlash firmware starting! ********************************************** - Hardware initialization - done - Display initialization - done QM -> draw_factor = 0 -> divide by zero exception will occur! QM -> draw_factor = 0 -> divide by zero exception will occur! - Starting up - done ---------------------------------------------- Version : 1.2.BF.7.13 C2 mark
Ok marc, your pics look like i remember the situation. Afair the problems are due to the samples not beeing stored in the correct order. I think only Jörg's new FPGA-design could help, but sadly he stopped working on that. Lets wait until Hayo is back again, he knows it better than i do.
Hello Guido. OK, thanks. Waiting for Hayo I would like to retake some of my questions and requests that have gone unnoticed, in the case him or somebody else being able to give an answer. Are EXT Trigger working while using DIGITAL mode function? I'm not able to use it even by setting the trigger to NORMAL. Are SINGLE mode trigger working while using DIGITAL mode function? I'm not able to use it even by setting the trigger to NORMAL. I guess due the well known issue of noise that plagues the Welec DSO's I have many random trigger acquisitions even when real one isn't present. Would be possible add a new DIGITAL function that allows for the same rappresentation on the screen as the usual ones togheter with the chance to adjust the thresholds of the triggering action? I understand that make no sense because DIGITAL trigger have their own levels. I mean rappresntation of the waveforms on the screen though, something like FILTERS in AQUIRE menu, don't a real DIGITAL trigger as those already allowed in the firmware. mark
Hi guys, I'm sorry but I'm just a bit in hurry due to business reasons. So don't be angry for waiting for some answers. I will try to take some time on weekend to make things a little bit clearer. regards Hayo
Ohoh, Hayo ist to busy. mark schrieb: > ********************************************** > BlueFlash firmware starting! > ********************************************** > > - Hardware initialization - done > - Display initialization - done > QM -> draw_factor = 0 -> divide by zero exception will occur! > QM -> draw_factor = 0 -> divide by zero exception will occur! > - Starting up - done > > ---------------------------------------------- > Version : 1.2.BF.7.13 C2 QM means QuickMath afair. Some parameters in Setup are not set correctly, so something horrible could happen showing the measuring values on screen.
:
Bearbeitet durch User
QM is the Quick Measure function. This seems to be only a message thrown out by the intializing routine. I think using the QM function will let this message disapear. mark schrieb: > Are EXT Trigger working while using DIGITAL mode function? > I'm not able to use it even by setting the trigger to NORMAL. I have no access to the code in this moment but if I remember right, there is no EXT trigger possible. > Are SINGLE mode trigger working while using DIGITAL mode function? > I'm not able to use it even by setting the trigger to NORMAL. > I guess due the well known issue of noise that plagues the Welec DSO's I > have many random trigger acquisitions even when real one isn't present. I'm not shure - I have to check it. > Would be possible add a new DIGITAL function that allows for the same > rappresentation on the screen as the usual ones togheter with the chance > to adjust the thresholds of the triggering action? > I understand that make no sense because DIGITAL trigger have their own > levels. At this time the triggerlevels are fixed due to the logic type. But indeed it would be possible to add a variable trigger for that. Also it would be possible to add a variable amplification for the voltage range. We discussed this some times in the past. Both are not so easy to implement and I decided to wait for Jörgs new FPGA design and the OSOZ firmware to implement those functions there. Nowadays it seems to be very unlikely that the new design will be finished anytime. So I will think about the possibility to implement those functions in the BF firmware (and maybe some other functions too). I did not realy understand what you meant with the overlay feature. Did anything go wrong? If there might be an issue - please make some additional screenshots to make things clearer. Kind regards Hayo
:
Bearbeitet durch User
Ok, found the issue with the message and fixed it. It occures only if the QM mode is active while startup. The new compilation C3 is available here... https://sourceforge.net/projects/welecw2000a/files/?source=navbar The message should not appear anymore. Kind regards Hayo
Thank you Hayo and sorry to annoying. Hayo W. wrote: > I have no access to the code in this moment but if I remember right, > there is no EXT trigger possible. OK, thanks! Hayo W. wrote: > I'm not shure - I have to check it. OK, thanks! Hayo W. wrote: > But indeed it would be possible to add a variable trigger for that. ... > I will think about the possibility to implement those functions in > the BF firmware (and maybe some other functions too). OK, nice to know. It 's really a good news, thanks! Hayo W. wrote: > I did not realy understand what you meant with the overlay feature. > Did anything go wrong? > If there might be an issue - please make some additional screenshots > to make things clearer. Simply I can only recall stored waveforms as overlay and not alway as memories. As you can see from the colour of the waveforms into the pictures I sent, almost the whole time are shown overlay. There may be a problem with my Welec or that I remember bad but for example acquiring a square wave and storing it with [Save Trace] as memory 1, a triangular as 2 and a sine as 3, then using [Recall Trace] should be possible show each of them on the screen. In my case [Recall Trace] has the only effect to RUN-STOP the oscilloscope by showing something waveforms which aren't related with the actual content of the given memory location. In order to show the actual shape of the stored waveforms in a given memory location I need to use the button [Overlay Trace] so that then it appears on the screen as an overlay with its expected color and sometimes as the real one with its expected color green and/or yellow depending on channels. I repeat, maybe something is wrong with firmware or it could be my Welec, anyway there is something weird. I have to go deeper, even because am I wrong or was there an alarm bell while acquiring screenshots on the computer? Honestly I'm a kinda confused, maybe it's just my fault. Hayo W. wrote: > 1.2.BF.7.13C3 I just upgraded my Welec with your new firmware 1.2.BF.7.13C3 and the error is gone. It does not show up anymore, thanks!: ********************************************** BlueFlash firmware starting! ********************************************** - Hardware initialization - done - Display initialization - done - Starting up - done ---------------------------------------------- Version : 1.2.BF.7.13 C3 mark
Hello Hayo. Some new details. I don't know if it's only a random case or not, but with the new firmware 1.2.BF.7.13 C3 the memories management behave better on my Welec, even if something weird still happens. I found that pushing the [Recall Trace] button then RUN-STOP is activated and the stored waveforms are shown on the screen but for something I think it's tied with the settings of the Time Base at the moment of memory recall only sometimes it's possible to see its right representation. With some range of the Time Base it's possible, with other ones it isn't and what is put on the screen it's meaningless although the recalled range of the Time Base is the correct one for that given memory location. So by turning the knob of the Time Base often it's possible to trigger the right visualization of the waveform that it's whished to see. In some cases, in my opinion depending on the range of the Time Base set at the moment of pushing the [Recall Trace] button, there is no need to operate the knob of the Time Base that the picture is shown already correctly without doing anything. In some other situations by changing the range of the Time Base doesn't do the trick and despite the memory location being the right one, then on the screen is shown the contents of a different stored memory location. Sometimes pushing [Clear Display] and/or [Restore Setting] does the same trick. Documentation explain what the meaning of [Restore Setting] is, but what about [Clear Display]? Talking about something else, seems that setting for Trace Middle, Keep Value or Keep+Follow a spurious spike is drawn on the screen. The same spurious signal is too overimposed on the waveform under measure. In that case [Pre Trig] is set wrong, it doesn't match the range of the Time Base based on its trigger position on the graticule, not even using [Adjust Window]. Instead by setting for Left Edge, First Div or Grid Middle, then the spurious spike doesn't show up on the screen and [Pre Trig] is set rigth, matching the range of the Time Base based on its trigger position on the graticule. This issue I think could be related with the worst shape sometimes drawn in the start or in the end of the waveforms on the screen depending on where the trigger is put on the horizontal axis (time for the trigger event). mark
Hallo, Habe ein WS2022A geschenkt bekommen. Es ist noch nichts modifiziert und auch die originale Software am arbeiten. Was soll ich da jetzt am besten machen? Ich habe keinen JTAG daheim, darum kann ich den FPGA nicht flashen. Was ist die letztbekannteste Version, die mit dem originalen FPGA zusammenarbeitet? Leider ist der Beitrag schon sehr unübersichtlich geworden.
Hier findest du alles, vom flashen der neuen FW bis zum modden und umbauen inkl. Dokumentationen, mußt eben ein "wenig" lesen! https://sourceforge.net/projects/welecw2000a/files/?source=navbar EDIT: neue Firmware kann über RS232, erst mal ohne "öffnen", geflasht werden Gruß Michael
:
Bearbeitet durch User
Hello Fred Ram. For unmodified DSO the latest supported firmware free is 1.2.BF.7.6 because it hasn't Save/Recall bug. Starting from 1.2.BF.7.9 there are new DAC-offset factors in order to matching the new R13 = 305Kohm instead of the old factory value (390Kohm) that will not be supported any longer. Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil5)" mark
Fred R. schrieb: > Was soll ich da jetzt am besten machen? Hallo Fred, nach den schon gegebenen Antworten auch noch mal ein Statement von mir. Also grundsätzlich - mit der originalen Firmware ist das Gerät nutzlos wie ein Kropf. Du hast jetzt diverse Optionen aus diesem Gerät etwas Brauchbares zu machen. Wie weit Du da gehen möchtest hängt letztlich von Dir ab. 1. Um das Gerät erstmal in einen benutzbaren Zustand zu versetzen solltest Du die aktuelle BF-Firmware flashen (1.2.BF.7.13 C3) die Du von Source Forge herunterladen kannst. Das Flashen geht dabei nur über RS232!!! Das USB-Kabel kannst Du gleich weglegen. An Deinem FPGA musst Du nichts machen. Wie man das macht und die benötigten Tools sind in dem Download-Package enthalten. Natürlich helfen wir auch gerne hier weiter wenn Du Fragen hast. 2. Es gibt 2 FPGA (Hardware) Versionen. Das Gerät meldet sich beim Hochfahren mit dieser Version. 1C9.xx und 8C7.xx. Bei der 1C9 wurde berichtet, dass hier vermehrt Probleme mit Spikes auftreten. Hier kann man jetzt das FPGA auf 8C7 umschießen wenn man möchte. 3. Es gibt diverse Hardwaremods die das Gerät verbessern. Dazu gehört eine bessere Belüftung oder auch Modifikationen an den analogen Eingängen oder am externen Trigger. Viel Erfolg Hayo
Hi Hayo, do you know this free program to analyze the analog/digital signals? https://sigrok.org/wiki/FAQ I'm doing hardware development of input stage for preamp and perhaps MSO inputs, may you evaluate W2000 FW mods to emulate one the listed instruments? Our DSO transformed to MSO oscilloscope is very useful! Sandro
Hi Sandro, no I don't know this software, but it seems to be very interesting. Also it seems to be a good idea to support an interface to this software. I will check this option in the next weeks and if it is possible I will add this feature. Thanks for the hint Hayo
Hi again, I checked some supported Hardware for SIGROK and my first Idea is to try a support for DSO/MSO with RS232 connection. This may be easier than to write an USB firmwaremodule and a system driver. Interesting are GW Instek GDS-800 and may be Hameg HMO or Rigol DS1000. I will check further options Hayo
Hi Hayo, thank you for your reply and new idea. I am registered at sigrok-devel@lists.sourceforge.net , they reply fastly and collaborate for development of new instruments with sigrok,the owner of the website came from city Braunschweig Germany,may be helps. Regards, Sandro
Hello Sandro, yes that may help. I just try to install and get familiar with the Software. If I understood right we have two main Options for using Sigrok. 1. we can create a file with our DSO which can be processed by Sigrok 2. we can connect Sigrok and the DSO directly via interface Both sounds interesting. I will check the possibilities. Hayo
Mal eine Frage am Rande - ich habe gestern ein bisschen mit den Cursors rumgespielt, wenn ich dann an der Zeitbasis drehe, werden die Werte des Cursors nicht automatisch angepasst, zeigen also die alten, falschen Werte. Soll das so? Meine SW Version ist relativ neu. Grüsse, Egberto
Du meinst die Werte, die auf den F-Tasten eingeblendet werden X1, X2, Y1, Y2 - richtig? Um ehrlich zu sein, ist mir das noch nicht aufgefallen und ich glaube es hat auch noch niemand sonst erwähnt. Aber Du hast natürlich Recht. Die Werte sollten aktualisiert werden. Ist in Arbeit... Gruß Hayo
New version out now - neue Version ist verfügbar! Die neue Version zeigt jetzt bei Änderung der Timebase und auch bei Änderung des Spannungsbereiches die aktuellen Cursorwerte an. Download hier: https://sourceforge.net/projects/welecw2000a/ Danke an Egberto für den Hinweis. Gruß Hayo
Der Dank geht an dich!! Ohne deine Arbeit hätten wir alle hier nur ein Stück Elektroschrott zu stehen. Und Fehlerkorrekturen/Updates so lange nach Projektende sind auch etwas besonderes. Viele Grüsse, Egberto
Danke für die Blumen... @Andiiy Wärst Du wieder so nett, die Änderungen ins Repo einzupflegen? Betroffen ist im Wesentlichen der Code in userif.cpp. Ansonsten nur das Changelog und tc_vars.cpp wegen der Versionsnummer. Gruß Hayo
natürlich ... wie immer (wird aber erst morgen)! PS: Ich fand die Idee mit sigrok auch ziemlich gut! Wobei NIOS2 immer noch ein schöner Gedanke wäre ... wo sind nur die ganzen FPGA Programmierer!
Supie! Ja ein neues FPGA-Image wäre sicherlich ein Sprung um Lichtjahre. Ich weiß gar nicht warum ich bisher nicht auf Sigrok aufmerksam geworden bin. Sehr vielversprechend. Ich analysiere derzeit die Treiberdateien für die GW Instek 800 Serie um eine Möglichkeit zu finden das W2000a auf das Protokoll zu synchronisieren. Das würde dann zumindest im 2 Kanalbetrieb einige Möglichkeiten eröffnen. Mehr als 2 Kanäle gibt der Treiber leider nicht her. Ein eigener Treiber für das WELEC wäre dann aber ziemlich einfach aus der vorhandenen Source zu erstellen. Für alle die an diesem neuen Projekt Interesse haben stelle ich mal die entsprechenden Sourcen hier bereit und hoffe, dass ich damit nicht gegen irgendwelche Lizenzbestimmungen verstoße. Gruß Hayo
:
Bearbeitet durch User
Andiiiy schrieb: > Wobei NIOS2 immer noch ein schöner Gedanke wäre ... wo sind nur die > ganzen FPGA Programmierer! Die ganzen... Also ich bin immer noch hier, auf der Welt. Wenn auch sehr mit anderen Dingen beschäftigt. Oszi-mäßig habe ich mir vor knapp einem Jahr "was ordentliches" gekauft, ein Keysight DSOX3014A, und zum Äqivalent eines MSOX3054A mit allen Optionen aufgerüstet, außer das meines sogar mit 5 GSa arbeitet. Es gibt da interessante Tuningmöglichkeiten. Macht viel Spaß damit zu arbeiten, ist superschnell und fühlt sich "analog" an. Leider zeigt es auch, daß man das Welec nie zu einem ordentlichen Werkzeug kriegen würde. Hardware-Rendering ist klasse. (60 mal in der Sekunde das Ergebnis von allen mittlerweile aufgelaufenen Triggervorgängen anzeigen, Häufung als Helligkeitsstufen, statt nur eine Welle.) Dafür ist der Speicher im FPGA viel zu knapp. Dazu noch alle erdenklichen Dekoder und Meßwertbildung in Hardware... Für den "normalen" und erschwinglichen Hobbybedarf bietet auch ein Rigol aus der 1000Z-Serie ein vielfaches. Die lassen sich ja bekanntlich leicht hochrüsten. Habe zugegeben noch nicht selbst damit gearbeitet. Zurück zum Thema, prima daß Hayo noch so tapfer dabei ist, Hut ab. Sorry daß ich mein Projekt nicht fertig genug bekommen habe. Viele Grüße Jörg
:
Bearbeitet durch User
Hallo Jörg, Glückwunsch zu Deinem tollen Neuzugang. Sowas hätte sicherlich jeder hier gerne. Aber ein Vergleich mit dem ehrwürdigen Welec ist auch etwas unfair :-) Das Keysight (bzw. ex-Agilent) ist ja Profiausstattung und mit 4,5K€ etwas außerhalb des normalen Hobbybudgets. Für den Hobby-Elektroniker oder auch Studenten mit schmalem Budget ist das Welec trotz aller Schwächen ein interessantes Gerät. Gerade deshalb wäre sicherlich die Unterstützung von Sigrok eine echte Bereicherung. Und wo hat man schon die Möglichkeit seinem Oszi eigene Funktionen beizubringen? Gruß Hayo
Nios2 ist aber nicht offener Quellcode? Mal OpenRisc angeguckt?
Andreas R. schrieb: > Mal OpenRisc angeguckt? Nein, noch nicht genauer. Wäre aber sicherlich auch eine Option. Die Lizenz für den NIOS2 wäre aber nicht das Problem. Jörg hatte da was am Start. Was wir brauchen, ist jemand, der sich mit dem Design von FPGAs auskennt und ein funktionierendes Design erstellt. Jörg hat sich ja schon relativ weit eingearbeitet. Das hörte sich zwischendurch schon echt gut an, bis dann die weitere Entwicklung abbrach. Ich hatte auch schon überlegt, ob ich da einsteige, aber mir fehlt etwas die Zeit um in das Thema wieder komplett neu einzusteigen (meine letzten Vorlesungen zu dem Thema waren in den 90iger Jahren). Denkbar wäre auch das Ganze als Studienarbeit oder so zu nutzen. Sowas hatten wir hier ja auch schon. Da lag der Schwerpunkt aber auf der Entwicklung von Filterbänken im FPGA und das Ganze auch nur für zwei Kanäle. So war das dann für uns nicht direkt nutzbar.
Hi, Ich habe mal das Screenshot-Tool etwas komfortabler gestaltet. Hier: Beitrag "Welec DSO Screenshot-Tool" falls Interesse besteht, kann ich das mit eurer Unterstützung noch etwas ausbauen. Gruß Michael
Hello Hayo. OK, thanks for the new 1.2.BF.7.14! This new one firmware corrects the problem wrote by Egberto, what about these others? Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil5)" Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil5)" Is there hope that also them can be adjusted too? Very good also for the intention to support the usage of SIGROK on the Welec's DSOs. About the bandwidth matter developed in some past posts and also in the intent of making calibrations of the DSO input stages I saw this: http://www.leobodnar.com/shop/index.php?main_page=product_info&cPath=124&products_id=295&zenid=82e2d98b8484f6fc53e13c392a4c3c47 http://www.eevblog.com/forum/projects/yet-another-fast-edge-pulse-generator/ I purchased it and with that device I have evaluated the bandwidth -3dB of my W2012A_OPA653_MOD equal to about 150MHz. Unlike other oscilloscopes, the measurement is quite difficult to do on Welec as the signal is rather unstable as it is drawn on the screen, anyway 150MHz is the most realistic value: rise and fall time equal to about 2,4ns (the fast pulser in question is rated 33ps rise time and 31ps fall time). Meanwhile for cheap I purchased a second hand W2022A too. The only change it has is the input resistors 33/150 ohm. By using the same fast pulser I wrote above I have evaluate its -3dB bandwidth equal to about 150MHz. I'm pretty sure my OPA653_MOD was done correctly but since I have now a new one Welec I changed its channel 1 input stage with OPA653_MOD as I done on my W2012A and still the -3dB bandwidth evaluated with the test device is about 150MHz. As I already wrote I'm happy with 150 MHz bandwidth, it's no problem. The thing is rather weird though. I wonder why somebody in bandwidth draws great benefits from OPA_653_MOD (Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil5)") and me no. Next step will be to change channel 2 with Low Budget Mod in order to check what happens.
@Michael sorry für die späte Antwort. Hört sich gut an. Bin aber momentan etwas unter Strom (passt zum Forum...) und konnte mir da noch nix ansehen. Hole ich aber schnellstmöglich nach. @mark > Is there hope that also them can be adjusted too? Yes - it just got out of my scope. Thanks for remembering. I will try to fix it after my holidays. > I wonder why somebody in bandwidth draws great benefits from OPA_653_MOD Please keep in mind, that the main idea behind this mod is not to increase the bandwidth, but to make the frequency response as linear as possible. It is easy to increase the bandwidth without linearity - but it is very useless because the signal shape you see on the screen is far away from reality. And that is what the original input stage does - it amplifies the higher part of the frequency range more than the lower part.
Hello Hayo. OK thanks. For bugfix it wasn't my intention to hurry. Sorry. About bandwidth improvement with OPA653_MOD I totally agree. As I already wrote I'm happy with it, that isn't the point. What I'm trying to understand is why of the behavior described by someone compared to others. Maybe OPA653 I purchased were fakes, maybe it's some other component inside the Welec, maybe I was wrong to make the change, maybe... I think the performance of some devices, that of Sandro for instance, falls in extraordinary case. The expected ones are those described and documented by you into the instructions you wrote. I'm pretty sure nothing is bad with how I made the modify as well as the performance I detect in my two specimens are what is normal to expect. Indeed what I get is roughly the same value you measured with your TR-0307 pulse generator which is 2,5ns rise/fall time: Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil5)" As it's possible to see in your documentation the frequency response evaluated with your Leader 3216, which stop at 140MHz max, from around that frequency value begins to get worse quickly. @ Michael D. Well done, thanks. mark
mark schrieb: > from around > that frequency value begins to get worse quickly. But that's no problem, if the frequency response is linear in this range. The sample rate of 1 GHz combined with about 150 to 200 MHz bandwidth is good for signals in the range of 20 to 50MHz. In the real live that are not sinus waves. That means, the signals contain frequencies which are factor 5 higher than the main frequency. Measuring signals with higher main frequencies will result in signal distortion and less measuring quality. So - to repeat what I said before - we can be happy if the modification leads to an accurate signal shape on our screen. Don't worry about some MHz more or less bandwidth, in practice that makes no difference. p.s. I will make some additional measurings with my DSOs after holiday to have some more value to compare with. I don't think you got fakes of the OPA653. The only fakes I know are the original parts of the W2012/W2014 and also some of the W2022/W2024 (with green dots). But parts directly from the manufacturer are beyond any doubt I think.
:
Bearbeitet durch User
Hayo W. schrieb : > @Michael > > sorry für die späte Antwort. Hört sich gut an. Bin aber momentan etwas > unter Strom (passt zum Forum...) und konnte mir da noch nix ansehen. > Hole ich aber schnellstmöglich nach. Kein Problem, eilt ja nicht! ;-) Bei Gelegenheit könntest du mir mal die Schalter für das abspeichern von CSV und ASCII mitteilen, ich kann die nirgends finden. Am besten hier rein: Beitrag "Welec DSO Screenshot-Tool" oder per PN Gruß Michael
:
Bearbeitet durch User
Hi mark, I tried to get the same failure as You - but I wasn't able to reconstruct the issue. I used the same settings and same signal. Can you give me a hint how to bring this on the screen? Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil5)" Hayo
:
Bearbeitet durch User
Hello Alles, I have a W2012A dso, and I have flashed BlueFlashFirmware since many years. I have flashed last version (1.2.BF.7.14) few minutes ago. I have an issue related to channel offset and amplitude. Offset: Input disconnected = 0V input. When the channel is centered, Trace is centered. Moving the channel (vertical position) the trace moves far from the arrows indicating "zero". The more the channel is away from center of the screen, the more the trace is away from the arrows. Amplitude Scaling: With 12.0V DC input connected, channel centered in screen, I read 9.0V. Moving the channel toward the bottom of the screen, the reading is correct (12.0V) when the trace is at center of screen (and the arrows are "-12V"). As the problem is there since many version of firmware, I was wondering if this is a software issue (firmware or calibration) or it could be hardware issue. Many thanks.
@Alessandro Mauro Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil5)" Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil5)"
Hi Alessandro, there are new hardware settings since the last firmware releases. So you have to go to your hardware menu and choose the correct settings. If you havn't modified your DSO, the factory setting is the best choice. Otherwise you have to choose the setting matching to your mod. If you are not shure how to setup your DSO, I will help you in detail. Regards Hayo
:
Bearbeitet durch User
Hi again, here a screenshot of my W2022A. The first setup is for the OPA653 Mod and the second for an unmodified DSO. The ADC-Setup can be changed for different signals and frequencies to avoid spikes and other crap. Regards Hayo
Hayo W. schrieb: > So you > have to go to your hardware menu and choose the correct settings. Thank you Hayo, it was that! Changed to Factory now it is okay!
Hallo, erst einmal recht großen Dank und Anerkennung an alle, die an diesen Projekt die vielen Jahre gearbeitet haben. Habe jetzt erst von 1.2.BF.2.x auf 1.2.BF.7.14 geflasht. Da ich derzeit einen Tastkopf 500:1 verwende ist mir noch ein Fehler in tc_vars.cpp aufgefallen.
1 | //Voltage ratio
|
2 | const float VoltFactor[19] = { 0.001, // 1mV |
3 | 0.002, // 2mV |
4 | 0.005, // 5mV |
5 | 0.01, // 10mV |
6 | 0.02, // 20mV |
7 | 0.05, // 50mV |
8 | 0.1, //100mV |
9 | 0.2, //200mV |
10 | 0.5, //500mV |
11 | 1.0, // 1V |
12 | 2.0, // 2V |
13 | 5.0, // 5V |
14 | 10.0, // 10V |
15 | 20.0, // 20V |
16 | 50.0, // 50V |
17 | 100.0, //100V |
18 | 200.0, //200V |
19 | 300.0, //500V sollte '500.0' sein. |
20 | 1000.0}; //1000V |
vielleicht kann das jemand noch bereinigen. Grüße jofri
Oh oh... wie konnte das passieren und so lange unbemerkt bleiben? Korrigiere ich natürlich umgehend. Danke für den Hinweis. Gruß Hayo
Hi Folks! Second compilation (C2) of 7.14 firmware with corrected divider table is available now on sf-net: https://sourceforge.net/projects/welecw2000a/ regards Hayo
Hallo Hayo, Danke für deine rasche Korrektur. Beim Utiliy-Menü sind mir die Punkte Defaut-Setup - was geschieht da genau? Calibration-Standard - was ist Set3 / Set4 nicht ganz Klar. Gibt es irgendwo eine zusammenfassende Beschreibung der Menü. Danke Josef
Hi Josef, eine kurze Beschreibung aller nicht Standard Funktionen findest Du in der Datei Special Functions im Doc Verzeichnis. Aber wo ich gerade dabei bin: Man kann verschiedene Kalibrierungen speichern. Wenn man z.B. einen aktiven Tastkopf hat, so weicht dessen Kalibrierung von der normalen Kalibrierung ab. Damit man nicht immer einen neuen Durchlauf starten muss, kann man sich für verschiedene Tastköpfe je ein Kalibrierungsset speichern. Wenn Du normalerweise nur selten mit anderen Tastköpfen arbeitest kannst Du auch einfach auf Standard bleiben und vor der Messung eine Kalibrierung machen. Das Ganze war eine Anforderung von einigen Spezialisten, die häufig mit unterschiedlichen Eingängen arbeiten. Gruß Hayo
Da mir meine liebe Frau ein neues Oszi geschenkt hat, gebe ich mein Welec 4-Kanal 200 Mhz mit (fast) aktueller Blueflash Firmware gegen Porto ab (keine Garantie, keine Tastköpfe und sonstige Kabel!!) Ich hatte damals den Lüfter gegen einen größeren, leiseren ersetzt, ein Abschirmblech eingebaut und die 2 Trigger LEDs in die Frontplatte gebaut. Das Gerät ist soweit funktionsfähig, hat aber die bekannten Welec Designschwächen. Ziel dieser Aktion sind Bastler, die dieses Gerät aktiv weiter entwickeln wollen bzw. Schüler/Studenten mit Ambitionen, die Entwicklung hier weiter zu treiben. Kontakt bitter per PM. Mirko
Hi guys, I've been away for a long time, is there still someone here? I hope so. I own a W2012A upgraded OPA653 with the latest firmware 1.2.BF.7.14C2. Based on the document "Spektralanalyse mit dem WELECW 20xxA" (https://www.mikrocontroller.net/attachment/53555/W20xxA_Spectrum_Analysis_de.pdf) it would be possible to switch from linear to logarithmic and reverse but I can't find anymore the MODE button which is used to switch among V and dB. Is it only me or the button has been removed? Regards, Antony
Hi Antony, sorry for the late reply. There is no button in your menu? It is correct, that the appearence of the menu changed. There are new modes available. The logarithmic mode is called Power Spectrum now - and that's what it is. But I found a little bug. When switching the modes, the type of magnitude in the display on the rigth side is not correct. You have to switch to x-y or main and back to get the correct display. I will try to correct this in the next time. Hayo
Hello Hayo, thanks and no worry. There is no hurry, one answers when he can and wants. OK, many thanks for the explain, I'll follow your advice. One more thing, if it's possible. I'm dumb for sure, but is it that with the new firmware it's no longer possible to display the values in dB overimposed on the graticule? OK, I had have the experienced the bug you wrote. Doing what you wrote in the end I have Mag:log(dBm). I don't know if this could be useful, but I managed to achieve the same result also with a reset. Much better your method though. Regards, Antony
Hi, I shifted the grid to the left, to get space for the display on the right side. So the values had to disapear. I found the display more useful than the dB values so I decided to sacrifice them for the new display. I hope this is useful for you too. I will try to solve the switching problem as soon as possible. I will let you know when a new version is available. Kind regards Hayo
Hi all - I corrected the bug yesterday night, so you can download the new release 7.15 here: https://sourceforge.net/projects/welecw2000a/ wish you all a nice week Hayo
Hello Hayo, OK, many thanks for the explain, now I understand. Surely what you wrote is very useful to me, thank you. I understand that even if not explicitly specified the 0dBm (1Vrms) are at the top exactly as in the screenshot I posted. Thanks a lot also for the new firmware that fix the issue by switching among V and dBm and reverse. I'm happy the thread isn't dead, even if I sense that the hard work is always only your since you alone dedicate your time to fix the problems of us users of the awesome Welec. We are really lucky to have you on our side Regards, Antony
Nabend, bin auf der Suche nach dem Wiki das sich unter:http://sourceforge.net/apps/trac/welecw2000a/ befand, in der Waybackmachine fehlt das meiste. Eigentlich suche ich das RS232 Protokoll.
Hi, das Wiki ist leider nicht mehr aktiv. Die Reste sind hier zu finden: http://web.archive.org/web/20120115071202/http://sourceforge.net/apps/trac/welecw2000a/wiki Ansonsten sind die meisten Sachen aber auch in den Dokumenten auf SF zu finden: https://sourceforge.net/projects/welecw2000a/files/ Ich kann Dir sonst im Coding auch gerne die Stellen nennen wo Du was dazu findest. Es ist da ja Verschiedenes zur RS232 programmiert worden. Da ist einmal das Firmwareupdate(komprimierte Firmwareupdates), dann die Fernsteuerung/Sonderfunktionen, dann die Screenshot- und Datenexportfunktion, was davon brauchst Du? Wenn Du sonst noch Fragen hast einfach direkt drauf los... Gruß Hayo
Hallo, mein Oszi hat sich gestern, nachdem ich ADC Setup Factory aufgerufen habe, aufgehangen. Aus/Ein sowie ein Reset bringt es nicht mehr zum Laufen. Hat jemand eine Idee wie ich es wieder zum Laufen bringe. Danke Stefan
Hi Stefan, erstmal sicherstellen, das die Firmware ok ist - d.h. die aktuellste Firmware noch mal neu laden und dann das Oszi neu starten. Wenn das vorher schon die letzte Version war, sollte das recht schnell gehen. Wenn eine sehr alte Version drauf war braucht es etwas Zeit bis sich das Gerät initialisiert hat. Danach noch mal ins Hardware-Menü und alles richtig einstellen. Wenn es dann nicht läuft, ist irgendwas nicht in Ordnung und wir müssen etwas mehr ins Detail gehen. Das würde ich aber eher nicht vermuten. Gruß Hayo
:
Bearbeitet durch User
Hallo Hayo, vielen Dank für die Unterstützung. Das Upload der Firmware (1.2BF.6.xx -> 1.2BF.7.15) ging ohne Probleme, hat aber nichts gebracht. Leider ist das Fehlerbild immer noch das gleiche. Zu Deiner Frage wie es zu dem Fehler gekommen ist: 1.) Ich habe das Hardware Menü aufgerufen. 2.) ADC Setup --> Der Bildschirm wurde grün und seitdem hängt das Oszi. Aber bitte mache Dir nicht zu viel Aufwand. Da das Ding ist schon etwas in die Jahre gekommen und ich möchte ungern an der HW noch was tun (bin da auch nicht so fit). Würde mir für meine Hobby Zwecke (IoT, Ardino, ESP, also bis ca. 10MHz) dann wahrscheinlich ein Rigol DS1054Z (oder Vergleichbares) zulegen. Im Voraus schon mal vielen Dank. Gruß Stefan
Hi Stefan, das sieht für mich bei näherer Betrachtung so aus, als wenn da der Zugriff auf das FPGA nicht richtig funktioniert. Normalerweise sollte der Bildschirm so aussehen: Model: W2024A Hardware Version: 8C7.0L Serial Number: 04063846C8 Flash ID: 0193 Die Werte werden aus dem FPGA gelesen - und bei Dir steht da leider Schrott drin. Was kann das sein? - Das FPGA hat irgendwo "kalte Füße", was ja bei den WELECS durchaus nichts Neues ist. - Das FPGA hat intern eine Macke (glaube ich eigentlich nicht so recht) - einer der Speicherchips hat "kalte Füße" - kommt öfter mal vor, äußert sich allerdings normalerweise durch Displayprobleme Man könnte also mal vorsichtig Beinchen nachlöten um hier weiterzukommen. Hat sonst hier in der Runde jemand eine Idee? Gruß Hayo
Danke Hayo, Habe das Oszi gerade zerlegt (leider mit leichten Schaden an einem Drehknopf) . Beide RAM'S nachgelötet. Alle Lötstellen sehen eigentlich gut aus. An den FPGA kann man ja wohl nichts machen Füße wärmen) . Wenn keine andere Idee vorhanden ist gebe ich die Reparatur auf. Gruß Stefan PS: kann dann gerne das Oszi gegen Porto als Ersatzteile zur Verfügung stellen.
Hi, Du bist ja schnell... Nein am FPGA lässt sich schlecht was machen. Ich würde auch am ehesten auf das RAM tippen, da hier öfter schon mal ein Problem war. Bin ja mal gespannt, ob Dein Nachlöten Abhilfe geschaffen hat. Gruß und viel Erfolg Hayo
Hallo Hayo, das Löten der RAMs (auf beiden Seiten und mit viel Flux) hat nix gebracht. Wie gesagt, ich gebe es auf. Es gibt jetzt ein vorgezogenes Weihnachtsgeschänk ;-). Noch mal vielen Dank. Gruß Stefan. PS: Wenn jemand das Oszi als Ersatzteile haben möchte gebe ich es gern ab. (gegen Porto).
Wenn es noch was anzeigt ist es gut genug für einen Trade-in bei Keysight. Es gibt da immer mal wieder so 30% Rabatt Aktionen. Wenn ich recht erinnere muß das Altgerät um qualifiziert zu sein mindestens halb so viel Bandbreite oder Kanäle haben wie das neue. So kam ich zu meinem DSOX3014 (OT, was jetzt eher ein MSOX3054 ist...)
Happy 2020 to all of you! I hope that Hayo, Jorg will devolope new features with our dso, may be serial decode with some basic information I provided time ago. Greetings, Sandro
Hi Sandro, happy new year to you and all others here. Unfortunately (for you) I bought a sailing yacht and now spend all my time to work on the boat. For this reason I will not develop new functionality in the next time but nevertheless I will support you with bug fixes if needed. Maybe anyone else here has the motivation and time to develop new functions - support from my side is guaranteed! Regards Hayo
Hallo Hayo, have a nice job with your boat. Just a little W2022A bug, in quick measure mode dual trace, switching the qm from Ch1 to Ch2 no changing, the measure remains to ch1. Regards, Sandro
Hello Sandro, this is not a bug. You can add a new measurement on CH2, so that you can measure both channels for example. There is no change of the choosen types of measurement in the channel number, if you switch between CH1 and CH2 - this is absolutely normal and also the solution on other oscilloscopes. Regards, Sven.
Hello Sven, I have also a Tektronix TDS 500MHz 4 channel updated to 800MHz and new LCD colour display, quick measure works different from our Welec, there it's very easy to change qm between channels. May be improved for sure, this is only a kind observation. Regards, Sandro
Ich grüße als Neuling in diesem Forum alle Experten! Ich habe da ein Problem mit meinem älterem W2012A, der vorgestern seinen Dienst quittiert hat. Es wäre schade, dieses tolle Gerät zu verschrotten ohne einen Reparaturversuch unternommen zu haben. Dazu bräuchte ich aber Euere Hilfe! Fehlerbeschreibung: Nach dem Einschalten und normaler Anzeige erschien nach etwa 2 Minuten ein vertikales Raster, ähnlich einem Gartenzaun, über den ganzen Bildschirm. Nach dem Aus- und Wiedereinschalten blieb der Bildschirm - bis auf einen leichten Schimmer - ohne Inhalt. Ausserdem blieben alle Bedientasten, ausser RUN/STOP, dunkel und funktionslos. Ohne Schaltplan ist es für mich ziemlich schwierig eine Reparatur durchzuführen. Kann mir da jemand weiterhelfen? Grüße, Reinhard
Hallo Reinhard, ja das ist kein Beinbruch, sondern eher ein abgelöstes Beinchen :-) Das Problem ist altbekannt und hat schon viele Besitzer ereilt. Ich habe jetzt auf die Schnelle nur diese Beiträge dazu gefunden: Beitrag "Ausfall W2024A" Beitrag "Re: Wittig(welec) DSO W20xxA Hardware (Teil 2)" Es gibt aber noch mehr dazu. Letzterer mit Foto, das Dir bekannt vorkommen sollte... In allen mir bekannten Fällen war es der RAM-Baustein auf der Außenseite, also der leichter zugängliche Baustein. Wenn man etwas Lötgeschick hat ist das kein Problem. Der Lötkolben sollte eine feine Spitze haben und man muss auch nur kurz auf die SMD-Beinchen tippen. Starkes Drücken, kann die Beinchen auf dem Pad verschieben und Kurzschlüsse verursachen. So gesehen bei einem Gerät, bei dem mit einem etwas zu großen Lötkolben gearbeitet wurde und welches dann bei mir landete als nix mehr ging. Wenn Du noch Hinweise brauchst, welcher SMD-Chip das ist... ...oder wenn Du noch Infos brauchst um das Gerät zu zerlegen - es gibt schriftliche Anleitungen beim SF-Download, aber ich helfe auch gerne direkt. Gruß Hayo
Guten Abend Hayo, habe mich heute mal an die Nachlöterei aller Beinchen der beiden RAM's gemacht: leider kein Erfolg. Hast Du noch weitere Vorschläge? Gruß, Reinhard
Hi Reinhard, kein Erfolg bedeutet, es ist noch alles so wie vorher? Hast Du mal ein Foto vom Bildschirm? Ist eine aktuelle Firmware drauf? Neu flashen kann manchmal auch schon helfen. Gruß Hayo
Danke für die schnelle Antwort, Hayo. Der Zustand ist wie vorher. Ich denke, dass ein Foto von einem dunklen Bildschirm keinen großen Informationswert hat. Wie kann ich das Gerät ohne Bidschirmanzeige neu flashen? Außerdem habe ich an meinem PC nur USB-Anschlüsse. Grüße, Reinhard
Hallo Reinhard, als ich vor Jahren mein mein W2012 von Wittig bekommen habe, zeigte es ähnliche Symptome. Der Display-Stecker war nicht ganz eingerastet. Grüße,Josef
Aahh - ok, ich dachte es würde noch was auf dem Display angezeigt. Wie Josef hier schon andeutet, kann es helfen das Gerät einmal ganz zu zerlegen und wieder zusammen zu bauen. Evtl. sind Kontaktschwierigkeiten irgendwo vorhanden. Wenn die Probleme erst nach dem Auseinandernehmen auftreten, kann es sein, dass man die Pfostenleiste zwischen den Platinen nicht richtig getroffen hat (um einen Pin verrutscht). Du solltest aber für weitere Diagnosen unbedingt einen Computer mit RS232 Anschluss haben. Für reine USB-Geräte habe ich einen USB/RS232 Converter im Einsatz (für's Lappy). Aber wie auch schon hier in den Foren berichtet scheinen nicht alle gleich gut zu funktionieren (musst mal hier oder im Hardwarethread suchen). Meiner meldet sich im Gerätemanager mit "Prolific USB to Serial Comm Port" (siehe Bild). Damit kann man dann die Debug-Ausgaben des Gerätes beim Start über ein Terminal mitverfolgen und auch eine neue Firmware aufspielen. Hast Du denn noch die Wittig-Firmware drauf (eigentlich unvorstellbar)? Gruß Hayo
Ich Frage mal nur aus Interesse: Ist der FPGA Teil dokumentiert so dass man da selber Code für schreiben kann? Bei kaufbaren Oszis kann man sich zwar die Samples nach einem Trigger geben lassen und damit Auswertungen machen, aber das ist oft sehr langsam und man hat viel Totzeit. Zu Messzwecken im Labor wäre das super zu diesem Preis. Die Auflösung würde mir auch locker genügen mit den 8 Bits. Wichtig sind mir das Erkennen von kurzen Impulsen zu denen ich dann jeweils einen Zeitstempel mit ausgeben. Da genügt locker die serielle Schnittstelle. Wie ist denn der Aufbau grob, muss man zwingend eine CPU verwenden um das FPGA zu konfigurieren und den ADC und UART zu verwenden oder reicht dafür eine FPGA Konfiguration die man über JTAG in einem Flash ablegt?
Gustl B. schrieb: > Wie ist denn der Aufbau grob, muss man zwingend eine CPU verwenden um > das FPGA zu konfigurieren und den ADC und UART zu verwenden oder reicht > dafür eine FPGA Konfiguration die man über JTAG in einem Flash ablegt? Moin Gustl, in dem Bereich wäre Jörg der richtige Ansprechpartner und Du wirst im Hardwarethread https://www.mikrocontroller.net/topic/goto_post/3068213 sicher einiges dazu finden. Nur kurz - die Konfiguration wird im Flash abgelegt. Am JTAG hängt ein ALTERA Klone (USB Blaster) für ca. 10€ vom freundlichen Chinesen. Eigene Designs wurden schon in Angriff genommen und waren aber bisher noch nicht verwendbar. Dennoch haben sie klar aufgezeigt, dass das Potential des Gerätes mit der Wittig-Programmierung maximal zu 10% ausgeschöpft wurde. Es geht deutlich mehr Geschwindigkeit und bessere (fehlerfreiere) Funktionen. Wenn Du da was auf die Beine stellen willst sei Dir noch der Thread "made from the scratch" (von Jörg) empfohlen: Beitrag "made from scratch Firmware für Wittig/Welec Oszilloskop W20xxA" Gruß Hayo
Gustl B. schrieb: > Ist der FPGA Teil dokumentiert so dass man da selber Code für schreiben > kann? Gustl B. schrieb: > Wie ist denn der Aufbau grob, muss man zwingend eine CPU verwenden um > das FPGA zu konfigurieren und den ADC und UART zu verwenden oder reicht > dafür eine FPGA Konfiguration die man über JTAG in einem Flash ablegt? Das Board ist gut bis sehr gut dokumentiert, beim FPGA fehlen (mir zumind.) ein paar Pins, die lasse ich aber als Input mit WeakPullup. Damit lassen sich dann RAM/ROM, LCD, UART, das Eingabeboard und die ADC-Stufen komplett ansteuern. Überflieg einfach mal hier die verschiedenen Forenthemen, da müssten alle notwendigen Links zu finden sein.
Hallo Leute, Ich habe gestern die Firmware meines W2024 auf 7.15 geflasht. Hat soweit auch alles super funktioniert nur leider wird jetzt die Amplitude eines Signals auf allen Kanälen ca. 1 V zu niedrig angezeigt. Da ich das Gerät nur selten brauche und noch seltener mit Frequenzen über 100Mhz zu tun habe, habe ich die Hardware bis jetzt nicht angefasst. gibt es eine möglichkeit die Y-Verstärker neu zu kalibrieren oder muss ich jetzt auch das Hardwareupdate durchführen ?? lg Rudi
Hi Rudi, nein - keine Sorge, Du musst nichts an der Hardware ändern. Du musst lediglich einmal durch das Setup gehen und alles richtig einstellen. Das machst Du so: 1. Taste Utility -> Du bist im Setup 2. Default Setup -> alles wird erstmal auf Defaultwerte gesetzt 3. Calibrate Offsets -> das machst Du nachdem das Gerät warm ist (5 Min) 4. More -> Hardware -> Jetzt bist Du im Hardware Setup 5. ADC Setup -> Hab ich bei mir auf HighFreq1 stehen - probier es aus! 6. Pre Gain -> muss bei Dir auf Factory stehen, sonst falscher Pegel!!! 7. Gain -> dient zur Feinkorrektur - default ist 1.000 8. ADC Driver -> solltest Du Assembler wählen, ist schneller Das war's! Wichtig ist vor allem Pre Gain, das wird bei Dir vermutlich falsch eingestellt sein, aber geh einfach alle Schritte der Reihe nach durch, und dann ist alles korrekt eingestellt. Punkt 3 kannst Du beliebig oft wiederholen, aber wenn Du das im kalten Zustand machst stimmen die Nullpunkte später nicht mehr. Gruß Hayo
:
Bearbeitet durch User
Hallo, mein W2024 aus Ebay mit BF 1.5x Firmware funktioniert gut, ich will erst mal nichts ändern. Ich finde nirgendwo die originale W2000 PC Application mit welcher man die Screenshots vom DSO wohl per USB Bus am PC visualisieren konnte . Screenshot via RS232 ist natürlich möglich, USB wäre aber unkomplizierter . Grüsse Dietrich
Hallo Dietrich, ich hänge die Software hier mal an, da keine Copyright-Verweise drin sind. Mit der BF-Firmware arbeitet das Programm aber nur begrenzt zusammen. Einige Remotebefehle gehen, aber es werden keine Daten angezeigt (zumindest bei mir nicht). Das liegt daran, dass die zugrunde liegende Originalfirmware der Version 1.2 schon nicht funktioniert hat. Aktuell muss man dafür wohl die Version 1.3 oder 1.4 verwenden. Die USB-Funktion erkauft man sich dabei allerdings mit dem Verlust fast aller Funktionalität des DSO! Denn die originale Firmware kann eigentlich fast nichts. Nebenbei würde ich Dir auf jeden Fall empfehlen von BF 1.5x auf die letzte 7.15 aufzurüsten - da hat sich doch Einiges getan. Zu der Welec Software habe ich (glaube ich) auch noch die originalen Delphi-Sourcen, falls da jemand noch dran programmieren möchte. Es wäre wohl auch möglich die BF-Firmware so anzupassen, dass man das Programm wieder benutzen kann. Wäre aber wohl schon noch etwas Gefummel bis das läuft. Gruß Hayo
Hallo Hayo, Vielen dank für die schnelle Hilfe. Ich habe alles so gemacht wie du beschrieben hast, jetzt läuft es wieder so wie es soll :-) . P.S. Ist das Projekt eigentlich abgeschlossen oder wird noch weiter daran gearbeitet? Ich habe es über die Jahre mehr oder weniger sporadisch verfolgt. Leider besitze ich weder die Zeit noch das Fachwissen um aktiv daran mitzuwirken !! Gruß Rudi.
Prima, freut mich, dass ich helfen konnte. Sowas ist ja eigentlich nie abgeschlossen. Es gibt immer etwas was man da einbauen oder erweitern könnte - wie z.B. im Beitrag einen weiter oben die USB-Unterstützung für das Welec Programm. Aber aktuell habe ich auch nicht mehr soviel Zeit dafür. Schuld daran sind andere Projekte (mit dem RasPI z.B.) und diverse Outdoor-Freizeitaktivitäten. Aber laufenden Support mache ich noch so nebenbei (Fragen beantworten oder kleinere Bugs beheben etc.). Gruß Hayo
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.