Ist aufgrund der geringen Speichertiefe pro Kanal leider nicht realisierbar. So wie es ausschaut selbst mit dem neuen LEON-Design auf unserer Hardware-Plattform nicht umsetzbar. branadic
Hi Hayo and guys all! Hayo schrieb: > So hier wie angekündigt die C15 > > - einige neue Fixes Hayo, only as a curiosity, has been the external trigger improved? I think that now it functions much better. Vielen Dank!!! Gruß Luc
Hi, beim weiteren Ausprobieren der neuen Funktionen gefiel mir das Scrollverhalten der Triggerlinie nicht. Daher bin ich zur Zeit dabei das zu verbessern. Weiterhin wird derzeit das Invertierte Signal nicht richtig unterstützt - ist in Arbeit und gibt es nachher. Leider fallen einem durch die genauere Anzeige mit der Linie auch einige Unzulänglichkeiten des Triggers mehr ins Auge - ist ebenfalls in Arbeit, wird aber wohl heute nicht mehr fertig da ich auch noch einige echte physische Baustellen hier habe die ich abarbeiten muß. @Luc All trigger functions have been modified a little bit since last 3 versions so it may be that something changed in the behaviour of the external trigger. Hayo
nur als Hinweis - in der Bucht gibt es wieder welche(man, die müssen ja ein Lager gehabt haben).
Na dann kriegen wir hier ja bald wieder Zuwachs... Hayo
Hallo boys!:) Luc writes: With some oscilloscope models amplitude adjustment (Volt/DIVS) may be going out of calibration passing from coarse to fine and vivecersa, this can be helpful in the manually measure of the rise or fall time. Uhmmm, good idea, is no bad to have selectable resolution of the Volts/Div knob (coarse as a 1–2–5 sequence and fine as to small steps between the coarse settings), but perhaps it's impossible. Hayo writes: Seht mal im Edge-Menü nach und spielt mal mit dem Triggerlevel. Mir gefällt das ganz gut. Ich hoffe es kommt bei Euch auch so gut an. Very nice, thanks!:) weitererGast writes: 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. I don't understand, what you mean? Also Hayo's answer isn't clear for me, please help about this. branadic writes: Ist aufgrund der geringen Speichertiefe pro Kanal leider nicht realisierbar. So wie es ausschaut selbst mit dem neuen LEON-Design auf unserer Hardware-Plattform nicht umsetzbar. Interesting considerations. What about LEON-Design? Is there a tutorial to upload LEON? Where? And about the read elsewhere pickaback is there a tutorial? Luc writes: Hayo, only as a curiosity, has been the external trigger improved? I think that now it functions much better. Uhmmm, I don't see differences. And finally, what about LED mods, what is it? Saluti from Italy. Antonio.
Hi @all die aktuellen Neuerungen habe ich leider heute nicht mehr fertigbekommen, aber ich versuche mal morgen die neuie Version fertigzustellen - überarbeitetes Scrolling der neuen Triggerlinie - neu überarbeitete Zerolinemarker Routine - gefixte Zeroline Marker im Delayed Mode (y-Position war falsch) I did not get the new version ready today but tomorrow it should be available. Changes as above. Hayo
Hi Antonio! > Luc writes: > With some oscilloscope models amplitude adjustment (Volt/DIVS) may be > going out of calibration passing from coarse to fine and vivecersa, this > can be helpful in the manually measure of the rise or fall time. > > Uhmmm, good idea, is no bad to have selectable resolution of the > Volts/Div knob (coarse as a 1–2–5 sequence and fine as to small steps > between the coarse settings), but perhaps it's impossible. I have that function on my analog oszis, but it may be a little bit tricky to realize it on our Welec-DSO. > Hayo writes: > Seht mal im Edge-Menü nach und spielt mal mit dem Triggerlevel. Mir > gefällt das ganz gut. Ich hoffe es kommt bei Euch auch so gut an. > > Very nice, thanks!:) It is only the first try (the trigger line). The scrolling is bad and inverted signal and delayed mode are not supported correctly. In the next version it will be implemented correctly. > weitererGast writes: > 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. > > I don't understand, what you mean? > Also Hayo's answer isn't clear for me, please help about this. 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. > branadic writes: > Ist aufgrund der geringen Speichertiefe pro Kanal leider nicht > realisierbar. So wie es ausschaut selbst mit dem neuen LEON-Design auf > unserer Hardware-Plattform nicht umsetzbar. > > Interesting considerations. > What about LEON-Design? > Is there a tutorial to upload LEON? > Where? > And about the read elsewhere pickaback is there a tutorial? I think on the hardware thread You may be lucky. Branadic is one of the "knowing" guys there. Beitrag "Wittig(welec) DSO W20xxA Hardware" > Luc writes: > Hayo, only as a curiosity, has been the external trigger improved? > I think that now it functions much better. > > Uhmmm, I don't see differences. may be dependent of the circumstances > And finally, what about LED mods, what is it? See also the hardwarethread. Beitrag "Re: Wittig(welec) DSO W20xxA Hardware" we added two LEDs at the trigger range on the front pannel which are indicating a waiting trigger and a trigger event. The mod is is very easy and nice to see! There are some more mods about that described there. > Saluti from Italy. > Antonio. Saluti from Hamburg (Germany) Hayo
Hello Hayo. Hayo writes: > Uhmmm, good idea, is no bad to have selectable resolution of the > Volts/Div knob (coarse as a 1–2–5 sequence and fine as to small steps > between the coarse settings), but perhaps it's impossible. I have that function on my analog oszis, but it may be a little bit tricky to realize it on our Welec-DSO. In fact, I have seen it only in analog oscope. Are you saying that, although with difficulty, could be added to the Wittig? Nice!:) Hayo writes: 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. Clear, thanks a lot!:) Hayo writes: I think on the hardware thread You may be lucky. Branadic is one of the "knowing" guys there. Beitrag "Wittig(welec) DSO W20xxA Hardware" I'll give it a look, I have some questions, thanks. Hayo writes: > Uhmmm, I don't see differences. may be dependent of the circumstances I already know is a hardware lack and can't be corrected by the firmware, I only see the crazy way in which levels change by turning the trigger level knob: 0mV, 100mV, 300mV, 350mV, 700mV, 1,25V and so:( ...and you must use the normal trigger:( Hayo writes: we added two LEDs at the trigger range on the front pannel which are indicating a waiting trigger and a trigger event. The mod is is very easy and nice to see! Ok, thanks. Good for 4 channel Wittig oscope, but in 2 channel type there are already the CH 3 and CH 4 LED, why not use them? And anyway isn't more easy add icons on the screen? Hayo writes: Saluti from Hamburg (Germany) Maybe you don't know but here in Italy you have many fans!:) There's even a group that talks about your work!:) Unfortunately it's currently not very active:(, it dozes, but as exit news after the people awake!:) Saluti, Antonio.
Antonio schrieb: > Ok, thanks. > Good for 4 channel Wittig oscope, but in 2 channel type there are > already the CH 3 and CH 4 LED, why not use them? > And anyway isn't more easy add icons on the screen? yes this suggestion was made by some guys here too. I could do it for those who want to test it without modifying the scope. > Maybe you don't know but here in Italy you have many fans!:) > There's even a group that talks about your work!:) > Unfortunately it's currently not very active:(, it dozes, but as exit > news after the people awake!:) That is nice to hear. So many regards to them from the german forum. Saluti, Hayo
Hallo Hayo, Hayo W. schrieb: > I could do it for > those who want to test it without modifying the scope. macht das wirklich Sinn oder trennen sich die Versionen der 2 und 4 Kanalgeräte dann? Wenn man schon mit dem Gedanken spielt eine Huckepackplatine nachzurüsten, dann sollten die LEDs doch wohl die kleinere Übung darstellen. branadic
Ich hatte da drei Ansätze, - einmal eine Spezialversion, die fest die LED der Kanäle 3 + 4 ansteuert, damit alle das ausprobieren können. - dann eine hardwareabhängige Version, die nur bei Zweikanalgeräten die LED von Kanal 3 + 4 ansteuert. - ein Auswahlmenü im Hardwaremenü, wo man dann beliebige Knfigurationen aussuchen kann. Letzteres hatte ich ohnehin schon angedacht um die LED bei Bedarf abschalten zu können wenn einem das Gflackere auf den Keks geht. Allerdings muß ich sagen, dass die LED schon einige Mal recht Hilfreich waren. Gruß Hayo
Ok, hat etwas länger gedauert, aber hier ist sie die C16. Die Zero-Marker Routinen sind komplett überarbeit und der Bug im Delayed Mode ist beseitigt. Die Positionen stimmen jetzt. Weiterhin ist die neue Triggerlinie jetzt vollständig implementiert und das Scrolling optimiert. Das ist gar nicht so einfach, da man hierfür in zwei unterschiedliche Graphiklayer pro Kanal schreiben muß um ein Flimmern zu vermeiden. Die Darstellung von Zero-Markern und Triggerlinie ist doch aufwändiger als man so denken sollte - die Funktion hat mehr als 1800 Zeilen Code (abzüglich Leerzeilen). Das erklärt auch den Zeitaufwand, denn ich bin im Prinzip jede einzelne Zeile durchgegangen und habe optimiert bzw. geändert. Wenn ich das vorher gewußt hätte... So und als kleines Schmankerl hab ich noch was ins Hardwaremenu eingebaut. Die LED-Steuerung ist jetzt tatsächlich einstellbar. Wer also mal ohne Modifikation die Trigger-Indikatoren testen will kann hier die Optionen "Map CH3" bzw. "Map CH4" wählen. Viel Spaß Hayo
Angehängte Dateien:
-
TriggerAutoLevel.GIF
15 KB
Hi Hayo, wieder mal eine tolle Arbeit von dir. Der Trigger Auto Level funzt nicht im Channel Center modus, bei beiden Kanälen! Sobald einer der Kanäle im Center Modus sind und dann Trigger Auto Level betätigt, geht der Level unter das Signal. Siehe Shot. Wenn nur ein Kanal aktiv ist und dieser im "Center" ist, lässt er sich nicht wieder in die Ausgangsposition bringen, das war bei der C15 auch schon so. Gruß Michael Edit: Noch was, ...schaltet man die Trigger-LED's im HW-Menu um, bleibt die LED von Kanal 3 an und geht nicht wieder aus, die LED von Kanal 4 hingegen erlischt, so wie es sein sollte!
Alles klar, danke für den schnellen Test und Feedback. Gruß Hayo
Ach ja noch eine Frage, da wir ja jetzt per Menu die LED-Funktionen steuern können, hat noch jemend eine Idee was man noch an sinnvollen Ereignissen oder Zuständen mit den LEDs anzeigen kann? Hayo
Michael D. schrieb: > Der Trigger Auto Level funzt nicht im Channel Center modus, bei beiden > Kanälen! > Sobald einer der Kanäle im Center Modus sind und dann Trigger Auto Level > betätigt, geht der Level unter das Signal. > Siehe Shot. Hmm, ich kriege Dein Problem nicht nachgestellt. Bei mir funktioniert alles wie es soll. Gib mir mal nen Tip was ich machen muß damit Dein Problem auftritt. > Wenn nur ein Kanal aktiv ist und dieser im "Center" ist, lässt er sich > nicht wieder in die Ausgangsposition bringen, das war bei der C15 auch > schon so. Auch hier kann ich das Problem nicht nachstellen. Nach dem Zentrieren kann ich den Level in beliebige Positionen kurbeln. Nur noch mal zur Info falls hier ein Mißverständnis vorliegen sollte: Wenn nur ein Kanal aktiv ist, dann ist Dispatch Channels = Center Channel, da das ja dann die optimale Verteilung auf dem Screen ist. > Gruß Michael > > Edit: Noch was, > ...schaltet man die Trigger-LED's im HW-Menu um, bleibt die LED von > Kanal 3 an und geht nicht wieder aus, die LED von Kanal 4 hingegen > erlischt, so wie es sein sollte! Fehler ist schon lokalisiert und beseitigt. Kommt heute Abend mit dem nächsten Update. Hayo
Hayo W. schrieb: > Michael D. schrieb: > >> Der Trigger Auto Level funzt nicht im Channel Center modus, bei beiden >> Kanälen! >> Sobald einer der Kanäle im Center Modus sind und dann Trigger Auto Level >> betätigt, geht der Level unter das Signal. >> Siehe Shot. > > Hmm, ich kriege Dein Problem nicht nachgestellt. Bei mir funktioniert > alles wie es soll. Gib mir mal nen Tip was ich machen muß damit Dein > Problem auftritt. > Ok, Kanal 1=Centermodus, Kanal 2=Centermodus. Jetzt sind beide Signale (1KHz-Prob) im Center. Jetzt "Triggerauto-Level drücken dann haut die Levellinie nach unten ab! Natürlich kann ich dann den Triggerlevel manuell korrigieren, sollte jedoch automatisch in die richtige Levelpos. gehen, oder? >> Wenn nur ein Kanal aktiv ist und dieser im "Center" ist, lässt er sich >> nicht wieder in die Ausgangsposition bringen, das war bei der C15 auch >> schon so. > > Auch hier kann ich das Problem nicht nachstellen. Nach dem Zentrieren > kann ich den Level in beliebige Positionen kurbeln. Jetzt meine ich nicht den Triggerlevel, sondern den Center-Modus! Ich habe nur "einen" Kanal aktiv, bringe diesen mit dem Softkey in die Centerpos.! Drücke ich "Dispatch Channels", müsste er doch wieder in die Grundstellung gehen??? Dies funzt nur, wenn beide Kanäle aktiv sind, dann gehen beide Kanäle vom Center Modus auch wieder in die Grundstellung. > > Nur noch mal zur Info falls hier ein Mißverständnis vorliegen sollte: > Wenn nur ein Kanal aktiv ist, dann ist Dispatch Channels = Center > Channel, da das ja dann die optimale Verteilung auf dem Screen ist. Das heißt, das dieser Kanal dann im Center bleibt? > >> Gruß Michael >> >> Edit: Noch was, >> ...schaltet man die Trigger-LED's im HW-Menu um, bleibt die LED von >> Kanal 3 an und geht nicht wieder aus, die LED von Kanal 4 hingegen >> erlischt, so wie es sein sollte! > > Fehler ist schon lokalisiert und beseitigt. Kommt heute Abend mit dem > nächsten Update. > > Hayo
Angehängte Dateien:
Hallo Hayo, gehe mal volgendermassen vor: Aktiviere beide Kanäle, gib das 1KHz Prob-Signal drauf. Shot 1 Drücke "Trigger Auto Level" (Alles ist hübsch) Verschiebe z.B. Kanal 1 in eine andere Position des Display's (nach oben oder unten), Drücke jetzt wieder "Trigger Auto Level", jetzt geht der Trigger-Level in die Mitte des Display's und das Signal zappelt ab. Shot 2 EDIT: Sicher kann ich den Trigger-Level manuell korrigieren. Die Funktion Trigger Auto Level sollte ja dies Automatisieren, oder? Gruß Michael
Ok ich hab's, das hängt mit der Zeitbasis zusammen, deshalb hat es bei mir alles funktioniert und bei Dir nicht. Ab 25 MSa/s (10µs) hin zu niedrigeren Abtastraten tritt das Problem auf. Vermutlich liegt das irgendwie am Speicherbereich der für die Berechnung verwendet wird. Ich check das! Hayo
Die Sonntags-Edition C17 hat jetzt eine nochmal überarbeitete Auto Level Routine. - die Probleme bei TB < 25 MSa/s sind gefixt - es werden jetzt auch invertierte Signale mit DC-Offset unterstützt - die gemapten LED von Channel 3+4 werden jetzt korrekt zurückgesetzt Die nächste Zeit bin ich wegen einiger IT-Projekte seltener zu Hause und bin daher hier erstmal nur noch Abends online. Gruß Hayo
WOW is das ruhig geworden........... dann fang i mal wieder an, mein liebling der Single mode Single gedrueckt, dann eine sofkey (unterm display) dann triggert er nicht mehr ;( Single gedrueckt, dann Ch1 oder Ch2 dann geht Single aus unn er triggert auch nicht mehr ;( was i sonst so probiert habe Hayo, super, tnx! vlg Charly
Hi Hayo, Antonio and guys all! First, thanks You very, very much Hayo for the great job and free time You provided generously to us!!! Hayo, I tried your new BF20_prev_C17 release and about it I have a few things to say. Hayo W. schrieb: > - die gemapten LED von Channel 3+4 werden jetzt korrekt zurückgesetzt I did not expect it to be so useful, maybe because I usually do not watch the READY and TRIGGERED indicators when I use other oscilloscopes, but with Welec there are situations where they become valuable: for example in the EXTERNAL TRIGGER's use (for this also see below, please). In my opinion this happens because with the EXTERNAL TRIGGER use in the Welec the NORMAL trigger is preferable so visual trigger's indication helps a lot. I have the two channels DSO version so also without any modification the two LEDs are well visible and the new feature works great just need to activate it in the HARDWARE menù! So simple and so useful, now I can not do without TRIGGERED and READY indicator ! Great job Hayo!!! Also about LEDs improvement: @Antonio Antonio schrieb: > Good for 4 channel Wittig oscope, but in 2 channel type there are > already the CH 3 and CH 4 LED, why not use them? > And anyway isn't more easy add icons on the screen? Hi Antonio. About your last question, I believe the use of two LEDs is better of the on screen icons because I believe that icons slow the DSO. You can realize it by yourself looking at the DSO's behavior with 1 and 2 channels and using the automatic measurements and cursors: more are things on the screen and most the DSO is not fast, I think an updated icon with the trigger time slow down a lot of the DSO, much better the two LEDs. Hayo W. schrieb: > - die Probleme bei TB < 25 MSa/s sind gefixt > - es werden jetzt auch invertierte Signale mit DC-Offset unterstützt Hayo thank You very much also for this! A clarification about a my previous related reply. It is true there were some small problems, problems I had not noticed, however what I have expressed about the implementation goodness it was more related to the way in which the desired result was obtained. In those circumstances I repeat again: Luc schrieb: > Longer I use the two new functions (SET LEVEL TO 50% and TRIGGER VIEW) > and more I am pleased with them. > I think the way they are implemented is truly brilliant, definitely much > better than what Tektronix did for his oscilloscopes TDS200, TDS1000 and > TDS2000 family. > In fact, in this case TRIGGER VIEW is always active, which is good, and > so You save a button! > Of course all of this in my humble opinion. As I mentioned above, now let's talk a little about the EXTERNAL TRIGGER and some things I have found. In order to test the EXTERNAL TRIGGER I bought a simple and inexpensive function generator. This my new tool provides sine , square and triangular waves with frequency up to 2MHz and amplitude up to 10Vpp on 50 ohm load. With it, also thanks to the implemented READY and TRIGGERED LEDs, I saw now for my purpose the EXTERNAL TRIGGER work fine, while before did not always happen to me. I do not think it is luck, before it did not work even with the 1KHz probe's compensation signal, now it works also with the signal generator and other signals. Of course I have to use the NORMAL trigger and the level adjustment is a bit difficult, however the EXTERNAL TRIGGER works. For exampe I put CH1 on clock, CH2 on data and EXTERNAL TRIGGER on the chip select of a 25AA010A SPI EEPROM and I able to see all the data packet. But I sometimes noticed that the little bug in the Mode/Coupling button reappears. When External Trigger or LINE is selected in the EDGE menù, COMBI mode item becomes unavailable in MODE COUPLING menù. COMBI item turns gray and can not be selected in MODE menù by the softkey, with the softkey is only possible to select NORMAL and AUTO in MODE menù. But repeatedly pressing the MODE COUPLING softkey You can set the COMBI parameter, as well as NORMAL and AUTO. when this happens the EXTERNAL TRIGGER stops working, READY and TRIGGERED LEDs working properly then the trigger is successfully acquired, but on the screen waveforms are not triggered. By changing the trigger source to CH1 or CH2, and then putting it as EXTERNAL TRIGGER sometimes the COMBI MODE bug's problem is fixes, other times it remains, however, the EXTERNAL TRIGGER stops working and to make it back to work You must perform a reset. Still about the EXTERNAL TRIGGER, although this has nothing to do with the COMBI MODE's problem, seems to me EXTERNAL TRIGGER work only with positive signals but I must pursue the matter. With respect to other: Hayo W. schrieb: > - neu überarbeitete Zerolinemarker Routine Hayo, about this I now noticed sometimes ADC and DAC calibrating is not working well, the offset is difficult to remove even after warmup and in AQUIRE menù You can not change the filters setting so You press the softkeys but nothing happens: reset fix the problem. I do not know if this is important, however I always have the noise filter activated. Passing over. Hayo W. schrieb: >> Antonio writes: >> Uhmmm, good idea, is no bad to have selectable resolution of the >> Volts/Div knob (coarse as a 1–2–5 sequence and fine as to small steps >> between the coarse settings), but perhaps it's impossible. > I have that function on my analog oszis, but it may be a little bit > tricky to realize it on our Welec-DSO. Oh, well Hayo, this makes me hopeful. Hayo, as usual these my observations do not want to be a criticism nor a imperative for any corrections. When You're free and especially when You want to do this take a look around to what I written. I repeat it is not an obligation, You do it only if You want to do it. I think You have already done a lot for us and for this I'll never stop thanking You Hayo!!! Now enjoy a deserved rest!!! Hayo again many thanks to You, really thanks very much!!! RESPECT!!! Vielen Dank!!! Gruß Luc
Hi Antonio and guys all! Antonio schrieb: >>> Uhmmm, good idea, is no bad to have selectable resolution of the >>> Volts/Div knob (coarse as a 1–2–5 sequence and fine as to small steps >>> between the coarse settings), but perhaps it's impossible. >> I have that function on my analog oszis, but it may be a little bit >> tricky to realize it on our Welec-DSO. > > In fact, I have seen it only in analog oscope. Not only analog oscilloscopes have that function, for example TDS220 DSO's by Tektronix and other have it. The problem is that since the implementation of the SET LEVEL TO 50% and TRIGGER VIEW functions required 1800 lines of code Hayo schrieb: > Die Darstellung von Zero-Markern und Triggerlinie ist doch aufwändiger > als man so denken sollte - die Funktion hat mehr als 1800 Zeilen Code > (abzüglich Leerzeilen). I dare not think how many are needed to implement the function of the COARSE and FINE in the Volt/DIV's knobs!!! Other things are interesting and perhaps easier. Michael D. schrieb: > Ich hätte da mal einen Vorschlag: > im Quickmeasure sowie im Curserbereich, stehen fett und breit, 3x > Messbereiche zur Verfügung! > Wäre es möglich, diese Anzeigen um ein Drittel (Breite)zu verkleinern > und einen vierten Messbereich dazu zzu nehmen? Genug Platz ist ja > voranden. 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. However, if one day the COARSE and FINE function will be included also it would not be bad.;-) Unlucky for the DPO (Digital Phosphor Oscilloscopes) feature. Mirko B. schrieb: > Jetzt die Frage - kann man mit dieser Hardware so etwas wie "Digitales > Phosphor" per Software realisieren? branadic > Ist aufgrund der geringen Speichertiefe pro Kanal leider nicht > realisierbar. So wie es ausschaut selbst mit dem neuen LEON-Design auf > unserer Hardware-Plattform nicht umsetzbar. However hats off to the hardware guys in the forum, it is amazing to know They also had arrived to assess the possibility of being able to transform the Welec's DSO in to a DPO! VERY IMPRESSIVE!!! Anyway we'll see, surely we will see beautiful things!:-) I think for now We can be satisfied with what these amazing guys have made available to us, so many, many thank to all Hardware and Software guys and to all those who contributed to achieve these great results: THANKS TO ALL YOU!!! Vielen Dank!!! Gruß Luc
Hi Charly hi Luc, Eure Posts habe ich notiert, sind also in Arbeit. Leider bin ich momentan tagsüber ziemlich eingespannt und komme nur abends zum Programmieren. Zur Zeit baue ich den USTB-Mode (TB > 500ms) um, da dieser, wie einige von Euch sicher bemerkt haben, durch die schnelleren Zeichen und ADC Routinen völlig aus dem (Timing) Tritt gekommen ist. Also nicht wundern wenn ich mich hier etwas rahr mache. I took notice of Your posts and the bugs are under construction, also the new Ideas for some additional functions. At the moment my time is a little bit limited. So don't wonder if I am answering not so quickly. Actually I'm redesigning the USTB-Mode (TB > 500ms) which is not running correctly since I speeded up the drawing and ADC routines some Cxx versions before. Grüße saluti regards Hayo
Hallo miteinander, da es immer wieder angesprochen wird: es ist sehr nützlich, wenn man die x- und y-Einheiten variabel machen kann, z.B. um beim Betrachten eines V24-Signals genau 1 - 4 Bits pro Kästchen sehen kann. Der LeCroy kann das zwar im Main-Display nur in y-Richtung, aber im Zoom-Display kann man sowohl x als auch y stufenlos zoomen. (Leider ist dort das Umschalten stufig / stufenlos umständlich (Menü muss geöffnet werden). Es wäre traumhaft, wenn der Zoom-Knopf auch eine Drückerfunktion hätte.) Dazu habe ich mal eine kleines DOS-C programm gesschieben, wie ich mir das vorstelle. Habe ich leider gerade nicht zur Hand, schicke ich aber demnächst. X-Richtung funktionert auf DDS-Basis, der Index in das Sample-Array wird mit DDS erzeugt, ähnlich wie der lineare Bresenham. Das ganze ist so einfach, dass man es kaum glaubt. Y-Richtung ist eine einfache Multiplikation. Ich habe keine Ahnung, in wieweit stufenlos überhaupt bisher implementiert ist. Da ich überraschende Reaktionen mit meiner LED-Idee ausgelöst habe, könnte ich mir vorstellen, dass aus dieses nette Feature Anklang findet.
ich habe auch noch einen Bug: Szenario: alle 4 Kanäle am Rechteck Ausgang Schalten in den Delayed Mode an der Zeitbasis rumdrehen (da passiert bei mir nur ca. bei jedem 3. drehen überhaupt was)...irgendwann hat man dann Artefakte im Signal (auf allen Kanälen) - Triggerung ist auch nicht stabil Schalte ich dann zurück zu Main, ist immer Kanal 2 um ca. eine halbe Phase verschoben! Dies ändert sich auch nicht, wenn ich das Oszi aus und ein schalte. Nach einem Default Setup ist dann wieder alles ok. Trotzdem schon sehr schön - die automatische Anordnung der aktiven Kanäle auf dem Display war das was ich immer vermisst haben (aber noch nicht wusste ;-)) Viele Grüße, Mirko
Hi Hayo and guys all! Hayo W. schrieb: > I took notice of Your posts and the bugs are under construction, also > the new Ideas for some additional functions. At the moment my time is a > little bit limited. So don't wonder if I am answering not so quickly. Hayo, again thanks You very, very much for the kind assistance and free time You provided generously to us!!! I do not want to be boring and I do not want to appear rude, but I have another request. Since we are talking about new ideas for some additional functions I try, so please excuse me Hayo and excuse me all. I'm playing around the EXTERNAL TRIGGER and I ask me if possible to add displaying of the EXTERNAL TRIGGER on the DSO's screen. I do not mean show the EXTERNAL TRIGGER's level, I mean show the EXTERNAL TRIGGER's waveform on the screen. Some oscilloscopes (for example the TDS220 by Tektronix) have this function, pushing a button on the oscilloscope's screen appear the EXTERNAL TRIGGER's waveform. I hope You understand what I mean. I do not know if it is possible or not, nor if it is hard to do, mine is only just an idea so sorry to all. Hayo again many thanks to You for the kindness and patience! Vielen Dank!!! Gruß Luc
wäre ein schönes feature - aber meine Meinung ist -erst die Pflicht, dann die Kür- will heißen, Bugfixing geht vor. Da aber da ja alle (vor allen Dingen Hayo) hier aus Spaß an der Sache dabei sind, sind natürlich Ausnahmen legitim. Viele Grüße, Mirko
Hi eProfi and guys all! eProfi schrieb: > Da ich überraschende Reaktionen mit meiner LED-Idee > ausgelöst habe, So You've had the excellent idea of the LEDs... ...many thanks eProfi! Vielen Dank! Gruß Luc
Hi Luc, as fare as i remember the circuits, this won't be possible. The external triggersection is a seperated circuit working around ttl-levels and tv-triggering. It's output isn't wired to the adc's input but one of the fpga's inputpins directly. Regards, Guido
So, im Anhang das TurboC-Programm ddsScope. Das Programm berechnet einen virtuellen Wellenzug (linear abklingender Sinus) mit 16k Samples. Tastenfunktionen: a,s,d,f: nach links scrollen (verschiedene Schrittweiten) g : zurück ins Zentrum (Sample 8192) h,j,k,l: nach rechts scrollen (verschiedene Schrittweiten) y,x,c,v: x Zoom in b : x Zoom reset n.m,,,.: x Zoom out A,S,D,F: y scroll up G : y scroll reset H.J.K.L: y scroll down Y,X,C,V: y Zoom out B : y Zoom reset N,M,;,:: y Zoom in Enter : redraw Grid Esc : quit Program Wie die Zeit vergeht, habe ich vor 14 Monaten programmiert. Berichtet mir, ob das auf den modernen PC überhaupt noch läuft. Guten Appetit.
Hallo, ich wollte generell mal fragen, ob das Scope denn mittlerweile einigermaßen zu dem gebrauchen zu ist, wozu es eigentlich mal gedacht war - nämlich messen? Ich habe zwar schon viel in den entsprechenden Threads gelesen, aber da braucht man ja mittlerweile mehrere Tage für, wenn man die von oben bis unten durchlesen und dann auch noch verstehen will. Nach dem, was ich hier lese, scheint die FW ja mittlerweile schon recht weit zu sein (wenn Luc sogar schon erste Vergleiche mit LeCroy anstellt). Wie ist denn im Moment die Geschwindigkeit der Darstellung, die Reaktionszeiten auf die Bedienelemente usw.? Bei YouTube findet man ja nur Videos mit der Originalen FW (furchtbar langsam) oder mit dem neuen VHDL Design (Sauschnell). Nach dem Abrauchen meines alten 5MHz Scopes klingt das Welec ganz verlockend: ein Scope (das, wenn es denn taugt, eh nicht mehr als vielleicht max. 10MHz sehen wird) und eine nette Spielwiese in einem... ;-) Schönen Gruß an die fleißige Community.
Moin, ist ein bisschen OT, aber mal eine Frage an die 'Wittig Gurus' was ist der unterschied zw. dem 2012 und 2022, ausser jetzt das das 2022 ein 200 Mhz ist, ist das teil wirklich viel besser und was ist mit der bedienung ? ist die genauso zaeh wie beim 2012 ? vielen dank & ein schoenes WE Charly
Hallo Charly, bei den Untersuchungen in der Anfangsphase dieses Projektes konnte ich keinen HW- Unterschied zwischen den Modellen 2022A u 2012A feststellen. Wenn du die unter SF veröffentlichten Schaltpläne betrachtest, dann siehst du das es nur einen für das Modell 2022A UND 2012A gibt. Der Einzigste Unterschied der meines Wissens bis dto. offenkundig ist, sind die besseren Tastköpfe beim 200MHz Modell. Es gab mal Messungen die gezeigt haben das die 100MHz Tastköpfe nicht nur eine tiefere Grenzfrequenz haben, sondern es fehlt ihnen ja auch die erweiterte Abgleichmöglichkeit der 200MHz Modelle (das Zweite C-Poti im BNC Anschluß) Irgendwo hatte ich auch mal Fotos von einem zerlegten Tastkopf rein gestellt... @ Schlumpfine Das Welec hat meiner Ansicht nach den Vorteil: es ist relativ günstig UND man kann seine Wünsche und Verbesserungsvorschläge direkt in die HW u FW Entwicklung mit einbringen. Für einen Frequenzbereich bis ca. 50Mhz lassen sich die Welec's inzwischen schon wirklich gut nutzen. Der Bedienkomfort und die Funktionsvielfalt übertrifft meiner Meinung nach die Konkurrenz vom China- Billigmarkt Sektor klar. Gruß, Brunowe
Hi, nur kurz ein Feedback von mir. Die Hinweise und Bugs sind notiert. @Luc As Guido wrote above, this is a hardware feature, not a firmware feature. So I am sorry about that, for I must agree that it might be useful. @Schlumpfine Für Deine Anwendungszwecke ist das WELEC mehr als ausreichend. Das Preis -Leistungsverhältnis ist meiner Meinung nach, seit es Alternativen zur originalen Firmware gibt, ungeschlagen. Und es bietet etwas was die Anderen nicht haben: Open Source Firmware + Community + Support + Experimentierspaß. Nebenbei lernt man auch noch eine Menge über Meßtechnik und Oszilloskope. Wo kriegt man das sonst? @Charly Diese Frage stellt sich wohl jeder WELEC Besitzer und Interessent. Ich habe ein W2014 und ein W2022. Der Bandbreitenunterschied ist so minimal, dass ich jedem empfehlen würde Geld zu sparen und lieber die 100MHz Variante zu nehmen. Anscheinend wird bei WELEC nur getestet welche Geräte im Rahmen der Toleranzen bestimmte Werte erreichen und welche nicht und dann entsprechend gelabelt. Die Messergebnisse der WELECS bei Frequenzen über 100MHz sind ohnehin eher als experimentell zu bezeichnen. Ich wollte in dieser Richtung aber noch mal weiter testen sobald ich über das geeignete Testequipment verfüge. Bei mir laufen aber beide Geräte bis 60 MHz völlig problemlos (Höhere Frequenzen kriege ich momentan nicht hin). So ich tauche mal wieder ab, die Projektarbeit als SAP-Berater frißt mich zur Zeit leider auf. Aber keine Sorge, auch wenn es von meiner Seite momentan etwas ruhig ist, es geht auf jeden Fall weiter. Gruß an Alle Hayo p.s. Respekt an alle die versucht haben den Thread komplett zu lesen ;-)
Haio Thanks! Thanks all! :) This tool now with bf2.0 is reaching amazing levels, and congratulations for the commitment to also give us the opportunity to use this to your wonderful work. Excuse me for the english..... Hello and thank you! :)
Hallo, inwieweit kann die neue Eingangsstufe nun mit der bestehenden Hardware angesteuert werden? Können wir uns da auf eine gemeinsame Lösung einigen? branadic
Buona Domenica. I'm from italian roboitalia forum (http://forum.roboitalia.com/showthread.php?t=5530&page=45) where from long time there is a thread devoted to Welec's DSO and where people often read your forum looking for news. All roboitalia's users are very satisfied with the results you gained and for the commitment and expertise you put to improve Welec's DSO, so we all thank you! But now I'm not here just to thank you, I'm here also to ask a few things, things may be possibles or may be impossibles, I don't know. Possibles or not the question is: can some specific items for measuring signal such as CAN, I2C, LIN, SPI, USB and so be added in to the trigger's menù? Something like this: http://www.tequipment.net/pdf/Agilent/7000Series_datasheet1.pdf and http://www.tequipment.net/pdf/Agilent/7000Series_manual.pdf. Of course not necessarily all mentioned types but only those who can be easy added. Due to the trigger weakness in the Welec's DSO I believe it isn't possible but maybe I'm wrong. It would be nice if you could do it, otherwise will mean to measure CAN, I2C, LIN, SPI, USB and so signals will go on as it always has been: will adjust manually everything, no problem. Thanks in advance and best regards, kcirreD
@Hayo: Danke für die Beschreibung und die Antwort. Dann will ich mal hoffen, daß es für meine Anwendungsfälle wirklich gut geeignet ist. Ich habe mir mal den Source-Code der BF20-prev12 angesehen. Sehe ich das richtig, daß in der Firmware kein Gebrauch von Interrupts gemacht wird und die Bedienelemente fleißig gepollt werden?
Hi @all, bin leider zur Zeit etwas busy und komme gerade nicht zum Weiterprogrammieren - ist aber nur vorrübergehend, da das Projekt das mich zur Zeit etwas in Anspruch nimmt in Kürze beendet ist. Immerhin sorge ich dafür, dass es bei Feinkost Albrecht leckere Knabbersachen im Regal gibt ;-) @Schlumpfine Nein da liegst Du falsch. Es wird sehr wohl mit Interrupts gearbeitet (Keyboard, Rotation Interface, Timer, UARTs etc.). Du findest die Interupt Service Routinen in der hardware_t.cpp und die Interrupthandler zum Teil in der userif_t.cpp. Gruß Hayo
Hallo! Ich verfolge diesen Thread jetzt so ziemlich seit Anfang an und muß mal ein dickes Lob aussprechen für das Engagement das in dieses Projekt gesteckt wurde und zu einer Firmware geführt hat, die der Originalsoftware weit überlegen ist! Darum habe ich mir vor etwas über einem Jahr auch ein W2024A zugelegt und dies mehr oder weniger regelmäßig mit den BF Releases geflashed und mich über die immer bessere Benutzbarkeit und zahlreichen Features gefreut. Leider habe ich aber jetzt ein kleines Problem mit dem Scope und möchte die Experten hier in der Runde um ihren Rat fragen. Vorgestern habe ich die aktuelle Version geflashed und danach das Skope für einige Messungen an einem Schaltregler genutzt. Als ich dann eine Pause gemacht habe, habe ich das Scope (wie vorher schon mehrmals) abgeschaltet. Beim Wiedereinschalten startete das Scope dann nicht mehr. Beim Einschalten wird der Bildschirm kurz hell und wieder dunkel. Die Run/Stop Taste leuchtet grün. Das wars. Keinerlei Reaktion auf Tastendrücke. Lediglich die Softkeys für den Flashloader und Reset funktionieren. Nach einem Reset leuchtet dann eine zufällige Kombination der LEDs. Der Flashloader funktioniert einwandfrei. Ich kann flashen, den Speicher auslesen und auch den Speicherinhalt über ein Terminalprogramm listen. Ab $40000 stehen auch Werte im Speicher. Trotzdem startet die Kiste nicht. Habe auch mal verschiedene Firmwarestände geflashed - keine Änderung. Hat jemand eine Idee, was ich noch testen kann? Ich würde mich über Tipps sehr freuen! Sorry für's off-topic. Die Mods mögen mir verzeihen. Danke! Frank
Hmmh, ob das Display Ärger macht? Da hatte doch schon jemand Probleme, ist aber länger her. Gibt es über RS232 noch Meldungen wenn du die Bedienelemnte (vor allem den Timbase-Drehgeber) betätigst? Dann würde die Firmware noch laufen.
Nee, das Displlay ist's wohl nicht. Wie gesagt: Es leuchtet nur die Run/Stop Taste und keine andere Taste/Drehgeber zeigt irgendeine Reaktion. Terminal bleibt auch stumm, bis ich in den Germ-Monitor Modus wechsle. Ich denke, daß die Firmware au irgendeinem Grund nicht gebootet wird. Wie war das noch: Nach dem Start wird die Firmware aus dem Flash in's RAM kopiert und dann da gestartet, richtig? Habe deshalb auch mal die RAM-Variante der BF 1.11 reingeladen. Leider auch kein Erfolg. Es scheint fast so, als würde die Software aus irgendeinem Grund nicht nach einem Reset starten. Gibt es eine Möglichkeit, im Monitorprogramm manuell die Firmware zu starten? Kann es sein, daß der Reset-Vektor nicht korrekt ist? Frank
Hab' gerade nochmal geschaut. Am Schluß des Firmware-Files steht ein 'r0' Das interpretiere ich mal als "Run from address $000000". Wenn ich aber im GERMSmonitor "m0" eingebe, gefolgt von etlichen <Returns>, sehe ich lauter FFFF Ist das normal? Kann das mal jemand verifizieren? Sollten da nicht irgendwelche Reset-Vektoren stehen? Oder bin ich auf dem Holzweg? Frank
Ich arbeite gerade an einer Lösung, der Test dauert aber einen Moment. Ich melde mich gleich. Hayo
Hallo Frank, das r0 setzt einfach nur das Offsetregister zurück. Aber nun zu Deinem Problem. Es kann sein, dass die Werte aus dem Config-Bereich nicht mehr zu Deiner Firmware passen weil sie irgendwie zerschossen sind. Beim Startup wird zwar ein Teil neu initialisiert, aber nicht alles. Probiere folgendes: Spiele erstmal die beigelegte C18 ein und sieh mal ob das schon hilft. Wenn das noch nicht hilft, dann spiele Dein komplettes Flashbackup ein (bei mir war das mit Firmware 1.4, sind ca. 3,1 MByte). Danach spielst Du nochmal die C18 ein. Ich habe das eben genauso gemacht und alles klappte prima. Falls Du kein Backup hast sag nochmal Bescheid. Gruß Hayo
@Jürgen Hast Du die Skalierung für Deine 24 Ohm Widerstände schon kalibriert? Wenn ja, dann lass mir doch mal die neuen Faktoren zukommen, damit ich die mit in die neuen Versionen einbauen kann. Gruß Hayo
Hallo Hayo Vielen Dank für Deine schnelle Hilfe! Habe das C18 (die Flash Version) eingespielt mittels ./GERMSloader.pl /dev/ttyS0 -w C18/TomCat.flash Upload wurde normal beendet. Das Scope zeigte keine Reaktion, also Power-Cycle. Selbes Bild. Dann auf dieselbe Weise mein seinerzeit gedumptes welec_1.4_dump.flash (Größe: 3359297 Byte) eingespielt. Wieder keine Reaktion. Sofort ohne Powercycle nochmal das C18 (flash) hinterher. Weder direkt nach dem Flashvorgang noch nach dem anschließenden Reset gab es irgendeine Reaktion. Also probehalber noch die C18 RAM Version eingespielt. Nach Upload leuteten ALLE LEDs. Aber ansonsten kein Erfolg. :-( Frank
Kleine Ergänzung: Ich schrieb: > Nach Upload leuteten ALLE LEDs. Stimmt nicht ganz. Habe es nochmal probiert. Während des RAM-Uploads ist wie nach dem Einschalten nur die Run/Stop LED an. Ist der Upload abgeschlossen, gehen alle LEDs für ca. 0.5 Sekunden an, dann sind wieder für ca. 0.5 Sekunden alle LEDs aus und schließlich gehen wieder alle an und bleiben an. Kann ich irgendwas helfen? Z.B. einen Speicherdump uploaden o.ä.? Frank
Hallo Frank, das heißt, dass der LED Test auf jeden Fall durchlaufen wird. Probiere mal die beigelegte Emergency Version, bei der die Funktion zum Laden des alten Zustandes aus dem Flash deaktiviert ist. Hilfreich wäre es wenn Du die Meldungen die wärend des Starts ausgegeben werden posten könntest. Wie das mit einem Terminal geht weißt Du nehme ich an? An alle anderen: Diese Version bitte nicht benutzen! Es kann zwar eigentlich nichts passieren, aber es bringt Euch auch nicht weiter. Gruß Hayo
Hallo Hayo, habe die im ZIP enthaltene .flash Version wie gehabt eingespielt. Keine Änderung. Dann die .ram Version probiert. Reaktion wie zuvor: Alles LEDs an, aus, an. Was die Bootmeldungen betrifft: Beim Einschalten bekomme ich keinerlei(!) Ausgaben vom Scope. Nur zum Verständnis: Ich habe das gtkterm gestartet, /dev/ttyS0 auf 115200 Baud N,8,1 gestellt und schalte dann das Scope ein. Keine Ausgaben im Terminalfenster. Dücke ich die Softkey-Kombination, meldet sich der GERMSmonitor mit #1F3A3048 TC CPU + Danach werden die eingegebenen Zeichen geechot und ich kann auch kommandos wie m, r etc. absetzen, die auch beantwortet werden. Was passiert denn nach dem LED-Test? Vielleicht hängt die Soft ja auch, weil irgendwo eine Hardware nicht initialisiert werden kann. Nochwas: Das LED-Blinken passiert NUR nach dem Einspielen einer RAM-Firmware. Löse ich einen Softkey-Reset aus, leuchtet stets eine jeweils zufällige Kombination von LEDs. Frank
Hallo Frank, ich hatte auch mal solche Symptome mit meinem W2012A. Ich habe daraufhin auf Lötstellen FPGA oder RAM als Fehlerursache geschlossen. Habe die Originalfirmware 1.4 wieder aufgespielt und mein Gerät nach email-Anfrage zurück zum Hersteller gesendet. Habe keine Möglichkeit einen FPGA nachzulöten :-) Das Gerät kam nach ca 14 Tagen zurück und der RAM war nachgelötet! Gruß Jürgen
Hallo Hayo, Hayo W. schrieb: > @Jürgen > > Hast Du die Skalierung für Deine 24 Ohm Widerstände schon kalibriert? > Wenn ja, dann lass mir doch mal die neuen Faktoren zukommen, damit ich > die mit in die neuen Versionen einbauen kann. > > Gruß Hayo hab ich leider noch nicht gemacht! Bin wohl irgendwie davon abgekommen... :-( Ich nutze z.Zt. die Factory Einstellung. Die passt so leidlich, da ich ja noch keinen 150 Ohm Abschluss eingebaut habe. Deshalb bin ich mir noch nicht klar, ob eine Scalierung ohne den 150 Ohm jetzt Sinn macht? Gruß Jürgen
Hallo Jürgen, könnte mir gut vorstellen, daß es sowas auch bei meinem Gerät ist. Hatte ja schon geschrieben, daß das Scope nicht beim Flashen, sondern während normaler Benutzung ausgefallen ist. Das RAM würde ich sogar nachlöten können, wenn ich nur wüsste, daß es wirklich die Fehlerursache ist. Eigentlich möchte ich das Gerät ungern einschicken. Hätte ja auch sein können, daß es mit einem Flashen z.B. des geschützten Bereiches getan ist. An dieser Stelle nochmals Dank an Hayo für seine Mühe und prompte Hilfe! Wenn es wirklich das RAM sein sollte, müsste man das im Prinzip doch mit dem GERMSmonitor sehen können, indem man das RAM dumped und schaut, ob das Richtige drin steht. Irgendwo gab's habe ich doch auch mal eine Memory Map gesehen. Finde ich aber leider bei SourceForge nicht mehr. Das Flash liegt ja ab $40000 Darum auch nochmal die Frage: Hilft's, wenn ich einen Memory-Dump hochlade? Wenn ja, welche Bereiche? Frank
Schon mal mit Fön / Kältespray versucht den Chip (mit der ev. kalten Lötstelle) zu lokalisieren? Nur so als Idee.... Viele Grüße, Mirko
@Frank Einen Memory-Dump scheint mir etwas fraglich. Ich weis jedenfalls so aus dem Stand nicht, wo was stehen muss. Der GERMS-Monitor hat kein direktes "Fill" Kommando. Also könntest Du nur versuchen über eine selbst erstellte S-Record Datei den RAM zu füllen, um danach auszulesen und einen Fehler in den Daten zu finden... Sehr aufwändig :-( Gruß Jürgen
Angehängte Dateien:
-
Kondensator010.jpg
170 KB -
Kondensator020.jpg
170 KB
Mirko B. schrieb: > Schon mal mit Fön / Kältespray versucht den Chip (mit der ev. kalten > Lötstelle) zu lokalisieren? > > Nur so als Idee.... > > Viele Grüße, > > Mirko ...genau, nimm das Ding auseinander und drücke mal ein wenig auf den Bauteilen, Steckern etc. herum, es könnte auch ein thermisches Problem sein. Die Welec's scheinen bei der Endprüfung der Platinen etwas geschludert zu haben. Ich hatte mal einen abstehenden Kondensator auf der Platine und dachte, ich sehe nicht richtig... Hi Hayo, was gibt's denn so Neues in der C18 ? Gruß Michael
Leute, *** IHR SEID KLASSE *** Danke für die Hilfe! Habe mir die Platine jetzt mal genauer angesehen, insbesondere das RAM (Danke Jürgen!). A0 von einem der RAM Chips sah sehr verdächtig aus. Nachgelötet - Bingo! Es rennt wieder. Die anderen Pins sind auch nicht wirklich toll gelötet. Verdammtes bleifreies Lot! Damit habe ich schon häufiger Ärger gehabt. Werde die RAM Chips mal sauber nachlöten. Nochmal 1000 Dank an alle für Eure Tipps! Liebe Grüße Frank
Angehängte Dateien:
-
Reset-Knopp01.jpg
180 KB -
Reset-Knopp02.jpg
130 KB
na also, geht doch... Mach mal ein oder zwei Shots, damit man mal sehen kann, was da los war, könnte ja sein, das es den Einen oder Anderen mal betreffen könnte! Ich habe hier noch ein paar Knöppe entdeckt, für was die wohl sind? Resets vielleicht?
+++++++++ Alles wird gut!!! ++++++++++++ Freut mich dass das Problem gelöst ist! Zur C18: Ich probiere noch an den USTB-Routinen, es hat sich für Euch also nichts Wesentliches geändert. Gruß Hayo
Hallo zusammen, arbeitet eigentlich jemand an dem Programmierinterface für die Huckepackplatinen? Wäre schön wenn es da auch Fortschritte gibt. :-) Mfg, Kurt
Hi Guido, Hayo and guys all! @ Guido and @ Hayo Thank You very much for the valuable information about my request to add displaying of the EXTERNAL TRIGGER on the DSO's screen. Pity it is not possible to do it, but no problem! :-) @ Hayo Again, thanks You very, very much Hayo for the great job and free time You provided generously to us!!! Hayo, I tried your new BF20_prev_C18 release and the DSO seems to me more noisy, perhaps it is only an impression. I could be wrong, I must investigate it. Hayo what's new in this version? I have a question and a request for all who can answer. Question. In the AQUIRE's AVERAGE tag how much are the averages? Request. Would it be possible to modify the AVERAGE's menu in order to adjust the averages number? Seems to me the averages are few and fast signals are distorted. But perhaps it is make for not slow the DSO. Still in AQUIRE's menù would it be possible to add Peak Detect acquisition mode? But perhaps NORMAL tag in the AQUIRE's menù already make that function. Hayo again many thanks to You for the new firmware's release! RESPECT!!! Vielen Dank!!! Gruß Luc
Hi Frank, Hayo and guys all! @ Frank Frank You were really good, my most sincere congratulations to You! My most sincere congratulations also to all those who helped You! I am really very happy! :-) RESPECT to You and who helped You! Hayo W. schrieb: >Zur C18: > >Ich probiere noch an den USTB-Routinen, es hat sich für Euch also nichts >Wesentliches geändert. Thank You very much for the information! Vielen Dank!!! Gruß Luc
Hello everybody, I just can fall into Luc's line. Amazing!!!!! Thank you all very much, particularly Hayo! On Skype and here I try to follow. Since I'm moving to another place, I'm a little short of time. Branadic and Kurt Bohnen asked about support for the Huckepackplatinen, but right now Hayo may have no time implementing that? Since having that leak of time right now, is there any ordering thing for components of the Huckepackplatine going on? Cheers, Peter
Hallo Kurt, Kurt Bohnen schrieb: > Hallo zusammen, > arbeitet eigentlich jemand an dem Programmierinterface für die > Huckepackplatinen? > Wäre schön wenn es da auch Fortschritte gibt. :-) Solange wir hier das "Henne-Ei"-Problem pflegen wird das wohl nichts! Soll heißen, die Softwerker warten auf die Hardware-Infos und die Hardwerker wartet auf die Software. Wie soll jemand die Software schreiben wenn er keine funktionieren Platine aufbauen kann weil die Bestückungs-Informationen nicht veröffentlicht werden? Aus meiner Sicht lässt sich die Software nicht entwickeln ohne Tests mit der Hardware. Ich verstehe auch nicht, warum der letzte Hardware-Stand der Platine nicht veröffentlicht wird, damit Testplatinen aufgebaut werden können. Gruß Bert
Hallo zusammen, habe gemerkt, daß in C16 die langsamen Zeitbasen nicht stimmen. Bei 5sek/ und langsamer wird immer mit ca. 2sek/div gemessen. Ab C17 friert mein 2024A komplett ein, wenn ich 2sek/ oder langsamer anwähle und 2-3 Sekunden laufen lasse. Ist das nur bei mir so? Danke! Lothar
Nur die Ruhe Lothar, Hayo arbeitet doch an dem Problem. Er kürzt halt diesen Bereich mit USTB (UltraSlowTimeBase) ab, damit es nur eingeweihte verstehen. ;-) Gruß, Guido
Großartig Bert, so wird einem also das Engagement gedankt. Du hast meinen tiefsten Dank dafür, ganz ehrlich! Das der Bestückungsplan zur Platine, die wir übrigens in unserer Freizeit entwickeln, weil wir so unendlich viel Langeweile haben, noch nicht veröffentlich ist liegt, wie ich schon einmal geschrieben habe, daran, dass ein paar wenige Bauteilwerte noch evaluiert werden müssen. Walter ist momentan dabei sein Oszi so zu modifizieren, dass er die Programmierung von außen vornehmen kann, um Messungen durchzuführen. Und weil wir natürlich so unendlich viel Langeweile haben und nur zu faul sind, sind diese Messungen noch nicht abgeschlossen und somit die finale Bestückung noch nicht klar. Wir sollten uns wirklich schämen. Und somit hast du natürlich vollkommen recht, es ist unverständlich, dass wir noch nicht alles veröffentlich haben was Layout, Schaltplan und Bestückung angeht. Wenn ich fünf Minuten Zeit finde werde ich mich in die Ecke stellen, ist das okay für? Jetzt mal im ernst, schämst du dich nicht hier so aufzutreten? Das der LH6518 über eine SPI-kompatible-Schnittstelle verfügt wurde hier schon diskutiert und zig mal erwähnt und wie diese grundsätzlich anzusprechen ist wurde in den Messprotokollen beschrieben und findet man auch im Datenblatt des Bausteins. Und diese Info ist nicht neu! Aber, es wurde hier noch nicht endgültig festgelegt, welche Anschlüsse für diese SPI-Schnittstelle auf dem Mainboard des Welecs zum Einsatz kommen sollen. Und das ist ein Punkt, das schrieb ich auch bereits, den wir gemeinsam diskutieren und festlegen müssen. Ich bin ein Freund von Jungs, die sich ins gemachte Boot setzen und dann Forderungen stellen. Da triffst du mich genau auf dem richtigen Senkel. Wenn du zu bequem bist die Diskussion aufmerksam zu verfolgen und zu sehen, dass ich diese offenen Punkte mehrfach angesprochen habe, aber niemand drauf einsteigen wollte, dann halte dich mit solchen Formulierungen in Zukunft bitte zurück, das stinkt mir nämlich und zwar gewaltig! branadic
Alles klar Guido, hatte die Abkürzung tatsächlich nicht verstanden. Wollte auch nicht hetzen und gebe zu, daß ich in letzter Zeit den Thread nicht aufmerksam gelesen habe. Übrigens: Ich bin begeistert, was die Software inzwischen alles kann!! Wünschte, ich könnte was beitragen. Lothar
Hi Folks, don't worry. All that is under construction, but the time is a little bit short in the moment because of my main business as SAP consultant. Hi Leute, keine Aufregung, einige Sachen brauchen halt etwas länger, da ja der Beruf auch seinen Tribut fordert. @Kurt Bin noch nicht dazu gekommen. Hatte gehofft, dass Stefan vielleicht in der Zwischenzeit dazu käme, aber er ist wohl auch ziemlich busy momentan. Ich muß mir mal die bisherige Ansteuerung raussuchen und dann mal mit Eurer Hilfe versuchen die Ansteuerung anzupassen. @Luc Thanks for the Ideas, I will check if it is possible to implement it. The noise may be indeed a little bit more, because of a hardware settings reset!! You have to adjust Your Oszi oncemore! I'm sorry, I did that for Frank to try a new initialization. @Lothar Sorry für die Abkürzungen, nochmal zur Erklärung: Ab Timebases 1s/div - 100s/div schaltet das Oszi automatisch in eine andere Betriebsart um. Die Abkürzung steht halt für "Ultralangsame Zeitbasen" (USTB). In den originalen WELEC-Firmwares werden die Zeitbasen überhaupt nicht unterstützt. Hier wird die Hardware einfach auf 50ns/div geschaltet - wenig hilfreich. Wie Guido schon sagte, bin ich zur Zeit dabei. Durch die neuen schnelleren Zeichen- und ADC-Routinen hat sich das sensible Timing der USTB-Bereiche ziemlich verschoben. Ich probiere momentan einen ganz neuen Ansatz, der aber noch bisweilen hakt. Was Ihr beitragt, nämlich Eure intensiven Tests und Rückmeldungen helfen mir enorm weiter! @all noch mal für alle die die C18 eingespielt haben: Ich habe die Hardwaresettings zurückgestellt um bei Frank zu prüfen ob das hilft. Ihr müßt Euch also nochmal ins Hardwaremenü hinabhangeln und alles neu einstellen (ADC-Offset, DAC-Offset, Hardwaresettings). Tut mir leid aber das mußte ich ausprobieren. Gruß Hayo
Hi Hayo, wollte nicht quengelig sein. Es fiel mir nur auf. Hatte halt den Neueren Teil des Threads nicht aufmerksam gelesen. Als der Frank und ich gestern an seinem Oszi gebastelt haben, fiel uns noch was auf: Auf seinem Oszi ist Kanal 2 nach dem Einschalten stark dejustiert. Bei meinem Gerät nicht. Bei ihm läuft C18 bei mir C16. Liegt das an den von Dir zurück gestellten Hardware Settings? Dann sollten wir bei Frank's Oszi wohl auch besser wieder die C16 aufspielen. Lothar
Hi Lothar, Ihr könnt die C18 ruhig weiter benutzen, Ihr müßt nur das Gerät einmal neu kalibrieren wie oben beschrieben dann ist alles wieder gut. Gruß Hayo
>Bin noch nicht dazu gekommen. Hatte gehofft, dass Stefan vielleicht in >der Zwischenzeit dazu käme, aber er ist wohl auch ziemlich busy >momentan. Das Hauptproblem ist momentan eigentlich eher, dass mein "svn update" ins leere läuft und ich nicht 8 Wochen alte Sourcen ändern will. Gruß, Stefan
Ok, hier ist die aktuelle C18 Source. Momentan ändere ich nur die USTB Routinen, alles Andere ist erstmal stabil. Da ich momentan nur wenig Zeit habe werde ich mich um die Hardwareansteuerung erst in ein oder zwei Wochen kümmern können. Wenn Du das vorher schaffst, wär das natürlich super! Der Gedanke war, wenn im Hardwaremenü die Option "Addon" gewählt wurde (MenuStatus[18][1] == 234), das dann die alternative Hardwareansteuerung zum Zuge kommt. Also einfach IF...ELSE.... Mir ist nur noch nicht ganz klar ob das in der <Hardware::SetDacOffset()> gemacht wird oder woanders. Gruß Hayo
Hallo, aufgrund der Klasse Arbeit von euch hab ich mir in der e-bucht von Herr Wittig ein w2022 ersteigert, vorne am Gehäuse fehlt das (a), beim booten zeigt es aber w2022a und 8C7.0E v1.4 an. Bedeutet das, das Herr Wittig bereits den Hack W2022 -> W2022a durchgeführt hat und ich Problemlos eure Firmware aufspielen kann? Aber Achtung, bevor jetzt einige in die Bucht rennen: Das Gerät war definitv nicht neu - Stromkabel in Frühstückstüte verpackt,... Beste Grüße Mike
@Mike Ich zitiere in Auszügen aus einer Mail von Wittig: "... das W2022 ist das selbe DSO wie das DSO W2022A. ... denn meine Aufkleber sind ausgegangen." Sind wohl immer noch aus. @Walter Der U24 wird, soweit ich das derzeit beurteilen kann, in der Firmware nicht angesprochen. Sollte also unbenutzt sein. Aber dahinter kann man den LMH nicht klemmen, weil dann hätte ich ja ein 32 bin-Datenwort. Von den 32-bit, die in der Firmware gesetzt werden, gehen aber 3bit auf die Adresse. Also kommen wahrscheinlich nur 24bit draußen an. Und das Datenwort in zwei Teile aufzuteilen, geht glaube ich nicht so trivial.
@Mike Das Thema gab es schon zu Anfang dieses Threads - vor 2 Jahren! Meine Geräte haben auch kein "A", sind aber definitiv A-Geräte. Also keine Sorge. Alle Geräte die jetzt vertrieben werden sollten A-Geräte sein. Gruß Hayo
Hi Hayo and guys all! Hayo W. schrieb: >The noise may be indeed a little bit more, because of a hardware >settings reset!! You have to adjust Your Oszi oncemore! I'm sorry, I did >that for Frank to try a new initialization. Hayo, as usual You are right! Yes, that's it. Actually after my post I had figured out why of the noise but I have not had time to correct me and You were faster than my fix! Anyway thanks for the help Hayo!!! :-) Hayo W. schrieb: >Thanks for the Ideas, I will check if it is possible to implement it. Thank You for your great kindness and patience!!! It would be nice it could be done, as it would be nice would be implemented the above suggestions also: I do not lose my hope! :-) Hayo again, thanks You very, very much for the time You provided generously to us and for your great job !!! RESPECT!!! Vielen Dank!!! Gruß Luc
Angehängte Dateien:
-
DSCF1340.jpg
400 KB
Hallo Hayo, ich habe inzwischen die Platine in Kanal 1 integriert und die Steuerung hinausgeführt mit der Absicht, die finale Anpassung durchzuführen. Danach käme der Bericht damit es auch alle nachbauen können … aber erst muß ich es zum Laufen bringen… Ich hab die BF20_prev_c17 drauf und den LTC2612 (14bit DAC) gegen den LTC2602 (16bit DAC) ausgetauscht – dieser DAC ist nur für Kanal 1 und Kanal 2 zuständig, bei Kanal 3 und 4 habe ich keine Änderungen gemacht. Die Spannung am 16bit - DAC Ausgang kann ich direkt messen- diese sollte zw. -2.5V und +2.5V einstellbar sein. Nun zu den Problemchen und Fragen: 1. die Ausgangsspannung des DAC nach Einschalten ist 1,25V (sollte 0V sein). Nach langem drehen komme ich nach unten auf 0V und das ist der Anschlag – darunter geht nicht. Vermutlich steuert die SW den Bereich 0V bis 2.5V durch – sollte aber von -2.5 bis +2.5 gehen (MSB nicht beeinflußbar?). Kann das jemand bestätigen? - den gesamten Offsetbereich zu verfahren kann bei 14bit schon lange dauern, bei 16bit noch schlimmer. Bei anderen Geräten benutzt man die Knopf-Dreh-Geschwindigkeit als Skalierung für den increment/decrement … Auch die eingestellte Empfindlichkeit sollte darauf Einfluß haben… 2. Ich bekomme keinen Strahl angezeigt (genauer – eine gerade Linie ganz oben im Bildschirm, als ob das Signal einen positiven Offset hätte – was nicht zutrifft. Die Offseteinstellung hilft mir nicht, das Signall mittig zu bekommen. Auch nicht für Kanal 3 wo ich keine HW-Änderungen gemacht habe (s.Foto). ADC Kalibrierung hab ich auch ausprobiert – erfolglos. Hast Du ein Tip für mich? Falls ich die Antwort meine Fragen irgendwo übersehen habe, bitte ich um Entschuldigung. Gruß Walter
Hallo Hayo, hab heute die 150 Ohm Widerstände eingebaut. Die Faktoren für 2 x 24.9 Ohm und 150 Ohm lauten: ScaleFactor: 3.674 fuer 1-er und 2-er und 2.949 fuer 5-er DAC-Scalefactor: 0.612, 1.224 und 3.059 entsprechend Schönen Abend! Jürgen
Hi, habe Eure Posts gelesen, bin aber etwas in Zeitdruck. Ich melde mich morgen nochmal. Hayo
kann mir jemand aus dem Inhalt der BF20_C18_src.zip eine TomCat.flash bzw. auch TomCat.ram erstellen, bin mit dem compilieren nicht vertraut.
@Walter Wenn ich das richtig verstanden habe ist der LTC2612 pinkompatibel gegen den LTC2602 getauscht worden. Der DAC (LTC2612) im original WELEC wird mit 8192 auf die Hälfte des Grids eingestellt und hat bei 16384 seinen Fullscalewert, der aber schon außerhalb des Grids liegt. Der LTC2602 hat seinen Fullscalewert aber bei 65536 und müßte demnach für die Gridmitte mit 32768 angesteuert werden. Hier müßten also die Werte angepasst werden, damit der DAC im richtigen Arbeitsbereich landet. Soll ich da mal eine Testversion mit den entsprechenden Werten basteln, oder ist Stefan da schon dran? Gruß Hayo
habe heute mal die aktuellese draufgespielt, Wahnsinn was sich alles verbessert hat, danke Hayo. Wollte dich aber trotzdem nochmal fragen ob du das mit der geringeren Auflösung mal probiert hast, da du meintest der Aufwand wäre nicht so groß. Vielleicht ist es auch wieder verschwunden da ich nicht alle Firmwares ausprobiert habe.
Wegen aktueller Anfragen zum Umrüsten der Widerstände und des Anpassens der Skalierung: Ich habe gestern endlich adäquates Testequipement erworben um Hochfrequenzmessungen bis 140MHz durchführen zu können. Im Laufe der Woche sollte der Signalgenerator bei mir ankommen. Bitte wartet noch mit der Umrüstung der Widerstände bis ich da nähere Infos zum Nutzen gesammelt habe, es ist immer noch nicht klar ob das wirklich Vorteile bringt. Wer schon umgerüstet hat und seine Faktoren selbst anpassen möchte braucht die Möglichkeit die Sourcen zu kompilieren. Es wurden ja schon Anleitungen für Windows und Linux gepostet. Ansonsten einfach nochmal anfragen. Die Anleitung zum Justieren der Faktoren hatte ich weiter oben schon mal für Jürgen gepostet, ansonsten auch hier einfach nochmal fragen. Gruß Hayo
Thomas O. schrieb: > Wollte dich aber trotzdem nochmal fragen ob > du das mit der geringeren Auflösung mal probiert hast, da du meintest > der Aufwand wäre nicht so groß. Vielleicht ist es auch wieder > verschwunden da ich nicht alle Firmwares ausprobiert habe. Hi, ja ich habe es ausprobiert und mir fiel auch wieder ein, dass ich es schon mal ausprobiert hatte. Leider hat es nicht so funktioniert wie erwartet, es gab leider keine Verbesserung. Daher habe ich weiterhin den Filter drin, da dieser zuverlässig das Rauschen vermindert. Gruß Hayo
Hallo Hayo, „Wenn ich das richtig verstanden habe ist der LTC2612 pinkompatibel gegen den LTC2602 getauscht worden.“ - der ist auch SW-kompatibel. Soll heißen, MSB (D13 bei LTC2612 bzw. D15 bei LTC26102) befindet sich an der gleichen Position. Aussteuerungsbereich (ausgangsspannung) dürfte mit gleicher SW unverändert bleiben, nur dass Du die letzten 2 bits auch noch programmieren kannst – das macht 4 Schritte dort, wo jetzt nur 1 möglich ist. Siehe auch S.11 der spec… Das Problem, was ich angesprochen habe dürfte auch den LTC2612 betreffen – deswegen habe ich das Bild von Kanal 3 gepostet, der ist bei meinem Oszi unverändert – und trotzdem bekomme ich den Strahl nicht mittig? Gruß Walter
Hallo Walter, habe ich da einen Denkfehler? Also das Datenwort wird doch seriell eingespeist. Beim Einen ist es 14 bittig beim Anderen 16 bittig. D.h. doch nach meinem Verständnis, bei einem Range von -2,5...+2,5 dass bei - 14 Bit 0x0000 = -2,5V und 0x3FFF = +2,5V -> 0x1FFF = 0V - 16 Bit 0x0000 = -2,5V und 0xFFFF = +2,5V -> 0x7FFF = 0V oder andersherum bei Nullansteuerung des 14 Bit DAC (8191 = 0x1FFF) gibt der 16 Bit DAC -1,87V aus, was im Grid einen Vollausschlag bedeutet, deshalb "klebt" die Linie auch bei Dir am Gridrand würde ich sagen. Liege ich da jetzt völlig falsch? Warum der Kanal 3+4 auch Probleme machen trotz unveränderter Hardware kann ich mir momentan auch nicht erklären. Gruß Hayo
Hallo Hayo, die Sache ist die, dass die beiden leeren Stellen beim LTC2612 hinter dem LSB sind. D.h., die Schreibweise ist rechts bindend bzw. FFFF bedeutet das gleiche beim LTC2602 wie beim LTC2612, nur das letzterer die beiden letzten Stellen ignoriert. Gruß Walter
Das hieße ja, dass für die 14 Bit Version die Werte immer um 2 Bit nach links geschoben werden müssen bevor sie in den seriellen Eingang gefüttert werden. Da muß ich mal in der Firmware nachsehen ob ich da sowas finde. Trotzdem ändert das aber doch nichts daran, dass der Nullpunkt und der gegenüberliegende Endwert bei 16 Bit nicht mit den gleichen Werten zu erreichen ist wie bei 14 Bit, oder habe ich da ein Brett vorm Kopf. Hilf mir mal auf die Sprünge. Gruß Hayo
Habs nochmal kurz gecheckt, der Wert wird tatsächlich um 2 Bit nach links verschoben, wobei die Shift-Operation von mir stammt, vorher wurde mit 4 multipliziert - was ja völlig bekloppt ist. Hier die Routine für Kanal 1: BufInt = CH1_DAC_Offset; //BufInt2 = (0x00310000 | (BufInt * 4)); BufInt2 = (0x00310000 | (BufInt << 2)); // Bei gelegenheit gegen Turnbits tauschen outbuf = (0x60000000 | BufInt2); serdata->np_piodata = outbuf; serstartsw->np_piodata = 1; serstartsw->np_piodata = 0; Gruß Hayo
Hallo Hayo, mit Deiner SW sollten sich beide LTC26x2 absolut gleich verhalten, es braucht nichts verschoben zu werden. - 14 Bit 0x0000 = -2,5V und 0x3FFF = +2,5V -> 0x1FFF = 0V - 16 Bit 0x0000_ = -2,5V und 0x3FFF_ = +2,5V -> 0x1FFF_ = 0V der Unterstrich markiert 2 zusätzliche Bits, die bei 14bit egal sind, bei 16bit nicht. Die können wir erst mal außer Acht lassen, sonnst verrutscht die ganze hexa-portionierung. Aus irgendeinem Grund starten aber die DACs bei 3/4 Bereich (ev.0x2FFF oder 0x3000) statt bei 50% Bereich wie oben. Kann es sein dass sich eine 1bit Verschiebung irgendwo eingeschlichen hat? Gruß Walter
@Walter Machen das beide DACs, also neu und alt? Ich schau mal nach.
wenn ich die Offseteinstellung ausreichend drehe, müsste ich irgendwann negative Werte erreichen können. Das klappt nicht. Das kann mit keinen Einstellungen zusammenhängen, es kann nur daran liegen, daß die 2 MSB im DAC auf 1 bleiben...?
@ Stefan "Machen das beide DACs, also neu und alt? Ich schau mal nach." Genau habe ich es nur mit dem 16-bitter gemessen, der andere verhält sich ähnlich (Strahl am Anschlag oben) Gruß
@Walter Probier mal diese bin-Datei. Beim Verändern des Offsets wird dem DAC von Kanal 1 0 als Wert gesendet und Kanal 2 auf 0x8000 gesetzt unabhängig vom Knopf. Schau mal, was da rauskommt.
Angehängte Dateien:
-
LMH_fix.jpg
1,4 MB
Hallo Hayo und Stefan, Entwarnung! Hab den Übeltäter gefunden – das Notebook, welches ich als serielle Eingabequelle benutze hat die -2.5V (interne Masse für den Oszi) mit 0V (externe Masse für’s Notebook) kurzgeschlossen. In Akkubetrieb funktioniert aber alles prima. Ich kann das Eingangssignal sehen und kontrollieren, demnächst fange ich also mit den finalen Anpassungen an. Für alle diejenigen, die das PCB jetzt schon bestücken wollen – anbei meine aktuelle Schaltplan-Version sowie ein unvollständiges Bestückungsplan vom PCB und meine Löthilfe für den LMH6518. Eine Korrektur ergab sich an Pin 3 des MAX4477 – der Pin sollte etwas nach oben gebogen werden damit kein Kontakt zum unterliegenden Pad entsteht. Später wird er per Draht an der Oszi-Platine angeschlossen, weitere Details werden folgen. In Abhängigkeit von den Messergebnissen könnten sich einige Widerstands- und Kondensatorwerte noch ändern. Gruß Walter
Hallo. @Hayo: Vorab: Ich will nicht Klugscheißen, sondern Dir Arbeit ersparen. Wenn ich hier überflüssiges oder selbstverständliches poste, ignoriert das bitte. Wenn ich das richtig sehe, wird zum Übersetzen der Quellen ein gcc-Derivat verwendet. Ich vermute mal Du hast dir das Kompilat Deiner Quellen (im Assembler) noch nicht angeschaut, sonst wäre Dir wahrscheinlich aufgefallen, das so ein moderner Kompiler durchaus gut optimieren kann. D.h. unter anderem, das der Kompiler automatisch 2^n Multiplikationen/Divisionen (von Intergerwerten) durch die entsprechenden Shift-Operationen ersetzt. Wenn ichs richtig erkenne, übersetzt Du üblicherweise mit -O2, das ist die zweithöchste Optimierung, es gäbe noch -O3 (wird noch schneller...) oder alternativ gibt es noch -Os, für das kleinste Kompilat. Ich möchte nur, das Du Deine Zeit nicht damit verbringst Optimierungen vorzunehmen, die vermutlich keine sind und Dich lieber den funktionalen Verbesserungen widmest. Lieber sauber lesbar Codieren, den Rest erledigt der Compiler. (Geschwindigkeits-) Optimieren kann man dann da wo es langsam wird bzw. wirklich zu langsam ist. Viele Grüße, Rainer Hayo W. schrieb: > Habs nochmal kurz gecheckt, der Wert wird tatsächlich um 2 Bit nach > links verschoben, wobei die Shift-Operation von mir stammt, vorher wurde > mit 4 multipliziert - was ja völlig bekloppt ist. Hier die Routine für > Kanal 1: > > > BufInt = CH1_DAC_Offset; > > //BufInt2 = (0x00310000 | (BufInt * 4)); > BufInt2 = (0x00310000 | (BufInt << 2)); > > // Bei gelegenheit gegen Turnbits tauschen > outbuf = (0x60000000 | BufInt2); > > serdata->np_piodata = outbuf; > serstartsw->np_piodata = 1; > serstartsw->np_piodata = 0; > > > > > Gruß Hayo
Hallo Rainer, danke für den Tipp. Ich muß zu meiner Schande gestehen, dass ich mich in der Richtung noch nicht so richtig schlau gemacht habe - auch wenn ich schon seit über 2 Jahren mit gcc arbeite. Ich hatte mir das aber schon gedacht, dass der Kompiler hier etliche Optimierungen vornimmt. Trotzdem würde ich an dieser Stelle die Shift-Operation vorziehen, da es ja auch genau diesen Zweck hat, nämlich die Bits nach links zu verschieben. Hier handelt es sich ja nicht um eine verkappte Multiplikation. Gruß Hayo
Apropo, > // Bei gelegenheit gegen Turnbits tauschen > outbuf = (0x60000000 | BufInt2); mal abgesehen davon, dass Gelegenheit groß geschrieben wird und solche Kommentare in englisch verfaßt werden sollten - weiß jemand was der WELEC-Programmierer hier mit Turnbits gemeint haben könnte? Gruß Hayo
Die Aufbau- und Umbau-Anleitung: http://welecw2000a.sourceforge.net/docs/Hardware/PCB_Aufbau.pdf http://welecw2000a.sourceforge.net/docs/Hardware/PCB_Integration.pdf mit freundlicher Unterstützung von André viel Erfolg!
Angehängte Dateien:
-
HF_01.jpg
150 KB
Hallo allerseits, heute ist mein neues HF/RF Equipement angekommen. Ich konnte natürlich nicht umhin gleich mal ein paar Vorabmessungen vorzunehmen. Hier schon mal einige grobe Erkenntnisse: - Die WELECs schlagen sich in der High Frequency Einstellung gar nicht mal so schlecht wie allgemein vermutet - die geänderten Widerstände scheinen sich tatsächlich positiv auf Messungen in höheren Frequenzbereichen auszuwirken (f > 30 Mhz) Testumgebung: - Signalgenerator Leader 3216 (bis 140 Mhz Sinus) - Referenzoszi Tek 2465A (350Mhz) - W2014A mit Originalbestückung - W2022A mit 33 Ohm und 150 Ohm Widerständen in der Eingangsstufe Das W2014A läßt sich bis 20 Mhz durchaus ganz gut einsetzen, danach wird die Dämpfung zu stark. Bei 50 Mhz sind von 2,7Vpp nur noch 1,9Vpp übrig Bei 100Mhz noch 1,35Vpp. Alles ohne Schwingungsneigung oder andere Verzerrungen. Der Trigger ist manchmal etwas unruhig und erwischt nicht immer die richtige Flanke. Mit geänderten Eingangswiderständen dürfte sich der nutzbare Frequenzbereich deutlich erhöhen. Das W2022A geht dank der geänderten Widerstände problemlos bis 100 Mhz mit konstanter Amplitude. Erst ab 120 Mhz bricht hier die Amplitude spürbar ein. Genaueres mit detailierten Screenshots folgt. Gruß Hayo
Sehr interessant, wenn das mal endgültig geklärt würde. Bis jetzt gab es da ja recht verschiedene Aussagen. Die Sache mit den Huckepack-Platinen ist mir zu aufwändig (und zu teuer), aber ein paar Rs wechseln, das bekomme ich bestimmt noch hin. Es wäre schön, wenn jemand da mal so etwas wie eine Step-by-step Anleitung für den Gelegenheitslöter posten könnte (oder gabs das schon?). Viele Grüße, Mirko
Hayo W. schrieb: > > Das W2022A geht dank der geänderten Widerstände problemlos bis 100 Mhz > mit konstanter Amplitude. Erst ab 120 Mhz bricht hier die Amplitude > spürbar ein. > Na das hört sich gar nicht schlecht an! Deshalb nochmal etwas geänderte Kalibrierfaktoren für 2 x 24.9 Ohm und 150 Ohm: ScaleFactor: 3.309 fuer 1-er und 2-er und 2.697 fuer 5-er DAC-Scalefactor: 0.6614, 1.3228 und 3.307 entsprechend So passen die Amplituden besser. Gruß Jürgen
@Hayo: Wollte mal fragen, was nicht so funktioniert hat, lags an der Skalierung weil diese dann erhöht werden muss? Wenn ja könnte man doch auch Nullen reinschieben bis das MSB eine 1 ist und die unteren 7 bits löschen oder würde das die Geschwindigkeit des Oszis so weit runterdrücken? Oder vielleicht eine 2te Filterauswahl die noch schärfer arbeitet. Kannst du mir sagen wo die Filtergeschichte im Code sitzt damit ich mir das mal anschauen kann.
Hi Thomas, die Filterroutine findest Du in der Datei signal_t.cpp etwa bei Zeile 840. In dieser Datei sind alle Signal-Processing Routinen untergebracht. Wenn Du da Ideen oder Verbesserungen hast nur zu. Wenn es gut funktioniert kippen wir das alles mit rein. Man könnte natürlich den Filter noch in einer zweiten Stufe mit mit engerer Bandbreite ansetzen, um bei niedrigen Frequenzen die Filterwirkung verbessern zu können. Das wäre auf jeden Fall recht einfach. Reicht denn der Filter so noch nicht aus? Ich habe da übrigens noch einen kleinen Bug im Filter entdeckt, er geht bei den interpolierten Zeitbasen nicht mit dem Fensterausschnitt, sondern bleibt immer am Anfang. Bin ich dran... Hayo
danke Hayo ich werde mir das ganze mal ansehen wobei ich nicht so C bewandert bin. Also Ideen hätte ich genug und in ASM wäre das auch kein Problem, ich werde mir das ganze mal anschauen in ein paar C-Schnipsel beitragen die du vielleicht einfügen könntest.
Mirko B. schrieb: > Es wäre schön, wenn jemand da mal so etwas wie eine Step-by-step > Anleitung für den Gelegenheitslöter posten könnte (oder gabs das > schon?). > Viele Grüße, > Mirko Hi Mirko, bitteschön, hier is'------------------------------------- die besagten 0 Ohmler befinden sich im Schaltplan hier: Beitrag "Re: Wittig(welec) DSO W20xxA Hardware" Auf der Platine hier: Beitrag "Re: Wittig(welec) DSO W20xxA Hardware" Getauscht sieht das so aus: Beitrag "Re: Wittig(welec) DSO W20xxA Hardware" Ein kleines Ergebnis hier: Beitrag "Re: Wittig(welec) DSO W20xxA Hardware" Den ADC's verpasst du gleich etwas Kühlung wenn du schon dabei bist: Beitrag "Re: Wittig(welec) DSO W20xxA Hardware" und der 150 Kilo Ohmler Abschluss sitzt hier: Beitrag "Re: Wittig(welec) DSO W20xxA Hardware" Feine Lötspitze mit 360 Grad, Aceton, Wattestäbchen, Löthonig, Lupe oder Mikroskop und eine ruhige, sehr ruhige Hand. Die verklebten Leitungen neben den AD8131 haben einen Kleber, der beisst wie s.. in der Nase, wenn der Lötkolben dran kommmt... Viel Spaß beim Tauschen Hoffe ich habe da nix vergessen?!? Gruß Michael
Schon mal schönen Dank (war bestimmt eine ziemliche Arbeit, das aus diesem Monsterthread rauszusuchen), muss mir das noch genauer anschschauen (und Widerstände bestellen), mal sehen, was Hayo so rausfindet. Viele Grüße, Mirko
Angehängte Dateien:
-
1KHz_ProbSignal_01.jpg
190 KB -
1KHz_ProbSignal_02.jpg
180 KB
...das ist wohl war, hatte gerade mal lust dazu... So als Low-Budged Tip, für die Bröckchen kämen alte CD-Rom Laufwerke oder kaputte Festplatten in Frage, da ist auf jeden Fall was für dich dabei! Ich habe gerade mal mit der neuen C18 gespielt...1KHz-Pro-Signal und jetzt steht das Teil, keine Reaktion mehr und völlich eingefroren!!! Einstellungen sind auf dem 1. Shot zu sehen! Auf dem 2. Shot sieht man noch die Trigger-LED, die steht auch... Was ist denn da jetzt los? Gruß Michael
Buona sera. Hayo W. schrieb: >Testumgebung: > >- Signalgenerator Leader 3216 (bis 140 Mhz Sinus) >- Referenzoszi Tek 2465A (350Mhz) >- W2014A mit Originalbestückung >- W2022A mit 33 Ohm und 150 Ohm Widerständen in der Eingangsstufe Well, well, congratulations for the equipment! Hayo W. schrieb: >Das W2014A läßt sich bis 20 Mhz durchaus ganz gut einsetzen, danach wird >die Dämpfung zu stark. Bei 50 Mhz sind von 2,7Vpp nur noch 1,9Vpp übrig >Bei 100Mhz noch 1,35Vpp. From the image I can't understand how the Leader 3216 is set. The frequency indicator is covered by the coaxial cable, I guess the frequency is 10MHz. Output level is 126, I guess 126dBuV, so about 1.99Vpp. Modulation is 22,5 so I guess for this reason the sine wave isn't pure. On the oscilloscope's input there is a 50 ohm through termination. For the same signal the W2014's screen shows 2,73Vpp at 20MHz, 1,9Vpp at 50MHz and 1,35Vpp at 100MHz, is it correct? Hayo W. schrieb: >Der Trigger ist manchmal etwas unruhig und erwischt nicht immer die >richtige Flanke. Unfortunately this is true. Congratulations for the test. Thanks and best regards, kcirreD
Jetzt habe ich einen Warmstart gemacht, das DSO weit über eine Std. laufen lassen, sobald ich in den Bereich (wie oben im Shot 1) 250Sa/s, 1s komme, friert das DSo komplett ein! Bei einigen Versionen vor der C18 war das nie der Fall, soweit ich mich erinnern kann... Hat das Jemand mal getestet? Gruß Michael
@kcirreD The picture is only a sample to show the equipemnt. For the measurements the modulation was switched off. The Frequency on the picture was 8.96 Mhz. @Michael Der USTB-Bereich ist noch "Under Construction". Hier geht momentan noch nichts - ist also nicht benutzbar!. Daher nicht wundern, das kommt noch. Gruß Hayo
Hi, ich habe mal was zum Thema Widerstände im HW-Thread gepostet: Beitrag "Re: Wittig(welec) DSO W20xxA Hardware"
Hayo W. schrieb: > @Michael > Der USTB-Bereich ist noch "Under Construction". Hier geht momentan noch > nichts - ist also nicht benutzbar!. Daher nicht wundern, das kommt noch. Ok, ich höre auf mich zu wundern... :) Ich dachte der USTB-Modus wäre schon fast abgeschlossen? Wie auch immer, der "USTB-Modus" ist dann aktiv wenn gleichzeitig der "Roll-Modus" aktiviert ist? Ab welcher Zeitbasis ist denn der "USTB-Modus" aktiv? Ab--- 250Sa/s, 1S ---was ich oben schon angegeben hatte? Vielleicht könntest du evtl. einen kleinen Hinweis in den Bildschirm mit einbauen, wann "USTB-Modus" aktiv ist und wann nicht? > > Gruß Hayo Gruß Michael
Ok, der USTB-Modus scheint etwas Aufklärung zu brauchen. Also nochmal: USTB <==> Ultra Slow Timebase D.h. alle Zeitbasen kleiner als 500ms/div. Die Umschaltung erfolgt automatisch. Im USTB-Modus gibt es zwei verschiedene Darstellungsarten: - den Rollmode - den Shiftmode Das hängt mit dem grundsätzlichen Prinzip des USTB-Modus zusammen der ganz anders arbeitet als der normale Zeitmodus. Während beim normalen Zeitmodus immer ein kompletter Datensatz ermittelt wird und dann als Linie ausgegeben wird, wird beim USTB-Modus immer Punkt für Punkt ermittelt und ausgegeben. Beim Rollmode wird der Punkt immer ans Ende gehängt und daher rolliert der gerade aktive Punkt immer von links nach rechts über den Screen. (Also wie beim analogen Oszi) Beim Shift-Mode wird der Punkt immer am Anfang (also ganz links) eingefügt und der Rest um einen Punkt nach rechts geschoben - daher der Name Shiftmode. Ich hoffe das war jetzt nicht zu umständlich erklärt. Sollte man vielleicht ins Wiki mit aufnehmen... Hayo
Angehängte Dateien:
-
img_4330.jpg
1,3 MB
Ach ja, falls Ihr Euch wundert warum das so lange dauert: Das Timing ist ziemlich sensibel. Da spielt die Zeichenroutine eine Rolle, die Übertragung in die Grafiklayer, die ADC-Auswertung und natürlich der Timer. Das muß alles genau aufeinander abgestimmt werden. Nicht so einfach, wenn man bedenkt, dass je nach Anzahl de aktiven Kanäle diese Zeitkonstante unterschiedlich ist. D.h. ich habe das Oszi an einer Präzisionssignalquelle hängen (siehe Bild) und probiere unterschiedliche Einstellungen aus, die aber auch jedesmal neu ins Oszi geladen werden müssen. Das kann schon mal mehrere Tage dauern bis man das alles im durch hat. Gruß Hayo
Ohh Hayo, so langsam werde ich neidisch auf deinen Messplatz. Sobald ich wieder etwas mehr Zeit habe, schau ich mich mal in der Bucht um. Das sieht wirklich sehr gut aus. Frohes Messen, Guido
Ja und es ist erschütternd (und natürtlich für uns erfreulich) welchem Preisverfall diese tollen und ehemals sündhaft teuren Geräte unterliegen. Der Leader Signalgenerator z.B. stammt vom norddeutschen Rundfunk und ist in einem hervorragend gepflegten und gewarteten Zustand - hat weniger gekostet als das WELEC... Und auf meine Mailanfrage in den USA hat mir Leader auch sofort ein Manual (PDF) zugeschickt, das nenne ich Kundenservice. Gruß Hayo
Salve, sul forum Italiano abbiamo scoperto un piccolo bug. Impostando il time base a 1 sec il dso si freeze. Ciao a tutti.
Sorry I missed the message .... :) Hi, on the Italian forum we found a small bug. Setting the time base of 1 sec freeze the DSO. Hello everyone.
Hi gyppe, the C## Versions are only experimental versions with some changes. Since the drawing and acquisition speed increased (about C5) the Ultra Slow TB are working incorrect. So this part is still under construction. Don't worry about that, in the next days I will publish the final BF2.0 as stable version. As I wrote some posts above (with picture) it takes much time to calibrate every TB in all working conditions precisely. The TB above 10s/div lets You become older and grayer while watching the signal creeping over the screen... ;-) Ciao Hayo
Hayo W. schrieb: > Der Leader Signalgenerator z.B. stammt vom norddeutschen Rundfunk und > ist in einem hervorragend gepflegten und gewarteten Zustand - hat > weniger gekostet als das WELEC... Da mussman aber auch das Glück haben, ein Gerät so günstig von einer sochen Anstalt zu erhaschen. Wie bist du dazu gekommen?
Thanks now I understand everything:) Sorry if I disturbed, but the German can not decipher it well even with a translator and a lot of things I do not understand:) Gyppe.
@gyppe No problem. Please ask at every time if You have questions. @Alex Reiner Zufall. Hab einfach mal mal bei der Bucht reingeschaut und dachte mir - biete mal einfach. Das es der NDR ist wußte ich nicht, das stellte sich erst raus als meine Frau das Teil abholte. Ist also wirklich etwas Glück. Der Anbieter bietet noch mehr an, hier der Link zu meiner Auktion: http://cgi.ebay.de/ws/eBayISAPI.dll?ViewItem&item=160493003238&ssPageName=ADME:X:AAQ:DE:1123 Hayo
Hallo allerseits, wie versprochen hier die finale 1.2.BF.2.0 - soweit ich testen konnte läuft alles recht stabil. USTB ist jetzt ebenfalls ok und läuft besser als vorher. Allerdings beachtet bitte, dass die TB 1s/div und 2s/div recht empfindlich auf äußere Einflüsse reagieren, so wie Temperatur und Interupts von Keyboard oder Drehgebern. Dies führt hier zu einer Frequenzungenauigkeit von ca. 5%. Je langsamer die Zeitbasis, desto genauer wird es, da hier die Einflüsse immer weniger eine Rolle spielen. Die Posts von: - Charly -> 5.10.2010 - Luc -> 5.10.2010 - Mirko -> 6.10.2010 habe ich versucht nachzuvollziehen, konnte die Bugs aber nicht nachstellen. Prüft bitte ob sie noch aktuell sind, und wenn ja möglichst mit genauer Beschreibunbg der Einstellungen oder Screenshot nochmal posten. @Luc couldn't repeat Your bug from 5.10.2010, so please check it again and post it with detailed description of Your settings (or screenshot). Gruß Hayo
Angehängte Dateien:
-
Puls_Width_Trigger1.png
4 KB -
Puls_Width_Trigger2.png
4,4 KB
Hallo Hayo, erstmal großes DANKE für die 1.2.BF.2.0 Hayo W. schrieb: > wie versprochen hier die finale 1.2.BF.2.0 - soweit ich testen konnte > läuft alles recht stabil. Mit dem Wort "finale" ist das wie mit "nie": Die Worte soll man nie sagen ... Beim Puls-Width-Trigger bin ich noch auf eine Kleinigkeit gestoßen: Mit Probe Comp z.B. an Ch2 und Triggereinstellung wie im Bild 1 läuft alles prima. Wenn ich dann das Signal mit dem Offset-Regler hoch- oder runterschiebe, wandert die Anzeige für 0-Linie und Triggerlevel mit, aber ab einer gewissen Verschiebung setzt der Trigger aus (dto. bei Center Channel 2). Das kommt mir so vor, als ob der Triggerlevel für die Pulserkennung nicht automatisch mit verschoben wird. Wenn ich zwischendurch kurz auf Edge und dann wieder auf Puls Width Trigger schalte, wird der Level anscheinend neu gesetzt und es läuft wieder. Schönen Sonntag an alle. Gruß Rainer
auch von mir ein Dankeschön, mir ist auch ein eher optischer Mangel aufgefallen, wenn ich im aufgezeichnetem Signal eines Singelshoots blättere sieht das Signal manchmal so aus als ob es lebt, also das Rechteck das ich verschiebe beginnt plötzlich zu rauschen (Zeichenroutine) vielleicht wird hier wegen der Geschwindigkeit nicht gelöscht, glaube das war nur in eine Richtung der Fall, werde es heute Abend nochmal genauer beschreiben inkl. Zeitbasen....
Thomas O. schrieb: > ... sieht das Signal manchmal so aus als ob es lebt ... Das ist ja auch so: Es lebt vom Speicherinhalt, der dann unterschiedlich dargestellt wird. Das "leben" verschwindet, wenn man ganz reinzoomt. Damit das nicht passiert, müßten wohl der Verschieberaster im Speicher und auf dem Bildschirm genau zusammenpassen. Schlimm find' ich's nicht. Rainer
wenn ich ein Rechtecksignal verschiebe dann sollte das Rauschen auch mitgeschoben werden. Da scheint aber in einer Zeichenroutine was nicht zu stimmen und das fällt dann auf der waagrechten Linie des Rechtecks auf wenn man schiebt. Ich werde heute Abend mal versuchen das zu filmen läßt sich per Bild schwer erklären. Es sieht halt so aus als ob es live rauscht auf einem Signal welches aufgezeichnet ist und sich eigentlich nicht verändern sollte.
Angehängte Dateien:
-
living1.png
3,5 KB -
living2.png
3,3 KB
Wenn ich mir ein aufgezeichnetes Probe Comp Signal in Originalzeitauflösung ansehe, springt das auf dem Signal sichtbare Rauschen beim langsamen Verschieben der Zeitachse immer zwischen genau den zwei in den Screenshots gezeigten Zuständen hin- und her. Rainer
auf deinen Bildern sieht es so aus als ob einmal das Signal mit dem Filter und einmal ohne dargestellt wird. Könnte gut sein das das Signal deshalb so lebhaft aussieht, weil immer zw. gefilter und ungefilter hergeschalten wird.
du hast recht. Anscheinend ist das eine dargestellte Signal gefiltert und das andere nicht. Wenn ich in das aufgezeichnete Signal reinzoome (100 bzw. 50 us/div), sieht es so aus, als ob immer ohne Filter dargestellt wird. Gemessen hatte ich es mit aktiviertem Noise Filter. Wenn ich Aquire auf "Normal" stehen habe und dann ein im Single Shot erfaßtes Signal zeitlich schiebe, springt das Bild zwischen zwei unruhigen Darstellungen hin- und her.
Hallo Ihr Beiden, @Rainer Deinen Bugreport habe ich notiert, werde ich mir mal in Kürze ansehen, zum Thema "Final" - das bezieht sich ja auch nicht auf den Gesamtzustand der Firmware, denn die wird eigentlich (und da sind wir auch schon beim zweiten Wort) NIE fertig. Gemeint ist damit nur der Arbeitsvorrat der in die 2.0 einfließen sollte. Wobei ich zugeben muß, dass die Neuerungen in der FFT-Sektion dabei hintenübergefällen sind. Die werden dann in den nächsten Versionen nachgereicht. Wie Ihr im Changelog sehen könnt, hat sich aber dennoch einiges unter der Haube getan. @Thomas Wie Rainer ganz richtig anmerkt liegt das "Eigenleben" des Signals beim Scrollen am Speicherinhalt. In den normalen Zeitbasen werden aus dem Speicher, je nach TB nur jeder 4te, 5te bis zu jedem 25ten Punkt dargestellt. Genau könnt Ihr das in den beigelegten Tabellen sehen. Wenn Du jetzt also durch den Speicher scrollst und das Signal verrauscht ist, so sieht die Darstellung natürlich bei jeden Schritt anders aus, weil er dann nicht das Pixel 1-5-9-13 usw. darstellt wie vorher, sondern Pixel 2-6-10-14 usw. beim nächsten Schritt 3-7-11-15 usw.. Das ist aber kein Fehler in der Zeichenroutine. So ich werde mich mal ransetzen und ein paar HF-Messungen machen, die Bilder könnt Ihr Euch dann gleich im HW-Thread ansehen. Gruß Hayo
@Hayo Hayo W. schrieb: > Wie Rainer ganz richtig anmerkt liegt das "Eigenleben" des Signals beim > Scrollen am Speicherinhalt. Thomas Einwurf mit dem Filter fand ich sehr überzeugend. Da scheint wirklich etwas schief zu gehen. Im einen Fall (living2.png, glatteres Signal) werden die Flanken des Probe Comp Signals auch systematisch und reproduzierbar flacher dargestellt. Mit Display > Vectors off ist das noch deutlicher. Rainer
Angehängte Dateien:
-
living3.png
3,8 KB
Noch eine Ergänzung zu gefiltert/nicht gefiltert: In einem Teil des nicht dargestellten zeitlichen Bereichs wirkt das Filter anscheinend gar nicht. z.B. - Zeitfenster ganz nach links schieben, - Single Shot, - Zeitfenster ganz rechts drehen. Dann tauchen ungefilterte Daten in der Anzeige auf (im Screenshot rechts vom Cursor). Rainer
Stimmt, das Filter arbeitet aus Performancegründen nur im Fensterausschnitt. Wenn der Stopmodus aktiv ist wird ja nicht neu gefiltert. D.h. wenn dann der Fensterausschnitt geändert wird, dann schiebt man sich aus dem gefilterten Bereich heraus - muß mal sehen ob man das ändern kann. Danke
Hayo W. schrieb: > muß mal sehen ob man das ändern kann Damit das Drehen an der Zeitverschiebung flüssig auf die Anzeige wirkt, kann man ja erst ungefilterte Daten darstellen. Wenn dann am Drehregler Ruhe herrscht, könnte man noch mal eine Darstellung mit gefilterten Daten nachschieben. Wäre das eine Möglichkeit? Rainer
Ist etwas schwierig, aber ich werde mal sehen ob mir da was einfällt. Gruß Hayo
@Hayo: Ich verstehe deinen Erklärung nicht genau, da ich ja beim scrollen keine Zeitbasis ändere. Wenn also die Pixel 1-5-9-13 (angenommen obere waagrechte Linie eines Rechtecks) oder sagen wir Speicherstelle 1-5-9-13 dargestellt werden und ich im Bildschirm scrolle sollten doch die Pixel 1-5-9-13 nach links oder rechts geschoben werden und nicht neue Pixel 2-6-10-14 aus dem Speicher eingebracht werden. Ich denke beim ändern der Zeitbasis würde das eh nicht auffallen da das Signal viel mehr versetzt wird als beim langsamen scrollen. Dann habe ich nochmal eine Frage zu der Filterroutine da ich mit C nichts am Hut habe. Sehe ich das richtig das nur Signaländerungen größer lmin -1 oder lmax +2 in die Darstellung einfließen oder kannst du das Entrauschen kurz erläutern?
Hi Hayo, Rainer W. and guys all! Hayo W. schrieb: >wie versprochen hier die finale 1.2.BF.2.0 First, again thanks You very, very much Hayo for the great job and free time You provided generously to us!!! I tried your new 1.2.BF.2.0 release and for me it works very well, it work like a charm, so Hayo thank You very, very much for the really amazing great work done!!! As usual I'm speechless, RESPECT!!! Hayo W. schrieb: >da hier die Einflüsse immer weniger eine Rolle spielen. > >Die Posts von: > >- Charly -> 5.10.2010 > >- Luc -> 5.10.2010 > >- Mirko -> 6.10.2010 > >habe ich versucht nachzuvollziehen, konnte die Bugs aber nicht >nachstellen. Prüft bitte ob sie noch aktuell sind Very good, again thanks You very, very much Hayo for the kind assistance!!! I tried and tried several times and with this new 1.2.BF.2.0 version is no longer appeared to me!:-) Rainer W. schrieb: >Das kommt mir so vor, als ob der Triggerlevel für die >Pulserkennung nicht automatisch mit verschoben wird. Wenn ich >zwischendurch kurz auf Edge und dann wieder auf Puls Width Trigger >schalte, wird der Level anscheinend neu gesetzt und es läuft wieder. Hello Rainer W. I see the trigger is set to NORMAL, could be this the reason. Perhaps with the button RUN/STOP fix the problem also. Would be interesting to see if the trigger is still acquired or not, the LED trigger's function can help to understand. Maybe the signal track will move but the trigger do not follow it so with the trigger set to NORMAL the signal track does not repaint. However I too have found some anomalies with the use of the PULSE WIDTH. ">" works fine, "<" not always work to me, "><" not work to me: I tried with the probes compensation signal, trigger mode is set to NORMAL. I have to study the question, maybe I have something wrong. Rainer W. schrieb: >Noch eine Ergänzung zu gefiltert/nicht gefiltert: > >In einem Teil des nicht dargestellten zeitlichen Bereichs wirkt das >Filter anscheinend gar nicht. >z.B. >- Zeitfenster ganz nach links schieben, >- Single Shot, >- Zeitfenster ganz rechts drehen. >Dann tauchen ungefilterte Daten in der Anzeige auf (im Screenshot rechts >vom Cursor). A similar thing happens to me when I use the PULSE WIDTH trigger mode, I have to pursue the matter. Hayo W. schrieb: >Bilder könnt Ihr Euch dann gleich im HW-Thread ansehen. Good work Hayo!!! I have also obtained similar results with W2022A and W2012A up to 170MHz. My equipment is very low compared to your but the results are similar. What I found is that Welec have not a hard time with the high frequencies, the real problem are the true amplitude signal values which is difficult to infer because of the linearity's lack. Unfortunately I can only generate high frequency sine waves, whereas I think it would be better to use square waves. However, comparing the signals with other oscilloscopes, ignoring the amplitudes speech , what I observe with the W2022A and W2012A is the same as what I see with other oscilloscopes, neither more nor less: this is undoubtedly due to the quality of work you Hayo, along with all others who contributed, you have done, then RESPECT!!! I can say that thanks to your work You are able to make the Welec/Wittig's DSO competitive with what the market currently offers, so again many thanks to You Hayo, really thanks very much to all You!!! Vielen Dank!!! Gruß Luc
Hallo Hayo, vielen Dank für die neue Version! Bin sehr angetan davon. Nach Anpassung der DAC Scales an die in meinem Gerät verbauten Widerstände ist jetzt alles "rund". Klasse! Danke! Lothar
@Luc NORMAL trigger should work, as the Probe Comp signal is a normal square wave of +/-400 mV and a trigger level of 0 mV is well in the middle of that range. But setting trigger to AUTO didn't change anything. In case I change the offset of a channel, i.e. the position on the display, IMO this should not have any influence on my trigger settings (and temporarily switching to EDGE trigger set the correct level for the pulse width detection). If trigger has stopped due to channel offset, the LED1 is ON. "><" works well using the correct settings, but with an a few quirks: To see the Probe Comp signal, the ">"-value should be well below the positiv pulse width, ">" + "deltaT" should be well above the positiv pulse width (e.g. 450us, 100us in Puls_Width_Trigger1.png above). I temporarily switch to EDGE trigger to get the correct decision level for the pulse detection. After messing around with "<" or ">"-trigger settings, i have to touch the ">"-value to start triggering in "><" mode. "<" do not works for me (Probe Comp triggers always, independent of "<" value, trig. NORMAL) @Hayo Beim OS-Screenshot mit Pulse-Trigger Menü kommt anscheinend die Zeichenebene mit dem inaktiven "Delta t" nicht mit rüber (alter Bug?, s.o. Puls_Width_Trigger1.png). Ist das deine Baustelle oder liegt das am Empfänger? Gruß, Rainer
Angehängte Dateien:
-
screenshot-0001.jpg
40 KB
Jetzt habe ich nach einigen Messungen doch ein kleines
Verständnisproblem:
Wenn ich die Widerstände in den Vorverstärkern ändere, muß ich auch die
Skalierungsfaktoren in der Software ändern - klar.
Jetzt gibt es deren 2:
In tc_vars.cpp den DAC_ScaleFactor musste ich ändern, damit die
Nullinien
nach der DAC-Kalibrierung stimmen. Also die Pfeile links und rechts auf
dem
Bildschirm bei offenem Eingang an jeder beliebigen Y-Position mit der
angezeigten Linie der Messwerte überein stimmen. Habe bei mir die Werte
der Dimension 0 (Standard Gain 1) ausgetauscht.
Bei mir (habe 22 Ohm verwendet) sind das jetzt:
float DAC_ScaleFactor[3][5] = {{ 0.84, 0.620, 0.6614, 0.630, 0.619 },
{ 1.68, 1.235, 1.3228, 1.245, 1.238 },
{ 4.2, 3.090, 3.3070, 3.108, 3.108 }};
Dann habe ich beim Messen von verschiedenen Spannungen festgestellt, daß
der angezeigte Wert in allen Bereichen deutlich zu niedrig ist.
Beispiel: Bekannte Spannung: 4.35 Volt, angezeigter Wert: ca 3.0 Volt
Also habe ich den Abweichungsfaktor (1.45) berechnet und damit
exemplarisch den für den 2V-Bereich zuständigen Wert im Array
ScaleFactor multipliziert.
(3.25 -> 4.713)
Geflashed, getestet und gewundert:
Die Messkurve sieht im 2V Bereich exakt genau so aus wie vorher.
Durch Zufall habe ich dann das QuickMeasure aktiviert und siehe da:
QuickMeasure zeigt als Maximum Wert ziemlich genau den gewünschten Wert
von 4.35 Volt an.
Aber: Die roten Linien von QuickMeasure weichen deutlich von der
Messkurve ab. Liegen also weit oberhalb der Messkurve in der oberen
Hälfte des Screens und weit unterhalb in der unteren Hälfte.
Es ist wohl so, daß der Korrekturwert in ScaleFactor das Richtige tut,
lediglich die grafische Ausgabe der Messkurve ist davon unberührt.
(siehe Anhang)
Wo ist mein Denkfehler?
Lothar
Hi Rainer W. and guys all! Rainer W. schrieb: >NORMAL trigger should work, as the Probe Comp signal is a normal square >wave of +/-400 mV and a trigger level of 0 mV is well in the middle of >that range. I agree with You Rainer W. Rainer W. schrieb: >But setting trigger to AUTO didn't change anything. Sorry Rainer W., I thought the problem could be related to the type of trigger used. Mine was only a hypothesis. Rainer W. schrieb: >In case I change the offset of a channel, i.e. the position on the >display, IMO this should not have any influence on my trigger settings Rainer W., I agree, should not have any influence on trigger settings. Rainer W. schrieb: >(and temporarily switching to EDGE trigger set the correct level for the >pulse width detection). Get you the same effect by pressing the RUN/STOP's button? It seems the trigger is no longer acquired so the signal track does not repaint. This would be normal with the trigger set to NORMAL but very strange with the trigger set to AUTO. Rainer W. schrieb: >If trigger has stopped due to channel offset, the LED1 is ON. Well, if I remember correctly LED1 lit is TRIGGER READY for acquisition and LED2 lit is TRIGGERED condition, so the trigger is not captured when the problem occurs or so it seems. Rainer W. schrieb: >"><" works well using the correct settings, but with an a few quirks: >To see the Probe Comp signal, the ">"-value should be well below the >positiv pulse width, ">" + "deltaT" should be well above the positiv >pulse width (e.g. 450us, 100us in Puls_Width_Trigger1.png above). I >temporarily switch to EDGE trigger to get the correct decision level for >the pulse detection. After messing around with "<" or ">"-trigger >settings, i have to touch the ">"-value to start triggering in "><" >mode. Very good Rainer W., thanks You very, very much for the kindly explanation! You were very detailed. Thanks again for the tip Rainer W., now I understand better, so many thanks again Rainer W.! Rainer W. schrieb: >"<" do not works for me (Probe Comp triggers always, independent of "<" >value, trig. NORMAL) Thanks also for this other useful information Rainer W.! Vielen Dank!!! Gruß Luc
Luc schrieb: > Rainer W. schrieb: >>(and temporarily switching to EDGE trigger set the correct level for the >>pulse width detection). > > Get you the same effect by pressing the RUN/STOP's button? No, RUN/STOP didn't do the trick after changing the channel offset ... Rainer
Thomas O. schrieb: > @Hayo: Ich verstehe deinen Erklärung nicht genau, da ich ja beim > scrollen keine Zeitbasis ändere. Ich habe mich da etwas verkehrt ausgedrückt. Es müßte nicht "Pixel" heißen sondern "Wert". Also Wert 1 wird auf Pixel 1 abgebildet, die nächsten 4 Werte werden übersprungen und Wert 5 wird auf Pixel 2 abgebildet, dann Wert 9 auf Pixel 3, Wert 13 auf Pixel 4 usw.. Die Filterroutine basiert auf genau dem gleichen Umstand, nämlich dem ungenutzten Wertevorrat. Die Filterung entsteht dadurch, das die Werte links und rechts vom eigentlichen Ausgangswert zu diesem Wert hinzuaddiert werden und dann das arithmetische Mittel gebildet wird. Solange hierfür nur Punkte verwendet werden die ungenutzt sind und keine Überschneidungen auftreten, liegt die Flanke des dadurch erzeugten Tiefpassfilters oberhalb der halben Abtastbandbreite, es gibt also keine Verluste. Bei einigen TB gibt es aber nur einen kleinen oder gar keinen Wertevorrat (100ns, 50ns -> 2ns). Hier sind Überlappungen nicht zu vermeiden, und die effektive Bandbreite wird etwas eingeschränkt (nur wenig). Gruß Hayo
noch ein kurzer Nachschlag: Die genauen Wertevorräte könnt Ihr Euch in der beigelegten "Programmers Reference" ansehen. Auf dem Arbeitsblatt "Timebase Table" findet Ihr eine Übersicht über die jeweiligen Parameter jeder Zeitbasis. Die Werte in der Spalte "Factor" entsprechen dem Wertevorrat. Je größer der Wertevorrat, desto effektiver kann man ohne Verluste filtern. Der Noisefilter arbeitet daher Je nach eingestellter Zeitbasis unterschiedlich intensiv. Hayo
Hallo Hayo, Ich habe mir etwas den Effekt des "verrauschten" Signals wenn ein mit "Noise Filter" gespeichertes Signal horizontal verschoben wird. Dabei habe ich gesehen das du den gebildeten Mittelwert in den original speicher zurück schreibst, das hat zur folge das im speicher gefilterte und ungefilterte werte stehen, solange nicht horizontal verschoben wird werden die gefilterten werte dargestellt, wenn man aber verschiebt werden je nach pos. die nicht gefilterten werte dargestellt. Dies führt zu dem "rauschen". Eine einfache Lösung währe es die Verschiebung immer um ein vielfaches von "draw_factor" zu machen. (userif_t.cpp Zeile 7503,7504, 7515 7116 und 7526?) Ich hab das mal ausprobiert, scheint soweit zu funktionieren. Danke noch mal für die grosse arbeit die du leistest, Martin
Lothar Merl schrieb: > Jetzt habe ich nach einigen Messungen doch ein kleines > Verständnisproblem: > > In tc_vars.cpp den DAC_ScaleFactor musste ich ändern, damit die > Nullinien > nach der DAC-Kalibrierung stimmen. Also die Pfeile links und rechts auf > dem > Bildschirm bei offenem Eingang an jeder beliebigen Y-Position mit der > angezeigten Linie der Messwerte überein stimmen. Korrekt. Die Anpassung der DAC-Faktoren führt aber gleichzeitig zu einer Änderung der Scalefaktoren und umgekehrt. Man muß sich hier langsam iterativ herantasten. > Habe bei mir die Werte > der Dimension 0 (Standard Gain 1) ausgetauscht. D.h. im Hardwaremenu die Einstellung Gain auf "Factory". > Bei mir (habe 22 Ohm verwendet) sind das jetzt: Mit oder ohne 150Ohm Längswiderstand? > float DAC_ScaleFactor[3][5] = {{ 0.84, 0.620, 0.6614, 0.630, 0.619 }, > { 1.68, 1.235, 1.3228, 1.245, 1.238 }, > { 4.2, 3.090, 3.3070, 3.108, 3.108 }}; Deine Faktoren kommen mir sehr groß vor. Ob das wirklich so passt? > Dann habe ich beim Messen von verschiedenen Spannungen festgestellt, daß > der angezeigte Wert in allen Bereichen deutlich zu niedrig ist. > Beispiel: Bekannte Spannung: 4.35 Volt, angezeigter Wert: ca 3.0 Volt > > Also habe ich den Abweichungsfaktor (1.45) berechnet und damit > exemplarisch den für den 2V-Bereich zuständigen Wert im Array > ScaleFactor multipliziert. > (3.25 -> 4.713) Auch dieser Faktor scheint mir sehr groß zu sein. > Geflashed, getestet und gewundert: Hast Du nach dem Flashen das Gerät resettet? Ansonsten zum Ausprobieren lieber ins RAM laden, das geht schneller und benötigt keinen Reset. > Die Messkurve sieht im 2V Bereich exakt genau so aus wie vorher. Achtung: Neuen DAC-Abgleich nicht vergessen! > Durch Zufall habe ich dann das QuickMeasure aktiviert und siehe da: > QuickMeasure zeigt als Maximum Wert ziemlich genau den gewünschten Wert > von 4.35 Volt an. > Aber: Die roten Linien von QuickMeasure weichen deutlich von der > Messkurve ab. Liegen also weit oberhalb der Messkurve in der oberen > Hälfte des Screens und weit unterhalb in der unteren Hälfte. > Es ist wohl so, daß der Korrekturwert in ScaleFactor das Richtige tut, > lediglich die grafische Ausgabe der Messkurve ist davon unberührt. > (siehe Anhang) Wenn beide Faktoren stimmen, dann stimmen auch die Cursor mit der Messkurve überein. Hayo
Hallo Martin, deine Analyse klingt sehr treffend. Martin H. schrieb: > ... hat zur Folge das im speicher gefilterte > und ungefilterte Werte stehen ... D.h. beim Reinzoomen wird z.Z. eine Mischung von Originalwerten und gemittelten Werten dargestellt, oder? Martin H. schrieb: > Eine einfache Lösung währe es die Verschiebung immer > um ein vielfaches von "draw_factor" zu machen. Für die Verschieberei bei der Originalzeitskala hört sich das gut an. Aber beim Zoomen in der Zeitachse bleibt es, wenn ich das richtig verstehe, trotzdem bei den gemischten Daten. Gruß Rainer
Martin H. schrieb: > Hallo Hayo, > > Ich habe mir etwas den Effekt des "verrauschten" Signals wenn ein mit > "Noise Filter" gespeichertes Signal horizontal verschoben wird. Dabei > habe ich gesehen das du den gebildeten Mittelwert in den original > speicher zurück schreibst, das hat zur folge das im speicher gefilterte > und ungefilterte werte stehen, Ja das ist korrekt. Mein Ansatz wäre daher auch ein Anderer. Ich bin am Überlegen, ob ich den gefilterten Werten einen eigenen Speicher spendiere (so wie den interpolierten Werten), da ich damit gleich mehrere Probleme gleichzeitig erledigen könnte. Ich prüfe noch ob ich evtl. den Speicherbereich der interpolierten Werte mitbenutzen könnte. Gruß Hayo @Rainer damit wäre Dein Thema dann auch erledigt
das wäre eine Lösung den vom langsamen Speicher ist ja genug da.
Angehängte Dateien:
-
1V_Bereich.jpg
54 KB -
2V_Bereich.jpg
50 KB
Hayo W. schrieb: > Korrekt. Die Anpassung der DAC-Faktoren führt aber gleichzeitig zu einer > Änderung der Scalefaktoren und umgekehrt. Man muß sich hier langsam > iterativ herantasten. Ay Caramba! >> Habe bei mir die Werte >> der Dimension 0 (Standard Gain 1) ausgetauscht. > > D.h. im Hardwaremenu die Einstellung Gain auf "Factory". Genau. Da die Werte ohnehin mit 1.25 identisch und somit eigentlich obsolet sind (?). >> Bei mir (habe 22 Ohm verwendet) sind das jetzt: > > Mit oder ohne 150Ohm Längswiderstand? Mit 150 Ohm Abschluss. >> float DAC_ScaleFactor[3][5] = {{ 0.84, 0.620, 0.6614, 0.630, 0.619 }, >> { 1.68, 1.235, 1.3228, 1.245, 1.238 }, >> { 4.2, 3.090, 3.3070, 3.108, 3.108 }}; > > Deine Faktoren kommen mir sehr groß vor. Ob das wirklich so passt? 100%ig. Nur mit diesen Werten bekomme ich die Nullinie nach DAC Abgleich hin. >> Also habe ich den Abweichungsfaktor (1.45) berechnet und damit >> exemplarisch den für den 2V-Bereich zuständigen Wert im Array >> ScaleFactor multipliziert. >> (3.25 -> 4.713) > > Auch dieser Faktor scheint mir sehr groß zu sein. Naja, kam mir ehrlich gesagt auch etwas groß vor, aber nur damit stimmen die Werte vom QuickMeasure anschließend. >> Geflashed, getestet und gewundert: > > Hast Du nach dem Flashen das Gerät resettet? Ansonsten zum Ausprobieren > lieber ins RAM laden, das geht schneller und benötigt keinen Reset. Schneller ist's nicht, da ich den Windows Firmware-Loader nutze. Würde auch lieber die Entwicklungsumgebung unter Linux laufen lassen, als unter Cygwin. Habe aber in der Richtung noch nichts unternommen. (Gibt es irgendwo ein entsprechendes Package?) Aber das ist 'ne andere Baustelle. Oszi (immer!) nach dem Flashen aus...21...22...23...an. >> Die Messkurve sieht im 2V Bereich exakt genau so aus wie vorher. > > Achtung: Neuen DAC-Abgleich nicht vergessen! Mache ich ebenfalls nach jedem Flashen: Utility Menu -> Default Setup -> Cal. ADC -> Cal. DAC >> Es ist wohl so, daß der Korrekturwert in ScaleFactor das Richtige tut, >> lediglich die grafische Ausgabe der Messkurve ist davon unberührt. >> (siehe Anhang) > > Wenn beide Faktoren stimmen, dann stimmen auch die Cursor mit der > Messkurve überein. Genau das ist mein Problem: INTERN scheint alles zu stimmen. Bei Quick Measure werden die roten Cursor Linien bei den richtigen Werten eingeblendet und auch die Digitalanzeige zeigt die richtigen Werte. Nur die Messkurve weiss davon nichts. Siehe auch mein Attachment im letzten Posting. Zur Verdeutlichung habe ich nochmal was angehängt. Ein 4 Vpp Sinus, den ich mit einem Philips Skope zur Kontrolle gemessen habe. Im ersten Bild sieht man das Signal im 1V/div Messbereich. Eingangsverstärker mit 22 Ohm / 150 Ohm modifiziert, aber nur Anpassung der DAC_ScaleFactor Werte. Wie erwartet wird ein zu kleiner Wert angezeigt. Im zweiten Bild dieselbe Messanordnung. Lediglich den Bereichsschalter habe ich auf 2V/div umgeschaltet. Der 2V Bereich hat die oben erwähnten neuen Skalierungsfaktoren. Man sieht, dass der Quick Measure Wert und die roten Cursor Markierungen halbwegs passen, nicht aber die Messkurve. Scratching my head... Lothar
Lothar Merl schrieb: > Genau. Da die Werte ohnehin mit 1.25 identisch und somit eigentlich > obsolet sind (?). Nein, nur die 5V-Bereiche sind gleich, da diese immer mit Gain 1,25 laufen. 2V und 1V sind unterschiedlich. Hast Du Dich da in den Spalten und Zeilen verhauen? > 100%ig. Nur mit diesen Werten bekomme ich die Nullinie nach DAC Abgleich > hin. Da Du den 150Ohm Widerstand drin hast, müßten die Faktoren von Jürgen eigentlich fast passen, da er diese für 24,9 Ohm augetüftelt hat. Der Unterschied dürfte nur minimal sein. Hast Du die 24 Ohm Einstellung in der aktuellen 2.0 mal ausprobiert? > aber nur damit > stimmen die Werte vom QuickMeasure anschließend. Nimm nicht Quickmeasure. Nimm die manuellen Cursor! Damit lässt sich genauer arbeiten und man vertut sich nicht so leicht mit der Messfunktion. > Schneller ist's nicht, da ich den Windows Firmware-Loader nutze. > Würde auch lieber die Entwicklungsumgebung unter Linux laufen > lassen, als unter Cygwin. Der Loader ist unabhängig von der Entwicklungsumgebung. Du must nur Active Perl installieren und kannst dann das beigelegte Perlskript benutzen. Anleitung findest Du im Doc-Ordner. > Oszi (immer!) nach dem Flashen aus...21...22...23...an. Reset reicht, das schont den Schalter (Erst den 2ten Softkey drücken und halten, dann den ersten Softkey kurz drücken also genau andersherum als beim Flashen) Hayo
Hayo W. schrieb: > Nein, nur die 5V-Bereiche sind gleich, da diese immer mit Gain 1,25 > laufen. 2V und 1V sind unterschiedlich. Hast Du Dich da in den Spalten > und Zeilen verhauen? Kann ich nicht ausschließen - muß ich prüfen. > >> 100%ig. Nur mit diesen Werten bekomme ich die Nullinie nach DAC Abgleich >> hin. > > Da Du den 150Ohm Widerstand drin hast, müßten die Faktoren von Jürgen > eigentlich fast passen, da er diese für 24,9 Ohm augetüftelt hat. Der > Unterschied dürfte nur minimal sein. Hast Du die 24 Ohm Einstellung in > der aktuellen 2.0 mal ausprobiert? Habe ich jetzt mal probiert. Passt tatsächlich in etwa. In den 5/2/1V Bereichen habe ich eine relativ konstante Abweichung. Statt der anliegenden 4.08V Gleichspannung zeigt das Oszi 3.79/3.76/3.78 Volt an. Gemessen mittels manuelle Cursor. Ein bisschen daneben steht der Nullpunktabgleich im 5V Bereich. Vertikal zentriert liegt die Kurve genau auf der GND-Markierung. Verschiebe ich aber die Kurve an den oberen/unteren Rand, liegt die angezeigte Kurve um geschätzte 0.7 Volt über bzw. unter der GND-Markierung. Aber das ist zu verschmerzen. > Der Loader ist unabhängig von der Entwicklungsumgebung. Du must nur > Active Perl installieren und kannst dann das beigelegte Perlskript > benutzen. Anleitung findest Du im Doc-Ordner. Ja, ich weiß. Active Perl könnte ich auch installieren. Entwickle nue generell lieber unter Linux. Werde einstweilen mal bei der 24Ohm Einstellung bleiben. Wäre interessant zu wissen, mit welchem Verfahren Jürgen seine Werte gefunden hat. Oder habe ich das überlesen? Mein Ansatz: Aus angezeigtem und Sollwert Korrekturfaktor berechnen und diesen Faktor auf die bestehenden Scale-Werte anwenden scheint ja wohl suboptimal zu sein. Lothar
Berechnen kannst Du Dir schenken, das hab ich auch mal versucht, ging aber auch in die Hose. Die Abhängigkeiten sind sind so fein miteinander verwoben, dass es am Besten geht, wenn man sich von bestehenden Werten Stück für Stück vortastet. Also am Besten die Spalte für die 24 Ohm jeweils für beide Arrays kopieren in die erste Spalte und dann die Werte für jeden Messbereich einzeln anpassen. Als Erstes die DAC-Scalefaktoren im Nachkommabereich leicht verändern und dann am Gerät überprüfen. Dann die Scalefaktoren nachziehen. Danach wieder die DAC-Scalefaktoren prüfen, denn die Nulllage verändert sich unter Umständen bei der letzten Änderung nochmal. Ist etwas fummelig, aber mittlerweile deutlich einfacher als früher. Dafür brauchst Du aber auf jeden Fall das Perlskript, sonst bist Du da mehrere Wochen dran. Das Perlskript braucht für das Flashen nur knappe 3 Minuten. Hayo
Lothar Merl schrieb: > Werde einstweilen mal bei der 24Ohm Einstellung bleiben. > > Wäre interessant zu wissen, mit welchem Verfahren Jürgen seine Werte > gefunden hat. Aber gern :-) - einen Kanal in die Mitte kurbeln 1. zuerst Verstärkungsabgleich ( Scalefactor ) - AC mit bekannter Amplitude ( oder auch DC ) an den Kanal anlegen - die Spitzen sollen möglichst oben oder unten am Bildschirmrand liegen - Faktor zwischen Soll- und Istanzeige ermitteln und mit vorhandenem Faktor aus der Liste multiplizieren = neuer Scalefactor - fuer 1-er und 2-er ein Faktor und fuer 5-er ein Faktor! 2. dann DAC_Scalefaktor im 5-er Bereich ermitteln - dazu Kanal ohne Signal an den oberen Bildschirmrand kurbeln und Faktor zwischen 0-Linie und vorhandener Strahlline berechnen und mit vorhandenem 5-er Faktor aus der Liste multiplizieren = neuer DAC_Scalefaktor fuer 5-er - der 2-er und der 1-er ist jeweils genau 0,5 x dem 5-er Faktor 3. Software übersetzen und flashen und DAC-Abgleich durchführen 4. die Prozedur noch 1x bis 2x durchführen 5. Fertig Alles ohne Garantie und gültig für 24,9 Ohm und 150 Ohm! Gruß Jürgen
Angehängte Dateien:
-
screenshot-0038.jpg
42 KB
Hi Rainer W., Hayo and guys all!
Rainer W. schrieb:
>No, RUN/STOP didn't do the trick after changing the channel offset ...
Many thanks for the information Rainer W.!
I tried with my W2022A and I too have encountered the same problem.
Exact, RUN/STOP button do not fix it also for me instead temporarily
switching to EDGE trigger set the correct level for the pulse width
detection.
It seems the trigger is no longer acquired but I do not know, I am
sorry...
You can see a screenshot.
However, thanks to your suggestions I did some tests with my W2022A and
finally I was able to use the trigger in PULSE WIDTH mode without
problem!
It works on my W2022A but with a W2012A is what I wrote in previous
posts.
The only problem is the same as you've reported Rainer W., so thank You
very much!:-)
@Hayo.
I'm still playing with the external trigger.
This time I used my W2022A so I found some curious things.
First, the W2022A seems to me works better with EXTERNAL TRIGGER
compared to my friend's W2012A.
LF Reject and HF Reject work very well!!!
I am not sure because I have no tried with the W2012A and new 1.2.BF.2.0
firmware release, so could be the new firmware that runs better the DSO.
However, again congratulations for the excellent work Hayo!!!
Talking about other.
In SAVE/RECALL menù what the function of the Restore Settings button is?
Once I pressed that button, the relays are triggered and then the
waveforms were distorted with NOISE FILTER inserted but NORMAL and
AVERAGEGE work well.
I was able to make a screenshot but then I've deleted it by mistake.
However, the probes's compensation signal seems to be a low resolution
digital sinusoid, roughly looks like a square wave superimposed on a
sinusoid.
I fix with Default Setup in UTILITY menù.
Now when I press the Restore Settings button in the SAVE/RECALL menù
then the DSO show settings for channel 2.
No really problem but rather curious.
Vielen Dank!!!
Gruß Luc
Hallo Hayo und Jürgen, danke für die Info! Habe inzwischen das Perlscript am Start, aber nicht unter Windows, sondern unter Cygwin. Da klappt die automatische Installation des Perl-Moduls nicht, aber von Hand geht's dann. Jetzt bin ich auch mit 3min/Test dabei. Jürgen, da war recht genau auch meine Vorgehensweise. Allerdings in anderer Reihenfolge. Ich hatte zuerst die DAC-Scales angepasst. Werde es jetzt mal mmit Deiner Methode versuchen. Macht ja auch mehr Sinn. Dank! Lothar
Hallo! Nach langer Abstinenz melde ich mich mal wieder. Ich finde es wäre an der Zeit für das LEON3 Design einmal ein "Klassendiagramm" zu erstellen. Mir ist schon klar, dass es in C keine Klassen gibt, aber man kann und sollte diese in einer ähnlichen Weise nachbauen. So unterschiedlich die HW-Ansteuerung (Signalerfassung + Display) zum Nios Design sein wird, so ähnlich kann die Bedienung ausfallen. Am besten wäre es, die Gemeinsamkeiten zu Kapseln und die Unterschiede als "Low-Level Treiber" einzubinden. Mir wäre auch sehr geholfen, wenn es ein fertig dokumentiertes Klassendiagramm über die NIOS GUI gäbe. Das würde auch der BF-Version weiterhelfen. Gibt`s da schon irgendwelche brauchbaren Modellierungsprogramme, die unter Windows und Linux gleichermaßen laufen? Ein Tipp für Hayo und alle anderen: Einen schnellen IIR-Filter (z.B. Noise-Filter) bekommst du mit der Berechnung: y[k+1] = y[k] + (x[k]-y[k])/(2^x) ... 2 Additionen + eine Schiebeoperation. Das würde hier Sinn machen, wenn der NIOSI keinen (schnellen) Multiplizierer hat. Falls man mit dem mehrmals über den Puffer fährt, erreicht man ein sehr steilflankiges Filter ohne Überschwinger. Als Interpolationsfilter schlage ich einen Polyphaseninterpolator vor (Effizienter FIR-Filter mit integrierter Interpolation). Das liegt schon im lange bei mir Repository, sowas habe ich schon für das erste Demo, welches mir dankenderweise Bruno zusammengeschnitten hatte, implementiert. Manchmal möchte man auch so einen stark Bandbegrenzten IIR-Filter als Math Funktion haben, macht bspw. bei PWM-Signalen oder extrem verrauschen Signalen Sinn. @Hayo und Co Gratulation! Eure Verbesserungen können sich schon sehen lassen, gegenüber der Originalversion ist das Oszi schon wirklich gut und gebrauchsfähig geworden. Gegen die unlösbaren HW-Bugs (Trigger,...) im NIOS-Design kann nur ein neues VHDL-Design helfen. Leider wird die Entwicklung hierfür warscheinlich noch sehr lange Dauern. MfG Alexander
Hallo Leute, lässt sich eigentlich auch noch eine Equivalent Sampling einbauen damit z.B. die hochfrequenten Sinüsse nicht mehr so eckig sind? Mfg, Kurt
@Alex
Im Prinzip rechnet Deine IIR-Routine genauso wie meine Filterroutine
(Erst addieren dann shift), nur dass bei mir die Berechnungstiefe je
nach Zeitbasis variiert. Trotzdem werde ich mal Deine Routine einbauen
und testen, vielleicht lässt sich da noch was rausholen.
Für die Interpolation würde ich lieber eine sin(x)/x Interpolation
verwenden, aber leider habe ich dazu bislang nur theoretische
Abhandlungen gefunden, aber nichts was sich direkt in Coding umsetzen
ließe. Hast Du da vielleicht brauchbares Material?
@Kurt,
> lässt sich eigentlich auch noch eine Equivalent Sampling einbauen
das muß ich mal prüfen. Wenn ja dann machen wir das auch...
Ansonsten macht das Noise Filter doch auch schon ein ganz gute Figur.
Gruß Hayo
Wenn ich das richtig verstanden habe, braucht man für Equivalent Sampling u.a. ja einen sehr zuverlässigen Trigger - da hapert es ja noch ein wenig (wenn es durch das Design überhaupt besser geht...) Viele Grüße, Mirko
@Hayo habe jetzt die 2.0 aufgespielt - konnte den Bug im Delayed-Mode nicht mehr reproduzieren. Hast du fein gemacht :-) Viele Grüße, Mirko
Hallo allerseits. Ich weiß es gab gerade eine neue Version, aber ich war gerade kreativ. Was ist neu - what is new? - Sample rate bug fixed (Sampleraten wurden falsch angezeigt) - neues zweistufiges Noise Filter (Acquire Menu) - Vorbereitung für verschiedene Interpolationen (Acquire Menü) - neue Screenshot version 1.6.BF - 2x Beep nach Screenshot -> nur für die Windows Version (Windows only!) Gruß Hayo
Ach ja, schnell noch angemerkt: - nach dem flashen wird die Hardwareeinstellung auf default zurückgesetzt. Ihr müßt also die Einstellungen neu machen und einen Abgleich machen Please notice that the hardware settings will be set to default. So You have to set again and calbrate Your DSO new. Hayo
Hi Hayo and guys all! Hayo W. schrieb: >Ich weiß es gab gerade eine neue Version, aber ich war gerade kreativ. > >Was ist neu - what is new? > >- Sample rate bug fixed (Sampleraten wurden falsch angezeigt) >- neues zweistufiges Noise Filter (Acquire Menu) >- Vorbereitung für verschiedene Interpolationen (Acquire Menü) >- neue Screenshot version 1.6.BF - 2x Beep nach Screenshot -> nur für >die Windows Version (Windows only!) Oh boys! Hayo, as usual You leave me speechless!!! No words... RESPECT!!! I'm running now to try this new release! Hayo, thanks also for the snapshot implementation of my request about the possibility to have an audible alarm in the screenshots management software. You are really great, thank You very, very, very much!!! RESPECT!!!, RESPECT!!!, RESPECT!!! Again thanks You very, very much Hayo for the great job and free time You provided generously to us!!! Vielen Dank!!! Gruß Luc
Hi Hayo and guys all! Hayo W. schrieb: >- neue Screenshot version 1.6.BF - 2x Beep nach Screenshot -> nur für >die Windows Version (Windows only!) Hayo, thanks for this new feature in the new 1.2.BF.2.1 firmware release, it makes me happy! An audible alarm in the screenshots management software may seem unnecessary, but not always is so. I should make room in my laboratory but I do not have time and space is what it is, so for my test I put the DSO behind the computer. In this way I can not see the computer's screen and when I send a screenshot on the computer I have to go from the DSO to the PC's monitor to verify that the acquisition is complete before sending the next. This is not easy because there is no room and so to save screenshots with the DSO is a big problem and a waste of time. Here is the reason for my unusual request. Now thanks to your excellent work done screenhot is no longer a problem, I do it in full relax without wasting time!!! Really amazing, so thanks You very, very much Hayo also for this your masterpiece!!! I'm doing some testing with your new firmware and I'm very satisfied. For now, I have not done much testing, I think, however, it is perfect and very stable rock solid I say!!! Very impressive your implementation of Kurt Bohnen's suggestion. Very well also for the alex008's suggestion add, even if this is no active now. Over the weekend I hope to do some tests. However I repeat that this your latest firmware version is very impressive, the difference with the original Welec's firmware is dramatic! Hayo, You are really great, thank You very much! Vielen Dank!!! Gruß Luc
Es ist mal wieder soweit, die BF.2.2 ist fertiggestellt mit zahlreichen Verbesserungen und Fixes. Heute bin ich zu müde, aber morgen (eigentlich heute) werde ich die neue Version mit den entsprechenden Erklärungen hochladen. New BF.2.2 is ready now. For I'm too tired now I will load up the new version tomorrow (today) Gruß und guten morgen Hayo
Danke Hayo, ich warte schon ganz gespannt :) einen schoenes WE vlg Charly
Hi Hayo and guys all! Hayo W. schrieb: >Es ist mal wieder soweit, > >die BF.2.2 ist fertiggestellt mit zahlreichen Verbesserungen und Fixes. >Heute bin ich zu müde, aber morgen (eigentlich heute) werde ich die neue >Version mit den entsprechenden Erklärungen hochladen. Hayo, thank You so much! I'm eager to try it, thank You very, very, very much!!! You are very kind and tireless. Hayo i wish You a good weekend. RESPECT!!! Vielen Dank!!! Gruß Luc
Ok, genau richtig zum Abendlichen rumspielen die neue Version. Es gibt jetzt eine reichhaltige Auswahl an Filtern, es sollte für jeden was dabei sein. Neu sind die IIR-Filter, angeregt durch Alex. Die Filter haben folgende Eckfrequenzen (cutoff frequency) bei 1GSa/s: - Smooth ca. 80 - 90Mhz -> in allen anderen TB liegt die Cut Off Frequ. bei der halben Abtastrate, ist also verlustfrei. - Strong ca. 30 Mhz -> durch die große Überlappung wird hier ordentlich was abgeschnitten - IIR 1 Stage ca. 70 - 80Mhz einstufiges IIR-Filter mit Koeffizient 0.5 - IIR 2 Stage ca. 35 - 40Mhz zweistufiges IIR-Filter Koeffizienten 0.5 - IIR 3 Stage ca. 20MHhz dreistufiges IIR-Filter - echt brutal!! Das Teil bügelt alles platt. Koeffizienten 0.5/0.5/0.25 Ich habe den Filtern jetzt eigene Speicherbereiche für den Ausgang spendiert. Was heißt das? Man kann jetzt im Stop-Mode nach Herzenslust scrollen, es wird jetzt durch den Filterbuffer gescrollt. Man kann sogar im Stop-Mode den Filter umschalten und sieht sofort die Veränderung - echt cool finde ich. Weiterhin habe ich die Cursorroutinen überarbeitet, neue Drehgeberkennlinie, schnellere Werteberechnung und was mich vorher immer gestört hat - in den TB 20ns/10ns/5ns/2ns konnte man nur in einem sehr groben Raster hoppeln. Jetzt geht es Pixelgenau. Da ich aus Zeitgründen nicht alles bis ins Detail testen konnte schaut doch bitte mal ob ich noch was übersehen habe. Noch zwei Hinweise: - bei Kanal 1 läßt sich der Spannungsbereich bis 1 mV herunterdrehen, das ist aber ohne brauchbaren Effekt und nur zum Testen. Ich hab einfach vergessen es wieder abzuschalten. Mach ich bei der nächsten Version. - Wegen der neuen Werte im Flash wird wieder alles auf default gesetzt. Ihr müßt also alles neu einstellen und kalibrieren! All settings are resetted to default. Please adjust your hardwaresettings! Calibration is recommended!! Gruß Hayo
Hi Hayo, der Autotriggerlevel funzt nicht mehr, kann das sein? Gruß Michael
Das würde mich doch wundern, muß ich mal prüfen, aber an der Sache war ich nicht dran. Hayo
Hab's grad mal geprüft, bei mir funktioniert alles wie es soll. Hast Du den richtigen Source Channel eingestellt? Gruß Hayo
Hi Hayo and guys all! Hayo again thanks You very, very much for the great job and free time You provided generously to us!!! You are tireless and very kind! No words. Hayo W. schrieb: >Es gibt jetzt eine reichhaltige Auswahl an Filtern, es sollte für jeden >was dabei sein. Neu sind die IIR-Filter, angeregt durch Alex. > >Die Filter haben folgende Eckfrequenzen (cutoff frequency) bei 1GSa/s: > >- Smooth ca. 80 - 90Mhz -> in allen anderen TB liegt die Cut Off Frequ. >bei der halben Abtastrate, ist also verlustfrei. > >- Strong ca. 30 Mhz -> durch die große Überlappung wird hier ordentlich >was abgeschnitten > >- IIR 1 Stage ca. 70 - 80Mhz einstufiges IIR-Filter mit Koeffizient 0.5 > >- IIR 2 Stage ca. 35 - 40Mhz zweistufiges IIR-Filter Koeffizienten 0.5 > >- IIR 3 Stage ca. 20MHhz dreistufiges IIR-Filter - echt brutal!! Das >Teil bügelt alles platt. Koeffizienten 0.5/0.5/0.25 Very impressive. Hayo, since You're improving the Acquire menu and even though I've already asked, would it be possible to add Peak Detect and modify the AVERAGE's menu in order to adjust the averages number in acquisition mode? I apologize for my rudeness, so sorry Hayo. Hayo W. schrieb: >Ich habe den Filtern jetzt eigene Speicherbereiche für den Ausgang >spendiert. Was heißt das? > >Man kann jetzt im Stop-Mode nach Herzenslust scrollen, es wird jetzt >durch den Filterbuffer gescrollt. Man kann sogar im Stop-Mode den Filter >umschalten und sieht sofort die Veränderung - echt cool finde ich. Hayo You are right, it is really very cool, thank You very much! I do not know how You can do these things, I can not wait to try it! Hayo W. schrieb: >Weiterhin habe ich die Cursorroutinen überarbeitet, neue >Drehgeberkennlinie, schnellere Werteberechnung und was mich vorher immer >gestört hat - in den TB 20ns/10ns/5ns/2ns konnte man nur in einem sehr >groben Raster hoppeln. Jetzt geht es Pixelgenau. This is really incredible! Hayo, I wanted to ask You if You could do it but I did not have the courage... Hayo You're too big! Thanks You very, very much for the great improvement! Hayo W. schrieb: >- bei Kanal 1 läßt sich der Spannungsbereich bis 1 mV herunterdrehen, >das ist aber ohne brauchbaren Effekt und nur zum Testen. Ich hab einfach >vergessen es wieder abzuschalten. Mach ich bei der nächsten Version. OK this is only for testing and of no useful effect but it is interesting to be able to take a look at it. Also this is something I've always wanted to try even if only for test. Hayo I wish You a good Sunday. RESPECT!!! Vielen Dank!!! Gruß Luc
Luc schrieb: > Hayo, since You're improving the Acquire menu and even though I've > already asked, would it be possible to add Peak Detect and modify the > AVERAGE's menu in order to adjust the averages number in acquisition > mode? I will try to improve the Average Function, but it is realized in Assembler. So it might be a little bit tricky... Please describe the function of Peak Detect. What should it do? What should be shown on the screen? Regards Hayo
Angehängte Dateien:
-
01_48MHz_Noise-OFF.PNG
6,5 KB -
03_48MHz_Noise-STRONG.PNG
6,5 KB -
02_48MHz_Noise-SMOOTH.PNG
6,2 KB -
04_48MHz_Noise-1-STAGE.PNG
6,2 KB -
05_48MHz_Noise-2-STAGE.PNG
6 KB -
06_48MHz_Noise-3-STAGE.PNG
5,9 KB -
Bonbon.PNG
4,1 KB
Komisch, kann das jetzt garnicht mehr reproduzieren, vielleicht ein
Schluckauf?
>Hast Du den richtigen Source Channel eingestellt?
Wenn ein Kanal weggeschaltet wird, ändert sich der Source Channel
automatisch auf den noch vorhandenen Channel.
Ansonsten ist der Triggerlevel Gelb oder Grün...
Hier mal ein 48MHz (soll ein Rechteck sein) Signal mit deinen Filtern!
Ch.1 ist ein Selbstbaukopp mit 10/1 Teiler
Ch.2 ist der Welec-Prob/200MHz mit 10/1 Teiler
Noise OFF, SMOOTH, STRONG, 1-STAGE, 2-STAGE, 3-STAGE
zum Schluss ein Bonbon :)
Gruß Michael
Hi Hayo and guys all! Hayo thanks for your prompt reply, You're very kind! Hayo W. schrieb: >I will try to improve the Average Function, but it is realized in >Assembler. So it might be a little bit tricky... Sorry Hayo, I did not know. I do not want to abuse your kindness and your patience. However, as usual, I thank You! Hayo W. schrieb: >Please describe the function of Peak Detect. What should it do? What >should be shown on the screen? something like this: Hayo W. schrieb: >Der TDS220 kann die Signaländerungen zwischen den später gespeicherten >Abtastpunkten erkennen, wenn er im Peak Detect Mode läuft: >"Peak Detect - High frequency and random glitch capture; captures >glitches as narrow as 10 ns using acquisition hardware at all time/div >settings between 5 µs/div and 5 s/div." From the TDS 200-Series Service Manual: Peak Detect Response captures 50% or greater amplitude of pulses ≥10 ns wide (5 s/div to 5 us/div) in the center 6 vertical divisions. The oscilloscope reverts to Sample mode when the sec/div (Horizontal scale) setting is from 2.5 us/div to 5 ns/div. The Sample mode can still capture 10 ns glitches. From the TDS 200-Series User Manual: Peak Detect. In this acquisition mode, the oscilloscope finds the highest and lowest values of the input signal over a sample interval and uses these values to display the waveform. In this way, the oscilloscope can acquire and display narrow pulses, which may have otherwise been missed in Sample mode. Noise will appear to be higher in this mode. Many thanks Hayo and best regards. Vielen Dank!!! Gruß Luc
Hi Hayo and guys all! @Hayo I am trying new software and I find it perfect! It is impressive, it seems to me to use a different DSO!!! If I did not see at it with my eyes I can not believe at it, really incredible!!! Then all the trigger's functions seem to me much more stable, the trigger works fine even at high frequencies and in all circumstances!!! Is really how to use a different DSO, a new DSO!!! No words, RESPECT!!! Gute Sonntag an alle Vielen Dank!!! Gruß Luc
Angehängte Dateien:
-
Zoom1.png
3,2 KB -
Zoom2.png
3,1 KB -
Zoom3.png
3,1 KB -
Filter_IIR3.png
3,1 KB -
Filter_IIR2.png
3,1 KB -
Filt2_off.png
4 KB -
Filt2_IIR2.png
3,8 KB -
Filt2_IIR3.png
3,7 KB
Hi Hayo, DANKE für den Großumbau bei der Filterei. Die Lösung mit den getrennten Speichern und der Möglichkeit zur Offline-Änderung der Filtercharakteristik finde ich sehr gut. Folgendes Schönheitsproblem hat sich da noch aufgetan: Nach Signalerfassung (Single) greift die Darstellungsroutine nach einer Verkleinerung des Zoom-Faktors unter bestimmten Bedingungen anscheinend am Ende auf ungültige Speicherbereiche zu. Das passiert sowohl mit als auch ohne Filter. Z.B. 1. Messung Single, Trig norm mit 2 ms/div 2. Pan auf Speicherende (ganz nach rechts, Zoom3.png) 3. Zoom auf 500 us/div und Pan ganz nach rechts 4. Zoom auf 1 ms/div (Zoom1.png, -> Fehlerhafte letzte Pixel) 5. Zoom auf 2 ms/div (Zoom2.png, -> Fehlerhafte letzte Pixel) 6. Pan Knopf berühren (Zoom3.png, -> Signal springt nach rechts, Darstellung ok) Der Sprung unter (6) deutet fast auf einen zunächst falsch initialisierten Pointer/Schleifenzähler hin, oder? p.s. Mit Probe Comp Signal und Messung bei 200 us/div sieht man's genauso. IIR3-Bias: Dann ist mir beim IIR3 Filter noch aufgefallen, dass die ausgegebenen Werte nicht ganz bias-frei sind. Ein Vergleich von Filter_IIR2.png und Filter_IIR3.png zeigt, dass zu Anfang die Nulllinie stimmt und nach dem erstem Puls mit IIR3 ein nach oben verschobener Pegel auftritt. In Filt2_xxx.png sind die Y-Cursor auf das ungefilteren Probe-Comp-Signal eingestellt. Besonders beim IIR3 rutscht das Signal deutlich hoch und ganz vorne sieht man ein Einpegeln, was sich vielleicht mit einer geeigneten Filterinitialisierung (z.B. mit Signalmittel der ersten Punkt?) noch etwas aufhübschen läßt. Anregung zu X-Cursorn: Momentan beziehen sich die als Cursorposition angegebenen Zeiten immer auf die Bildschirmposition, was eigentlich ziemlich belanglos ist. Ich wäre dafür, die Zeiten auf den Triggerzeitpunkt zu beziehen, so dass man unabhängig von Zoom- und Panfunktionen einen festen Bezug zum Signal hat. Wie ist die allgemeine Meinung dazu? Danke noch mal für dein klasse Arbeit. Gruß Rainer
Hallo Allerseits, auf die Frage nach freie Programmieradresse(n) für die LMH6518 – Platinen: Ich hab mein 4-Kanal Oszi untersucht und einiges über die Schieberegister-Struktur ermittelt. Es scheint mir jetzt, die Programmierung doch einfach integrieren zu können – dazu brauche ich aber noch einige Informationen bzw Bestätigungen: Auf Adresse 0 habe ich keinen angeschlossenen Schieberegister finden können. - Meine Frage an alle Programmierer: taucht die Adresse 0 in den Programmiersequenzen überhaupt auf und wofür? - 2. Frage: Welche Funktionen beeinflusst U26 (Adr. 2) – das IC befindet sich neben der RS232 - Buchse? Und wie viel bits werden dafür belegt – 8 16 24 ? - nach meinen Messungen und laut Schaltplan nur 8? - 3. Frage: Adr. 3 scheint nur für 4-Kanal-Geräte benutzt zu werden. Wie viel bit werden dafür belegt – 8 16 24 ? - nach meinen Messungen nur 8? - 4. Frage: Auf Adr. 5 werden U22 (8bit) sowie U24(8bit) programmiert. Sind es tatsächlich nur 16 bit, die auf diese Adr. eine Bedeutung haben? - 5. Frage: - an alle, die ein 2-Kanal-Gerät haben und Fotos von der PCB-Bestückung posten können damit ich sehen kann, welche ICs bei den Kanälen 3 und 4 bestückt sind (der Bereich um die AD8131 - ICs)? Gruß Walter
Angehängte Dateien:
-
Puls_Trig.png
3,7 KB
Hi Hayo,
mit dem Puls Width Trigger habe ich gerade ein Brett vorm Kopf.
Mir gelingt es nicht, eine minimale Pulsbreite (">"-Wert) von hier z.B.
1.45 ms einzustellen.
Unterhalb von 1.0 ms ändert sich der Wert in Schritten von 1 us und ab
1.0 ms geht es gleich mit Siebenmeilenstiefeln in Schritten von 1 ms
weiter.
Gibt es da einen Trick?
Schönen Sonntag an alle.
Gruß
Rainer
Rainer W. schrieb: > Folgendes Schönheitsproblem hat sich da noch aufgetan: > Nach Signalerfassung (Single) greift die Darstellungsroutine nach einer > Verkleinerung des Zoom-Faktors unter bestimmten Bedingungen anscheinend > am Ende auf ungültige Speicherbereiche zu. Das passiert sowohl mit als > auch ohne Filter. Hmm, hat bei mir irgendwie nicht geklappt. > IIR3-Bias: > Dann ist mir beim IIR3 Filter noch aufgefallen, dass die ausgegebenen > Werte nicht ganz bias-frei sind. Ein Vergleich von Filter_IIR2.png und > Filter_IIR3.png zeigt, dass zu Anfang die Nulllinie stimmt und nach dem > erstem Puls mit IIR3 ein nach oben verschobener Pegel auftritt. Ich hab mal etwas genauer getestet. Das könnte der Gleichspannungsanteil des Rauschens sein. Der Offset der da auftritt ist abhängig von der Stärke der Filterung und ist nur maximal so groß wie der Rauschpegel. Das Einschwingen hab ich beseitigt indem ich einfach etwas früher (also außerhalb des Bildschirms) mit der Berechnung anfange. > Anregung zu X-Cursorn: > Momentan beziehen sich die als Cursorposition angegebenen Zeiten immer > auf die Bildschirmposition, was eigentlich ziemlich belanglos ist. Ich > wäre dafür, die Zeiten auf den Triggerzeitpunkt zu beziehen, so dass man > unabhängig von Zoom- und Panfunktionen einen festen Bezug zum Signal > hat. Wäre machbar, aber bringt das denn einen Vorteil? Bislang fand ich das so ganz ok. Gruß Hayo
Rainer W. schrieb: > Hi Hayo, > > mit dem Puls Width Trigger habe ich gerade ein Brett vorm Kopf. > Mir gelingt es nicht, eine minimale Pulsbreite (">"-Wert) von hier z.B. > 1.45 ms einzustellen. > Unterhalb von 1.0 ms ändert sich der Wert in Schritten von 1 us und ab > 1.0 ms geht es gleich mit Siebenmeilenstiefeln in Schritten von 1 ms > weiter. > > Gibt es da einen Trick? Kein Trick! Diese Zählweise hat der WELEC-Programmierer bei allen vergleichbaren Funktionen so implementiert. Dadurch kann man bestimmte Werte nicht einstellen!!! Offenbar hat er sich wohl gedacht, dass man es oberhalb der jeweiligen 3er Potenz nicht genauer braucht. Da grübel ich schon einige Zeit drüber nach, wie man das verbessern könnte ohne sich einen Wolf kurbeln zu müssen. Hast Du Vorschläge? Gruß Hayo
Ciao a tutti e grazie ancora ad Hayo per il grandioso lavoro! Grazie grazie, ora è ancora migliore! Segnalo un piccolo problema, visualizzando il segnale di test a 1KHz, dopo lo stop e lo switch della base dei tempi o dei filtri, il segnale visualizzato è completamente sbagliato.
Ops, sorry for Italian. Hello everyone and thanks again to Hayo for the great job! Thank you thank you, now it's even better! Report a small problem, shows the test signal at 1KHz, after the stop and the switch time base or filters, the displayed signal is completely wrong.
Angehängte Dateien:
-
SPIKE_CH1_S.jpg
55 KB -
SPIKE_CH2_S.jpg
54 KB -
SPIKE_CH1_Q.jpg
49 KB -
SPIKE_CH2_Q.jpg
49 KB -
SPIKE_CH1_T.jpg
54 KB -
SPIKE_CH2_T.jpg
54 KB
Hi Rainer W., Hayo and guys all! Rainer W. schrieb: >Folgendes Schönheitsproblem hat sich da noch aufgetan: >Nach Signalerfassung (Single) greift die Darstellungsroutine nach einer >Verkleinerung des Zoom-Faktors unter bestimmten Bedingungen anscheinend >am Ende auf ungültige Speicherbereiche zu. Das passiert sowohl mit als >auch ohne Filter. >Z.B. >1. Messung Single, Trig norm mit 2 ms/div >2. Pan auf Speicherende (ganz nach rechts, Zoom3.png) >3. Zoom auf 500 us/div und Pan ganz nach rechts >4. Zoom auf 1 ms/div (Zoom1.png, -> Fehlerhafte letzte Pixel) >5. Zoom auf 2 ms/div (Zoom2.png, -> Fehlerhafte letzte Pixel) >6. Pan Knopf berühren (Zoom3.png, -> Signal springt nach rechts, >Darstellung ok) hallo Rainer W. I do not know if it is related but in the last part of the displayed waveforms there are some ripetitive glitches, some spike I say. These glitches are present regardless of the type of filter inserted and also when no filter is inserted, please look at my screenshoot. This is also observed by others? I could be wrong but I never noticed them before now but at the same time I think I read here something about it. I'm a bit confused. Rainer W. schrieb: >p.s. Mit Probe Comp Signal und Messung bei 200 us/div sieht man's >genauso. > >IIR3-Bias: >Dann ist mir beim IIR3 Filter noch aufgefallen, dass die ausgegebenen >Werte nicht ganz bias-frei sind. Ein Vergleich von Filter_IIR2.png und >Filter_IIR3.png zeigt, dass zu Anfang die Nulllinie stimmt und nach dem erstem Puls mit IIR3 ein nach oben verschobener Pegel auftritt. In >Filt2_xxx.png sind die Y-Cursor auf das ungefilteren Probe-Comp-Signal >eingestellt. Besonders beim IIR3 rutscht das Signal deutlich hoch und >ganz vorne sieht man ein Einpegeln, was sich vielleicht mit einer >geeigneten Filterinitialisierung (z.B. mit Signalmittel der ersten >Punkt?) noch etwas aufhübschen läßt. I agree, I find this thing even. Rainer W. schrieb: >mit dem Puls Width Trigger habe ich gerade ein Brett vorm Kopf. >Mir gelingt es nicht, eine minimale Pulsbreite (">"-Wert) von hier z.B. >1.45 ms einzustellen. >Unterhalb von 1.0 ms ändert sich der Wert in Schritten von 1 us und ab >1.0 ms geht es gleich mit Siebenmeilenstiefeln in Schritten von 1 ms >weiter. > >Gibt es da einen Trick? Me too, I confirm so I agree with the question: Gibt es da einen Trick? Hayo W. schrieb: >Kein Trick! Diese Zählweise hat der WELEC-Programmierer bei allen >vergleichbaren Funktionen so implementiert. Dadurch kann man bestimmte >Werte nicht einstellen!!! > >Offenbar hat er sich wohl gedacht, dass man es oberhalb der jeweiligen >3er Potenz nicht genauer braucht. Da grübel ich schon einige Zeit drüber >nach, wie man das verbessern könnte ohne sich einen Wolf kurbeln zu >müssen. > >Hast Du Vorschläge? Hallo Hayo. Ok, I understand but unfortunately I can not help, I am sorry Hayo. Schönen Abend an alle. Gruß Luc
Angehängte Dateien:
-
gyppe.jpg
61 KB
Hi gyppe, Hayo and guys all! gyppe schrieb: >Report a small problem, shows the test signal at 1KHz, after the stop >and the switch time base or filters, the displayed signal is completely >wrong. @ gyppe Ciao gyppe. Provato e riuscito solo con STOP + FILTRO + cambio TEMPO di BASE. Per piacere guarda mia immagine e conferma. @all Hi gyppe, I tried but I succeeded only in this way: 1)I capture the image of the compensation signal of the probe by pressing the RUN/STOP's button 2)I insert or I change the filter 3)with the DSO still in STOP I change the TIME BASE. 4)On the screen appears the without sense waveform that You can see in my screenshot. Please gyppe, is this what you mean? Hayo W. schrieb: >Do You have a Screenshot for us? @gyppe Questo volta avere io!:-) @Hayo and all I have it!:-) Buona sera a tutto. Schönen Abend an alle. Gruß Luc
Angehängte Dateien:
-
PulsWidth_0.9-2.0ms.png
3,8 KB
Hallo Hayo, Hayo W. schrieb: > ...Diese Zählweise hat der WELEC-Programmierer bei allen > vergleichbaren Funktionen so implementiert. Dadurch kann man bestimmte > Werte nicht einstellen!!! Das kann doch wohl nicht sein Ernst gewesen sein :-( Von einem Pulsweitentrigger erwarte ich einfach, dass man z.B. Intervalle wie [1.4 ms .. 1.6 ms] einstellen kann!!! Nochmal Pulstrigger: Mit dem Puls Width Trigger scheint noch mehr schief zu gehen: Bei obigen Einstellungen sollte ein 1.7 ms Puls sauber triggern. Weit gefehlt - [1.0 .. 1.47] ms kriegt er zu fassen. (Display persist, Pulsbreiten [0.95 .. 2.05] ms reingefütter) Über eine Eingabemethode für die Parameter werde ich auch mal nachgrübeln. Gruß Rainer
Angehängte Dateien:
-
DELAYED_FILTER.jpg
85 KB
Hi guys all! @Hayo @gyppe Seems to happen even with the delayed time base when filters are switched. Please look at my screenshoot. Gruß Luc
Ciao luc, parli Italiano? :) Unfortunately I can not make screenshots, i use linux, and bf1.6 does not work, I do not know if it depends on my system or if there are problems in the Linux version. Yes, the images are similar, I discovered that I also only happens with the filters turned on, even as delayed same effect. Spero di riuscire a farmi capire, non parlo inglese molto bene. Gyppe.
Nice Screenshos....I like them, looks like modern art!! ;-) Tomorrow I will try to reproduce them and if possible - to fix the problem. @Rainer Das Problem ist, wenn die Schritte zu fein sind, dann kurbelt man sich eine Wolf, und wenn sie zu grob sind kann man es nicht genau genug einstellen. Man muß eigentlich die Schrittweite bei jedem beliebigen Wert frei einstellen können - ich denk drüber nach. In english: The problem is, if the steps are too small, You will get gray and old while changing the value from 0.001 to 1000. Otherwise if the steps are to big it is not possible to adjust the values accurately. So the solution must be to be able to choose the step width free at every value - I'm thinking about it. Noch einen schönen Abend - nice evening to all - Buona sera a tutto Hayo
gyppe schrieb: > Ciao luc, parli Italiano? :) > > Unfortunately I can not make screenshots, i use linux, and bf1.6 does > not work, I do not know if it depends on my system or if there are > problems in the Linux version. Hmm, whats going wrong? Doesn't it start or doesn't it start after triggering a screen shot? Did You switch to the BF-Version in the Quick Print menu? On my Suse Linux 11.1 it works without problems (AMD Mainboard 3 Ghz direct RS232 connection - no USB-converter) Hayo
>Auf Adresse 0 habe ich keinen angeschlossenen Schieberegister finden >können. >- Meine Frage an alle Programmierer: taucht die Adresse 0 in den >Programmiersequenzen überhaupt auf und wofür? >BIs jetzt nicht. >- 2. Frage: Welche Funktionen beeinflusst U26 (Adr. 2) – das IC befindet >sich neben der RS232 - Buchse? Das sollte der externe Trigger-Level sein >Und wie viel bits werden dafür belegt – 8 16 24 ? - nach meinen >Messungen und laut Schaltplan nur 8? Keine Ahnung. Ist ein Integer. Müsste ich erst genauer suchen. Morgen misst Crazor die genaue Funktion der seriellen Schnittstelle aus. Dann sehen wir weiter.
Thread beobachten
Seitenaufteilung abschalten
