Hallo Hayo,
mit der aktuelen BF 3.0 C2 bin ich bei der inversen Erfassung mit Kanal
1 auf ein sehr merkwürdiges Feature gestoßen. Zum Vergleich liegt das
selbe Signal am normal dargestellten Ch2.
Am linken Rand taucht ein falscher Wert ("Flanke") auf (Bild:
Messung...) und wenn man auf STOP geht und das Anzeigefenster nach
rechts verschiebt, kommen merkwürdig nach unten versetzte Daten ins Bild
(Bild: Pan_...).
Eingangssignal ist Probe Comp (passiert aber genauso mit anderen
Signalen). Wenn man dagegen Ch2 invertiert, ist alles gut. :-)
Gruß
Rainer
p.s. Die Screenshots wurden mit w2000a-screenshot 0.97 erstellt und
nicht nachbearbeitet - sicher ist sicher. ;-)
Angehängte Dateien:
-
Messung_Ch1_inv.png
4,1 KB -
Pan_Ch1_inv.png
4,1 KB
Oha, das ist ja merkwürdig. Da muß muß ich wohl mal ran. Danke für den Tip Hayo
Angehängte Dateien:
-
W0000287.png
1,2 KB
@Hayo, denke bitte daran mir die mail wegen dem USB-Host zu schicken. ;-) Ich wollte gerade die neuesten Änderungen in meine Firmware übernehmen. B/W funktioniert aber nicht richtig. Da schon in der UC_SCREENSHOT_BW() die Schwarz/Weiß Werte zusammengebaut werden vermute ich den Fehler dort. Die Gegenprobe mit dem screenshot zum PC scheitert leider daran:
1 | - Receiving a monochrome screenshotError: screenshot data version newer on DSO than known here in receive_screen(), exiting. |
Ok Kurt, ich check das mal. Die Mail kriegst Du morgen. Gruß Hayo
hmpf, > Nein, da war ich nicht dran. Hast Du Dein Gerät hardwaremäßig richtig > eingestellt und auch kalibriert? kennst mich doch, mach das jedes mal, auch resette ich das Teil mehrmals bevor ich pöpel! Wie sieht's denn bei den Anderen so aus? Apropos kalibibrieren, Im Kalibriermenu steht Standart= is' klar, Active Probe= Is' auch klar, Set 3 und 4= is' nicht klar! Sind das die Einstellungen für die 24 u. oder 33 Ohmler? Zum Germsloader über die RS232 Schnittstelle: Ich selbst habe Win XP auf dem Lappi sowie auf dem Hauptrechner Athlon Phanom 9500, SP2(Laptop) SP3 (Athlon) funzt mit der eingebauten RS232 sowie mit dem Adapter(FTDI)! Wichtig sind die Comport-Einstellungen!!! Diese müssen oder sollten immer überprüft werden, d.h. 115kb , Datenbits=8, Parität=non(keine), Händshake(Flussteurung)= none(keine), Stopbit=1 Hat mal ein Gerät darauf zugegriffen, kann es vorkommen, daß der Port nicht, oder noch nicht freigegeben ist, dann zickt das Ganze und man muß den Rechner komplett neu hochfahren!!! Das sind jetzt meine Erfahrungen, die ich hier weiter gebe kann. ...habe bis jetzt jedes Miststück zum laufen gebracht, unter Anderem auch das LEON3 Design! Wie ist denn da eigentlich der Fortschritt? Das was ich bisher aufgespielt hatte, war schon sehr beachtlich, schade, wenn das einschlafen würde... Gruß Michael
Angehängte Dateien:
-
screenshoot1.jpg
41 KB -
screenshoot2.jpg
41 KB
Hi Hayo, Niklas O. and all! I take just peeping through, I am in a hurry, so apologize me. First: @Hayo and all who involved in the Welec project: I installed the new 1.2.BF.3.0_C2 release and I'm trying it. I have few time and I was able to give only a superficial glance, but this new release seem to me very, very impressive!!! Modifications and improvements are so many and such that I make it hard to use the oscilloscope. It is as if I were using a new DSO and I have to read the instruction manual for understand how to use it. Options and settings are significantly increased compared to a few previous versions, have been added feature that I couldnt even imagine could be implemented in the Welec DSO!!! The DSO seem me to be more fast and especially for me now it is less noisy, a lot less noisy!!! Then the calibration is now super precise than ever on mine W2022A and W2012A. For me also the trigger behavior is better now. I repeat, very, very impressive!!! Over the weekend I'll try to find time to do some testing instrument. That said, Hayo and all who involved I thank You very, very much for this new jewel, I have no words, RESPECT, RESPECT, RESPECT!!! Niklas O. schrieb: >Wo Du Tastkoepfe erwaehnst... Wegen eines Analogoszis hab' ich >kuerzlich nen "100 MHz" Tastkopf aus China von Dealextreme bestellt. >Der ist vor ein paar Tagen eingetroffen, und, da ich dem "100 MHz" >Sticker nicht traue und es Angaben bzgl. Anstiegszeig/BW in Stellung >x1 und x10 schlicht nicht gibt, hab' ich diese doch gleich kurz mal >mit den Original Welec "200 MHz" grob am Rechtecksignal des DSO >verglichen. > >Resultat seht ihr in den Screenshots. Kanal 2 ist der 6 USD >(inkl. Versand) Tastkopf. Die Traces sind etwas verschoben, >da ich den Versatz nocht nicht wieder ueber die Delays im >Utility-Menue kompensiert habe. Man sieht's aber auch >"mit blossen Augen" ohne Cursor recht gut ;) About this I tried with the W2012A probe in CH1 and W2022A probe in CH2 of my W2012A (screenshoot 1) and then I exchanged them in the channels (screenshoot 2), both are set x1 so like also the DSO's channels: W2012A's probe win on the W2022A. The square wave is the inner DSO probe calibrator and both probes are correctly matched. I have to investigate further, I have to try with the W2022A. Now I run away. Hayo again many thanks to You and all, really thanks very much to all You!!! Vielen Dank!!! Luc
Angehängte Dateien:
-
BW_Sample_1.jpeg
54 KB -
Invert.jpg
54 KB
Hallo Kurt, hab es schnell noch mal gerichtet. Die UI Planes 3 + 4 dürfen nicht mit übertragen werden, da sie die anderen Planes überdecken. Weiterhin habe ich das Übertragungsprotokoll für B/W an die neueste Version angepasst - sollte also keinen Abbruch mehr geben. Ergebnis der aktuellen Änderungen siehst du auf den Screenshots. Anbei das korrigierte Coding und die Kompilation 3. Gruß Hayo
Hayo W. schrieb: > Oha, das ist ja merkwürdig. > Da muß muß ich wohl mal ran. Vielleicht war das Problem doch vor dem Oszi und du mußt da nicht noch mal ran. Mein letztes "Default Setup" war vor dem Einspielen der 3.0 C2. Nachdem ich das jetzt nachgeholt habe, benimmt sich auch der invertierte Kanal 1 anscheinend richtig. Dafür bin ich drauf gestoßen, dass bei im Single Shot mit Einstellung "Invert" erfaßten Signalen das Invertieren anscheinend auf allen Kanälen ignoriert wird. Beim STOP, wo der gleiche Effekt auftrat, hattest du das ja schon repariert. Gruß Rainer
Hayo W. schrieb: > Ergebnis der aktuellen Änderungen siehst du auf den Screenshots. Anbei > das korrigierte Coding und die Kompilation 3. Super. Danke! Gute Nacht.
Angehängte Dateien:
-
Mess_ch123_inv.png
5,1 KB -
Pan_ch123_inv.png
5,2 KB -
Single_ch123_inv.png
5,2 KB
Moin Hayo, Hayo W. schrieb: > Oha, das ist ja merkwürdig. > Da muß muß ich wohl mal ran. Gestern Abend war es wohl doch schon etwas spät. Langer Rede kurzer Sinn: Der Fehler mit den falsch dargestellten invertierten Daten beim Pan ist doch echt und betrifft alle 4 Kanäle in gleicher Weise, was schon mal beruhigend ist. Reproduzieren läßt sich das (jetzt mit BF 3.0 C3) wie folgt: ProbeComp an Ch1..4 - Default Setup - Autoscale - AutoPreTrigger "Trace Middle" - Invert Ch1..3 (Bild Mess...) - STOP - Pan nach links oder rechts (Bild Pan...) bringt dann falsche Daten zur Anzeige. Das Ding mit der normalen Darstellung eines invertierten Kanals beim Single Shot sieht man ebenfalls mit obigen Einstellungen. (Bild Single...) Für die ScreenShots habe ich Ch4 als Referenz nicht invertiert, der Effekt tritt dort aber genauso auf. Gruß Rainer
Hallo Rainer, das Problem sitzt nicht vor dem Gerät. Es ist tatsächlich ein Fehler, den ich auch schon gefunden habe. Auch die Lösung habe ich mir schon überlegt. Leider ist es ein grundsätzliches Problem und die Lösung erfordert einen etwas größeren Umbau. Bin ich aber dran... Gruß Hayo
@Michael
> man muß den Rechner komplett neu hochfahren!!!
Das kann es sein!
Ich hatte nur die Schnittstelle im Gerätemanger ausgetragen und dann
neue Hardware suchen lassen. Auf die Parameter habe ich geachtet.
Ich reiche mal den Fix für den Invertion Bug nach. Es gibt da zwei Lösungsansätze. Zum Einen die einfache Lösung die Performance kostet aber gut und problemlos funktioniert, zum Anderen die aufwändige und auch fehlerträchtigere Variante die aber deutlich performanter ist. Ich habe erstmal die langsamere Lösung eingebaut um auf die Schnelle eine fehlerfreie Lösung biten zu können. An der Optimierung arbeite ich dann in der nächsten Zeit. Gruß Hayo
Angehängte Dateien:
-
Inv_C4fix.png
3,9 KB
Hayo W. schrieb: > Ich reiche mal den Fix für den Invertion Bug nach. Das ging ja fix mit dem Fix. Wenn du an der optimierten Lösung arbeitest, hast du dann ein Auge auf das letzte Byte am Ende vom Speicher, dass im Moment bei invertierten Kanälen im Display als unschöner Spike erscheint, wenn man das Fenster ganz nach rechts schiebt. (Ch1 im Anhang) In den CSV-Daten konnte ich mir das nicht ansehen, weil die letzte w2000a-screenshot 0.97 beim Drücken von "Save CSV" oder "Save ASCII" die Zusammenarbteit mit dem Argument: " - Receiving trace... * Receiving parameters...Error: trace parameter format newer on DSO than known here in receive_trace(), exiting." verweigert. Und noch etwas (wahrscheinlich aber bekannt): Die großen Spikes auf Ch3/4 scheinen immer synchron zu kommen. Schönes Wochenende Gruß Rainer
Hallo Rainer, > In den CSV-Daten konnte ich mir das nicht ansehen, weil die letzte > w2000a-screenshot 0.97 beim Drücken von "Save CSV" oder "Save ASCII" die > Zusammenarbteit mit dem Argument: > > " - Receiving trace... > * Receiving parameters...Error: trace parameter format newer on DSO > than known here in receive_trace(), exiting." > > verweigert. die Header-Groesse die das DSO dem Programm uebermittelt ist um ein Byte zu klein. Als Version liest es jetzt den Index des Pretriggers. Wie das jetzt zustande kam weiss ich nicht. Ob mein letzter Patch gg. Firmware von mittlerweile anno dazumal, versionsgeschichtlich gesesehen, schon den Fehler hatte oder zwischendurch noch was geaendert wurde weiss ich nicht, ist aber auch egal. Workaround, ohne Firmware neu zu kompilieren, waere nen para_len++; in receive_trace() vom Screenshotprogramm vor dem malloc(). Niklas
Was war eigentlich der letzte Stand bezüglich des DAC LTC2602? Wird der jetzt korrekt unterstützt, auch auf Kanal 3+4? Die Nulllinien kleben bei mir immer am oberen, manchmal auch am unteren Rand. Kanal 1+2 sind OK.
Kurt Bohnen schrieb: > Was war eigentlich der letzte Stand bezüglich des DAC LTC2602? Wird der > jetzt korrekt unterstützt, auch auf Kanal 3+4? Wird komplett unterstützt, automatisch! > Die Nulllinien kleben bei mir immer am oberen, manchmal auch am unteren > Rand. Kanal 1+2 sind OK. Dann ist beim Einlöten was schiefgelaufen. Hayo
Hayo W. schrieb: > Dann ist beim Einlöten was schiefgelaufen. Stimmt. Ein Pad hatte kein Zinn angenommen. Ich hätte nicht nur per Lupe, sondern auch per Mikroskop kontrollieren sollen. Dafür habe ich aber die alten LTC2612 nicht so bestialisch geschlachtet wie du. ;-)
Niklas O. schrieb: > Workaround, ohne Firmware neu zu kompilieren, waere nen > para_len++; in receive_trace() vom Screenshotprogramm vor > dem malloc(). Danke für den Tip. Das läßt sich vielleicht hinkriegen. Wahrscheinlich ist Hayo mit dem nächsten Update aber wieder schneller. ;-) Rainer
Kurt Bohnen schrieb: > Dafür habe ich aber die alten LTC2612 nicht so bestialisch geschlachtet > wie du. ;-) Na prima, was machst Du jetzt damit? Klebst Du Ihn in einen Bilderrahmen und hängst eine Lupe daneben damit man ihn sich ansehen kann? ;-) Übrigens gehe ich immer nach dem Motto vor: Für eine gute Sache muß man auch mal Opfer bringen! Den zweiten hab ich übrigens heil raus gekriegt, aber was ich damit machen soll weiß ich auch nicht... Gruß Hayo
Rainer W. schrieb: > Danke für den Tip. Das läßt sich vielleicht hinkriegen. Wahrscheinlich > ist Hayo mit dem nächsten Update aber wieder schneller. ;-) Ich arbeite dran :-) Hayo
Angehängte Dateien:
-
80MHz.jpg
49 KB -
25MHz.jpg
64 KB -
12_5MHz.jpg
71 KB
Gute Sonntag Hayo and guys all! @Hayo and all who involved in the Welec project: I installed the new 1.2.BF.3.0_C4 release and I played with it. For the way I use the DSO I have not found defects, the new 1.2.BF.3.0_C4's release works like a charm. It is fast, stable and for me it is also a lot less noisy and much more precise. Even AUTO SCALE works well, but I must point out something perhaps already You know. As usual, I specify that this report is not intended as a critique of the good work You Hayo and all who involved in the project have done, but only like a remark. In most cases the AUTO SCALE works very well, quickly and accurately, but the signals in a particular range of frequencies are displayed incorrectly. I tried with my RF sine wave generator and for example with 80MHz, 25MHz and 12.5 MHz frequency's signals I got the screenshots You can see. This actually is not much of a problem, You can fix it by manually adjusting. I must stress that AUTO SCALE's function in previous releases never worked so well, so even like it is now it still a huge leap forward from the original Welec/Wittig's implementation! So Hayo and all who involved I thank You a lot for this new bug fix release that make me happy in the DSO usage, again I have no words, RESPECT, RESPECT, RESPECT!!! Good also for Grid Intensity / Grid Color and Quick Print menu. Very well and much impressive the Auto Pretrigger / Pre Trigger Setup and Manual Trigger / Single Trigger Setup menu where settings's number and improvements are so many and such that them are not commonly available even in high-end DSO! In the end just one last thing, I did not understand how use the "Send Measure" button, how it work? Vielen Dank!!! Gruß Luc
Wie versprochen, Pixelfehler bei Invertion behoben, .csv funktioniert auch wieder. @Luc Thanks for Your detailed report. I will check it! >In the end just one last thing, I did not understand how use the "Send >Measure" button, how it work? When using the Cursor or Quick Measure function there are displayed additional values on the screen. These values are sent to a file if You push the Send Measure button. This is working only with activated cursors! Gruß Hayo
Hi Hayo, die inversen Signale sehen ja jetzt aus wie eine eins. Da habe ich mit meiner Bemerkung doch deinen Ehrgeiz geweckt. Die Bemerkung war aber nicht als Aufforderung gemeint, jetzt sofort den Compiler anzuschmeißen. Ich hoffe, du hast das nicht falsch verstanden. Vielen Danke Gruß Rainer
Nein nein, Du muß jetzt kein schlechtes Gewissen haben. Aber so ein Fehler in der Firmware ist wie ein unausgedrückter Pickel. Irdendwie muß man da ran und das beseitigen ;-) Davür gebe ich mir jetzt auch die Badewanne - verdienterweise. Gruß Hayo
seht ihr irgendwie eine Möglichkeit den Spannungsabfall an einem Shunt über 2 Kanäle zu messen (also Kanal 1 vor dem Shunt und Kanal 2 nach dem Shunt) und am Oszi dann eine Stromkurve anzuzeigen?
Angehängte Dateien:
-
NORMAL.jpg
41 KB -
INV.jpg
44 KB
Guten Abend Hayo and guys all! Hayo W. schrieb: >Wie versprochen, > >Pixelfehler bei Invertion behoben, .csv funktioniert auch wieder. Hayo, super danke für blitzschnelle Updates!!! Klasse!!! Hayo You really are tireless and very kind, so thanks You very, very much Hayo for the great job and free time You provided generously to us!!! I immediately installed the newest 1.2.BF.3.0_C5 version. For me the problem with the INVerted channels is solved, thank You, really thank You very much Hayo!!! RESPECT!!! However, at the risk of appearing rude, I would like to point out one thing. I do not know if it also happened with previous versions, I do not even know if it happens only with my DSO. But I have noticed that when I activate the INV's function then the tracks suffer from a certain offset, especially in my case the CH2. Please look at the screenshot. The two images refer to the CH1 and the CH2 shorted to GND. The NORMAL image shows the tracks that are superimposed on the zero line. The INV image shows the tracks set to INVerted mode that are not on the zero line, especially the CH2's track even if also CH1's track is a little bit raised by the zero line. The oscilloscope was switched on for about 2 hours and it had reached thermal equilibrium when I made the two screenshots As usual this my report is not intended as a critique but only like a remark. @Hayo, @Niklas O. Hayo, really thank You very much for your kind explanation about the "Send Measure" function. Now I understand and I must to say it is a very usefull function. Of course I also thank Niklas O. for it because if I am not wrong, He has suggested it. So, Niklas O. RESPECT! Vielen Dank!!! Gruß Luc
bin jetzt heute erst dazu gekommen habe jetzt die 3.0_C5 drauf, die Fortschrittsanzeige ist echt klasse. Bin auch der Meinung das die Anzeige noch einen Tick schneller geworden ist. Mir ist noch ein Fehler aufgefallen, kurze Beschreibung: Ich habe im Singlemodus auf die ansteigende Flanke getriggert, Pretrigger ist egal hatte verschiedenen Werte zw. 200 nSek und 4µSek(Standart) ausprobiert. Alle paar Messungen hat man diese negativen Spikes auf Kanal 1. Auf dem nicht mal ein Tastkopf angeklemmt war. Zu der Übertragung der BMP. Ich finde die Dateigröße sehr groß also ich habe es gerade als PNG umgewandelt aber als BMP ist die 640x480 Pixel Datei 901kb groß. Kann man hier die Farbtiefe begrenzen? Denke 4 Bit wäre doch absolut ausreichend. Dann habe ich noch einen Wunsch bezüglich des Screenshot Programms. Ich fände es gut wenn man die Übertragenen Dateien in einen festgelegten Ordner speichern könnte. Im Moment ist es ja so ich lade mir eine neue Firmware runter entpacke sie und es wird ein neues Verzeichnis erstellt, wenn ich jetzt die dazugehörige Screenshot.exe aus diesem Verzeichnis starte landet das Bild in diesem Verzeichnis. Beim nächsten Firmwareupdate dann wieder in einem anderen Verzeichnis. Vielleicht könnte man das Programm so gestalten das es eine Systemvariable durchsucht und sich dort ein festgelegtes Verzeichnis ausliest. Mit Systemvariable meine ich z.B. die Festlegung wie temp=C:\TEMP tmp=C:\TEMP SCREENSHOT=C:\Eigene Dateien\Thomas\Bilder\Screenshot so wäre es egal aus welchem Verzeichnis ich die Screenshot.exe aufrufe oder welche Version sie hat, die Shots landen immer im vorgegebenen Verzeichnis.
Thomas O. schrieb: > Firmwareupdate dann wieder in einem anderen Verzeichnis. Vielleicht > könnte man das Programm so gestalten das es eine Systemvariable > durchsucht und sich dort ein festgelegtes Verzeichnis ausliest. Hi Thomas, mit der -f option geht das Abspeichern von Screenshot in einem festen Verzeichnis auch ohne Systemvariable. Beispiel für den Aufruf, um unter Windows die Dateien in C:\bilder abzuspeichern, wäre z.B. w2000a-screenshot.exe -a -f c:\bilder\ Gruß Rainer
Hello, Luc schrieb: > About this I tried with the W2012A probe in CH1 and W2022A probe in CH2 > of my W2012A (screenshoot 1) and then I exchanged them in the channels > (screenshoot 2), both are set x1 so like also the DSO's channels: > W2012A's probe win on the W2022A. > The square wave is the inner DSO probe calibrator and both probes are > correctly matched. This is especially strange because according to the specs that came with the Welec probes, the 100 MHz and 200 MHz versions should both have the same rise time/bandwidth on 1:1. The 200 MHz probe seems to perform poorly. I don't have the means to fuly measure the 1:10 bandwith, but I strongly suspect it isn't quite 200 MHz as advertised. I don't have the Welec probes spec sheet at hand at this moment, I will have to scan and upload it at a later time. Niklas
Hallo, Thomas O. schrieb: > Zu der Übertragung der BMP. Ich finde die Dateigröße sehr groß also ich > habe es gerade als PNG umgewandelt aber als BMP ist die 640x480 Pixel > Datei 901kb groß. Kann man hier die Farbtiefe begrenzen? Denke 4 Bit > wäre doch absolut ausreichend. Ja, 4 Bit mit Palette waere ausreichend. Der Grund, warum das Screenshot-Programm aus den proprietaer RLE komprimierten Daten, die das DSO sendet, ueberhaupt BMP macht, statt das fuer diese Anwendung praedestinierte PNG-Format, ist allein, dass dies der einfachste Weg ist. BMP, PPM und so weiter sind sehr einfach ohne Hinzunahme von externen Libraries usw. zu schreiben. Ich hab' mir nicht angesehen, in welcher Groessenordnung es Aufwand waere 4-bittige BMPs zu schreiben, dennoch halte ich das fuer einen Schritt zu kurz. Die Dateien waeren immer noch 150kB gross, satte 145kB groesser als noetig. Wenn, dann sollten wir eine Loesung ueber externe passend lizensierte Libraries suchen und konsequent PNG schreiben. > Dann habe ich noch einen Wunsch bezüglich des Screenshot Programms. Ich > fände es gut wenn man die Übertragenen Dateien in einen festgelegten > Ordner speichern könnte. [..] Wie Rainer auch schon schreibt gibt es genau dafuer den Schalter -f. > Mit Systemvariable meine ich z.B. die Festlegung wie > temp=C:\TEMP > tmp=C:\TEMP > SCREENSHOT=C:\Eigene Dateien\Thomas\Bilder\Screenshot Systemvariablen, wie geht man da unter Windows eigentlich mit um? Soweit ich weiss muss man da unter Windows auf "My Computer" rechts klicken, dann "Properties", dann im neuen Fenster auf den Reiter "Advanced" wechseln, dort dann "Environment Variables" anklicken und im neuen Fenster kann man dann endlich den Kram setzen. Was ich sagen will: Zu kompliziert. Angesichts dessen, dass ich, wie schonmal angedeutet, in Zukunft plane, auch eine Konfigurationsdatei zu benutzen, suche ich noch nach ner Moeglichkeit den Standort dieser irgendwie global festzulegen. Unter unixoiden Betriebssystemen ist btw. systemweit /etc und per-User in Dotfile unter ~/ bzw. in ~/.config/ Standard. Vorschlaege? Niklas
Luc schrieb: > I do not know if it also happened with previous versions, I do not even > know if it happens only with my DSO. > But I have noticed that when I activate the INV's function then the > tracks suffer from a certain offset, especially in my case the CH2. Hi Luc, the offset of inverted signals is not specific to your DSO. To me it looks like a gain error. The offset depends on the position of the trace. Traces at the top don't show any offset, those at the bottom do. I am confident Hayo will catch it. Gruß Rainer
Niklas O. schrieb: > Was ich sagen will: Zu kompliziert. Angesichts dessen, dass > ich, wie schonmal angedeutet, in Zukunft plane, auch eine > Konfigurationsdatei zu benutzen, suche ich noch nach ner Moeglichkeit > den Standort dieser irgendwie global festzulegen. Unter > unixoiden Betriebssystemen ist btw. systemweit /etc und per-User > in Dotfile unter ~/ bzw. in ~/.config/ Standard. Hi Niklas, unter Windows gibt es z.B. die vordefinierte Environmentvariable "APPDATA" die auf das Verzeichnis "Anwendungsdaten" des Benutzers zeigt. Mit C kommt man an den Pfad vermutlich über Aufruf von getenv("APPDATA") dran. Die Alternative wäre ein Eintrag in der Registrierdatenbank. Gruß Rainer
Hi Niklas O., Rainer W. and guys all! Niklas O. schrieb: >This is especially strange because according to the >specs that came with the Welec probes, the 100 MHz and 200 MHz >versions should both have the same rise time/bandwidth on >1:1. The 200 MHz probe seems to perform poorly. I don't >have the means to fuly measure the 1:10 bandwith, but I strongly >suspect it isn't quite 200 MHz as advertised. In the parallel to the 1Mohm oscilloscope input impedance there are for example, 30pF (the value is written on the oscilloscope) and even in parallel you still have the capacitive value of the cable (such as another hundred of pF). Do not put any attenuation, this total capacitive value will in parallel with the voltage to be measured. To reduce the capacitive load (cable + oscope), the first thing you can think is to put an R in series, for example a 9Mohm, so the measured circuit sees a more high impedance and the signal is divided by 10. But this only works in DC. In AC, the two R and two capacitors form a low pass filter that cuts to about 1.4 Mhz. To extend the system bandwidth (ie to put on the oscilloscope a tension that is 1/10 of what is measured with the probe even at high frequency) it must be put in parallel to the 9Mohm R a capacitor of 130 pF divided by the ratio of resistors (9 in this case). In this way a capacitor of about 15pF removes the low-pass effect and the probe can work until at frequencies far greater (about hundreds of megahertz). The 9Mohm R and the compensation capacitor are in the probe. To fix the exact capacitive ratio's values (which must be equal to that of the resistors), need somewhere to put a small variable capacitor with which to calibrate the tolerances that may to exist. If instead of divide by 10 should be divided by 100, the values become 99Mohm and 1.5 pF: this explains why often the probes that go (were) to more high frequency had an attenuation of 100:1 and so why the x1 probes have a frequency response limited compared to the x10 probes. Said that, perhaps the behavior of the W2022A probes is caused from an incorrect setting of the second trimmer. In fact, according to the instructions of my analog oscilloscope probes (they are x10 probes with a 300Mhz bandwidth), they must be tuned by a 1Khz and 1Mhz square wave with not more than 4ns's rise time. In my case the problem may depend on this but I must investigate further. I will try to use the W2022A probes that are credited as 200Mhz bandwidth on my 150Mhz analog oscilloscope who is provided with 300Mhz probes and which has a suitable calibrator for calibration. However, the probes provided by Welec / Wittig with the W2012A are the same as those provided by LeCroy with its WaveAce series DSO. I'm sure because I use them where I work. Niklas O. schrieb: >I don't have the Welec probes spec sheet at hand at this moment, >I will have to scan and upload it at a later time. Me too I have not the data sheet handy. I think it would be useful and interesting. Thanks in advance Niklas O. Rainer W. schrieb: >the offset of inverted signals is not specific to your DSO. To me it >looks like a gain error. The offset depends on the position of the >trace. Traces at the top don't show any offset, those at the bottom do. >I am confident Hayo will catch it. Thank You very much for the useful information and explanation Rainer W.! I hope someone can fix the problem. Vielen Dank!!! Gruß Luc
Hello Luc, the entire "operator's manual" for the probes is attached. According to it, the rise time on x1 should be 23.3ns for both types of probes. > Said that, perhaps the behavior of the W2022A probes is caused from an > incorrect setting of the second trimmer. Since there's no description how to use those I never touched them. (I've got two seperate ones in the box near the BNC.) The attached manual contradicts itself, it mentions that the input capacitance can be compensated "Within the box cover located near the BNC (W202 Probe)", but on the next page under "Compensation and Adjusting the Probe" it explicitly tells to compensate with the trimmer on the body of the probe. It fails to mention that the probe needs to be put into 1:10 divider. Niklas
Hi Luc, the INV-offset is the result of the combination of the DAC-scale factor and screen drawing scale factor. It has to be adjusted more precisely. But this is not so easy because of thermal drift and differences between the DSOs. If You want to measure precisely You have to center the trace in the screen middle. In this positon there are no offsets because it is the virtual zero. Regards Hayo
@Niklas Ich hätte noch mal einen Wunsch bzw. Vorschlag zum Screenshot: Bei der Aufnahme meiner Akku-Ladekurve hätte ich mir gerne die aufgezeichneten USTB-Werte runtergeladen. Das ist aber momentan nicht implementiert. Im USTB-Modus liegen die Werte nicht im normalen Signalspeicher, sondern in einem separaten USTB-Speicher. Es sind 600 Werte (Bytes), also eine recht schnelle Sache. Man müßte nur das Flag mit if (USTB_Mode != USTB_OFF) abfragen und dann anstatt des normalen Signalspeichers den USTB-Speicher übertragen. Die übertragene Länge wird jetzt ja schon zwischen 4K und 16K unterschieden. Käme noch 600 hinzu. Was sagst Du? Gruß Hayo
Hallo Hayo, Hayo W. schrieb: > Ich hätte noch mal einen Wunsch bzw. Vorschlag zum Screenshot: > > Bei der Aufnahme meiner Akku-Ladekurve hätte ich mir gerne die > aufgezeichneten USTB-Werte runtergeladen. Das ist aber momentan nicht > implementiert. > > Im USTB-Modus liegen die Werte nicht im normalen Signalspeicher, sondern > in einem separaten USTB-Speicher. Es sind 600 Werte (Bytes), also eine > recht schnelle Sache. > [..] > Was sagst Du? Ja, das werde ich einbauen. Bei USTB-Sachen waere vllt. auch die Aufnahme ueber noch laengere Zeitraeume interessant, also sowas was ein Trace Recorder macht. Es gibt da z.B. Leute die ueber Tage hinweg Daten von einer Heizungsregelung loggen. Bei einem 4-Kanal Geraet kann das durchaus schon interessant sein. Ich hab' noch nicht auf unserem DSO mit der USTB gearbeitet, ich nehme an die 600 Werte sind im Moment zugleich das Maximum was gespeichert werden kann (Hartverdrahtet im FPGA), danach wird dies durch neue Werte ueberschrieben? Hier koennte man zum einen die Werte direkt "Realtime" mit dem Screenshot-Programm aufzeichnen lassen, zum anderen muesste doch auch die Moeglichkeit bestehen, da die Werte bei langen Aufzeichnungen im Flash abzulegen und am Ende abzurufen? Mein Plan sieht nun wie folgt aus: - zunaechst Flash-Upload-Programm fuer Windows erstellen mit minimaler GUI (File-Open Dialoge usw.), erst einmal wirklich nur Upload-Funktion, kann dann spaeter um Download/Backup-Funktionen erweitert werden - im Screenshot-Programm: - kontinuierliches Loggen von den Measurement-Daten - USTB-Speicher download - Evaluation bzgl. direktes Speichern als PNG - Dokumentation Uebertragungs-Protokolle (in absteigender Prioritaet) Niklas
Niklas O. schrieb: > zunaechst Flash-Upload-Programm fuer Windows erstellen mit > minimaler GUI (File-Open Dialoge usw.), erst einmal wirklich > nur Upload-Funktion, kann dann spaeter um Download/Backup-Funktionen > erweitert werden Warum war der Welec Updater so langsam, kann man den nicht beschleunigen? Niklas O. schrieb: > - Evaluation bzgl. direktes Speichern als PNG Auch BMPs haben eine Lauflängenkodierung. Die funktioniert nur nicht bei BottomUp-BMPs. Das sollte aber für den PC-screenshot kein Problem sein.
ja wenn die Konfigurationsdatei global festgelegt wird wäre das super. Sonst muss man immer die config.ini vom alten ins neue Screenshot-Verzeichniss verschieben oder die Screenshot.bat jedesmal um das eigene Verzeichniss ergänzen. Es wäre wünschenswert diese Globale festlegung ändern zu können da nicht jeder mit den Standart APPDATA Verzeichnissen arbeiten. Meine Eigenen Dateien sitzen z.B. auf einem 2ten Laufwerk.
Niklas O. schrieb: > - Evaluation bzgl. direktes Speichern als PNG Kennst du das Netpbm Toolkit? Möglicherweise sind die im PnmToPng Konverter (Umwandlung PPM in PNG) genutzen Bibliotheken auch hilfreich, um direkt die PNGs abzuspeichern. http://netpbm.sourceforge.net/ Gruß Rainer
Kurt Bohnen schrieb: > Niklas O. schrieb: >> zunaechst Flash-Upload-Programm fuer Windows erstellen mit >> minimaler GUI (File-Open Dialoge usw.), erst einmal wirklich >> nur Upload-Funktion, kann dann spaeter um Download/Backup-Funktionen >> erweitert werden > Warum war der Welec Updater so langsam, kann man den nicht > beschleunigen? Wir sprechen doch von dem Ding der Wittigs, oder? http://sourceforge.net/apps/trac/welecw2000a/wiki/FWupload Da steht auch was von 25 Minuten. Ich hab' das Wittig-Ding zuletzt Anfang 2009 oder so gearbeitet, also kurz nachdem ich mein Scope bekam. Haben wir davon ueberhaupt den Sourcecode? > Niklas O. schrieb: >> - Evaluation bzgl. direktes Speichern als PNG > Auch BMPs haben eine Lauflängenkodierung. Die funktioniert nur nicht bei > BottomUp-BMPs. Das sollte aber für den PC-screenshot kein Problem sein. Ja, das habe ich mir auch noch nicht angesehen. Ich weiss nicht, wie effizient die wirklich ist. Ein kurzer Versuch in Gimp mit Reduzierung auf 16 Farben Palette und RLE zugeschaltet bringt mir ein File mit 36kB Groesse. Ob das noch mit zu rechtfertigem Aufwand zu Fuss gemacht werden kann, oder man da besser eine externe Library nimmt, muss ich schauen. Notieren wir also mal "Evaluation BMP mit optimierter Palette u. RLE" in meine ToDo-Liste. Niklas
Thomas O. schrieb: > ja wenn die Konfigurationsdatei global festgelegt wird wäre das super. > Sonst muss man immer die config.ini vom alten ins neue > Screenshot-Verzeichniss verschieben Hi Thomas man kann doch einfach eine Batch-Datei irgendwo ablegen, in der eine einzige Zeile mit dem aktuellen Screenshot Programmverzeichnis und dem Bilderverzeichnis drinstehen, ohne irgendetwas zu verschieben und zu kopieren, z.B. "C:\Programme\Screenshot-0.97\w2000a-screenshot.exe" -a -f C:\Bilder\ IMO ist man damit flexibler, da man sich für jeden Zweck eine passende Start-Datei zurechtlegen kann.
Rainer W. schrieb: > Niklas O. schrieb: >> - Evaluation bzgl. direktes Speichern als PNG > Kennst du das Netpbm Toolkit? Möglicherweise sind die im PnmToPng > Konverter (Umwandlung PPM in PNG) genutzen Bibliotheken auch hilfreich, > um direkt die PNGs abzuspeichern. > http://netpbm.sourceforge.net/ Ja, kenne ich (hab' ich glaub' ich auch in der README.txt empfohlen zur Konvertierung ;)), jedoch bislang nur mit den Kommandozeilen-Tools gearbeitet. Niklas
im Moment sieht es bei mir z.B. so aus E:\Treiber\Welec\1.2.BF.3.0_C5\Screenshot_0.97 davor war es E:\Treiber\Welec\1.2.BF.3.0_C2\Screenshot_0.97 und da man ja immer die neueste/dazugehörige Screenshot.exe nutzen will startet man die Scrennshot.exe aus dem neuerem Verzeichniss. Oder evtl. wirds ja mal E:\Treiber\Welec\1.2.BF.3.0_C6\Screenshot_0.98 und dann darf man jedesmal die .bat Datei anpassen. Deswegen würde ich mir wünschen das jede zukünftige Screenshot.exe sich am gleichem Punkt im System die gewünschten Einstellungen holt. Hat nichts mit faul zu tun sondern eher mit Comfort das man nicht immer alles anpassen muss. Was sagen denn die anderen dazu, vielleicht gibt es ja bessere Vorschläge das ganze zu lösen.
Mein Ansatz war, die aufrufende(n) Batch-Datei(en) an einem festen Ort stehen zu haben, so dass man bei irgendwelchen Updates mit dem Verzeichnis der neuen Version gar nicht weiter in Berührung kommt, sondern nur einmal den Programmpfad in der Batch-Datei anpassen muß. Wenn das Bilderverzeichnis an einer festen Stelle im System liegt, verbaut man sich den Weg zu projektbezogenen Speicherorten und ist dann bei jedem Screenshot am rumschieben. Es ist halt die Frage, ob man öfter Screenshots macht oder öfter Updates vom Programm einspielt. Gruß Rainer
Hallo zusammen, wie wäre es denn, das Screenshot-Programm zuerst nach einer ini-Datei z.B. in "Eigene Dateien" (bzw. $HOME) suchen zu lassen und die Parameter dahin zu verlegen. Wenn es da keine passende ini-Datei gibt, sucht man noch im lokalen Verzeichnis (des Programms) und Vorrang haben immer die mitgegebenen Parameter. Damit kann man z.B. die exe auch per Doppelklick aufrufen und die Einstellungen bleiben unabhängig von der Version gleich. Viele Grüße, Rainer
Niklas O. schrieb: > Wir sprechen doch von dem Ding der Wittigs, oder? > > http://sourceforge.net/apps/trac/welecw2000a/wiki/FWupload Die Wittig Software lief über USB. Unser Welec Updater aber über RS-232. Sourcecode haben wir auch: http://sourceforge.net/apps/trac/welecw2000a/browser/pc/WelecUpdater
Hallo, (sitz' im Zug und habe keine Zugangsdaten, daher Post als Gast) Kurt Bohnen schrieb: > Niklas O. schrieb: >> Wir sprechen doch von dem Ding der Wittigs, oder? >> >> http://sourceforge.net/apps/trac/welecw2000a/wiki/FWupload > > Die Wittig Software lief über USB. Unser Welec Updater aber über RS-232. > Sourcecode haben wir auch: > http://sourceforge.net/apps/trac/welecw2000a/brows... Okay. Da gibt's dann das Problem dass ich weder Pascal beherrsche noch die Entwicklungsumgebung dafuer habe. Wie sieht es jetzt aus? Reicht uns das Programm, moechte vllt. jemand anderes sich dem annehmen der entsprechende Moeglichkeiten besitzt, oder soll dennoch ein weiteres Upload-Programm her? Niklas
Niklas O. schrieb: > Hallo Hayo, > Ja, das werde ich einbauen. Bei USTB-Sachen waere vllt. auch die > Aufnahme ueber noch laengere Zeitraeume interessant, also sowas > was ein Trace Recorder macht. Ja das ist machbar. > Ich hab' noch nicht auf unserem DSO mit der USTB gearbeitet, ich nehme > an die 600 Werte sind im Moment zugleich das Maximum was gespeichert > werden kann (Hartverdrahtet im FPGA), danach wird dies durch neue > Werte ueberschrieben? Nein, es ist nicht das Maximum und auch nicht hart verdrahtet. Die USTB-Funktion ist ja eine reine Softwarefunktion die ich nachgerüstet habe. Zur Zeit steht ein 1200 Byte Buffer pro Kanal zur Verfügung von dem aber nur 600 Byte genutzt werden. Ich könnte aber auch deutlich mehr zur Verfügung stellen. Ich hatte auch schon überlegt ob es Sinn macht dass man durch den Speicher scrollen kann (so wie in den normalen TB) > Hier koennte man zum einen die Werte direkt "Realtime" mit dem > Screenshot-Programm aufzeichnen lassen, Ja, ist auch eine Möglichkeit, jeden Abtastwert einzeln zu übertragen um eine Langzeitmessung zu realisieren. > zum anderen muesste doch > auch die Moeglichkeit bestehen, da die Werte bei langen Aufzeichnungen > im Flash abzulegen und am Ende abzurufen? Ebenfalls eine Möglichkeit... Platz ist im Flash noch genügend vorhanden! Gruß Hayo
Hi Niklas O., Rainer W., Hayo and guys all! Niklas O. schrieb: >the entire "operator's manual" for the probes is attached. Thank You Niklas O., at this time my DSO packaging is not handy. The document is very interesting. Niklas O. schrieb: >According to it, the rise time on x1 should be 23.3ns for >both types of probes. I had forgotten these values. 23.3nS means something like a 15MHz bandwidth, seem to me quite optimistic. Even more curious the x10 values where the bandwidth is precisely 100MHz and 200MHz just like the W2012A and W2022A to which the probes are provided with. For the W201 I'm sure it is very similar or the same Chinese manufactured probe supplied by LeCroy DSO with its WaveAve 224 model DSO. The model provided by LeCroy is called PP016 and it is claimed as a 300MHz probe. The only visual difference between the W201 and PP016 is a sticker label on the latter where it says the 300MHz bandwidth. The PP016 is not a good probe, it is quite fragile, often it breaks even though it is always handled with care: where I work has happened twice within the first month of use. I have to make checks. Niklas O. schrieb: >Since there's no description how to use those I never touched them. >(I've got two seperate ones in the box near the BNC.) About the second capacitor on the W2022A probe, I know for a fine adjustment I must set two capacitor for RF compensation with my analog oscilloscope's probes. These two capacitors are on BNC plug, a third capacitor is located on the probe body and it is for the LF compensation. The probes adjustment need a 1KHz and 1MHz square wave with a rise time no more than 4nS and it is done in this way: 1) Connect probe to a 1 kHz square wave signal and adjust LF compensation trimmer for optimum square wave response. 2) Connect probe to a 1 MHz square wave signal and adjust HF compensation trimmer(s) for optimum square wave response. I guess also with W202 Welec's probes is the same. I have to check. Unfortunately my oscilloscope analog probes are fixed at x10 and can not be switched to x1. However I have other probes switchable x1 and x10. I was also thinking of building a pulse generator with rise and fall times of about 300ps. With an such instrument would be simple to evaluate the probes bandwidth. It could also be used to assess the bandwidth of W201xA and W202xA DSO without worrying too much about the linearity lack of the front-end, thing that makes hard performing a such measure in the Welec DSO. But perhaps this is not a suitable place for this because there is a "hardware section", so apologize me. Niklas O. schrieb: >The attached manual contradicts itself, it mentions that the >input capacitance can be compensated "Within the box cover located >near the BNC (W202 Probe)", but on the next page under >"Compensation and Adjusting the Probe" it explicitly tells to >compensate with the trimmer on the body of the probe. The welec's manuals are always a little foggy. ;-) Niklas O. schrieb: >It fails to mention that the probe needs to be put into 1:10 divider. This is really a serious lack! But who is not a newbie should know it. @Hayo. Very well Hayo, thank You very much for the kindly explanation. Now with the Rainer W.'s help and your help I understand how it works and I know there is a way to avoid it. I understand is not so easy to fix the problem due the thermal drift and differences between the DSOs, but now I know a simple way to avoid it. I can say the problem is gone for me, so thanks very much to Rainer W. and You Hayo: RESPECT!!! Vielen Dank!!! Gruß Luc
@Niklas Bau mal noch nichts um im Screenshot. Ich habe mir was überlegt wie ich den USTB-Betrieb etwas "aufbohren" kann und den 16K Signalspeicher nutzen kann. Und der wird ja schon übertragen. Dazu kommt dann noch die Möglichkeit durch den USTB-Speicher zu scrollen. Das Konzept dazu habe ich schon fast fertig. Mal sehen wie schnell ich das eingebaut kriege. Gruß Hayo
Kurzer Tipp an alle die Windows 7 64 Bit einsetzen: Dieser USB- Seriell Adapter funktioniert einwandfrei und auch die Screenshot- Funktion läuft damit super: http://www.amazon.de/gp/product/B003AVQ00A/ Digitus DA-70156 Da ich mir selber einen abgesucht habe bis ich einen Adapter gefunden wurde der unter W7 gut läuft denke ich dass das dem einen oder anderen nützlich sein könnte.
Das ist ein guter Tip und sollte auf der SFN-Seite untergebracht werden. Gruß Hayo
Hallo zusammen, Hayo W. schrieb: >> zum anderen muesste doch >> auch die Moeglichkeit bestehen, da die Werte bei langen Aufzeichnungen >> im Flash abzulegen und am Ende abzurufen? > > Ebenfalls eine Möglichkeit... > > Platz ist im Flash noch genügend vorhanden! > > Gruß Hayo Haupsache es bleibt noch genügend Platz im Flash für Save und Restore der Kurven! Da brauche ich nämlich keine extra Hardware, bis ich mal wieder an einem PC vorbei komme :-) Gruß Jürgen
Hi, > Apropos kalibibrieren, Im Kalibriermenu steht Standart= is' klar, Active > Probe= Is' auch klar, Set 3 und 4= is' nicht klar! Sind das die > Einstellungen für die 24 u. oder 33 Ohmler? mein Anfrage ist wohl etwas unter gegangen?!? ---Set 3 und Set 4, wüsste ich gerne, was es damit auf sich hat.--- Gruß Michael
Jürgen schrieb: > Haupsache es bleibt noch genügend Platz im Flash für Save und Restore > der Kurven! Da brauche ich nämlich keine extra Hardware, bis ich mal > wieder an einem PC vorbei komme :-) Keine Sorge, die haben Ihre eigenen reservierten Segmente. Es sind aber noch einige 64K Segmente frei. Gruß Hayo
Michael D. schrieb: > > ---Set 3 und Set 4, wüsste ich gerne, was es damit auf sich hat.--- Ist einfach nur eine Bezeichnung, mir fiel nichts Besseres ein. Es sind einfach nur vier verschiedene Kalibriersets die man auswählen kann. Die ersten Beiden habe ich einfach mal Standard und Active Probe genannt. Es ist einfach nur so, dass die Kalibierung unter dem gerade eingestellten Set abgespeichert wird. Man kann auch eine kalt/warm Kalibrierung abspeichern oder eine mit einem vorher auf den Eingang gelegten DC-Offset, was auch immer. Mann kann dann ohne neue Kalibrierung zwischen den Werten hin und herschalten. Du kannst auch als Standardkalibrierung Set 3 verwenden, das ist echt egal. Ich habe bei mir auf allen 4 Sets die normale Kalibrierung drauf, damit ich da nicht versehentlich falsche Werte eingestellt habe. Gruß Hayo
Hi Niklas O. and guys all! @Niklas O. About the W2022A's probe, I will be brief because this is not the right place. I did the tests and in the x1 position the rise time is about 30nS (10MHz bandwidth) while the rise time is about 15nS (about 20MHz bandwidth) with the W2012A's probe. In the x10 position the W2012A's probes are like my 250MHz Hameg's probes, so about 200MHz bandwidth. Instead in the x10 position the W2022A probes are best of my 250MHz probes by Hameg, they have better rise and fall time response, so they are a 200MHz probes for sure. The W2022A probes are optimized to high frequencies work and W2012A probes for low frequencies. The W201 probes by Welec/Wittig and PP016 probes by LeCroy are the same, same rise and fall time. LeCroy claim they like a 300MHz bandwidth probes, their performances are same of my 250MHz bandwidth probes by Hameg, so no bad. But W202's probes for the W2022A are better than both PP016 and W201, great! Vielen Dank!!! Gruß Luc
Hallo, anbei der erste Wurf des Firmware-Upload-Programmes fuer Windows. Schaut mal ob das funktioniert. Niklas
Ich hab auch noch eins, irgendwie war ich wohl zu langsam :-( Aber eins wird ja nun funktionieren, bei Bedarf könnte ich das dann auch für Linux anbieten. Viele Grüße
Mit TomCat.ram getestet. * Opening COM1 (115200,8,N,1)... success * Asking the user to put the DSO into GERMS loader, if not already done... * Uploading firmware to DSO - @line 134 |writing to DSO| |reading response| Bis dahin funktionierte es bei mir, dann hängt er sich auf. Die Verbindung ist ok, Gegentest mit GERMSloader.pl hat funktioniert.
@Fritz Hat mit der TomCat.ram funktioniert. 122secs. Evtl. mal die Adressausgabe rausnehmen, der Fortschrittsbalken reicht doch finde ich.
Hallo nochmal, Hayo W. schrieb: > @Niklas > [16K Samples fuer UTSB] > Dazu kommt dann noch die Möglichkeit durch den USTB-Speicher zu > scrollen. Das Konzept dazu habe ich schon fast fertig. Mal sehen wie > schnell ich das eingebaut kriege. Das klingt doch gut! @Luc: Thank you kindly for your explanations and tests! It is good to know that the W202 probes actually are usable for high frequency. stone schrieb: > [..] > - @line 134 |writing to DSO| |reading response| > > Bis dahin funktionierte es bei mir, dann hängt er sich auf. > Die Verbindung ist ok, Gegentest mit GERMSloader.pl hat funktioniert. Du warst der mit den Uebertragungsproblemen, oder? Ich hab' da noch kein Timeout eingebaut und keine erneuten Uebertragungsversuche wie (ich glaube) der GERMSloader.pl macht, auch fange ich Schreibfehler nicht ab. Bei Dir wartet das Programm nach Uebertragung von Zeile 134 auf das '+' von GERMS. Wenn da 100% CPU Usage sein sollten liegt das daran das ich da noch die ComTools.cpp nutze (wie das Screenshot-Programm unter Windows auch) was nur Polling kann (in ner Schleife dauernd fragen "ist jetzt was da?"). Ich wuerd' daher noch gerne Berichte von anderen hoeren. (Selber testen kann ich nicht weil ich keinen Windows-Rechner mit serieller Schnittstelle habe und jegliche USB-seriell-Wandler die ich habe nicht unter Windows tun (oder ich stelle mich zu bloed an). Fritz Richter schrieb: > Ich hab auch noch eins, irgendwie war ich wohl zu langsam :-( > Aber eins wird ja nun funktionieren, bei Bedarf könnte ich das dann auch > für Linux anbieten. Haettest Dich vorher melden sollen dass Du auch was vorhast, dann haette ich mir das Suchen in MSDN heute Nachmittag sparen koennen :) Bei einer kurzen Suche zu Deinem Namen hab' ich diesen interessanten Beitrag von 2009 gefunden: Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware" Hast Du das danach noch weiter verfolgt? Bei Deinem Programm koenntest Du noch einbauen dass es in der Dropdown-Liste nur Ports anzeigt die auch existieren, zudem kann der Fall dass ein Port existiert aber schon durch ein anderes Programm geoeffnet ist abgefangen werden und evtl. entsprechend angezeigt. Womit hast Du das entwickelt, btw.? Wundert mich gerade warum es so gross ist. Wenn Du Lust/Zeit/Interesse hast koenntest Du eine GUI fuer das Screenshot-Programm machen. Die Core-Funktionalitaet wollten wir eh ausgliedern. GUI bzw. Konsolen-Variante wuerden dann auf entsprechende C-Funktionen zugreifen die dann Trace, Screenshot, usw. liefern. Niklas
Niklas O. schrieb: > Schaut mal ob das funktioniert. Hallo Niklas, die Übertragung einer .ram unter WinXP SP3 über einen Prolific USB-Seriell Wandler (Treiber V. 2.0.13.130) hat gut funktioniert. Gruß Rainer
Niklas O. schrieb: > Bei einer kurzen Suche zu Deinem Namen hab' ich diesen > interessanten Beitrag von 2009 gefunden: > Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware" > Hast Du das danach noch weiter verfolgt? > > Bei Deinem Programm koenntest Du noch einbauen dass es > in der Dropdown-Liste nur Ports anzeigt die auch existieren, > zudem kann der Fall dass ein Port existiert aber schon > durch ein anderes Programm geoeffnet ist abgefangen werden > und evtl. entsprechend angezeigt. > > Womit hast Du das entwickelt, btw.? Wundert mich gerade > warum es so gross ist. Du meinst das USB? Ich war damals ziemlich entsetzt über die erreichbare Geschwindigkeit, es war deutlich langsamer als seriell, deshalb hatte ich es erstmal frustriert sein gelassen. Deinen Vorschlag mit den existierenden Comports habe ich noch eingebaut. Programmiert habe ich das mit Delphi, weil ich gerade nix anderes zur Hand hatte, deshalb wahrscheinlich die Größe.
Hi Niklas, > Hallo Niklas, > die Übertragung einer .ram unter WinXP SP3 über einen Prolific > USB-Seriell Wandler (Treiber V. 2.0.13.130) hat gut funktioniert. > Gruß > Rainer ...dito, habe das Teil von HAMA mit dem FTDI drinnen, funzt wunderbar und es gibt kein gezicke! Ganz hilfreich wäre noch die Angabe der verbleibenden Downloadzeit in Sekunden, wie es beim Germsloader der Fall ist?!? Gruß Michael
Hallo! Mich würde mal interessieren, was es beim NIOS Design für Debugmöglichkeiten gibt. Ich bin in der Firma zufällig beim RTEMS Betriebssystem auf einen gdb Stub gestossen und überlege, dass ich den gdb stub und RTEMS für das LEON3-Zeug benutzen werde. Falls es was besseres oder einfacheres beim NOIS Design gibt, wäre ich dem gegeüber auch sehr offen. Übrigens scheint das Changelog im Trac nicht mehr ganz am neuesten Stand zu sein. MfG Alexander
Hallo Nochmal! Ich habe jetzt mein zweites Preview Version 1.1 auf im Sourceforge zum Download bereit gestellt. Das Ausprobieren ist gefahrlos, da ich den FLASH-Speicher nicht benutze oder verändern kann. Nach dem man das Gerät komplett Ausgeschalten hat, ist alles wieder wie es vorher war. Ausprobieren auf eigene Gefahr (, die es praktisch nicht gibt)! Das FPGA-Design ist jetzt schon in einem sehr brauchbaren Zustand. Die Firmware ist hingegen noch in einen sehr frühen Stadium und für den normalen Einsatz nur bedingt geeignett. http://sourceforge.net/projects/welecw2000a/files/LEON3%20FPGA%20Design/Previews/ Dennoch bietet sie eine GUI, manuelles Einstellen der Zeitbasen, der analogen Spannungsbereiche, und es kann der DAC-Offset analog eingestellt werden. Die digitalen Filter HW-Filters und die 8kSamples Speichertiefe pro Kanal sind die größte Verbesserung gegenüber dem NIOS-FPGA-Design. Da ich nur ein 2-Kanalteil habe, unterstütze ich hier auch nur 2 Kanäle. Die Sprünge der Offsets bei den 5er,2er und 1er sind durch das analoge Frontend bedingt und fehlen hier noch im Gegensatz zu der Firmware für den Nios Softcore. Im AUTO Trigger Mode ist die Bildwiderholrate langsam, falls nichts zum Triggern gefunden wurde. Die Spannungsverstärkung ist auch noch nicht kalibriert. MfG Alexander
Gute Sonntag an alle und Niklas O. Niklas O. schrieb: >anbei der erste Wurf des Firmware-Upload-Programmes fuer Windows. >Schaut mal ob das funktioniert. Niklas, thank You very much for the masterpiece and free time You kindly provides to us: RESPECT!!! I have tried your software and it works like a charms both through direct serial connection than via MANHATTAN's usb to serial converter. My equipment are: computer Pentium IV@3GHz with operating system Windows XP Home Edition SP3 and hardware version 8C7.0.C of W2022A's model DSO. Through a usb to serial converter it is little slower than direct serial connection, but this even with Perl Script, so it is normal. I do not want to appear rude and I do not want to criticize your excellent work, but I would say that the software is very detailed in describing the operations to be done but it not warn you when it ended (the Perl Script at the end thank for the fishes so the user understands the operations are successfully completed). Repeat, this my reporting is not intended as a criticism but it is simply for knowledge, so apologize me. Niklas O. RESPECT! Vielen Dank!!! Gruß Luc
Und noch ein längeres als Bedienungshinweis! MfG Alexander
Wow, is ja Wahnsinn, was sich inzwischen überall getan hat. Beim Leon Design erscheint es jetzt langsam sinnvoll, wenn Hayo und Kollegen mal schauen würden, ob sie die Firmware portiert bekämen. Das Leon-Design selber hat ja ein unglaubliches Potenzial!!! Als reiner Nutzniesser noch einmal einen besten Dank an alle. Ist schon echt klasse, dass das Welec jetzt inzwischen voll brauchbar ist und mit dem Leon Design sogar noch Best-Of-Class werden könnte (mal vom analogen Teil abgesehen). Michael
Hallo, Michael D. schrieb: > Ganz hilfreich wäre noch die Angabe der verbleibenden Downloadzeit in > Sekunden, wie es beim Germsloader der Fall ist?!? Jupp. Baue ich noch ein. Luc schrieb: > [..] but I would say that the software is very detailed in > describing the operations to be done but it not warn you when it ended > (the Perl Script at the end thank for the fishes so the user understands > the operations are successfully completed). Yes. It will open a MessageBox saying that the operation is finished but I forgot to write that info on the console, too. Michael schrieb: > Wow, is ja Wahnsinn, was sich inzwischen überall getan hat. > > Beim Leon Design erscheint es jetzt langsam sinnvoll, wenn Hayo und > Kollegen mal schauen würden, ob sie die Firmware portiert bekämen. Das > Leon-Design selber hat ja ein unglaubliches Potenzial!!! Ich stimme zu, allerdings glaub' ich nicht, dass wir da an ein "Portieren" der Firmware denken koennen. Ganz abgesehen vom unterschiedlichen FPGA-Design ist da immer noch jede Menge Furcht erregende Altlast drin. Ich finde aber, dass es nun an der Zeit ist mitzuwirken und die GUI aufzubauen. Da ich ein 4-Kaeneler habe muss ich zum Ausprobieren des Leon-Designs nochmal auf und Front ab und Loetbruecke rein. Ich hoffe ich komme mal die naechste Zeit endlich dazu. alex008 schrieb: > Die digitalen Filter HW-Filters und die 8kSamples Speichertiefe pro > Kanal sind die größte Verbesserung gegenüber dem NIOS-FPGA-Design. Mhm, nur 8kSa? > Da ich nur ein 2-Kanalteil habe, unterstütze ich hier auch nur 2 Kanäle. Im FPGA-Design generell oder nur in der Firmware? Niklas
Hallo Niklas! Die 8 kSamples ergeben sich im Moment aus der Firmwarekonfiguration. Sie ist auf 2 Kanäle mit 16 Bit Daten eingestellt. Falls man auf 8 Bit, 1 Kanal umstellt hat man 32kSamples. Mehr geht nicht, da der Cyclone II "nur" ca. 56 kByte zu Verfügung hat, und der LEON3 mit seinen Registerwindows und seinem Cache auch eine ganze Menge an RAM-Blöcken braucht. Das 4-Kanalmodell hat den doppelten internen Speicher, da es doppelt so viele FPGAs (2 statt 1) nutzt. Das NOIS-Design kann da bei den meisten Samplinraten weniger. Nebenbei unterstützt es hardwaremässig nicht alle Samplingraten, die es anzeigt. Des weiteren ist der Messdatenpuffer auf den Roll-Mode ausgelegt, jedoch wird das von der Firmware noch nicht unterstützt. Ein entsprechender DMA, mit dem 20MSamples/sec beim Roll-Mode theoretisch möglich sind, ist im FPGA-Design angedacht, aber noch nicht drinnen. MfG Alexander
alex008 schrieb: > Die 8 kSamples ergeben sich im Moment aus der Firmwarekonfiguration. Sie > ist auf 2 Kanäle mit 16 Bit Daten eingestellt. Wie machst Du das mit den 16 Bit? > Das 4-Kanalmodell hat den doppelten internen Speicher, da es doppelt so > viele FPGAs (2 statt 1) nutzt. Habe ich das richtig mitgekriegt, dass Kanal 3 + 4 zur Zeit FPGA-seitig noch nicht unterstützt werden? > Das NOIS-Design kann da bei den meisten Samplinraten weniger. Nebenbei > unterstützt es hardwaremässig nicht alle Samplingraten, die es anzeigt. Vor allem gibt es aus unbekannten Gründen einen ziemlichen Sprung zwischen 25MSa und 250MSa was ziemlich unpraktisch ist. da die dazwischenliegenden Samplingraten auf Kosten der effektiven Speichertiefe geht. @Niklas Die effektive Speichertiefe ist beim NIOS-Design nur bei <=50ns/div 16KB. Bei den anderen Zeitbasen sorgt der Zoomfaktor dafür, dass nur ein Teil der 16KB bzw. 4KB im normalen Betrieb genutzt werden. Dafür stehen die ungenutzten Werte im Stopmodus und im Delayedmodus für weitere (schnellere) Zeitbasen zur Verfügung. Gruß Hayo
Alex, klasse! Das sieht ja schon richtig gut aus. Wir müssen dem Alex mal einen 4Kanäler sponsorn... Vorher wird das mit mir und der Leon-Firmware nix. Ich würde echt gern selber dran mitarbeiten, aber mir fehlt die Zeit. Nur am Rande, bestimmt hatte schon mal jemand die Idee, ich frage trotzdem: Wäre es eigentlich möglich, aus dem Welec ein DPO (statt momentan DSO) zu bauen? Also eines was kontinuierlich abtastet und in der Kurvendarstellung statt Einzelwerten entsprechend breitere Verteilung anzeigt? Ich habe zugegeben noch nicht mit sowas gearbeitet, fände ein "analogeres" Feeling gut. Derzeit nehme ich fast immer mein Hameg statt dem Welec, da weiß ich was ich sehe, falle nicht auf Unterabtast-Artefakte rein. Jörg
Angehängte Dateien:
-
Triggerart.png
23 KB
ich habe gerade bei Yokogawa folgende Triggerarten gesehen und wollte mal fragen ob sich das vielleicht auch integrieren lässt. 1. "Oder-Trigger" die erste Flanke triggert egal ob diese auf Kanal 1, 2, 3 oder 4 auftritt. 2. Flankentrigger der in Abhängigkeit von Low/High eines anderen Kanals steht, so könnte man z.B. bei I2C aufs Start Bit triggern.
Hi Niklas O., alex008, Hayo and guys all! Niklas O. schrieb: >Yes. It will open a MessageBox saying that the operation is finished >but I forgot to write that info on the console, too. Niklas O., thanks so much for your kind explanation! @alex008 Alex008, really very impressive your work who it also make user friendly the approach to the LEON 3 Design: RESPECT!!! I will try to explore the question, thank You very much Alex008 and all who are involved with the LEON 3 NIOS design: again RESPECT!!! @all who can answer I update my W2022A to the latest 1.2.BF.3.0_C5 firmware revision and with it I experimented the spikes problem, this is known as spikes that affect both channels simultaneously. Now with the same software release on mine friend's W2012A it seems less noisy, as I already written, and no spikes problem. Instead my W2022A seems to me less noisy also, but there is the spikes problem I never seen before on my W2022A. Normally I could set "Factory" or "Hi Frequency" in the hardware menu without problem, now only "TEST 5" give some improvement but do not entirely eliminate the problem. So I ask myself: My W2022A is hardware version 8C7.0C while my friend's W2012A is hardware version 8C7.0B, but what the difference is? Could this be the cause of the problem? And what means 8C7.0C, 8C7.0B, 8C7.0L, 8C7.0G and so? Are they perhaps the NIOS revision? I know Hayo have W2022A hardware version 8C7.0G or 8C7.0L (http://sourceforge.net/apps/trac/welecw2000a/wiki/usersinstrument), so He test firmware with it and due the differences between the DSOs I understand is not so easy for He to release a firmware that will work on all W202XA and W201XA Welec's revisions, although he usually succeeds in this. @Hayo Hardware's menu settings are used to eliminate ringing problems plaguing some Welec's DSO, precisely the spikes's problems. Broadly, what are the affected parameters? I mean the inside firmware parameters to be adjusted to eliminate the spikes Vielen Dank!!! Gruß Luc
Hallo Hayo, eine Frage zur FFT: Im Zeitbereich schaltet ja zwischen "Ablenkgeschwindigkeit" 5 us/div und 10 us/div die Abtastrate zwischen 250 MSa/s und 25 MSa/s um. In der FFT springt dann die Frequenzskala direkt von 15.62 MHz/div auf 1,56 Mhz/div. Aus der Abtastung ergibt sich natürlich dieser Sprung, aber für die Ablesung wäre es manchmal gut, ggf. per Zoom Zwischenwerte einstellen zu können. Habe ich da etwas übersehen oder geht das (noch?) nicht? Gruß Rainer
@Luc The hardware version consists of three single values: tc_hw_version, tc_production_lot1, tc_production_lot2 Only 8C7 (tc_hw_version)is the real hardware version! This value is read from the FPGA. The values after the dot are stored in the protected flash (tc_production_lot1, tc_production_lot2). This are values which where set by WELEC while programming the flash. Maybe the values after dot are not correct in my W2022A because I restored my flash after an upload crash from another DSO (I think is was from Falk). Do You have a screenshot of Your spike problem? Regards Hayo
Angehängte Dateien:
-
Spike1.jpg
48 KB -
Spike2.jpg
46 KB -
AUTOSCALE_probe.jpg
40 KB -
no_signal.jpg
44 KB -
no_signal3.jpg
42 KB -
no_signal4.jpg
44 KB -
probe_comp.jpg
40 KB
Hi Hayo, Niklas O. and guys all! Hayo W. schrieb: >Only 8C7 (tc_hw_version)is the real hardware version! Hayo as always You are very kind! I thank You very much for the explanation and for your patience! Hayo, You are great! So ultimately be always the same review worked at different times without substantially differences. For me this is very interesting, thank You Hayo! Hayo W. schrieb: >Maybe the values after dot are not correct in my W2022A because I >restored my flash after an upload crash from another DSO Well Hayo, but the batch is not relevant if there are not other differences. If I understand correctly means that comparing different hardware revisions the only difference is related with the production batches fields. Is this correct? This means uploading an hardware revision rather than another in the DSO make no difference. Certainly when the LEON 3 design will be implemented in full there will be a standard environment that perhaps will help the compatibility between the different DSO, this I think. Hayo W. schrieb: >Do You have a screenshot of Your spike problem? Hayo, spikes are very fast and random, very difficult to capture. I unable to get it directly, so in order to capture they I had to enable the persistence of the display. The result is visible in the two attached screenshots named Spike1.jpg and Spike2.jpg. However, I noticed my W2022A has a bit crazy behavior. AUTOSCALE do not work correctly, the AUTOSCALE_probe.jpg pic show the result of the function with the signal for the probes compensation: very crazy! Other pics show the behavior without signal on CH1 and CH2: also very strange. @Niklas O., @Hayo I tried to reload the same firmware via Perl Script but I have not solved the problems. I had updated the W2022A using the fwupload.exe software released by Niklas O. Now, Niklas O. schrieb: >Yes. It will open a MessageBox saying that the operation is finished >but I forgot to write that info on the console, too. But when I upgrade I have no get the message, so I wrote: Luc schrieb: > [..] but I would say that the software is very detailed in > describing the operations to be done but it not warn you when it ended > (the Perl Script at the end thank for the fishes so the user understands > the operations are successfully completed). So, might be this related? I would like to make it clear that I do not write these things to blame Niklas O. or others for what happens to me but only for knowledge because this maybe can help to prevent a recurrence of the problem also to other. I am sure that Niklas O. has done a great job and I thank him again for the amazing fwupload.exe software and for free time He kindly provides to us, Niklas O. RESPECT!!! I hope not to seem rude and above all not be misinterpreted. I even do not expect a solution, I will only document the fact. Repeat this is for knowledge, I do not write these things to blame Niklas O. or others but only because this maybe can help to prevent a recurrence of the problem also to other. I hope all You understand what I mean, what I want to say. However, I'm sure I can certainly solve by loading a previous revision of the Hayo's firmware, so really no problem for me, I do not think my W2022A was permanently ruined ! :-) Vielen Dank!!! Gruß Luc
Hi, bin grad (Ihr ahnt es schon) vom Griechen zurück, diesmal allerdings zwecks 10. Hochzeitstag. Trotzdem ist noch kurz Zeit für eine Antwort (ist halt die beste aller Ehefrauen!). @Rainer Es gibt leider (aus unerfindlichen Gründen) einen Sprung zwischen 250MSa und 25MSa. Das Ganze wird im laufenden Betrieb durch den Zoomfaktor zwischen 10 und 25 kaschiert. Das ist natürlich suboptimal. Ich habe auch schon mit diversen Registerwerten experimentiert, aber ohne Erfolg. Anscheinend haben die Jungs (Wittigs) es voll vergeigt! Die einzige Abhilfe die mir da so in den Sinn kommt ist das LEON3 Design. Mit dem NIOS Design läßt sich da wohl wenig ändern. Gute Nacht Hayo
Hallo! Ich habe eine mögliche Erklärung zu den unterschiedlichen Speichertiefen bei den verschiedenen Samplingraten im NIOS Design. Es scheint mir so, dass beim NOIS Design jeder ADC einen Puffer von 4 kB oder 4 kSamples hat. Bei 500 MS/s werden nur 2 ADCs benutzt, weshalb auch nur 2*4 kB Speicher zur Verfügung stehen. Bei 250 MS/s wird nur ein 4kB Speicher benutzt. Um nun die 1,2,4,10, ... Teilung zu schaffen, ohne dass der vertikale Gridabstand verändert wird, muss wenn nur ein 4kB Speicher verwendet wird, die erste Teilung einen Faktor 10 aufweisen. 250MS/s / 2,5 Samples = 100MS/s geht nicht mit Samples verwerfen, die das NIOS Design sicher nicht hat. Möglicherweise gibt es auch die 50MS/s Teilung nicht, da der 4kB Speicher mit hoher Warscheinlichkeit mit 16 Bit @ 125 MHz beschrieben wird, und das dem FPGA-Entwickler zu schwierig oder zu aufwendig war. Im Unterschied hat das LEON3 design einen 32 kB Puffer, welcher nach der Dezimierung mit oder ohne HW-Filter ist, und kein einziges Sample Jitter auf irgendein Triggerevent hat. @LUC To be shure you do not have a hardware fault (soldering) try the LEON3 design. It does have an glitch trigger which can trigger downto one sample long gliches with every samplingrate (also @ 1 GS/s)! The HW-Filters must be turned off for this! @Thomas Einen OR-Trigger habe ich im Moment noch nicht drinnen, die Triggereinheit ist aber so modular aufgebaut, dass eine Nachrüstung relativ einfach wäre. Die Bandbreitenbegrenzung im DLM2000 unter 100MHz wird laut Aussage eines Yokogawa Vertreters auch mit ähnlichen digitalen Filtern gemacht, wie die HW-Filters bei mir! MfG Alexander
@Hayo: Also hat die Triggerung nicht mit dem Nios Design zu tun, gibs da einen Baustein in Hardware der sich darum kümmert, oder wie meinst du das mit modularer Triggereinheit.
@Axel Wenn ich mit Datenrate und Tracelänge nachrechnet, scheint es so, dass bis einschließlich 10 us/div (25 MSa/s) eine Speichertiefe von knapp 4 kSa pro Kanal verwendet wird, ab 5 us/div (250 MSa/s) komme ich dann auf 16 kSa pro Kanal, d.h. das ist noch eine andere Sache als das Reduzieren des ADC Interleaves von 4..2..1 ADC. Hayo kann das bestimmt bestätigen. @Hayo Da man an den Samplingraten vermutlich erstmal nicht drehen kann, zielte meine Bemerkung zum 1:10 Sprung in der Frequenzachse eigentlich mehr in Richtung Zoom-Funktion für die FFT. Bei 1024 gerechneten Punkten wären ein 2:1 Zoom sicher drin, ein 4:1 Zoom eventuell nicht schön, aber darstellbar. Früher gab es ja schon mal die Frage nach einer Art Frequenzlupe. Ohne neue Berechnung von Frequenzdaten, könnte man sowas vielleich in der Anzeige auf Basis der bestehenden Daten umsetzen. Gruß Rainer
@Thomas die Triggerung ist größtenteils hardwareseitig (ADC, FPGA) implementiert. Das schränkt die Möglichkeiten firmwareseitig etwas nachzurüsten ziemlich ein. Beim LEON3 hat Alex zum Beispiel die Möglichkeit ein Oder-Glied in die Triggerlogik des FPGA einzufügen, diese Möglichkeit habe ich beim NIOS nicht. Ich kann also nur mit dem arbeiten was bei der Firmware ankommt und das ist nur die Triggerung eines einzelnen Kanals zur Zeit. @Rainer Zur Zeit verwende ich für die FFT nur die realen Abtastraten, Daher auch der Sprung zwischen 250 und 25MSa. Ich könnte natürlich stattdessen die virtuellen Abtastraten des Zeitbereichs verwenden, dann hätte man eine feinere Abstufung. Dazu müßte ich dann wie beim Zoom die nicht benötigten Abtastwerte weglasssen. Das wäre machbar. Ich seh mal was da geht. Zur Zeit bin ich noch ziemlich mit dem Umbau der USTB-Funktionen beschäftigt. Gruß Hayo
Hayo W. schrieb: > Zur Zeit bin ich noch ziemlich mit dem Umbau der USTB-Funktionen > beschäftigt. Dann will ich lieber nicht stören. Gruß Rainer
Hallo zusammen, wegen der Sammelbestellung: Es sind immer noch zu wenig Interessenten. Beim USB-Host erst 5 Leute. Dann wollen noch 4 Leute Teile für die Huckepackplatinen und auch noch Platinen. Die Teile sind natürlich kein Problem, wohl aber die <10 Platinen die eine Bestellung unwirtschaflich machen. Ich würde vorschlagen die Sammelbestellung (USB-Host+Huckepack2) solange offen zu halten bis Hayo die Firmware angepasst hat. Dann werden sich sicherlich noch mehr Interessenten melden. Gibt es Meinungen/Einwände dazu? Mfg, Kurt
Mach nur! Ich habe es nicht eilig damit. Grüße, Guido
wird wohl sinnvoll sein, da sicherlich eine Menge Leute abwarten wie sich das ganze fertig implementiert macht. Mich eingeschlossen ;)
Gute Sonntag an alle und alex008, Kurt Bohnen, Thomas O. und Hayo. alex008 schrieb: >@LUC >To be shure you do not have a hardware fault (soldering) try the LEON3 >design. It does have an glitch trigger which can trigger downto one >sample long gliches with every samplingrate (also @ 1 GS/s)! >The HW-Filters must be turned off for this! Thanks for the suggestion alex008! As I have already written, I am sure my W2022A is not dead and it is just a loading error. I already load an old Hayo's firmware release in to W2022A and spikes problem is gone, so I am pretty sure the W2022A is ok and it has no problem. On the other hand I have similar experiences with firmware upgrades asthe my work even covers these issues, so nothing new for me. The problem is due to hardware incompatibility or loading error or both. Returning to your kind suggestion, I have installed the LEON3 design in my W2022A. It is very easy, maybe because I use Quartus and similar software daily when I work but it is very easy to do! To be honest, I was able to easily install the NIOS LEON3 design and its software, but I was not able to do any measure due the fact I am unable to do even simple thing like move traces, so they are always in a bad position on the screen, I am only able to move the trigger level, nothing other. I am able to set some parameters like probe attenuations, time base's factor, vertical amplitude's factor, set the trigger source, set the trigger slope and so, but nothing other. Signal track are very clean and noiseless, but seems to me like they are be fixed. However, I repeat I was unable to make use of the DSO with the LEON 3 design installed on it, I am so sorry. Is there no a user manual that explains how to use it? What mean LEON or FPGA UART setting? For me the LEON 3 DEMO design is really very user friendly to put in to the DSO, although then I was not able to properly use the DSO I invite everyone to try the LEON 3 design, if only because it is very easy and safe to install it in the DSO: You load the LEON 3 in the DSO, You try it and once You turned off and on the oscilloscope everything is back as it was before without a trace! Really very cool, so thank You very much to You alex008 and all who is involved with the LEON 3 design's development: RESPECT!!! However moving forward, to more accurately test the hardware of my W2022A I decided to hurt me and I reinstalled the original 1.4 version by Wittig/Welec! ;-) A blast from the past, a return to youth! ;-)) After having played a little with the good old Wittig/Welec firmware, go running to update the DSO to the latest 1.2.BF.3.0_C5 firmware release! ;-))) Now spikes are come back like in a nightmare! My goodness, this is really a wonderful and unforgettable Sunday! :-) In the end seems the 1.2.BF.3.0_C5 firmware do not like at my W2022A so I make a downgrade! @Kurt Bohnen What is the >Huckepack2? @all Thomas O. schrieb: >ich habe gerade bei Yokogawa folgende Triggerarten gesehen und wollte >mal fragen ob sich das vielleicht auch integrieren lässt. > >1. "Oder-Trigger" die erste Flanke triggert egal ob diese auf Kanal 1, >2, 3 oder 4 auftritt. >2. Flankentrigger der in Abhängigkeit von Low/High eines anderen Kanals >steht, so könnte man z.B. bei I2C aufs Start Bit triggern. In the Wittig(welec) DSO W20xxA Open Source Firmware (Teil3) weitererGast schrieb: >>> Ist eigentlich schon implementiert, dass man auch auf einen Kanal >>> triggern kann der ausgeblendet, aber dennoch angeschlossen ist? Das >>> missfiel mir am Anfang gewaltig. Manchmal muss man wegen der >>> Übersichtlichkeit schlichtweg auch mal den zu triggernden Kanal >>> ausblenden. Antonio schrieb: >> I don't understand, what you mean? >> Also Hayo's answer isn't clear for me, please help about this. Hayo W. schrieb: >What he meant is, that triggering should be possible on channels which >are inactive. But to realize that I have to change the source channel >selection logic because the actual logic switches off the source channel >if it becomes inactive and searches for the next available active >channel automatically. Subject matter in some ways similar. Vielen Dank!!! Gruß Luc
Luc schrieb: > @Kurt Bohnen > What is the >Huckepack2? Hello Luc, it´s the second collective order of the pickabackboard parts (and PCB).
mir ist gerade etwas in den Sinn gekommen und da wollte mal fragen ob das praktizierbar ist. Ein differentielles Signale anzuzeigen also Kanal 1 mit Kanal 2 zu verrechnen und ab einer Differenz größer X das eigentliche Signal darzustellen dazu wäre es vielleicht sinsvoll die gespeicherten Werte rechts zu schieben um die Auflösung zu verringern und dann miteinander verrechen. Viellicht läßt sich sogar eine 3 Oszilinie zw. Kanal 1 und 2 Zeichnen. http://www.kfztech.de/kfztechnik/elo/can/bmw1.JPG
Hm also mir ist jetzt nicht klar, wo der Unterschied zur einfachen Subtraktion der Kanäle liegen soll, kannst du das nochmal erklären? Gruß Michael
ich sehe gerade das die Subtraktions-Funktion dabei ist, muss mal schauen ob sich das so gut auf digitale Signale anwenden lässt.
Hi Leute, ich weiß man hört im Augenblick nicht viel von mir. Aber ich ich bin trotzdem dabei. Zur Zeit bin ich noch an den USTB-Funktionen dran. Vorab noch ein Fix zum Spikeproblem dass Luc gemeldet hatte. @Luc I fixed the spike problem caused by the hardware setting "High Frequ". I changed the register setting and it seems to work. Hayo
Thomas O. schrieb: > ich sehe gerade das die Subtraktions-Funktion dabei ist, muss mal > schauen ob sich das so gut auf digitale Signale anwenden lässt. Zum Glück sind die Digitalsignale eine Teilmenge der Analogsignal. :-)
Hallo Hayo, mal noch eine Frage etwas anderer Natur. Wäre es denkbar die Auflösung des Scopes zu 9bit hin zu treiben? Ich glaube die Diskussion hatten wir schon mal an irgendeiner Stelle. Ich stelle mir das so vor: - Sampledurchgang 1: Es wird gesamplet wie bisher - Sampledurchgang 2: Die Spannung am DAC wird soweit erhöht, dass das Signal am ADC um 1/2 LSB erhöht ist. - Zusammenführen der Daten aus Sampledurchgang 1 und 2 Mir ist klar das das auf dem Bildschirm keinen Unterschied machen wird, jedoch beim Export der Daten auf einen PC wird das einen Unterschied machen, weil dann die höhere Auflösung zur Verfügung steht. Ließe sich das grundsätzlich realisieren? branadic
branadic schrieb: > - Sampledurchgang 1: > Es wird gesamplet wie bisher > > - Sampledurchgang 2: > Die Spannung am DAC wird soweit erhöht, dass das Signal am ADC um 1/2 > LSB erhöht ist. > > - Zusammenführen der Daten aus Sampledurchgang 1 und 2 Das Problem sind das Zusammenführen der Signale und die Wiederholrate. Die Wiederholrate wird massiv einbrechen, da 1. doppelt so viele Sampledurchgänge pro Frame benötigt werden 2. vor jedem einzelnen Sampledurchgang der DAC justiert werden muß, was noch viel mehr Zeit kostet, da vor dem nächsten Sampledurchgang solange gewartet werden muß bis der DAC (und OP Amp) gesetzt und eingeschwungen ist. Das Zusammenführen ist insofern problematisch, dass es einen sehr präzisen Trigger erfordert, da sonst das Signal in Horizontalrichtung unscharf wird. Man erkauft sich dann vertikale Präzision mit horizontaler Unschärfe. Wie das aussieht kann man sich ansehen wenn man ein Signal mit steiler Flanke auf dem Bildschirm hat und dann auf persistente Anzeige schaltet. Gruß Hayo
Hallo Hayo, ich hab mir schon fast gedacht, dass das auf Basis des Nios nicht klappen wird. Es wird wirklich Zeit, dass der Leon das Licht der Welt erblickt, denn da steht auch der Trigger wie eine eins und ließe, aufgrund seiner Geschwindigkeit, solche Spielereien ebenfalls zu. branadic
Hi Hayo, Kurt Bohnen and guys all! @Hayo First, thanks You very, very much Hayo for the free time You provided generously to us and for have fixed the spike's problem!!! Hayo, I installed your latest great job, the new 1.2.BF.3.0_C6. It is very impressive, as always You are right the spikes are gone!: RESPECT!!! I setted hardware configuration as "High Frequency" and "1,25 Gain" and no more spikes! You are great, so thank You very much again for the excellent job done: RESPECT!!!!!!! I know the work must not have been easy, so as usual I am speechless!!! Kurt Bohnen schrieb: >It's (the "Huckepack2") the second collective order of the >pickabackboard parts (and PCB). Hello Kurt Bohnen, thank You for your kind explanation. What You wrote it is very interesting for me and I guess for many other also. How can I place a purchase order? How can I pay the materials? How much is it shipping included? Is there a possibility to purchase a Vinculum VNC2 USB-Host also? And the power supply shield? Please, let me know, I guess it is very interesting also for many other people. Thank in advance. Mit Freundlichen Grüßen, Luc
Hi Luc, I will post more information about the collective order on Sourceforge this weekend.
Hello LUC, sorry for my late answer. I am happy to read you did try the LEON3 design. For your measuring problem: The LEON3 design software is not ready to use for daily operation. Their is no DC offset calibration available at the moment. And because the original analog frontend was made with poor quality you have to set the dc offset with the offset gain button and the offset wheels before you can measure anything. I have put a video about setting the dc offset on a previous entry from 10.04.2011 here. The signal quality can be improved with the HW-Filters. Alexander
Frohe Ostern Euch allen! Details zur Sammelbestellung gibt es jetzt hier: http://sourceforge.net/apps/trac/welecw2000a/wiki/collectiveorder Die englische Übersetzung folgt später. Bis dahin muss google helfen. ;-) Mfg, Kurt
hat außer mir noch jemand Probleme mit Timebase >1s/div mit der 3.0 C6 oder wurde da irgentwas geändert, ich habe einige Versionen übersprungen. Bekomme keine Aktualisierung mehr mit den Sekunden- Einstellungen.
Ja, bei mir geht ab 1s/div auch nichts. Wenn ich Hayo richtig verstanden habe, ist USTB z.Z. Baustelle. Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil4)" Gruß Rainer
Hi BLUE I have a worrying problem on my W2012. While today I tried to adjust the course to display a horizontal drive a TVC suddenly the track of the instrument has become fixed and immobile, but clean (not even a pixel out of place). Of course not display any picture nor the TEST SIGNAL. I say that at the time of the defect, the tip was removed from the circuit. I reinstalled an earlier version that was installed but the defect remains. Channel 2 still works Sorry for the language
wailer schrieb: > Hi Hayo > I have a worrying problem on my W2012. > While today I tried to adjust the course to display a horizontal drive a > TVC suddenly the track of the instrument has become fixed and immobile, > but clean (not even a pixel out of place). Of course not display any > picture nor the TEST SIGNAL. > I say that at the time of the defect, the tip was removed from the > circuit. > I reinstalled an earlier version that was installed > but the defect remains. Channel 2 still works > Sorry for the language
Hi Kurt Bohnen, alex008, wailer, and guys all! Kurt Bohnen schrieb: >Details zur Sammelbestellung gibt es jetzt hier: >http://sourceforge.net/apps/trac/welecw2000a/wiki/... Very well Kurt Bohnen, great job! Kurt Bohnen thank You very much for your kind support! You are really a big one, RESPECT!!! alex008 schrieb: >sorry for my late answer. >I am happy to read you did try the LEON3 design. Hi alex008, no apologies, I must thank You for the great work and free time You provided generously to us: RESPECT!!! alex008 schrieb: >For your measuring problem: >The LEON3 design software is not ready to use for daily operation. >Their is no DC offset calibration available at the moment. >And because the original analog frontend was made with poor quality you >have to set the dc offset with the offset gain button and the offset >wheels before you can measure anything. >I have put a video about setting the dc offset on a previous entry from >10.04.2011 here. Ok alex008, I understand, so thank You a lot for the kindly and useful explanation. alex008 schrieb: >The signal quality can be improved with the HW-Filters. I am currently away from my computer and I have no to hand Quartus, so I can not try but in the weekend I will try for sure. Thank You again alex008! wailer schrieb: > I have a worrying problem on my W2012. > While today I tried to adjust the course to display a horizontal drive a > TVC suddenly the track of the instrument has become fixed and immobile, > but clean (not even a pixel out of place). Of course not display any > picture nor the TEST SIGNAL. > I say that at the time of the defect, the tip was removed from the > circuit. > I reinstalled an earlier version that was installed > but the defect remains. Channel 2 still works > Sorry for the language Hi wailer, seem to me to understand perhaps you damaged your DSO while performing a measurement on a TV color set. Is it correct? I think already I read You somewhere and I guess You are Italian, so I try to write Italian to facilitate the understanding. Italian translation: Ciao wailer, mi sembra di capire che tu hai danneggiato il tuo DSO effettuando una misura su un televisore a colori. E' corretto? Mi pare di averti già letto da qualche parte e che tu sia italiano, per cui provo a scrivere in italiano per facilitare la comprensione. @ all Due to high voltage on some point inside a color television set, is unfortunately possible you damaged your DSO for true. How much is great the signal amplitude on which You done the measure? Was the probe setted x1 or was it setted x10? Sorry, but due to the exceeded in the maximum input voltage for analog inputs is possible the DSO is now broken. Please weiler, tell us more about what you done. Italian translation: A causa dell'alta tensione presente in alcuni punti di un televisore a colori è purtroppo possibile che tu abbia realmente danneggiato il DSO. A quanto ammonta l'ampiezza del segnale sul quale hai effettuato la misura? Come era impostata la sonda, x1 o x10? Spiacente ma a causa del superamento dei valori massimi consentiti per gli ingressi analogici è possibile che il DSO sia adesso guasto. wailer per favore facci sapere di più circa quello che hai fatto. Mit Freundlichen Grüßen, Kind regards, Cordiali saluti, Luc
Luc grazie Preciso che il probe non era a contatto con i circuiti del TVC Sul TVC il trasformatore di EAT era smontato (assente)Quindi non poteva esserci Alta Tensione. Il pilotaggio (driver) di riga ha come Vpp 12-15 volts Il blocco del Input 1 è avvenuto cercando di regolare il Time Base Posso ora dire che il problema era software ed è RISOLTO. Con WELECUPDATER ho reinstallato il firm originale (avevo Backup) e il DSO ha ripreso a funzionare. Successivamente ho aggiornato alla 3.0C6 del grande HAYO .Ora tutto sembra funzionare. Prima del blocco avevo notato che il DSO a volte si bloccava ed era necessario riavviarlo English Version: Thanks Luc Specify that the probe was not in contact with the circuitry of the TVC The TVC transformer EAT was removed (absent), then there could be high voltage. The pilot (driver) has the Vpp line 12-15 volts The input block 1 occurred trying to set the Time Base I can now say that the problem was software and ubuntu. With WELECUPDATER I reinstalled the original signature (I Backup) and the DSO has resumed operation. Then I upgraded to 3.0C6 Hayo's great. Now everything seems to work. Before the block I noticed that the DSO sometimes crashed and had to restart
Hi there, I'm just back from holiday in Spain. In the "outback" (Alicante) where I spent my time, I had no internet connection. This is the reason why my answer is coming a little bit later. @wailer You solved Your problem by yourself - well done! @elec + Rainer Tut mir leid wenn im USTB-Bereich Probleme auftreten. Da sind dann wohl doch schon einige Änderungen mit reingerutscht. Zur nächsten Version wird ohnehin alles im USTB-Bereich umgekrempelt, dann hat sich das auch erledigt. Sonst Notfalls downgraden auf auf eine ältere 3er Version. Die C4 oder C5 müßte doch noch funktionieren oder? @Kurt Muß ich irgendwas machen wegen der Bestellung, oder warte ich bis ich von Dir eine Nachricht bekomme? Gruß Hayo
Hayo W. schrieb: > Tut mir leid wenn im USTB-Bereich Probleme auftreten. Hallo Hayo, kein Problem - mit der C5 läuft USTB wie gewohnt. Bezüglich Spikes - die, die synchron auf Ch3 und 4 auftreten - konnte ich zwischen C5 und C6 übrigens keinen rechten Unterschied feststellen. Gruß Rainer
Die Unterschiede sieht man auch nur bei Hardwareeinstellung "High Frequ". Wenn man dann ein Rechtecksignal mit der steigenden Flanke mittig positioniert (z.B. bei 100ns) und auf persistente Anzeige schaltet dann sieht man die Spikes synchron auf Kanal 1 + 2. Gruß Hayo
Hallo Hayo, wie oben schon geschrieben sind weitere Fakten zur Bestellung auf http://sourceforge.net/apps/trac/welecw2000a/wiki/collectiveorder nachzulesen. Die offene Deadline gibt es damit nicht wieder 10 Nachzügler kommen, nachdem die Huckepackplatine von der Firmware unterstützt wird. Mfg, Kurt
Kurt Bohnen schrieb: > Hallo Hayo, > wie oben schon geschrieben sind weitere Fakten zur Bestellung auf > http://sourceforge.net/apps/trac/welecw2000a/wiki/collectiveorder > nachzulesen. Alles klar, dann warte ich also ab, da Du meine Mail ja schon hast. Gruß Hayo
Angehängte Dateien:
-
A_W2022A_compare.jpg
110 KB -
B_W2012A_compare.jpg
110 KB -
C_LeCroy_compare.jpg
120 KB -
D_Yokogawa_compare.jpg
100 KB -
E_Hameg_compare.jpg
100 KB -
F_TDS220_compare.jpg
100 KB -
G_TDS1012_compare.jpg
100 KB -
H_TDS3052_measure.jpg
56 KB -
I_TDS3052.jpg
46 KB -
L_W2022A_5V.jpg
43 KB -
M_W2102A_5V.jpg
45 KB -
N_W2012A.jpg
45 KB -
O_W2022A.jpg
42 KB -
P_HAMEG_FALL_TIME.jpg
42 KB -
Q_HAMEG_RISE_TIME.jpg
41 KB -
R_HAMEG_1500-2.jpg
39 KB -
S_HAMEG_amplitude.jpg
40 KB -
T_LeCroy_WaveAce_224.jpg
55 KB -
U_YOKOGAWA_DL1540.jpg
36 KB -
V_TDS220.jpg
37 KB -
Z_TDS1012.jpg
33 KB
Guten Abend an alle. With a friend, I'm trying to assess the bandwidth of the W2022A and W2012A. It is not so easy, just completed the measures I will explain the matter in detail in the Hardware forum. At this moment I would to talk about some things maybe to be already known. I built a pulse generator which has Rise and Fall time so fast that I can not measure them with precision. The best oscilloscope I could use to calibrate the pulse generator has a bandwidth of 500MHz, but it is inadequate to measure the Rise and Fall times of pulses, which should be less than 300ps, so I preferred to compare the performance of the W2022A and W2012A compared with those of other oscilloscopes with known characteristics. Seems to me the W2022A is better than the W2012A, better frequency and amplitude response. About this last I am not sure due the linearity lack of the Welec. However I noticed some things. A) With the Welec's oscilloscopes, in order to make better measure I must put the trigger level just below the peak of the pulse otherwise the waveform is continually moving. But in this way the signal amplitude increases considerably compared to when the trigger level is set lower. In short, the size of the displayed signal depends on the position of the trigger threshold, if the trigger threshold is low, the amplitude of the signal is so and the waveform is moving, whereas if the amplitude is high it becomes high itself and the waveform is more steady. I had never noticed this thing before, but maybe it is always been so. B) Seem to me when the Rise or Fall time are less than 1nS, in the Quick Measure is show 0,00S not allowing to know which is the measured in true. Ok, it exist the cursors, but also this thing I had never noticed before, but maybe it is always been so. C) Both W2022A and W2012A have the 1.2.BF.3.0_C6 firmware. About this, I have no more spikes problem, but during the measurements I have noticed that "High Frequency" setting in Hardware menù is good for show the inner probe compensation signal but it is inadequate for the fast pulse, so I must to switch it to Test3 to perform the measure: by setting Test3 I can visualize both slow and fast waveform optimally, for me is the better choise with my W2022A and W2012A. Now, I know the 1.2.BF.3.0_C6 firmware fix the spike's problem caused by the hardware's setting "High Freq" by changing the register setting. Have others noticed this? Seems to me strange the better choice is now other than "High Freq" setting, also "Factory" works well without spikes problem. About this, I tried a downgrade on both W2022A and W2012A and i noticed no spikes when I connect an external signal generator, while there are spikes using the internal probe compensation signal. So, I do not know if it was a case or not, but could spikes really be caused by noise coming from the power supply? Mit Freundlichen Grüßen, Luc
Hi Luc, thanks for Your detailed report about pulse response. It would be interesting to find out how the C5-Version with the old High Frequ. setting is working. Maybe I rename the Test 3 setting like "Pulse" or something in this way as hint to use this for quick signals. In the moment I'm a little bit short in time, so I have to stave You off in relation to the next version. But don't worry - it will go on. Kind regards Hayo @all Hi Leute, bin zur Zeit etwas im Stress und muß Euch leider erstmal etwas vertrösten bis zur nächsten Version. Aber nicht verzagen, es geht auf jeden Fall weiter. Bis dahin genießt das schöne Wetter Gruß Hayo
Hello Hayo, I tested the W2022a with FW c2/C5 at 100 MHz 100mV, the best accuracy occures with these settings: ADC :High freq Pregain 1.25 Filter IIR1 .With C6 the accuracy is 1dB less and settings are different. Just one question ,I can't see anymore the higher resolution in the frequency counter,is it possible to see 1 kHz at 100 Mhz carrier? Regards, Alex
Hi Alex and guys all! Alex schrieb: >I tested the W2022a with FW c2/C5 at 100 MHz 100mV, the best accuracy >occures with these settings: ADC :High freq Pregain 1.25 Filter IIR1 It would be possible to see some screenshots, please? I mean a screenshot for each acquisition mode: noise filter off, noise filter smooth, noise filter strong, noise filter IIR 1 stage, noise filter IIR 2 stage and noise filter IIR 3 stage. Due the filter switch in STOP mode this is easy to do. However, should not the best results be obtained without filters? Alex schrieb: >With C6 the accuracy is 1dB less and settings are different. It would be possible to know how the DSO is set for better performances in this case, please? @Alex Alex, is your W2022A a standard version or a modified version? Thanks in advance. Mit Freundlichen Grüßen, Luc
Hello, my W2022A is standard.About the screenshot Let's wait the next version from Hayo. Without any filter at 50MHz and upper the noise cause a level peak error because,up to now,there isn't a sin interpolation available. I only tried C6 ,anyway works well up to 50MHz and fix some issue, now I'm using the previous on the lab. Sandro(Alex)
Hi Alex(Sandro) and guys all! Alex schrieb: >my W2022A is standard. Thank You for the answer! Alex schrieb: >About the screenshot Let's wait the next version from Hayo. Thank You Alex, You are very kindly, then I will wait. Alex schrieb: >Without any filter at 50MHz and upper the noise cause a level peak error >because,up to now,there isn't a sin interpolation available. I know, it was my intention to talk about this. Alex, You tested your W2022A with a 100 MHz 100mV, I guess a leveled signal generator, so have You noticed that signal amplitude depend on the trigger treshold? I mean, when the trigger treshold is not a bit below the waveform's peak it is then continually moving and lower level than when the trigger level is just below the waveform's peak and it is itself more steady and its level has much more great amplitude. In short, the size of the displayed signal depends on the position of the trigger threshold, if the trigger threshold is low, the amplitude of the signal is so and the waveform is moving, whereas if the amplitude is high it becomes high itself and the waveform is more steady. Maybe it is due sin(X/X) lack, maybe it is for ather reasons... I tested both W2012A and W2022A up to 170MHz and they work well, if it were not for a lack linearity problem and poor representation due up to now there is not a sin(X/X) interpolation available. From my test on high frequencies the W2022A is better than the W2012A. Both W2012A and W2022A I tested are not modified unit, they are standard manufactured by Welec. Alex schrieb: >I only tried C6 ,anyway works well up to 50MHz and fix some issue, now >I'm using the previous on the lab. Can you kindly tell us how your W2022A is set for the better performances with the C6 release? I mean the Hardware menu's settings and the Filter setting in the Aquire menu. Thanks in advance. Mit Freundlichen Grüßen, Luc
Hallo Leute Ich habe vor ein paar Tagen ein Welec W2024A geerbt. Nach der ersten Euphorie kam nach einem Vergleich mit meinen anderen Oszis schnell die Ernüchterung. (Ich Arbeite sonst mit einem Hameg HM1005 und einem Tektronix TDS 340). Gestern habe Ich mich dann getraut die Kiste zu Flashen dabei ist mir aufgefallen das eure Flashsoftware ein Problem mit unterschiedlichen COM Ports zu haben scheint. Zuerst auf COM 1 kam immer wieder die Meldung wie oben beschrieben mal Abbruch in Zeile 30 mal in 234 u.s.w. ein Neustart des PC konnte auch nicht helfen, nach ca. 20 missglückten versuchen habe Ich dann mein Glück mit COM 2 Probiert und da funktioniert es immer. (Die W2000 Update Software funktioniert bei mir überhaupt nicht b.z.w. behaupte immer „File not Found“). Ich habe jetzt die Letzten 3 Versionen eurer Firmware ausprobiert und muss sagen Ihr habt ganze Arbeit geleistet Kompliment!!!! Mir ist aber auch aufgefallen das die angezeigten Spannungen nicht korrekt sind b.z.w. ca. 60% zu hoch angezeigt werden. Aus 10 V PK-PK werden bei mir 16V PK-PK. „Version 3.0_C6“ Mache Ich hier etwas falsch oder liegt das an den (Noch nicht vorgenommenen Hardware Änderrungen)? Ich habe leider keine Bedienungsanleitung und alles was Ich im Netz gefunden habe ist in English und beinhaltet sicher auch nicht eure Änderrungen. Gibt es vielleicht eine Bedienungsanleitung die einem Einsteiger die Funktionen des Geräts erklärt? Ich habe gesehen das ihr eine Huckepack Platine entworfen habt wenn das möglich ist würde Ich mich an der Sammelbestellung noch ganz gerne beteiligen. Ich hoffe meine Erfahrungen helfen euch weiter. Gruss Rudi
Hallo Rudi, unser Wiki kennst du schon? http://sourceforge.net/apps/trac/welecw2000a/wiki Da gibt es auch eine Seite mit Infos zur Sammelbestellung: http://sourceforge.net/apps/trac/welecw2000a/wiki/collectiveorder Mfg, Kurt
Hallo Rudi, > (Die W2000 Update Software funktioniert bei mir > überhaupt nicht b.z.w. behaupte immer „File not Found“). die originale Upd-Software ist Schrott, dauert auch viel zu lange! Am schnellsten ist der Germsloader, da muß aber das komplette Paket heruntergeladen werden... Hier der Link für die neuen Downloader, müssen nicht installiert werden und funktionieren einwandfrei: ---Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil4)" > Mir ist aber auch aufgefallen > das die angezeigten Spannungen nicht korrekt sind b.z.w. ca. 60% zu hoch > angezeigt werden. Aus 10 V PK-PK werden bei mir 16V PK-PK. „Version > 3.0_C6“ Ich habe auch im Leerlauf so um die 400-600mV Pk-Pk(bei jeder Version), egal welchen Filter ich einschalte...Hayo wird's schon richten :-) > Ich habe gesehen das ihr eine Huckepack > Platine entworfen habt... Schick mir mal eine PM, habe einen kompletten Satz inkl. Platinen abzugeben. Gruß Michael
Hallo Ja genau diese Uploader habe Ich benutzt!!! Bei offenen Eingängen ist das mehr oder weniger Normal da kommen natürlich Einstreuungen rein oder Leck ströme an den Sperrschichten der Eingangs OPs bei anliegendem Signal sind 60% Abweichung aber nicht akzeptabel mal schauen wie es nach dem Hardwareupdate aussieht. Rudi
Was für ein Signal hast du denn eingespeist? Das Welec ist zwar kein Präzisionsgerät aber 60% Abweichung hat es definitv nicht solange man sich nicht in höheren Frequenzbereichen bewegt. Gruß Michael
Hallo,
ich habe ein 4-Kanal-Welec (W2014A, sofern das überhaupt eine Rolle
spielt) abzugeben.
Das Gerät besitzt das Schirmblech aus galvanisch verzinntem Stahlblech,
die DACs sind bereits auf die 16 bit Version umgerüstet und Kanal 4 ist
für die Huckepackplatine vorbereitet, sprich die originale Eingangsstufe
ist entfernt.
Die anderen Kanäle besitzen die 24.9 Ohm (0.1%) Widerstände vor den
ADCs.
Zum Scope kommen drei fertig aufgebaute sowie vier nicht bestückte
Huckepackplatinen hinzu.
Zum Gerät gehören die vier Tastköpfe.
Als Bonus gibt es einen meiner selbstgebaut aktiven Tastköpfe V4b dazu.
Bei Interesse mailt einfach an: branadic [ed] users (punkt) sf {punkt}
net
branadic
Müssen wir uns Sorgen machen? Das klingt ja fast nach Projektaufgabe! :-( Alex braucht dringend einen 4Kanäler, finde ich. Wenn das Leon-Design mit 4 Kanälen arbeiten würde wäre ich schon längst mit Feuer und Flamme dran am Software-schreiben. Ich würde Alex auch einen Teil des Gerätes sponsorn. Ich tue schon mal 50€ in den virtuellen Pott. Machen noch mehr mit? Wie stünde Alex dazu? Jörg
Jörg H. schrieb: > Ich würde Alex auch einen Teil des Gerätes sponsorn. Ich tue schon mal > 50€ in den virtuellen Pott. Machen noch mehr mit? Wie stünde Alex dazu? Ich bin dabei, Betrag unbenannt. Warten wir auf Alex.
Ok, ich geb auch was zu (wenn Interesse). Viele Grüße, Egberto
Ach ja, Hayo hatte sich ja irgendwie gegen jedes Sponsering ausgesprochen - da würde ich aber noch viel mehr hin überweisen (wenn Interesse ;-)) Viele Grüße, Egberto
Hallo Das Eigespeiste Signal liegt zwischen 1Hz und 10Mhz Sinus Dreieck Rechteck. also nichts besonderes. Rudi
Jörg H. schrieb: > Müssen wir uns Sorgen machen? > Das klingt ja fast nach Projektaufgabe! Genau das ist es. Ich möchte Projektleichen loswerden und für mich zählt das Welec mittlerweile dazu. Ein kurzer Abriss: Im Oktober/November 2009 haben Walter und ich die erste Version der Huckepackplatine entworfen und gelayoutet, im Februar 2010 wurde die erste Version dann vorgestellt und vermessen. Dieser Version sind drei weitere Versionen gefolgt. Im Dezember letzten Jahres wurde der Einbau der finalen Version dokumentiert und die erzielten Möglichkeiten vorgestellt. Bis heute hat die Huckepackplatine keine Softwareunterstützung erfahren und ich sehe offen gestanden auch nicht, dass sich daran was ändern wird. Auch das Leon-Design wird noch eine ganze Weile brauchen. Alex ist mittlerweile berufstätig und zeitlich eingeschränkt, nicht zuletzt dank Freundin. Im Laufe des Projektes sind unzählige Leute, die anfangs mit Eifer dabei waren, heimlich still und leise untergetaucht und waren nicht mehr gesehen. Als Walter das Projekt verlassen hat gab es einen kurzen Aufschrei und die Unterstützung der Huckepackplatine ist in der Prioritätenliste ganz nach oben gerutscht. Davon ist nicht viel über geblieben. Salz macht aus Wasser noch lange keine Suppe und die Änderungen an der Firmware mögen Hayo wichtig erscheinen, aber mir genügen diese schon lang nicht mehr, zu viel Schein, zu wenig echte Funktionalität, viel zu viel für das Auge. Für mich steht das Projekt seit der Fertigstellung der Huckepackplatine still. Unzähliges Nachfragen, wann die Huckepackplatinenansteuerung in Angriff genommen wird, hat nicht den Erfolg gebracht. Daher meine Entscheidung, ich bitte diese zu verstehen. branadic
Aber das ist doch kein Grund die Flinte ins Korn zu werfen. Ich würde meine Basteleien nie für Geld verkaufen, da steckt ja unbezahlbarer Aufwand drin. In diesem Fall fände ich es auch etwas unfair euren "Kunden" gegenüber. Letztes Wochenende hätte ich meine Huckepackplatinen fast bestückt, wenn mir ein Kollege nicht das Equipment abgezogen hätte. Steht auf jeden Fall noch auf der Liste. Supportest du den Einbau noch, auch wenn du selber keine Platinen hast? Jörg
Jörg H. schrieb: > Aber das ist doch kein Grund die Flinte ins Korn zu werfen. > Ich würde meine Basteleien nie für Geld verkaufen, da steckt ja > unbezahlbarer Aufwand drin. Eben. Und genau das legt die Vermutung nah, dass der plakative Ausstieg eher ein Statement¹ ist. Sowas gibt es (auch) in der Open-Source-Szene regelmässig. Meine Empfehlung: nicht groß drüber nachdenken. /Hannes ¹) Das Statement lautet: "Ihr nehmt mich und meine Arbeit nicht ausreichend ernst/wichtig, also hab ich euch nicht mehr lieb."
Johannes S. (johannes_s94) schrieb: > Das legt die Vermutung nah, dass der plakative Ausstieg > eher ein Statement¹ ist. Sowas gibt es (auch) in der Open-Source-Szene > regelmässig. Stimmt, das scheint bei manchen Leuten an der Tagesordnung zu sein. Beitrag "Projekt: DDS basierter Funktionsgenerator mit AD5930" Aber deswegen nicht entmutigen lassen und vor allem nicht um Gnade winseln. Grüße Klaus Bauer
Jörg H. schrieb: > Aber das ist doch kein Grund die Flinte ins Korn zu werfen. > Ich würde meine Basteleien nie für Geld verkaufen, da steckt ja > unbezahlbarer Aufwand drin. > In diesem Fall fände ich es auch etwas unfair euren "Kunden" gegenüber. Hallo Jörg, die Entscheidung muss man mir überlassen. Ich habe genug Baustellen zu bedienen, da kann ich auf die ein oder andere Dauerbaustelle gut und gern verzichten. Jörg H. schrieb: > Supportest du den Einbau noch, auch wenn du selber keine Platinen hast? Klar, das hat Walter angeboten und das gilt für mich gleichermaßen. Johannes S. schrieb: > Eben. Und genau das legt die Vermutung nah, dass der plakative Ausstieg > eher ein Statement¹ ist. Sowas gibt es (auch) in der Open-Source-Szene > regelmässig. > > Meine Empfehlung: nicht groß drüber nachdenken. > > /Hannes > > ¹) Das Statement lautet: "Ihr nehmt mich und meine Arbeit nicht > ausreichend ernst/wichtig, also hab ich euch nicht mehr lieb." Klaus Bauer schrieb: > Stimmt, das scheint bei manchen Leuten an der Tagesordnung zu sein. > > Beitrag "Projekt: DDS basierter Funktionsgenerator mit AD5930" Noch einmal, ich bin niemandem Rechenschaft schuldig und die Entscheidung treffe ich ganz allein für mich, dazu brauche ich kein Feedback von irgendwelchen Leute die meinen sich nur aktiv beteiligen zu müssen, wenn man mit dem Knüppel auf jemanden hauen kann und sonst nicht konstruktives beitragen. Die Gründe für meine Entscheidung sind auch ganz allein meine Sache und hat euch nicht zu interessieren. Ich euch, lasst jedwede Unterstellung oder Verleumdung meiner Person, das gilt insbesondere für Johannes S. und Klaus! Danke, branadic
branadic (Gast)schrieb: > Ich habe genug Baustellen zu > bedienen, da kann ich auf die ein oder andere Dauerbaustelle gut und > gern verzichten. Frage: Entsteht mal aus den vielen "Baustellen" was produktives, oder muß man mit unfertigen Projekten weiterleben. Ich finde es unfair gegenüber den (nicht technisch Entwicklungsbegabten) Leuten hier Hoffnungen vorzugaukeln, worauf diese sich Bauteile zulegen welche danach nutzlos sind. Darüber sollte mal nachgedacht werden. Gruß Klaus
Klaus Bauer schrieb: > branadic (Gast)schrieb: > >> Ich habe genug Baustellen zu >> bedienen, da kann ich auf die ein oder andere Dauerbaustelle gut und >> gern verzichten. > > Frage: Entsteht mal aus den vielen "Baustellen" was produktives, oder > muß > man mit unfertigen Projekten weiterleben. > Ich finde es unfair gegenüber den (nicht technisch Entwicklungsbegabten) > Leuten hier Hoffnungen vorzugaukeln, worauf diese sich Bauteile zulegen > welche danach nutzlos sind. > Darüber sollte mal nachgedacht werden. > > Gruß > > Klaus Ich kenn dich nicht und habe mir dir nichts zu tun, ich bin dir zu nichts verpflichtet und wenn du der Meinung bist technisch unbegabt zu sein, so steht es dir frei das zu ändern! Aber versuche nicht mich für deine Unfähigkeit in die Verantwortung zu ziehen! Es wurde keine Hoffnung vorgegaulkelt, sondern eine Lösung erarbeitet. Diese Lösung hat bisher keine Unterstützung gefunden und damit ist das Thema Welec für mich beendet. Alle Imformationen zur Huckepackplatine sind veröffentlicht worden und für jedermann frei zugänglich, was willst du eigentlich noch? Hast du auch nur eine Minute mit in die Entwicklung gesteckt? Du hast doch bisher alles mundgerecht bekommen, ohne selbst etwas beigetragen zu haben! Ich versteh gar nicht, warum hier von der "Knüppeltruppe" so ein Wind gemacht wird. Andere Mitwirkende haben sich irgendwann einfach nicht mehr gemeldet. Hat da jemand was gesagt? Als Walter sich vom Projekt verabschiedet hat, hat da irgendwer das Motzen angefangen? Warum wird jetzt wo ich klipp und klar sage das ich keine Lust mehr auf dieses Langzeitprojekt habe, weil ich ein Messmittel brauche und keine Entwicklungsplattform, so ein Wind gemacht? Die Huckepackplatine ist fertig entwickelt und muss nur noch eingebaut und durch die Software unterstützt werden. Noch einmal ganz klar für dich Klaus, lass die Unterstellungen gegenüber meiner Person. Du musst mit keinem meiner Projekte leben, ich bin nicht zu deiner Unterhaltung da. Die Entwicklung der Huckepackplatine ist abgeschlossen!!! Abgeschlossen!!! Das Welec bleibt aber eine Baustelle, solange das neue FPGA-Design mit der neuen Firmware nicht die neue Basis bilden und die Huckepackplatine unterstützen. Ich möchte nicht mehr länger warten bis das so weit ist, weil ich, ich sage das noch einmal, ein Messmittel und nicht länger eine Entwicklungsplattform brauche. Ich hoffe das ist jetzt auch endlich bei dir angekommen. Statt in Foren zu pöbeln solltest du die Energie lieber dazu verwenden, dich in die Themen einzuarbeiten, um selbst auch mal etwas, wie du es so schön formuliert hast, produktives beizutragen! Frage: Ist das jetzt endlich auch bei dir angekommen? branadic
Ich habe großen Respekt vor branadic, hayo, alex und all den andern die dieses Projekt so weit gebracht haben, danke. Ich kann auch nicht verstehen, dass manche Leute jetzt hier rumpöbeln, gerade über Menschen die sich hier besonders eingebracht haben. Ich habe das Projekt gern verfolgt, dass es jetzt vorläufig nicht weitergeht ist bedauerlich. Alle die wie ich bis jetzt sich nicht aktiv an der Entwicklung beteiligt haben, aber Interesse am Fortgang haben, können sich jetzt an die eigene Nase fassen. @branadic: Willst du dein Welec Equipment nicht liebe einmotten, wäre doch schade wenn hier doch noch was zustande kommt und du nicht davon profitieren würdest. Gruß Stefan
Kleiner Vorschlag am Rande: ímmer wenn man veröffentlichte Oszillogramme in Fachzeitschriften oder sonstwo sieht, sieht man auf den ersten Blick dass es sich um ein Bild eines Tektronix Geräts handelt weil in der linken oberen Ecke das "Tek" steht. Wie wäre es wenn sowas auch hier gemacht würde? Ich fänds lustig. Besonders wenn sich manche Leute auf einmal fragen: was ist das denn für ein Hersteller? Das sieht ja richtig gut aus von Funktionsumfang und Design her... Falls es umgesetzt werden sollte fragt sich nur: was für ein Kürzel?
moin,
> Falls es umgesetzt werden sollte fragt sich nur: was für ein Kürzel?
Gute Idee! Als Kürzel käme ja eigentlich nur " WT " in Frage...
Ansonsten fände ich die "Sinuskurve" ganz schick...
Ack kommt wohl von der Antwort in Bussystemen die ein Slave als "zustimmung" sendet. I²C hat dies z.B. soviel ich weiß. Gruß Andi
branadic (Gast) schrieb:
> Frage: Ist das jetzt endlich auch bei dir angekommen?
Antwort : JA, ich hoffe bei all den anderen nicht so technisch
hochbegabten auch.
Klaus
Hayo!! Where are you gone? :-) Regards, Paolo P.S:: since your last firmware update, the WELEC become semi-officially my Laboratory DSO.
Hallo! Ich finde es auch sehr schade, dass wir keine neuen Entwickler für das Open Source Projekt mehr finden. Unsere zwei größten Mankos sind, dass wir einerseits zu wenig im Internet präsent sind, und dass den meisten Open Source Entwicklern die Kompetenzen für so eine Embedded Systems Programmierung fehlt. Leider schauen die meisten Personen nur auf den kurzzeitigen Erfolg, da man mit dieser Strategie die größten positiven Rückmeldungen bekommt. Mit Hayos Verbesserungen der Software mit dem originalen FPGA-Design ist leider die Warscheinlichkeit von Nachschub an Entwicklern für das LEON3-FPGA-Design stark geschrumpft. Hayo hat es geschafft, dass die meisten Nutzer mit dem Oszilloskop zufrieden sind. Was aber klar ist, dass dieses Oszi so niemals überall so gut oder besser wie die Markenoszilloskope sein wird. Branadic hat mit Walter meiner Meinung nach eine sehr gute Arbeit beim analogen Frontend gemacht. Wenn ich bei der Entwicklung des LEON3-Zeug schon weiter wäre, hätte ich das sicher schon integriert. Schließlich sollte man möglichst versuchen, die eingebrachten Fähigkeiten und Arbeitsleistungen anderer möglichst versuchen zu Integrieren und zu Ergänzen, da man sonst irgendwann nur mehr alleine weiter entwickelt. MfG Alexander
Hallo zusammen. Ich hätte folgenden Vorschlag: schreiben wir doch (von mir aus ich) einen Artikel für das embedded projects journal. Da erreicht man Leute, die sich für Open Source begeistern und durchaus auch sehr fähige Menschen, jedenfalls gibt es dort immer wieder ganz interessante Projekte. Man könnte auch versuchen, Alex' Weg fortzuführen und Professoren kontaktieren, um Diplomanden für das Projekt zu gewinnen. Ich z.B. habe nach wie vor guten Kontakt zu einem Professor, der selbst in Sachen VHDL sehr versiert und auch aktiv ist - der könnte evtl. Studenten dafür gewinnen. Denn meiner Erfahrung nach wollen viele was in Richtung VHDL machen, finden aber kein passendes Thema in der Industrie. Mir ging es übrigens auch so, genauso wie einem Masterstudenten den wir zur Zeit in der Arbeit beschäftigen. Leider habe ich selsbt keine Zeit um einen wirklich sinnvollen Beitrag zu leisten aber das könnte doch ein Weg sein... Eure Meinung? Gruß Michael
>Da erreicht man Leute, >die sich für Open Source begeistern und durchaus auch sehr fähige >Menschen Zumindest an der Firmware hier ist es sehr schwer sich zu beteiligen. Die letzte Aktualisierung des Codes in Sourceforge ist 6 Monate her (stammt noch von mir) und den Quellcode hier rauszusuchen wird sich auch keiner antun. Zumindest hatte ich darauf irgendwann keine Lust mehr und habs einfach gelassen. Von daher mach es für mich keinen Sinn, Leute extra für die Firmware anzuwerben. In diesem Sinne.
Hallo Michael! Deine Idee mit dem embedded projects journal finde ich sehr gut. Ich würde mich sehr über so einen Beitrag freuen. Vor allem sollte betont werden, dass sich das Welec Oszilloskop quasi als Open Source Prototyping Plattform sehr gut eignet (Verfügbarkeit, Doppelnutzen,...). Unser langfristiges Ziel ist ein vollkommen offenes Oszilloskop mit hoher Qualität zu schaffen. Zur VHDL- und Firmware-Entwicklung schadet die mäßige Signalqualität nicht. Weiters sollte auf die Möglichkeit der Adaptierung auf hochauflösenenden ADCs hingewiesen werden (Doku dazu gibts aus Mangel an Interesse im Moment keine). Übrigens ist der Zustand des VHDL-Design wirklich schon reif für ein Release. Das größte Manko liegt an der Firmware, die noch weit von einem Release entfernt ist. Die Dokumentation habe ich im Moment auch nur sehr minimalistisch ausgeführt, da den zuküftigen Softwareentwicklern fertig programmierte Hardwareschnittstellen mehr bringen und ich zugleich die von mir geschriebene Hardware testen kann. @Stefan: Die Originalsoftware verbessern bringt nur den Wittigs und den Besitzern des Welec was, sonst niemanden. MfG Alexander
Hallo Alex. Es ist ja toll, dass du das VHDL Design schon zur Einsatzbereitschaft gebracht hast, dafür zolle ich dir meinen größten Respekt! Dann werde ich mal zusehen, dass ich einen Artikel entwerfe. In Bezug auf dein VHDL/Leon3 Design werde ich dann vermutlich aber auf dich zukommen müssen, da ich darüber leider noch nicht sonderlich viel weiß. Ich könnte mir vorstellen, dass einige Leute bei dem Projekt Open Source Oszi hellhörig werden, hoffentlich täusche ich mich da nicht. Wenn die Programmiermaschine Hayo wieder mehr Zeit hat, kann er sich ja vielleicht auch mit dem Thema Leon3 beschäftigen, dann wären Fortschritte garantiert, allerdings wäre es dann natürlich toll wenn es mit svn klappen würde... Ich finde es übrigens ziemlich schade, dass branadic aufgegeben hat. Vielleicht wird es ja trotzdem noch was mit der Huckepack Unterstützung, dann wäre die Arbeit von ihm und Walter nicht vergebens gewesen. Gruß Michael
Ich bestücke gerade meine Eingangsplatinen... Bis später, Jörg
Von mir auch nochmal ein großes Danke an die die hier mitbearbeitet haben und werden. Ihr habt aus dem Scope ein für mich verwendbares Werkzeug gemacht. Ich beschäftige mich mit Elektronik nur als Hobby und nicht beruflich, konnte so leider hier auch nichts beitragen - aber von eurem Einsatz profitieren. Für das Geld, das es mich die Anschaffung gekostet hat, habt ihr und das umsonst, den Nutzen des Gerätes für mich mehr als verdoppelt. DANKE Ich hoffe, dass es weitergeht und wünsche allen hier beteiligten mindestens so viel Spaß am Hobby, wie es mir bereitet.
Hi @ all.sich I'm just alive, so don't worry! Work will go on soon... Hallo allerseits, leider hatte ich in letzter Zeit etwas wenig von selbiger für unser Projekt. Mit Bedauern lese ich, dass Branadic sich aus dem Projekt zurückzieht. Ich weiß, dass sich das mit der Hardwareunterstützung etwas hinzieht. Ich möchte aber nochmals darauf hinweisen, dass zeitweilige Entwicklungspausen kein Grund zur Besorgnis sind. Da ich berufstätig bin ist die Zeit manchmal etwas knapp. Die beste aller Ehefrauen ist da wirklich sehr tolerant, wenn man bedenkt wieviel Zeit ich schon in das Projekt gesteckt habe. Ich möchte ebenfalls darauf hinweisen, dass ich das Ganze aus reinem Spass an der Sache mache. Ich könnte mir ohne Weiteres auch ein 3000,- Euro Gerät kaufen wenn es mir darauf ankäme. Nur würde das keinen Spaß machen! Zu den beschriebenen Problemen: - das mit den falschen Messwerten werde ich mal prüfen und ggf. korrigieren - ich stelle in den nächsten Tagen mal eine weitere Compilation bereit bei der die USTB-Bereiche wieder gehen. Noch einen sonnigen Tag Hayo
So, die Platinen sind bestückt. Hat deutlich länger gedauert als ich dachte, mit Bauteilgröße 0402 ist das doch sehr fummelig. Gut das Kurt etwas Reserve in die Tütchen gepackt hat, ein paar von den Sandkörnern sind mir aus der Pinzette gehüpft, natürlich auf nimmerwiedersehen. Nun habe ich den Compiler vorgewärmt und Hayos Software in der Version C6 zum Üben durchkompiliert. Spricht eigentlich was dagegen, die im Sourceforge-Branch "bf" einzuchecken, zur ggf. gemeinsamen Arbeit? Dort liegen anscheinend ältere Sourcen. Ich kenne die Arbeitsweise hier zugegeben nicht. Ich Noob suche mir gerade zusammen, wie denn die Ansteuerung der Platine zu machen wäre, bin für Starthilfe dankbar. Ist diese Schaltplanänderung von Kurt aktuell? Trägt das auch für 4Kanäler? Beitrag "Re: Wittig(welec) DSO W20xxA Hardware" Wenn ich das recht deute wird aus dem 16-Bit Schieberegister aus U23/U21 dann ein 24-Bit Schieberegister U23/U21/U24. Die Chip-Selects der Eingangsstufen werden daraus gewonnen. Sind die anderen Ausgänge von U24 obsolet? Macht das FPGA auch 24-Bit breite Shifts? Um unsere Chip-Selects wieder wegzunehmen muß U24 neu "befüllt" werden. Machen die Takte dann nicht unsere Daten im LMH651 kaputt? Mir ist auch noch nicht klar, wie SPI von der Software aus bedient wird. Wie werden die von U25 erzeugten Chip-Selects programmiert, wie die Anzahl der Shifts eingestellt? In der Software wird fleißig auf serdata->np_piodata zugegriffen, der Transfer anscheinend mit serstartsw->np_piodata ausgelöst. Jörg
Ich antworte mir mal selbst, mit meinen Forschungsergebnissen von gestern. Bin durch Hardware und Software gekrochen. Die SPI-Hardware im Nios-Design macht mehr selbst als ich dachte. Der Chip-Select Adressdecoder U5 wird vom obersten Hex-Digit des Registerwerts serdata->np_piodata eingestellt, genau genommen Bits 22:20. Die Länge des Schiebetransfers ist entweder immer 24 Bit, oder (was ich nicht hoffen will) von den Bits 22:20 abhängig. Die DACs brauchen 24 Bit, die Schieberegisterketten 8 oder 16. Um das genauer rauszufinden muß ich mir da Drähte anlöten, zum Logic Analyzer, um das im Betrieb zu messen. Den Anschluß der Huckepackplatinen stelle ich mir daher etwas anders vor. Ich hoffe das FPGA schiebt auch 24 Bit an Daten wenn Register Bits 22:20 gleich Null sind, also keiner von den bestehenden Chip Selects aktiv ist. Dann können wir die Platinen direkt an SPI Clock und Data anschließen, nicht hinter ein Schieberegister. Auf den Platinen müssen die Pullups entfallen oder vergrößert werden, denn die SPI-Signale sind wegen der Transistorschaltung Q9,Q10 speziell nach low recht schwach. Den Schieberegistern habe ich ein Stück weit hinterhergemessen. In Brunos Bestückungsplan "Analog-Input-Part_assignment_V3_4.pdf" ist eine Diskrepanz zum Schaltplan, die mich in die Irre führte. Sein U21 ist in Wirklichkeit U23. U21 ist auf der anderen Platinenseite, unter dem Abschirmkäfig von Kanal 1. Wo ich gerade bei den Bauteilbezeichnungen der Schieberegister bin: Das im Plan unbeschriftete MC4094 (unterhalb vom 74HCT238, der U23 wäre) ist U22. Weiter rechts und nicht mehr im Bild sind zwei weitere Schieberegister, wie die heißen weiß ich noch nicht. Wieder auf der anderen Seite, nahe der seriellen Buchse ist U26. Ich bin glücklicher Besitzer eines Stereomikroskops, zum Löten der Platinen sehr nützlich. Gestern habe ich Sittenstrolch damit den Schieberegistern zwischen die Beine geguckt um zu sehen welche Ausgangsleitungen tatsächlich noch unbeschaltet sind. Wir brauchen ja 4 Stück für die Chip Selects der Eingangsplatinen. Der Schaltplan ist da noch recht unvollständig. Auf der den Chips der Oberseite gehen von allen Ausgängen Leiterbahnen weg, die sind also anscheinend alle belegt. Auf der Unterseite sind insgesamt 6 Ausgänge frei, aber ungünstig verteilt, jeweils 3 bei U21 und U26, an verschiedenen Positionen. Dann nehmen wir wohl besser Ausgänge die an die alten Eigangsstufen gehen und deshalb obsolet werden. Wie störempfindlich sind die neuen Eingangsstufen eigentlich? Sollte man die besser mit in die Abschirmkäfige löten? Dann sähe es auf der Platine vielleicht auch nicht so schlimm aus, das Gebastel wäre versteckt. So long, Jörg
Hallo Jörg, ich sehe Du kniest Dich da voll rein. Wenn Du firmwareseitig Unterstützung brauchst sag Bescheid.. Ich kann Dir dann die Stellen sagen an denen Du im Coding eingreifen mußt. Gruß Hayo
@Hayo: Danke, ich melde mich. Du meinst warscheinlich die Funktion Hardware::SetSwitches(). Dort werde ich verzweigen müssen, je nach Eingangsstufe. Gibt es auf der Tastenplatine eigentlich noch freie Eingänge, die man als Kennung anders brücken könnte? Dann brauchen wir keinen Konfigurationsdialog ob alte oder neue Eingangsstufe. @All: Ich messe gerade mit dem Logicanalyzer wie das FPGA denn den SPI bedient. Leider tut es das bereits maßgeschneidert für die jeweilige Empfangskette, nicht generisch. Die Anzahl der erzeugten Bitclocks ist genau passend, 8 Bit für Chip Selects mit einem Schieberegister, 16 Bit für Chip Selects mit zwei Schieberegistern, 24 Bit für die DAC-Chipselects. Für letzere wird Enable während der Bits gehalten, für die Schieberegister ist es ein Strobe hinter den Bits. Von daher klappt es nicht, irgendwelche Register umzuketten oder sich dahinter zu hängen. Für Adressbits = 0 wird gar kein Signal erzeugt. Ich habe aber eine Art Lücke gefunden: Für die eigentlich nicht vorhandenen Adressen 8 und 9 (der Demux kümmert sich nur um 0 bis 7) werden auch Daten rausgetaktet, und zwar 16 Bit wie für 2 Schieberegister. Der Adressdekoder U25 kriegt eine 0, erzeugt dann also keinen verwendeten Chip Select. Eigentlich genau das was ich suchte, außer das wir 24 Bit brauchen. Man muß so eine Adresse also zweimal beschreiben. So long, Jörg
Hallo Jörg! Es freut mich zu lesen, dass du für die nette Huckepack-Platine eine Software-Unterstützung dazufügst. Das ist für mich aus Respekt für die geleistete Arbeit von unseren Analogtechnikern ein muss. Das der NIOS die SPI Ansteuerung in Hardware gemacht hat, schreckt mich ein wenig und erklärt auch ziemlich, weshalb das noch nicht vorher (erfolgreich) in Angriff genommen wurde. - Selbst ich habe nur das eine Oszi und keinen Logic-Analyser zur Hand. Anfangs hatte ich die SPI Ansteuerung auch beim LEON3 Design in Hardware vorgesehen. Während ich die Software-Treiber dafür schrieb, fiel mir aber auf wie blöd so eine zugescheiderte Ansteuerung in einem möglicht portablen FPGA-Design ist, und habe das ganze auf GPOs zurückgebaut. MfG Alexander
Jörg H. schrieb: > @Hayo: > Danke, ich melde mich. Du meinst warscheinlich die Funktion > Hardware::SetSwitches(). Dort werde ich verzweigen müssen, je nach > Eingangsstufe. Jupp, eine (ganz kleine) Verzweigung ist schon drin für Gain 1,25. Ansonsten habe ich alles kommentiert was sich mir so an Funktionen erschlossen hat. Der WELEC-Programmierer war mit Kommentaren und Doku ziemlich geizig... > Gibt es auf der Tastenplatine eigentlich noch freie Eingänge, die man > als Kennung anders brücken könnte? Dann brauchen wir keinen > Konfigurationsdialog ob alte oder neue Eingangsstufe. Keine Ahnung, die Idee ist gut, aber ich finde das mit dem Konfigmenü auch nicht so schlimm. Gruß Hayo
Muss man überhaupt unterscheiden? Wer die Huckepackplatine nicht hat, den stört doch das Bitgewackel nicht. Und wer den ursprünglichen Eingang nicht nutzt, dem kann doch egal sein, wie der eingestellt ist?
Guido schrieb: > Muss man überhaupt unterscheiden? Wer die Huckepackplatine > nicht hat, den stört doch das Bitgewackel nicht. Und wer > den ursprünglichen Eingang nicht nutzt, dem kann doch egal > sein, wie der eingestellt ist? Ich widme eine Steuerleitung der alten Eingangsstufe um, zu einem Chip Select für die neue. Von daher stört es, diese Leitung muß penibel bedient werden. Und wenn man (wie ich) nicht alles auslötet, dann muß der letzte Analogschalter der alten Stufe offenbleiben, sonst muß man ihn entfernen. Die neue Eingangsstufe hat zudem mehr Möglichkeiten, das könnte man in Zukunft nutzen. Die Verstärkung ist fein einstellbar, die Bandbreitenbegrenzung hat mehrere Stufen. Der SPI-Bus kann nicht lesen, nur schreiben, die Einstellungen erfolgen blind. Sonst ginge das damit ganz gut. Man könnte das Oszi theoretisch über das gemessene Signal "erfühlen" lassen, welche Eingangsstufe es hat. Aber erstmal muß es überhaupt funktionieren. Ich komme frühestens am Wochenende dazu. @Hayo: Viele Variablen werden ins Flash geschrieben und davon wieder gelesen, und da gibt es noch auskommentierte Lücken. Ich habe nun 4 Flags neu eingeführt, die pro Kanal anzeigen ob alte oder neue Eingangsstufe. Kann ich mir eine solche Lücke aussuchen, oder muß das aus irgendwelchen Kompatibilitätsgründen frei bleiben? Jörg
Ich such Dir mal 4 raus. bzw. da es ja eine long Variable ist, könnte man natürlich auch alle vier Flags in einen Speicherplatz mergen. -> ich sag gleich bescheid Hayo
Also da es sich ja um eine feste Hardwareinformation handelt gehört das ja eigentlich ins Protected Flash. Du könntest die Flags ab Speicherplatz 80 ablegen. Wenn Du die Flags lieber ins normale Config Flash schreiben willst würde ich empfehlen die Werte in der jeweiligen Kanalsektion unterzubringen. Da bieten sich z.B. an: Speicherplatz 74/92/110/128 -> also nicht zusammenmergen. Gruß Hayo
Ein kleines Statusupdate zur Eingangsplatine: Sie funktioniert, und ich habe sie softwaremäßig "unter Kontrolle". Zwar noch nicht an allen Stellen der Software, bei Spezialitäten wie Autorange arbeitet die nämlich an ihren eigenen Funktionen vorbei. Es sind auch noch keine Kalibrierwerte drin und keine Konfigurationsmöglichkeit. Ich habe die Einstellungen welcher Kanal welche Eingangsstufe hat aber immerhin schon wie von Hayo vorgeschlagen im Protected Flash abgelegt. Der Anschluß an SPI kann leider doch nicht so wie von mir vorgeschlagen erfolgen. Der Chip auf der Eingangsstufe mag es nicht, wenn ich ihm zu lange Datenworte sende. Ich hoffte, er ignoriert die überzähligen Bits, aber stattdessen akzeptiert er das ganze Datenwort nicht. Nun wurde es doch "SPI over SPI", Bitbanging mit den bereits über SPI angesteuerten Registerausgängen. Ist nicht schlimm, nichts wird langsamer, der Zugriff paßt locker in die Zeit die eh auf die Relais gewartet wird. Etwas blöd ist nur, daß man sich 2 Signale von der anderen Seite der Platine holen muß. An der Hardware der Platinen ist noch Feintuning nötig. Momentan sind das kleine UKW-Sender, sie schwingen etwas. Andre und sogar Walter helfen mir netterweise (siehe Skype-Chat), die kriegen das bestimmt hin. Wenn ich in dieser Software rumfummele kriege ich Zustände. Eigentlich wäre das ja ganz einfach, wenn man eine vernünftige Hardwareabstrakion hätte und sich dran halten würde. Aber hier sind die Dinge unnötig kompliziert, vieles ist für die 4 Kanäle 4 mal codiert (schon mal was von Arrays gehört?). Das bläht den Code auf und man wartet lange auf den seriellen Download. Es juckt, da neu anzufangen und eine Codebasis zu schaffen, die bis auf eine Hardwareschicht unverändert auch auf dem Leon-Design laufen könnte. Ich kenne die Features und Spezialitäten beider zugegeben nicht. Hayo, wärst du dabei? Grüße, Jörg
Hey Jörg, ich finde es klasse, welche Fortschritte du erzielst. Nicht nur, dass es mich freuen würde, wenn die vier Platinchen auf meinem Schreibtisch irgendwann einsetzbar wären, es freut mich auch für Walter und branadic, wenn ihre Arbeit Früchte trägt. Tolle Sache! Gruß Michael
Hallo ihr Teilnehmer an der Sammelbstellung der Bauteile für die Huckepackplatine! Es hat seitens Digikey einen Fehler beim abpacken gegeben. Aus diesem Grund sind die Widerstände in 0402 mit 6k8 und 220k vertauscht! Vor dem bestücken solltet ihr zumindest diese beiden Werte nochmal nachmessen. Falls ihr schon bestückt habt und Ersatzwiderstände braucht schicke ich euch diese kostenlos zu. Mfg, Kurt
Hallo an alle, tut mir leid, dass Ihr momentan so wenig von mir hört. Bin die nächsten zwei Wochen in Thailand. Melde mich danach wieder. So muß jetzt zum Flughafen. Bis dann Hayo
Hi there, gruss aus dem sonnigen Thailand - es ist kurz vor 20:00 Uhr und es sind 30 Grad hier - schwitz! Nach einer Woche Strand habe ich jetzt auch den Kopf wieder frei und habe eine menge Ideen bezueglich (Umlaute gibts hier nicht auf der Tastatur) der neuen USTB-Engine. Alles was mir einfiel habe ich natuerlich sofort am Strand direkt auf das gute alte Offlinemedium Papier niedergeschrieben. Wenn ich in einer Woche zurueck bin werde ich mal wieder etwas Bewegung in die Sache bringen. Vielleicht ist dann ja auch Joerg schon soweit das seine neue Hardwareansteuerung mit einfliessen kann (sz gibt es auch nicht). Lasst Euch solange auch die Sonne auf den Bauch scheinen Gruss Hayo
Blessed are you for these holidays in Thailand We can not wait Hello
Don't worry! I got some new ideas in the meantime on the beach... :) I will be be back soon and looking forward to go on with the new version. Be relaxed and enjoy the summer time meanwhile Hayo p.s. going to the beach now to get some more good ideas :)
Hayo W. schrieb: > es ist kurz vor 20:00 Uhr und es sind 30 Grad hier - schwitz! Hallo Hayo, erwartest du jetzt soetwas wie Mitleid? ;-) Gut, dass du neue Kräfte sammeln kannst und eine schöne Zeit in Thailand verbringst. Wenn ich dich so höre, scheint der WAF von Paperwork ok zu sein. Bei Cursor-Anzeige und Delay-Fenster haben sich auch noch ein paar Dinge gezeigt, die sich hoffentlich mit deinem Insiderwissen abbiegen lassen. Gruß Rainer
Rainer W. schrieb: > Hallo Hayo, > erwartest du jetzt soetwas wie Mitleid? ;-) Nicht wirklich - aber fuer einen Norddeutschen ist das hier schon eine harte Nummer mit den Temperaturen. Da heisst es langsam bewegen oder besser garnicht. > Gut, dass du neue Kräfte sammeln kannst und eine schöne Zeit in Thailand > verbringst. Wenn ich dich so höre, scheint der WAF von Paperwork ok zu > sein. Unbedingt! Die beste aller Ehefrauen hat ca. 24 kg Kriminalromane dabei und ist froh wenn sie in Ruhe lesen kann - da eroeffnen sich mir ungeahnte Moeglichkeiten ;-) > Bei Cursor-Anzeige und Delay-Fenster haben sich auch noch ein paar > Dinge gezeigt, die sich hoffentlich mit deinem Insiderwissen abbiegen > lassen. Lass hoeren, welche Probleme gibt es da? Vielleicht kann ich mir da schon ein paar (offline) Gedanken machen. Notfalls kann ich mir hier das Coding mal auf SFN ansehen. Es gab doch vor einigen Wochen die Meldung, dass bei Quickmeasure der RMS-Wert nur die Haelfte anzeigt. Hat das mal jemand ueberprueft? Ich hatte leider noch keine Zeit dazu. Gruss Hayo p.s. es ist garnicht so leicht an nichts zu denken ;-)
Angehängte Dateien:
-
CursorPos_Delayed.png
5,3 KB -
CursorValue_wrong.png
4,7 KB -
CursorValue_ok.png
4,6 KB -
RMS_ok.png
4,3 KB -
CursorPos_Delayed2.png
5,7 KB
Dann will ich mal was gegen mögliche Langeweile tun. Ich habe die BF.3.0 C5 drauf, weil bei der C6 irgendwas (USTB?) gar nicht lief. Hayo W. schrieb: > Lass hoeren, welche Probleme gibt es da? Vielleicht kann ich mir da > schon ein paar (offline) Gedanken machen. Notfalls kann ich mir hier das > Coding mal auf SFN ansehen. 1. Wenn man das (sogenannte) Delayed Fenster geöffnet hat, haben die dort dargestellten Cursorpositionen nichts mit der Realität zu tun. Im Screenshot (CursorPos_Delayed) liegt das Fenster in der rechten Hälfte des Signale. Die beiden Cursur x1 und x2 stehen im Main an der ersten steigen Flanke bzw. 80 µs dahinter, also außerhalb des Delayed-Fensters. Die im "Delayed"-Fenster dargestellten Cursor sind im richtigen Abstand, aber an einer völlig falscher Position dargestellt. Gerade ist mir aufgefallen, das möglicherweise für die Cursordarstellung im Fenster einfach auf die falsche Bezugsposition zugegriffen wird: Ein Cursor, der im "Main" dicht vor dem Fensteranfang steht, wird im "Delayed" kurz vor dem Fensterende eingezeichnet. (CursorPos_Delayed2) 2. Wenn man die Cursorposition verdreht, werden oft die Zahlenwerte nicht aktualisiert (z.b. X2 in CursorValue_wrong). Erst wenn man nach einer Gedenksekunde (gefühlte 3s?) den Universalregler noch einmal etwas dreht, springen die angezeigten Zahlenwerte auf den richtigen Wert (CursorValue_ok.png). Wenn man ohne die genügend lange Pause immer wieder die Position verdreht, findet gar kein Update statt. > > Es gab doch vor einigen Wochen die Meldung, dass bei Quickmeasure der > RMS-Wert nur die Haelfte anzeigt. Hat das mal jemand ueberprueft? Das sieht IMHO gut aus, bei AC-Signal ist RMS = 1/2 Peak-Peak (RMS_ok.png) Ich wünsche euch noch schöne Tage in Thailand und gutes Tüfteln Gruß Rainer
Rainer W. schrieb: > Gerade ist mir aufgefallen, ... Zu spät: p.s. Die Theorie paßt aber nicht immer (im ersten Bild trifft das nicht zu)
So die Angebetete laesst sich am Strand grillen, da hab ich mal die Zeit genutzt um den Hotelrechner zu maltraetieren. Schnell mal die wichtigsten Programme installiert und das Coding runtergeladen - so kann man ja nicht arbeiten ;-) @Rainer Danke fuer die Info. Im Cursor-Modus ist der Werte-Refresh leider grundsaetzlich etwas langsam. Im Delayed-Modus muss man da noch etwas mehr Geduld haben, da noch mehr bremsende Grafikausgabe dazukommt. Die Cursorpositionen kann ich aber leider erst zu Hause am Geraet ueberpruefen - also in 3 Tagen :) @Joerg Jörg H. schrieb: > Wenn ich in dieser Software rumfummele kriege ich Zustände. Willkommen in meiner Welt ;-) Du Solltest Dir mal den Spass machenb und Dir das alte Origanalcoding ansehen. Da bekommt man direkt Ausschlag im Gehirn. Mittlerweile ist das ja schon einigermassen strukturiert. > Eigentlich > wäre das ja ganz einfach, wenn man eine vernünftige Hardwareabstrakion > hätte und sich dran halten würde. Ich hatte mal angedacht einen Hardware Abstraction Layer (HAL) zu bauen, es dann aber aus Performancegruenden wieder verworfen. > Aber hier sind die Dinge unnötig > kompliziert, vieles ist für die 4 Kanäle 4 mal codiert (schon mal was > von Arrays gehört?). Das bläht den Code auf und man wartet lange auf den > seriellen Download. Das war zu Anfang noch viel schlimmer. Ich habe zig hunderte Zeilen "blinden" copy & paste code rausgeschmissen und durch Schleifen bzw. Arrays ersetzt -> to be continued... > Es juckt, da neu anzufangen und eine Codebasis zu > schaffen, die bis auf eine Hardwareschicht unverändert auch auf dem > Leon-Design laufen könnte. Ich kenne die Features und Spezialitäten > beider zugegeben nicht. Hayo, wärst du dabei? Ich hatte davon erstmal abgesehen, weil die Hardware (WELEC FPGA-Design) des NIOS voellig undokumentiert ist und man vorher die Funktionalitaeten genau ermitteln muesste. Um schnell brauchbare Ergebnisse zu bekommen habe ich mir dann immer einige Hotspots gesucht die ich dann Stueck fuer Stueck ueberarbeitet habe. Ich hatte mir das fuer das LEON-Design eine entsprechende Implementierung vorgenommen da es hier wohl eine komplette Doku der Funktionen geben wird. Grundsaetzlich waere ich aber dabei. Das duerfte allerdings eine ganze Zeit dauern bis wir da was lauffaehiges zusammen haben. So muss jetzt Coctails besorgen... Gruss Hayo
Hayo W. schrieb: > Danke fuer die Info. Im Cursor-Modus ist der Werte-Refresh leider > grundsaetzlich etwas langsam. Langsam wäre ja nicht sooo schlimm, aber der Werte-Refresh kommt gar nicht, wenn man den Drehregler nach den mindestens 3 s nicht noch einmal bewegt. Gruß Rainer
Hayo W. schrieb: > ... Im Cursor-Modus ist der Werte-Refresh leider grundsaetzlich > etwas langsam. So, nach etwas Probieren scheint das Update-Problem deutlich klarer. Wenn man den Cursor anfängt zu bewegen, findet einmal ein Update der Werte statt. Beim Weiterdrehen wird dann nur noch der Cursor auf dem Bildschirm bewegt, aber anscheinen kein Flag mehr gesetzt, was das Update anstößt. Erst wenn man die 3s-Pause gewartet hat, wird bei Reglerbegung wieder ein Werte-Update angestoßen. Ich hoffe, der Sun-Downer hat gemundet. Gruß Rainer
Rainer W. schrieb: > So, nach etwas Probieren scheint das Update-Problem deutlich klarer. > Wenn man den Cursor anfängt zu bewegen, findet einmal ein Update der > Werte statt. Beim Weiterdrehen wird dann nur noch der Cursor auf dem > Bildschirm bewegt, aber anscheinen kein Flag mehr gesetzt, was das > Update anstößt. Erst wenn man die 3s-Pause gewartet hat, wird bei > Reglerbegung wieder ein Werte-Update angestoßen. Ok, das ist ein guter Hinweis, da kann ich gleich mal das Coding durchstoebern nach den Verdaechtigen. Hier ist dank Regenzeit bedeckter Himmel mit kraeftigen Schauern - das Ganze bei 33 Grad. Da bietet sich ein kleiner Code-Review geradezu an :) > Ich hoffe, der Sun-Downer hat gemundet. Hat er. Geht doch nichts ueber einen Kaipi bei der Waerme. Nebenbei habe ich mir auch noch Gedanken zum Thema Triggerlevel gemacht. Es wurde ja schon mehrfach kritisiert, dass der Triggerlevel beim Umschalten des Spannungsbereiches nicht konstant bleibt sondern stattdessen die Position auf dem Bildschirm. Das fuehrt dazu das der Level beim Umschalten jedesmal seinen Wert aendert - anders als bei einem analogen Oszi zum Beispiel. Grundsaetzlich liesse sich ein konstanter Level schon implementieren, aber das Problem ist, dass das Triggerlevel-Register nur 8 Bit breit ist sprich 256 Werte abbilden kann. Das wuerde dazu fuehren, dass beim Herunterschalten aus einem hohen Spannungsberech der Trigger in die Begrenzung faehrt und der angezeigte Level nicht mehr mit dem tatsaechlichen Trigger uebereinstimmt. Der Triggerlevel ist also vom Spannungsbereich abhaengig. Daher ist die momentane Loesung also technisch bedingt. Ich hatte mir allerdings ueberlegt ob ich einen "partiell konstanten" Triggerlevel implementiere, der z.B. beim Hochschalten von niedrigen zu hohen Spannungsbereichen konstant bleibt. Das Ganze natuerlich per Triggermenue auswaehlbar. Werd mal sehen ob das brauchbar ist. Gruss Hayo
Hi there! Hayo W. schrieb: >Der Triggerlevel ist also vom Spannungsbereich abhaengig. Daher ist die >momentane Loesung also technisch bedingt. Hi Hayo. Could this be related to the fact that with the Welec's oscilloscopes, the displayed signal's size depends on the position of the trigger's threshold? If the trigger's threshold is low, the signal's amplitude is so and the waveform is moving, whereas if the amplitude is high it becomes high itself and the waveform is more steady. I noticed this when I tested both the W2022A and W2012A for the pulse responce. Please, refer to my previous message here Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil4)" Mit Freundlichen Grüßen, Luc
Hallo Hayo et al, ich bin selber kurz vor Urlaub, da versuche ich doch mal eine Übergabe bevor ich die Software nicht mehr wiedererkenne, mit Hayos neuem Tatendrang! Der Status zur neuen Eingangsstufe ist wie folgt: - Im Gehäuse eingebaut habe ich keine Oszillation oder Einstreuung mehr. Das lag an meinem offenen Aufbau, der hat sich die Signale der Tastenplatine eingefangen. - Die Eingangsstufen sind empfindlich. Wogegen ist noch unbekannt, ESD oder Überspannung. In einem Meßbereich ohne die Relais-Vorteiler habe ich mir bei Kalibrierübungen mit kleiner Gleichspannung je den Eingangs-FET zerschossen. Mittlerweile habe ich von Kurt Ersatzteile und kann die unter kontrollierteren Bedingungen zerstören. ;-) - Jede Platine verbrät etwa ein Watt, größtenteils am Verstärkerchip. Der wird in freier Luft über 100°C heiß, in der engen Gehäuseposition sicher mehr. Wärmekontakt zu dem Stahlblech wäre gut, da liegt er eh fast an. - Die Hardwareansteuerung ist in der Software vollständig (Basis BF 3.0 C6), inklusive Programmierung der verschiedenen Gains (1/2/5) und der Bandbreitenbegrenzung. - die zur veränderten Empfindlichkeit passenden Skalierwerte in den Tabellen "ScaleFactor[]" und "DAC_ScaleFactor[]" fehlen noch. Ich habe Messungen gemacht, hatte aber noch keine Zeit das dort einzubauen. - an der Benutzeroberfläche habe ich nichts gemacht. Man kann also noch nicht einstellen, ob man neue Eingangsstufen hat. Das habe ich mir derzeit hart reincompiliert. - Die Software kann keinen echten "Mischbetrieb" der verschiedenen Eingangsstufen, mit dazu passender Skalierung. Ist zugegeben diskussionswürdig, ob das überhaupt sein soll und kann. An diesem prinzipiellen Problem scheitere ich erstmal und übergebe an Hayo. Ich habe zwar 4 Flags eingeführt (HasNewInputStage[4], die auch ins Flash kommen) und pro Kanal anzeigen, ob neue oder alte Eingangsstufe. Das wird in Hardware::SetSwitches() abgefragt und je nachdem die neue oder alte Routine aufgerufen. Das führt aber nicht so recht weiter, man müßte die Flags überall abfragen, wo derzeit die Variable "GainIdx" bewertet wird. Zu allem Übel wird an GainIdx auch noch "herumgefummelt", in Hardware::AutoScale() wird der vorübergehend auf 1 gesetzt. In einem weiteren Versuch habe ich ein Array GainIdx[4] gemacht, also ein Wert pro Kanal. Damit kam ich bis zu den Lookuptabellen "ScaleLookupTable[]" für die Anzeige, die quasi statisch sind. Ich habe noch nicht verstanden, warum es davon 2 Satz gibt, einen für die 1er und 2er Bereiche, und einen für die 5er Bereiche. (BTW, die Indizes sind ungünstig, wären besser vertauscht, damit der innere Zugriff schnell geht. Der letzte Index sollte die 0..255 Tabelle sein. Ferner würde ich diese Tabelle dynamisch berechnen, bei Bereichsumschaltung neu, und dann alles mit rein, incl. Clipping auf Displaygrenzen. Dann braucht die Zeichenschleife das nicht tun.) Nun ja, auch diese Tabelle müßte ich verdoppeln (einmal pro Eingangsstufe), vor dem Speicherverbrauch schreckte ich noch zurück. Mit einer Tabelle pro Kanal landet man da allerdings auch. Ein paar Bugs habe ich noch gefunden, ohne Rücksprache noch nicht korrigiert: 1.) in Hardware::RestoreFromFlash() statt: Hardware::SetSwitches(2, -1); besser: Hardware::SetSwitches(2, Selected_Voltage_CH2); 2.) Hardware::Start_Up() ruft immer AMDFlash::Write_Config_Flash() auf, das tut dem Chip wohl nicht gut. Nur nebenbei, in meinen Projekten habe ich mir angewöhnt, Flash oder EEPROM erst zu vergleichen, nur echte Veränderungen zu schreiben. Zudem nicht sofort, sondern nach einem Timeout, verhindert versehentliches Dauer-Schreiben. 3.) Die Offsetregler verhalten sich bei Extremwerten komisch, ich weiß aber nicht wo der Bug ist. Bei Kanal 3 kann ich den "überdrehen", die Offsetspannung springt von positiv nach negativ und umgekehrt. Ist wohl ein numerischer Wraparound. Bei Kanal 4 bleibt der Wert wie erwartet am Anschlag kleben, aber ich kann noch in eine Art wirkungslosen Bereich drehen. D.h. weitere Drehung hat zwar keinen Effekt, muß aber auch nach Umgekehr wieder zurückgelegt werden bevor der Offset wieder sinkt. Genug für heute, den Sourcecode hänge ich morgen an. Grüße an nah und fern, Jörg
Hallo, wird mir jetzt zeitlich doch arg knapp, deshalb kann ich hier nur noch einen "Snapshot" hochladen. Ich wollte dass eigentlich noch besser aufbereiten. Jörg
Back from Thailand! Und auch schon wieder aktiv... @Luc I guess it is another matter, but I will check this. Thanks for Your hint. @Jörg Das sind eine ganze Menge Hinweise und offene Fragen. Ich werde die mal durcharbeiten und versuchen alle zu prüfen/beantworten. Mal sehen was ich schon einbauen kann. Schönen Urlaub. Gruß Hayo
Hi there! Welcome back Hayo! @Hayo I guess it also and about another matter, I noticed that waveforms shape are crude and not smooth compare to other DSO when I tested both the W2022A and the W2012A for the pulse responce. Is maybe this due to the sin(X/X)'s lack? I guess the poor graphic representation problem might just to be due up to now there is not a sin(X/X) interpolation available. What about this? Gute Sonntag für alle. Mit Freundlichen Grüßen, Luc
Hallo allerseits,
kurzer Report zum aktuellen Stand. Die neue USTB-Engine läuft bereits.
Zur Zeit mache ich noch Fein-Tuning und implementiere die neuen Menüs.
(den Fehler in der alten C6 der die USTB-Funktion blockiert hat habe ich
gefunden und beseitigt).
Wer das in der Zwischenzeit für sich korrigieren möchte:
- in der hardware_t.cpp -> Methode Start_Record habe da leider was
"kaputt optimiert". Richtig muß es so aussehen:
void Hardware::Start_Record(void)
{
if(acq_ready->np_piodata == 0x01)
{
la_pulse->np_piodata = 0x01; //stop record Port On
la_pulse->np_piodata = 0x00; //stop record Port Off
}
READADC(1);
if (NumberOfChannels == 4) // JK
{ READADC(3); } // JK
ADC_Data_Available = 0;
adc_started = true;
start_acq->np_piodata = 0x01; //start record Port On
start_acq->np_piodata = 0x00; //start record Port Off
//printf("Start Record\r\n");
}
Zu den neuen Errungenschaften von Jörg bin ich noch nicht gekommen, ist
aber im nächsten Final Release auf jeden Fall mit drin.
Auch die Cursor und die Werteanzeige im Delayed Modus stehen noch auf
dem Pflichtenzettel.
@Luc
Hi, I'm sorry but until now I didn't check Your problem because I'm
working on the new USTB engine which is just working with its main
functions. I will check that and - if possible - fix it for the next
main release.
Gruß / regards
Hayo
Hayo W. schrieb: > Vorab noch ein Fix zum Spikeproblem dass Luc gemeldet hatte. Diese FW-Revision hab ich jetzt auf dem 2024 drauf und kämpfe gerade ein wenig mit der Single-Shot-Funktion. Wahrscheinlich verstehe ich nur an der Bedienphilosophie etwas verkehrt, vielleicht kann mir ja einer auf die Sprünge helfen. Ich habe auf Ch1 mit 2V/div und bei 10MSa/s (glaube ich, ich habe da gar nicht so genau drauf geachtet, weil ich einfach nach optischen Gesichtspunkten so lange dran gedreht habe, bis das Signal schön formatfüllend aussieht ;-)) an einem CAN-Bus gehorcht und wollte das Datagramm direkt nach dem Einschalten fangen. Also habe ich den Single-Knopf gedrückt und beim ersten Versuch fängt das Scope die erste Flanke meistens wunderschön (das klappt aber nicht immer, und das auch ganz ohne für mich nachvollziehbares Muster). Wenn ich Single erneut drücke, um die nächste Flanke zu fangen, steht das Scope ewig scharfgeschaltet da und der Singleknopf leuchtet rot. Ich habe es noch ab und zu hinbekommen, dass wieder eine Flanke gefangen wird, wenn ich (teils mehrmals) Run/Stop drücke und dann erst wieder Single. Der Triggerlevel steht ca. bei 60-70% der Signalamplitude. Wenn ich das Ganze mit Tippen des Tastkopfes an Probe Comp versuche, klappt das Fangen auf jeden Fall öfter, aber auch nicht immer. Daraus schließe ich, dass es entweder mit der Abtastrate zu tun hat oder ich irgendwas verkehrt mache. Wo klemmt's?
Hallo Johannes, da ich sowieso gerade die Start/Stop Funktion für die neue USTB-Engine überarbeite, kann ich mir das mal ansehen. Kann sein, dass der Fix den ich oben als Code gepostet hab das Problem schon löst. Ansonsten bräuchte ich noch Deine Triggereinstellungen. Am besten einen Screenshot mit dem Triggersubmenü drauf (Quick Print doppelt drücken) posten. Ansonsten komme ich gut voran obwohl es noch einiges anzupassen gibt. Gruß Hayo
Das große Schweigen im Walde... Um nicht den Verdacht zu nähren ich würde faul rumhängen hier ein kurzer Zwischenstand. Ich bin seit drei Wochen fleißig am Programmieren und es hat sich sehr viel getan. Aktueller Versionsstand ist 3.3 beta. Bis zum Final Relase 4.0 HE gibt es aber noch viel zu tun. Ich hoffe ich bin zum Ende der Sommerpause fertig. Da dürfte wieder für jeden was dabei sein... For our "out country" friends... ;-) I'm working hard on the next final release 4.0 HE. Many things have been changed or fixed. I hope to be ready after german holidays. I think You will like it... Gruß / regards Hayo
der Hayo, es lebt... :-)) und 'nein', du bist wohl das Letzte, der Letzte, was faul rum hängt. :-) Mal eine kleine Kostprobe von dem, was du verändert hast? Ansonsten wünsche ich noch einen schönen Sonntach! Gruß Michael
das wuerden wir doch nieee von dir denken Hayo, ich bin auch fuer eine kleine Kostprobe, und haste auch an mich gedacht ? (STB & Single) vlG Charly
Moin moin, da ich gerade größere Umbauten an der Menüstruktur vornehme, ist die 3.3 zur Zeit nicht lauffähig. Daher hier die 3.2 beta die schon Einiges zu bieten hat. Bitte beachten - da sich recht viel geändert hat mußte ich wieder einen Config-Reset durchführen. Ihr müßt also beim ersten Start neu kalibrieren und die Hardwareeinstellungen neu machen. Hier in Kürze die Neuerungen: - Math gefixt - Zeichenroutinen sind nochmals schneller geworden - es gibt eine neue Funktion "Center Window" im Displaymenü, die den Bildschirmausschnitt bei normalen TB auf den Pretrigger zentriert und bei USTB auf den aktuellen Samplezeitpunkt. - neue USTB-Engine V2.1 mit 16K Signalbuffer. Sehr viel höhere Zeitgenauigkeit, unterstützt Memorybrowser, volle Zerolevelunterstützung, Math-Unterstützung, Quick Print Datenübertragung wird unterstützt, Invertierung wird unterstützt, Details im changelog Über Vorabtestberichte und Fehlerreports freue ich mich natürlich wie immer. Gruß und viel Spaß Hayo
@Charlie Die kleineren Fixes und Änderungen und auch die Hardwareunterstützung von Jörg kommen erst wenn die größeren Umbauten beendet sind. Daher auch der beta-Status. Gruß Hayo
Thread beobachten
Seitenaufteilung abschalten