Hier ist die Fortsetzung von: Beitrag "Wittig(welec) DSO W20xxA Open Source Firmware (Teil3)" Und noch die Hardware Diskussion: Beitrag "Wittig(welec) DSO W20xxA Hardware"
:
Gesperrt durch Admin
> Das heißt du könntest nur die Kompressionsroutine übernehmen? Eigentlich ja, aber das Coding von Falk ist doch ziemlich "kompakt" geschrieben und daher nicht ganz einfach nachzuvollziehen. Es gibt auch noch einige weitere Änderungen die ich dann anpassen müßte. Ich hatte mir das schon mal angesehen, aber dann doch keine Zeit/Lust gehabt. Vielleicht baue ich das demnächst trotzdem mal um. >>Hayo W. schrieb: >> Was ich mir vorstellen könnte wäre, dass abhängig von der Auswahl BF/OS >> die Buttons eine jeweils eigene Beschriftung und Funktion haben >Gute Idee! Bekomme ich dann den 5. Soft-Button als "Save to USB"? Klar kein Problem. Ich vermute mal nur für die OS-Version solange ich die Kompressionsroutine noch nicht upgedatet habe? Die Funktion die hinter dem Button steckt würdest Du dann zur Verfügung stellen? Gruß Hayo
Hayo W. schrieb: > Die Funktion die hinter dem Button steckt würdest Du dann zur Verfügung > stellen? Na klar!
Ich versuche mal das zum nächsten Release vorzubereiten, für die Funktion mach ich Dir dann einen leeren Methoden-Body. Hayo
Habe nur ich ein Problem beim Norm-Trigger vom W2024 Ch3/4? Mit der FW 2.9.C2 W2024 beobachte ich folgendes Problem: Ein normaler Edge-Trigger auf Kanal 3 bzw. 4 funktioniert bei Umschaltung der TB nur in jeder zweiten Stellung, also z.B. bei ... 20, 5 und 1 us/div kommt der Trigger durch und bei ... 10, 2 und 1 us/div kommt er nicht durch. Dagegen hilft: Run/Stop auf 'Stop' und wieder auf 'Run'. Dann geht's auf den anderen Stufen, als ob dabei irgendetwas wesentliches wieder richtig gesetzt wird. Trigger auf Ch1/2 tut's immer. Hat jemand eine Idee oder ist das ein (bekanntes?) FPGA-Problem? Gruß Rainer
Du hast recht, bei mir ist das auch zu beobachten. Ich kümmere mich darum. Danke für den Tip Hayo
Bei mir tritt das nur bei Zeitbasen von 5ms bis 500ms auf. Hat hier jemand andere Erkenntnisse? Das Problem müßte eigentlich auch bei älteren FW-Versionen auftreten. Muß ich nochmal prüfen. Hayo
Hayo W. schrieb: > Ok, Problem ist behoben. Klasse, hatte gerade alles von 2 ns/div bis 200 ms/div durchprobiert - trat überall auf. Aber du warst schneller. Danke Rainer
Die 2.10 ist zwar noch nicht fertig, aber Du kannst ja mal bei diesem Vorabrelease prüfen ob das Problem bei Dir noch auftritt. Bei mir war alles ok. Es ist auch schon die zusätzliche manuelle Triggerung via Single-Button und die Hardwareunterstützung des LTC 2602 drin. Gruß Hayo
Hallo Hayo, nächstes Problem: Ich muss auf ein (beliebiges) Zeichen vom UART warten. Dazu habe ich eine globale Variable angelegt die in der Hardware::ISR_UART() auf 1 gesetzt wird. Die Abfrage sieht dann einfach so aus:
1 | rx=0; //Globale Variable zurücksetzen |
2 | while(!(rx)); //Warte bis sie von der ISR gesetzt wird |
3 | rx=0; //Wieder zurücksetzen (eigentlich hier unnötig) |
Gibt es da eine elegantere Möglichkeit oder kann das so bleiben? Ginge auch eine Abfrage von puart->np_uartstatus und puart->np_uartrxdata? Das beliebige Zeichen ist zur Zeit ein Leerzeichen (0x20). Besteht die Gefahr dass ich damit etwas durcheinanderbringe? Mfg, Kurt
Hayo W. schrieb: > Die 2.10 ist zwar noch nicht fertig, aber Du kannst ja mal bei diesem > Vorabrelease prüfen ob das Problem bei Dir noch auftritt. Bei mir war > alles ok. Der Trigger über Ch3/4 scheint zu funktionieren. Aber ganz weit bin ich mit Testen nicht gekommen, weil die Kiste jetzt sehr gerne total einfriert. Bis auf Softkey-Reset geht dann gar nichts mehr. Gruß Rainer
Sorry, hatte vorhin quick & dirty die Sache ausprobiert und dabei eine Endlosfalle mit eingebaut. Jetzt ist da ein Timeout drin und alles sollte gut sein. @Kurt Wenn Du das so machst, steht die ganze Kiste bis was vom UART kommt. Und wenn nix kommt, hast Du das Gleiche wie ich vorhin! Also entweder einen Timeout einbauen, oder besser nur mit if() abfragen, denn dann kann die Hauptschleife weiterlaufen und die Abfrage wird jedesmal gemacht. Hayo
Hayo W. schrieb: > hatte vorhin quick & dirty die Sache ausprobiert und dabei eine > Endlosfalle mit eingebaut. Jetzt ist da ein Timeout drin und alles > sollte gut sein. Hajo, da kommt noch kein weißer Rauch. Irgendwie scheint die Falle immer noch drin zu sein. Nur manchmal (etliche Sekunden) kommt die Bedienung durch, so dass man eine Chance hat die TB zu verstellen. Nix mit locker durchdrehen ... Gruß Rainer
Hi Rainer, gib mir mal ein paar Details zu den verwendeten Einstellungen (Hardwaremenü, TB, aktive Kanäle, Spannungsbereich), denn bei mir lief das irgendwie problemlos. Gruß Hayo
So - hab nochmal eine kleinigkeit geändert, damit die Bedienung bei Zeitbasen mit langer Abtastzeit etwas flüssiger wird. Bitte berücksichtigen, dass aber grundsätzlich das Ganze ab 20ms an aufwärts etwas langsamer wird, und damit auch die Reaktionsgeschwindigkeit auf das Human Interface. Gruß Hayo
Hi Hayo, mmh, keine besonderen Einstellungen: - Default Setup - Trigger Norm, Ch.4 rising Edge, Level 2.5 V - TB um die 1us/div, sofern machbar ;-) - Signal: 5V Einzelpulse 1us auf Ch.4 Problem scheinen die Einzel-Events zu sein. Dabei verfängt das DSO sich gerne. Wenn ich aber statt dessen nach einem Soft-Reset das Probe Comp Signal dran habe, läuft alles. Gruß Rainer
Noch einer! Ich habe jetzt einen völlig anderen Lösungsansatz gewählt. Die Bedienung wird dadurch flüssiger und ich hatte auch keine Aussetzer bei meinen Tests. Diese Variante gefällt mir bislang am besten. Probierts doch bitte mal aus. Hayo
Hayo W. schrieb: > Probierts doch bitte mal aus. Signal: Probe Comp an Ch1, Einzelpulse an Ch4 Die Hänger sind in der 2.10.Pre4 weg, aber wenn Trigger auf Ch4 steht und ich die TB langsamer mache, kommen ab 10us/s bei Einzelpulssignal kein Trigger mehr durch, d.h. 2ns/div ..5us/div geht, 10us/div ... geht dann nicht mehr. Allerding: Wenn ich dann bei z.B. 20us/div auf Ch1-Trigger schalte (Erfassung läuft wg. Ch1.Signal) und wieder zurück auf Ch4, funktioniert auch Trigger auf Einzelpulse wieder, solange ich nicht von 5us/div auf 10us/div umschalte. Wird an dieser Grenze irgendetwas Grundlegendes geändert? Gruß Rainer
Ja zwischen 10µs und 5µs wird anscheinend die Betriebsart der ADC umgeschaltet, denn bei 5µs werden 16k Werte gesampelt und ab 10µs sind es dann nur noch 4k. Genauer kann man das in der Programmers Reference sehen auf dem Reiter "Timebase Table". Allerdings tritt das Problem bei mir nicht auf, außer ich wähle das Signal zu klein kleiner als ein Div hoch. Dann setzt der trigger schon mal aus. Aber sobald das Signal größer ist läuft alles ohne Aussetzer. Können die Anderen hier das auch mal testen bitte? Nicht das ich der Einzige bin bei dem es keine Aussetzter gibt. Gruß Hayo
Hayo W. schrieb: > @Kurt > > Wenn Du das so machst, steht die ganze Kiste bis was vom UART kommt. Und > wenn nix kommt, hast Du das Gleiche wie ich vorhin! > > Also entweder einen Timeout einbauen, oder besser nur mit if() abfragen, > denn dann kann die Hauptschleife weiterlaufen und die Abfrage wird > jedesmal gemacht. > > Hayo Den Timeout mit if() habe ich schon drin, oben war nur ein (zu) stark verkürztes Beispiel. Sorry. Es ging mir nur darum ob die Sache mit der globalen Variablen so in Ordnung ist oder man es besser machen kann.
Hayo W. schrieb: > Allerdings tritt das Problem bei mir nicht auf, außer ich wähle das > Signal zu klein kleiner als ein Div hoch. An der Signalhöhe liegt es definitiv nicht (2,5 div und TL ca. 50%). Ich kann auch reproduzierbar zwischen 5 und 10us/div umschalten, Trigger Ch4 mit Einzelpuls kommt nur bei 5us/div durch, dto. die rote/Ch4-Trigger-LED. Bei 10us/div rauscht nach gefühlten 30 s ein Puls durch (Spike auf Ch4) und dann triggert das DSO auch wieder aufs Einzelsignal. Hilft das?
Im Prinzip mache ich das auch so mit globalen Flags. Allerdings solltest Du bei globalen Variablen den Namen möglichst sprechend wählen - z.B. USB_rx_flag oder USB_rx_request oder so, Dann wird das etwas übersichtlicher und besser lesbar. Gruß Hayo
@Rainer Ich hatte etwas schwierigkeiten Deinen Fall nachzustellen, hab es aber jetzt hingekriegt. Die Pulse müssen schon sehr langsam kommen damit das Problem auftritt (1 Puls pro Sekunde). Aber dann passiert es bei mir auch wie beschrieben. Mal sehen ob ich die Ursache lokalisieren kann. Gruß Hayo
Hayo W. schrieb: > Die Pulse müssen schon sehr langsam kommen damit das > Problem auftritt (1 Puls pro Sekunde). Tun sie, ich löse die von Hand aus. Die "gefühlten 30 s", die das DSO nach der Umschaltung von 5 auf 10us/div keinen Trigger annimmt, sind reproduzierbare 35 s. Kann es sein, dass in der Zeit ein 32-Bit Zähler einmal die Runde läuft, der eigentlich hätte auf 0 gestellt werden müssen? Gruß Rainer
> Die "gefühlten 30 s", die das DSO nach der Umschaltung von 5 auf > 10us/div keinen Trigger annimmt, sind reproduzierbare 35 s. Kann es > sein, dass in der Zeit ein 32-Bit Zähler einmal die Runde läuft, der > eigentlich hätte auf 0 gestellt werden müssen? Keiner den ich benutze, aber es ist schon mal ein Ansatz für die Suche. Gruß Hayo
Zück schon mal den Lötkolben, Hayo. Die Leiterplatten gehen heute noch in den Postkasten. branadic
Na Du bist aber fix. Da passt das ja das heute meine Lötstation gekommen ist. Gruß Hayo
Angehängte Dateien:
-
kompost.jpg
200 KB
moin moin Hayo, hier was fuers Wochenende, hat mich ein paar stunden suche gekostet obwohl meine Soft 'unschuldig' war was du auf dem Bild siehst ist ein SYMETRISCHES Signal, nur das Oszi zeigt was anderes, irgendwie als waehre dein Puffer zu kurz oder wird ueberschrieben, oder ? FW = BF2.8 vlG Charly
@Charly, Hayo Der am rechten Rand dargestellte Datenmüll stammt zeitlich aus einem anderen Bereich des Signals und taucht am rechten Rand immer auf, wenn das Fenster mit der Horizontalverschiebung ganz nach Rechts geschoben ist, d.h. am Ende der gesampleten Daten liegt. Horizontalregler a bissl nach links drehen und schon ist es nicht mehr zu sehen ;-) Schönen Sonntag Rainer
Is ja'n Ding. Das war mir noch nicht aufgefallen. Muß ich mal ausprobieren. Wegen der Triggeraussetzer auf Kanal 3 + 4 bin ich leider auch nicht weitergekommen. Ich denke aber dass es sich eher um ein minder priorisiertes Problem handelt oder? Ich habe erst mal am Quick Print Menü weitergemacht, was schwieriger war als ich dachte, da ich (eigentlich wie immer) auf Altlasten in der Menüsteuerung gestoßen bin. Jetzt hab ich da aber aufgeräumt und alles ist gut. Ich werde nachher mal die fertige 2.10 hier hochladen. Gruß Hayo
Hayo W. schrieb: > Ich habe erst mal am Quick Print Menü weitergemacht Super, ich werde die später meine neuen Funktionen schicken: UC_rle_enc(...) UC_SCREENSHOT_BW() UC_SCREENSHOT() UC_DUMPCSV() Mfg, Kurt
Hayo W. schrieb: > Is ja'n Ding. Das war mir noch nicht aufgefallen. Muß ich mal > ausprobieren. Mit einem Sägezahnsignal läßt sich vielleicht am einfachsten klären, wo die Mülldaten herkommen. > Wegen der Triggeraussetzer auf Kanal 3 + 4 bin ich leider auch nicht > weitergekommen. Ich denke aber dass es sich eher um ein minder > priorisiertes Problem handelt oder? Das denke ich auch. Die W2022 Nutzer haben sowieso nur 2 Kanäle zum Triggern und die Frontend-Front lauert ja auch noch auf Einbindung der Chip-Ansteuerung. Gruß Rainer
> Wegen der Triggeraussetzer auf Kanal 3 + 4 bin ich leider auch nicht > weitergekommen. Ich denke aber dass es sich eher um ein minder > priorisiertes Problem handelt oder? >>Das denke ich auch. Sehe ich anders. Für mich hat das zuverlässige Funktionieren der Elementarfunktionen (z.B. Triggerung) oberste Priorität. Der Oszi ist ja immerhin ein Messmittel und ich möchte ihn auch so einsetzten (und mich drauf verlassen!). Ich will hier aber keinem den Spaß verderben, Hayo soll das machen, was er am spannendsten findet (aber solche lästigen Bugs bitte nicht vergessen). Da wir schon mal dabei sind - vielen Dank an alle, die hier ihre Zeit investieren!! Viele Grüße, Mirko
Hallo Hayo, na dann bin ich gespannt auf die 10er. Mal eine kurze Frage am Rand, woran erkenne ich dann in der neuen Firmware, dass der DAC auch richtig unterstützt wird? Ich hab den heutigen Tag genutzt meine DACs auszutauschen und zugleich meinen Kanal 4 etwas frei zu machen, damit die Huckepackplatine Platz findet. branadic
So, der Reihe nach: - @Charly -> das Datenmüllproblem habe ich eben noch beseitigt. - @Mirko -> ja ist irgendwie ärgerlich, aber wenn man einen zuverlässigen Trigger braucht muß man eben Kanal 1 oder 2 nehmen. Vielleich stoße ich noch auf eine Lösung. - @Kurt -> alles klar, ich habe Dir eine leere Methode gebaut, die angesprungen wird wenn der USB-Button gedrückt wird. Zur Zeit gibt sie nur einen Text auf dem Terminal aus. Du Findest sie in der commif_t.cpp ganz am Ende -> void CommIF::Save2USB(void) - @Branadic -> tja entweder funktioniert es mit dem 16 Bit DAC - oder nicht. Kann sein das ich den Registerwert noch um zwei Bit verschieben muß, das muß ich aber noch ausprobieren. Zur Zeit kann ich das ja leider noch nicht testen. Wenn Du umschaltest auf 16 Bit werden die drei anderen Kanäle sich nicht mehr verstellen lassen. Wenn es gut Läuft geht dann aber der Kanal 4. Ansonsten einfach bescheid sagen, dann ändere ich das. Zur 2.10: - Es gibt jetzt zwei unterschiedliche Quick Print Menüs für OS und BF. Die Umschaltung erfolgt wie gehabt. Gruß Hayo
Hallo Hayo, hier sind die geänderten Dateien. Ausgangsbasis war die 2.9_C2 Mfg, Kurt Jetzt warst du schneller. Mal sehen was du angestellt hast. ;-)
Sieht doch schon gut aus! Aber wäre nicht ein eigener Eintrag im Screenshot-Versions Softbutton besser? Und dann die 3 linken Softkeys wie in der OS-Version (Color, BW, CSV).
Hi Kurt, ich hatte Dich in Deinem Post neulich so verstanden, dass Du da an der freien Stelle einen Button für den USB-Transfer hinhaben wolltest. Hab ich Dich da falsch verstanden? Wir können das natürlich noch ändern bei Bedarf. Gruß Hayo
Hallo Hayo, nach dem Umstellen des DAC auf LT2602 verschwinden bei Kanal 1 und 3 die Signale irgendwo außerhalb es Bildschirmes, Kanal 2 bleibt an gleicher Stelle. Auch ein Calibrate DAC bringt die Signale für Kanal 1 und 3 nicht zurück. Veränder ich nun die Position von Kanal 2 durch Drehen am Knopf, was ja in einer Änderung des DAC-Wertes resultieren sollte, bleibt das Signal an selber Stelle, aber das Kanal-Zeichen inkl. des Pfeiles (linker und rechter Bildschirmrand) wandert. Tut also noch nicht wie gewünscht. branadic
Kann sein dass ich mich da etwas undeutlich ausgedrückt hatte. Das Dateiformat in dem gespeichert wird kann ich auf meinem µC einstellen. Aber für die Art der Datenübertragung (Farbe, S/W, CSV) bauche ich je einen eigenen Softbutton. Ich könnte zwar meine UC_ Funktionen mit den OS_ Funktionen zusammenlegen (die sind im Prinzip kompatibel, nur die RLE unterscheidet sich) aber das halte ich in der Entwicklungsphase nicht für sinnvol.
Ok, dann baue ich das nochmal um und spendiere Deiner Funktion ein eigenes Menü. Gruß Hayo
@Hayo, Hayo W. schrieb: > Rainer W. schrieb: >> Die "gefühlten 30 s", die das DSO nach der Umschaltung von 5 auf >> 10us/div keinen Trigger annimmt, sind reproduzierbare 35 s. Kann es >> sein, dass in der Zeit ein 32-Bit Zähler einmal die Runde läuft...? > > Vielleich stoße ich noch auf eine Lösung. Der Trigger läuft ja schon zuverlässig. Man hat "nur" die Totzeit nach der TB Umschaltung 5->10us. Falls an meiner etwas kühnen 32-Bit Vermutung etwas dran ist, wären das z.B. 34,4 s bei 125 MHz. Nur mal so ins Blaue gedacht... Hayo W. schrieb: > - @Charly -> das Datenmüllproblem habe ich eben noch beseitigt. Kann es sein, dass da immer noch ein einzelnes falsches Datenwort am Ende mit ins Display rutscht? Sieht bei mir so aus... Gruß Rainer
Angehängte Dateien:
-
plane1_5.png
573 Bytes
Jetzt noch 2 (optische) Kleinigkeiten: In OS_SCREENSHOT_BW(void) und UC_SCREENSHOT_BW(void) muss die UI_Plane1 noch mit in das Array. Also:
1 | unsigned long *planes[] = { |
2 | UI_Plane1, UI_Plane2, UI_Plane5, // UI_Plane3, UI_Plane4 |
3 | Channel_Plane1, Channel_Plane2, Channel_Plane3, Channel_Plane4, |
4 | Channel_Math_Plane, |
5 | Memory_Plane1, Memory_Plane2, Memory_Plane3, |
6 | Marker_Plane1, Marker_Plane2, |
7 | Grid_Plane, |
8 | NULL
|
9 | };
|
In der UI_Plane1 scheint auch noch ein Fehler beim Zeichnen der Umrandung des rechten Softbutton zu sein. Auf dem Bild im Anhang sieht man dass die Umrandung nicht geschlossen ist.
Danke Hayo, hab grad die neue Ver. eingespiel, werd heut mal testen... aber 2 neue Fehler / 'Unschoenheiten' 1. ab einer TB >1ms muss man f. manuelles triggern im Single mode die Single Taste mehrmals druecken ;( 2. der Pretrigger Wert wird beim langsamen durchdrehen der TB nicht aktualisiert vlG Charly
@Hayo Rainer schrieb: > Kann es sein, dass da immer noch ein einzelnes falsches Datenwort am > Ende mit ins Display rutscht? Sieht bei mir so aus... Das was da auf dem letzten Pixel noch zu sehen ist, stammt wohl vom Noise-Filter bei Einstellungen "smooth" oder "strong". Gruß Rainer
@Kurt baue ich mit ein. @Charly Stimmt, ist in Arbeit. Sollte in der nächsten Version behoben sein. Danke für die Rückmeldung Hayo
Hayo, hast du meine Meldung bezüglich der DACs gesehen? Scheint in den letzten Postings der anderen User irgendwie untergegangen zu sein. brandic
Hi branadic, sorry, der Post war tatsächlich etwas an mir vorbeigerauscht. Bin momentan immer noch etwas in Stress hier beim Rollout meines Projektes. Welchen Kanal (bzw. Kanäle) hattest Du denn nun auf 16 Bit umgerüstet? War das nicht Kanal 4? Übrigens ist heute Deine Sendung bei mir angekommen - danke! Muß mal sehen wann ich das einbauen kann, da muß man sich ja schon etwas Zeit für nehmen. Gruß Hayo
Hallo Hayo, da es sich bei dem DAC um einen DUAL DAC handelt werden pro gewechseltem DAC also auch zwei Kanäle in Mitleidenschaft gezogen (Kanal 1 + 2 und Kanal 3 + 4). Ich habe bei mir beide DAC gewechselt, demzufolge sind alle 4 Kanäle davon betroffen. Da ich aber an meinem Kanal 4 etwas aufgeräumt habe, um Platz für die Huckepackplatine zu machen, kann ich dir nicht sagen was jetzt dort genau passiert. Schön das die Sendung schon eingetroffen ist, dann kann es ja bald mit der Implementierung losgehen. Das freut mich. Ein wenig Zeit wird man sicherlich brauchen, aber die größte Last, der Aufbau einer Leiterplatte, wurde dir ja schon abgenommen ;) branadic
Wenn es bei Dir momentan noch nicht funktioniert werde ich Dir bei Gelegenheit mal eine modifizierte Version bauen. Bin aber momentan echt im Streß, da ich ab morgen für den Rest der Woche eine Schulung gebe und mich auch noch vorbereiten muß. Gruß Hayo
Hayo W. schrieb: > @Charly > > Stimmt, ist in Arbeit. Sollte in der nächsten Version behoben sein. Danke Meister ! <tiefes verbeugen> & viel erfolg bei der schulung, und hoffentlich haste keine mit 'Teflonpfannenkopf' dabei :)
So, bin gerade nach Hause gekommen - und was finde ich im Briefkasten? Post von Linear Technology! Die Jungs haben mir doch tatsächlich zwei LTC2602 als kostenloses Sample geschickt und das ziemlich zügig. Danke noch mal für den Tip! Schade, dass ich momentan überhaupt keine Zeit habe etwas zu basteln. Naja, muß halt noch etwas warten. Gruß Hayo
hi mir ist gestern ein fehler in den math-funktionen aufgefallen. messen wollte ich die restwelligkeit einer gleichspannung (8V). da sich an dem messpunkt noch ein welliger spannungsabfall (1Vpp) von einem shunt hinzu addiert, wollte ich diesen mit der CH1-CH2 funktion herrausrechnen. beide kanäle waren dabei im 5V messbereich und die referenzlinien in der bildschirmmitte. die überlagerte spannung vom shunt wurde zwar korrekt herraus gerechnet, allerdings stimte die skalierung des ergebnisses nicht. die ergebnisslinie lag nicht wie erwartet bei 8V sondern irgendwo bei 11V. gruß sunny
Ich möchte nochmal an die Sammelbestellung für die Bauteile der Huckepackplatine erinnern. Die Frist endet Freitag Abend. Beitrag "Re: Wittig(welec) DSO W20xxA Hardware" Mfg, Kurt
Hi, bin wieder mal gerade erst zu hause angekommen und wollte mal kurz die Gelegenheit nutzen zu fragen wo ich denn den LTC2612 auf der Platine finde. Ist ja doch recht klein das Teilchen. @Branadic Du hast da doch bestimmt aktuell den Überblick oder? Sonst such ich mir da bestimmt nen Wolf. Gruß Hayo
Ach, das ist ja gleich um die Ecke bei den Vorwiderständen die ich schon getauscht hatte. Danke.
Kurt Bohnen schrieb: > Ich möchte nochmal an die Sammelbestellung für die Bauteile der > > Huckepackplatine erinnern. Die Frist endet Freitag Abend. > > > > Beitrag "Re: Wittig(welec) DSO W20xxA Hardware" Oh, danke, wäre mir sonst durchgegangen. Ich komme gerade aus dem Urlaub wieder und konnte das aktuell nicht verfolgen. Mehr dort. Jörg
Und wieder ward es ruhig. Es gibt ja anscheinend doch eine ganze Reihe Leute, die sich ein Welec zugelegt haben. Jetzt hat man mehrfach die Ausrede gehört, dass für Mikrocontrolleraufgaben das Welec ausreichend sei. Nur wenige Leute wollen wirklich anspruchsvollere Messungen damit durchführen. Also Frage an all die Mikrocontroller-Programmierer, die ihr im Besitz eines Welec seid, warum könnt ihr Hayo beim Programmieren nicht unterstützen? Wenn Hayo nichts implementieren kann, weil er gerade keine Zeit hat, passiert scheinbar überhaupt nichts mehr. Auf die Art und Weise kommt das Projekt nicht voran. Ich verstehe, dass Walter das Projekt verlassen hat und so langsam verliere auch ich die Lust immer nur zu warten.. branadic
Wenn Hayo grade nichts dran tut würde ich mich anbieten mal meine Grafikfunktionen in seine Quellen zu mergen, die ich vor 1,5 Jahren in Subversion eingecheckt hatte. Wie sieht der Entwicklungsflow derzeit aus? Hayo, kann ich mit die Quellen von dir "ausleihen" und dir das Resultat zurückschicken? Oder gibt es mittlerweile eine Versionsverwaltung? Jörg
branadic schrieb: > Also Frage an all die Mikrocontroller-Programmierer, die > ihr im Besitz eines Welec seid, warum könnt ihr Hayo beim Programmieren > nicht unterstützen? Hast du selbst mal einen Blick in die Sourcen geworfen? Das ist kein LED blinken lassen. Rechne mit 2 Wochen Vollzeit bis du leidlich nachvollziehen kannst, wo was erledigt wird. Nur wenige werden je verstehen wie was erledigt wird. Gruß, Guido
Guido schrieb: > Rechne mit 2 Wochen Vollzeit bis du leidlich > nachvollziehen kannst, wo was erledigt wird. Außerdem müsste Hayo entscheiden, wer wo was ändern darf. Und dafür braucht er auch wieder Zeit. Vor allem braucht man auch SELBER Zeit. Ich hatte seinerzeit vorgehabt, Alex008 beim FPGA-Design zu unterstützen, aber aufgrund zuwenig Zeit davon Abstand genommen. Es macht keinen Sinn, wenn man nur halbe Arbeit abliefern kann. Insofern finde ich es nicht schlimm, wenn dieses Projekt ab und zu mal eine kleine Pause einlegt. Dass es überhaupt schon soweit vorangekommen ist - alle Achtung! Dickes Kompliment an die Entwickler! > Nur wenige werden je verstehen wie was erledigt wird. Hat Hayo inzwischen eine Liste erstellt, wo was zu erledigen wäre? Wenn es viele kleine Teile wären, könnte man sich eher mal dran setzen. Gruß Ingo
Da kommt auch die Frage auf, was ist mit den ganzen anderen Programmierern der OS-Firmware? Vor längerer Zeit gab es Zoff weil Hayo "sich quergestellt" hat. Danach haben anscheinend 5-10 Programmierer ihr Welec auf den Schrott geworfen und haben kapituliert. Nur Hayo hat tapfer weitergearbeitet und treibt auch jetzt noch das Projekt vorwärts. Das ist schon eine merkwürdige Geschichte!? Wenigsten Jörg möchte "zurückkommen", vielen Dank! Den Einwand von Guido muss ich leider bestätigen. Der Quelltext umfasst ca. 48000 Zeilen. Das ist etwas mehr als die normalen µC Projekte. Vieleicht findet sich noch jemand der Alex helfen kann bei Software oder VHDL? Eine kleine Statusmeldung seinerseits wie weit er mit der Dokumentation gekommen ist, wäre auch schön. Ist euch eigentlich aufgefallen dass die Auktionspreise für die Welecs deutlich gefallen sind? Früher waren es immer so 350€. Jetzt nur noch 250-280€. Verlieren die Leute das Vertrauen in unser Projekt? Sobald die Sammelbestellung für die Teile der Huckepackplatinen abgeschlossen ist werde ich noch eine Sammelbestellung für den USB-Host organisieren. Die Hardware ist fast endgültig fertig, die Firmware hat schon einen brauchbaren Funktionsumfang und läuft stabil genug.
Kurt Bohnen schrieb: > Vieleicht findet sich noch jemand der Alex helfen kann bei Software oder > VHDL? Gibt es irgendwo eine Übersicht, was noch zu erledigen wäre? Gruß Ingo
Guido schrieb: > Hast du selbst mal einen Blick in die Sourcen geworfen? Das ist kein > LED blinken lassen. Rechne mit 2 Wochen Vollzeit bis du leidlich > nachvollziehen kannst, wo was erledigt wird. Nur wenige werden > je verstehen wie was erledigt wird. Hallo Guido, das Projekt gibt es doch auch nicht erst seit gestern und ganz ehrlich, eine LED blinken lassen hat mit Programmieren nicht das geringste zu tun. Es ist halt blöd, wenn die Software ein reines 1-Mann-Projekt ist. Ich denke auch Hayo ist für Unterstützung dankbar. Du hast dich ja scheinbar auch zurück gezogen. Ingo M. schrieb: > Insofern finde ich es nicht schlimm, wenn dieses Projekt ab und zu mal > eine kleine Pause einlegt. Genau das passiert, wenn nur noch einer am Projekt arbeitet und der Rest sich raus hält. Dann kann aber keine Rede mehr von "unserem Welec-Projekt" sein. Zumindest hat meine Anfrage hier doch den Erfolg gebracht, dass sich einige Leute melden und ihre Unterstützung anbieten, das ist doch ein Anfang. branadic
Hallo Jungs, nur keinen Stress. Bin zwar momentan noch etwas knapp an Zeit, aber nur keine Panik, es geht bald weiter. Ich sag morgen noch mal was dazu bis dann Hayo
branadic schrieb: > Du hast dich ja scheinbar auch zurück gezogen. Schon, aber nicht weil ich mir irgendwann gesagt habe, da mache ich nicht weiter. Die Unterbrechung, als Hayo abwesend war, hat mich halt völlig rausgebracht, ich habe andere Projekte begonnen. Jetzt müsste ich wieder bei Null anfangen und sehe dafür aber keine Notwendigkeit. Der Aufwand wäre sehr groß, da C++ nicht meine Welt ist, und besser als Hayo würde ich es doch nicht hinbekommen. Du musst einfach akzeptieren, dass es nur sehr wenige Elektrotechniker gibt, die auf diesem Niveau programmieren können. Andererseits gibt es nur sehr wenige Informatiker, die genügend von Messtechnik verstehen um ein solches Projekt zu stemmen. Herr Wittig könnte dir sicherlich ein Lied davrüber singen. Und nocheinmal: Niemand hier hat etwas gegen SFN! Nur diskutieren tun wir halt lieber hier. Grüße, Guido
Guido schrieb: > Du musst einfach akzeptieren, > dass es nur sehr wenige Elektrotechniker gibt, die auf diesem Niveau > programmieren können. Andererseits gibt es nur sehr wenige Informatiker, > die genügend von Messtechnik verstehen um ein solches Projekt zu > stemmen. Niveau hin oder her, Programmieren ist so anspruchsvoll nun auch wieder nicht, lassen wir doch mal die Kirche im Dorf. Es ist einfach nur so, dass die meisten einfach keinen Bock darauf haben, weil es eine stupide Arbeit ist. So umfangreich ist das Einarbeiten in die Thematik auch nicht, man ist nur zu bequem, weil es da ja jemanden gibt der die Arbeit für einen erledigt, so sieht es doch wohl aus! Hayo hat nur das größere Durchhaltevermöge gezeigt. Gesetz dem Fall Hayo hört auch auf, dann war es das mit eurem Projekt. Es hat schon immer geschadet seine Karten auf ein Pferd zu setzen, man sollte immer noch einen Trumpf in der Hinterhand haben. Mit einer solchen Organisationsstruktur in einem Projekt ist man zum Scheitern verurteilt. Da kann man nur sagen, Welec-Projekt adé. MFG, T. Dübel
Hallo allerseirs, ich sehe ich muß mir mal die Zeit nehmen einen längeren Beitrag zu schreiben. Da meine Beweggründe für die eine oder andere Entscheidung anscheinend immer noch nicht ganz transparent für alle sind werde ich das noch mal erläutern: Ich bin schon recht lange in der Softwareentwicklung tätig und weiß daher das ein Projekt welches von mehreren Entwicklern bearbeitet wird eine steuernde Instanz braucht die: - Vorgaben macht - koordiniert - Ergebnisse prüft - entscheidet welche Änderungen übernommen werden - neue Releases herausgibt nachdem die Änderungen getestet wurden Das gilt nicht nur für kommerzielle Projekte sondern auch für Open Source. Bei unserem Projekt gab es (auch wegen relativ dünner Personaldecke) sowas nicht. Das führt zum Teil zu etwas unkoordinierter Entwicklung und Wildwuchs. Um hier unabhängig zu sein habe ich meine Version getrennt von der OS-Version weiterentwickelt und dann gegenseitig sinnvolle Verbesserungen ausgetauscht. Das ist auch immer noch der aktuelle Stand, obwohl zur Zeit an der OS-Version relativ wenig gearbeitet wird. Zum Beitrag hier drüber: Lieber T.Dübel, Programmieren gehört zu den komplexesten Ingenieursleistungen überhaupt. Dass es nicht ganz so einfach ist wie Du behauptest sieht man an dem Ergebnis das die Firma WELEC nach mehreren Jahren Entwicklung abgeliefert hat und auf dem unsere Entwicklungen hier basieren. Und gesetzt den Fall ich höre auf, so stehen alle bisherigen Arbeiten als Source mit Dokumentation zur Verfügung, so dass es keinen Grund gibt die Entwicklung nicht fortzuführen. Ich habe 2008 mit sehr viel weniger angefangen! Zu SFN: Ich finde es unbedingt wichtig, das wir alle Ergebnisse und Informationen an einer zentralen Stelle wie SFN zusammentragen um diese allen geordnet verfügbar zu machen. Das hat nichts damit zu tun, das ein großer Teil der Kommunikation hier im Forum stattfindet. Meine aktuellen Releases sind immer auch auf SFN zu finden. Hier im Forum habe ich einfach direkteren Kontakt zu allen Betroffenen. @Jörg, Ingo, Guido, Kurt und alle die mithelfen wollen: Meine aktuelle To Do Liste die mir so gerade einfällt sieht ungefähr so aus: - Pretriggerwerte aktualisieren wenn TB geändert wird (ist in Arbeit) - Unterstützung für 16 Bit DAC. Die erste Anpassung scheint noch nicht zu funktionieren. Ich hätte eine Idee wo noch etwas geändert werden müßte. Wenn sich jemand des Themas annehmen möchte kann ich gerne Hinweise zu den entscheidenden Stellen geben. - Unterstützung für die Addon-Platine von branadic. Auch hier ist kurzfristige Hilfe willkommen damit die hardwareseitige Entwicklung weitergehen kann. Ich helfe auch gerne bei der Orientierung in der Source. - Druckmenü für Kurt erweitern -> ist in Arbeit - Manuellen Trigger prüfen und evtl. anpassen (geringe Prio) - Math-Funktionen (+ - *) prüfen überarbeiten (falsche Ergebnisse?) - Neues USB-Interface weiterentwickeln und PC-Software erstellen. - FFT-Bereich weiter entwickeln. - Screenshot BF-Version auf die aktuelle Komprimierungsroutine der OS-Version updaten um etwas schneller zu werden und kompatibel zu sein. Fehlt was entscheidendes? Wenn Ihr Ergebnisse habt, baue ich die gerne mit in die Source ein. Zu Subversion: Ich hatte mit Rolfs Hilfe ein SVN-Verzeichnis bei SFN eingerichtet, aber die Synchronisation hat nur zwei mal geklappt, dann habe ich aus Versehen bei mir die Steuerdateien gelöscht und habe es dann nicht mehr hinbekommen. Ich müßte das also versuchen wieder neu einzurichten. So erstmal genug Gruß Hayo
Hi Hayo, ich habe mich gestern Abend mal mit Walter über die Ansteuerung der Huckepackplatine unterhalten und er hat versucht mir die nötigen Änderungen zu erklären. Leider habe ich es nur zu 90% verstanden und muss nochmal nachfragen. Danach werde ich ein Bildchen malen wie die Platinen angesteuert werden müssen. Mfg, Kurt
Hi Kurt, das klingt gut. Wenn ich mich da nicht komplett neu reindenken muß kann ich da auch schneller eine Implementierung anbieten - bzw. jemand anderes hier. @All Ach ja, falls der Eine oder Andere Bedenken hat, dass ich mit der Entwicklung hier aufhöre, so möchte ich darauf hinweisen, dass ich mir extra für die Entwicklung und zum Testen der WELECS umfangreiches Equipment im Wert von über 1000 Euro zugelegt habe. Das haut man nicht mal eben so in die Tonne. Also locker bleiben und Ruhe ausstrahlen ;-) Gruß Hayo
Hallo, zu deinem Problem: Hayo W. schrieb: > Zu Subversion: > > Ich hatte mit Rolfs Hilfe ein SVN-Verzeichnis bei SFN eingerichtet, aber > die Synchronisation hat nur zwei mal geklappt, dann habe ich aus > Versehen bei mir die Steuerdateien gelöscht und habe es dann nicht mehr > hinbekommen. Ich müßte das also versuchen wieder neu einzurichten. Mögliche Abhilfe: 1.) Projekt von Sourceforge neu auschecken(in neuen lokalen Ordner). 2.) Sourcen, usw. vom Ordner ohne Steuerdaten direkt in den ausgecheckten Stand kopieren. 3.) dann ist ein Commit wieder möglich und sollte gleich vorgenommen werden. zuküntig: Oft Committen und ggf. branches bei Teständerungen o.ä. verwenden. weitere Fragen zu Subversion: bitte gerne hier stellen... MfG Werner S.
Liebe Oszilloskop-Gemeinde! Wie Branadic, Hayo und Co schon behauptet haben, stimme ich zu, dass die Programmierung keine stupide Arbeit ist. Das gilt besonders hier für den Embedded-Bereich, welcher sich mit Messtechnik, Signalverarbeitung wie hier zu tun hat. Für das Programmieren hier muss man die Messtechnik gut verstehen und mittelmäßig selbst bauen können und digitale Schaltungen verstehen. Die Programmiersprache C, C++ ist nunmal Standard in dem Bereich und keinesfalls Deppensicher. Zudem ergeben sich erschwerte Bedingungen auf Grund der spärlich vorhandenen Debug-Möglichkeit und der begrenzten CPU-Performance. Für eine VHDL-Entwicklung ist unbedingt ein Niveau für einen Digitalchip-Entwickler nötig. Das war der Teil in unserem Studium, bei welchen die meisten Studienkollegen aufgrund der Fehleranfälligkeit und der Unüberschaubarkeit teils große Schwierigkeiten haben. Weiters wollen die meisten im Berufsleben nichts mehr damit zu tun haben. Eines ist klar, sich in einen unvollständigen fremden Source-Code einzulesen, ist sehr mühsam und kann manchmal so sehr frustrieren, dass jeder seine eigene Suppe kocht. Die geringe Verbreitung der Hardware kommt noch dazu - Kein Wunder also, dass wir so wenig Entwickler sind. MfG Alexander
@Hayo Eine Frage zur Screenshot-Funktion: Früher konnte man durch "Doppel-Click" auf die Quick-Print-Taste einen ScreenShot auslösen, den man dann auf dem PC via RS232 mit dem entsprechenden w2000a-screenshot.exe empfangen konnte. Ist die Funktion gerade im Bau bzw. unter die Räder gekommen oder was macht das DSA jetzt bei Doppel-Click. Muß man da jetzt besondere Einstellungen vornehmen, damit der PC das mitbekommt? Mit der 2.10 bekomme ich z.Z. nur einen ScreenShot hin, wenn ich direkt die Tasten im Quick-Print Menü benutze, kann dann aber z.B. Cursoreinstellungen nicht dokumentieren. Kannst du da, wenn du Zeit hast, mal ein paar erhellende Worte fallen lassen? Gruß Rainer
Hallo Rainer, hast du darauf geachtet das die Screenshot Version (BF oder OS) von PC und Oszi übereinstimmen? Mfg, Kurt
Hallo Rainer, die Funkion sollte wie gehabt arbeiten. Wie Kurt schon sagt muß aber die richtige Version eingestellt sein (passend zur PC-Software). Ich bin ja ohnehin gerade dabei die Druckfunktion für Kurt anzupassen, da kann ich das sonst noch mal testen. Gruß Hayo
Was heißt "übereinstimmen"? Die beiden w2000a-screenshot.exe sind schon etwas betagter (BF 2.Nov.2010 bzw. OS 21.Sep.2010) und habe ich aus dem letzten FW-Update von Hayo (1.2.BF.2.10.zip). Gibt es da was aktuelleres? Auf PC-Seite funktioniert eigentlich alles, wenn ich den ScreenShot.exe auf Daten vom DSO lauern lasse. Nur der "Quick Print" Doppel-Click tut anscheinend etwas anderes als früher. Gruß Rainer
Ich prüf das mal und sag dann Bescheid. Hayo
Hayo W. schrieb: > Ich prüf das mal und sag dann Bescheid. Das wäre prima, das DSO ist nach dem Doppel-Click beschäftigt, aber der PC merkt nichts von Daten. Gruß Rainer
Ja Du hast recht. Das hatte ich bislang noch nicht bemerkt. Ich vermute, dass ich durch den Umbau für Kurt da einen Fehler eingebaut habe. Das korrigiere ich natürlich zur nächsten Version. Danke für den Hinweis Hayo
So, hab mich heute mal drangesetzt und einige Punkte abgearbeitet: - neues Quick Print Menü mit Unterstützung für Kurts Projekt - Pretrigger wird jetzt immer korrekt upgedatet - 16 Bit DAC wird jetzt (hoffentlich) korrekt unterstützt. Ich habe mir mal die Spezifikation runtergeladen und das Registersetting angepasst - Quick Print double push funktioniert wieder Und jetzt geht es wieder ab zum Griechen. Bis nachher Gruß Hayo
Hallo Hayo, das gefällt mir sehr gut und es funtkioniert! Leider hast du vergessen die handleInChar anzupassen. Hier nochmal die benötigten Zeilen:
1 | case 5: |
2 | CommIF::UC_SCREENSHOT(); // -> UC version |
3 | break; |
4 | case 6: |
5 | CommIF::UC_SCREENSHOT_BW(); // -> UC version black and white |
6 | break; |
7 | case 7: |
8 | CommIF::UC_DUMPCSV(); // -> UC version |
9 | break; |
Dann habe ich noch eine neue uc_dumpcsv die bei 2 Kanal Geräten auch nur Daten der 2 Kanäle überträgt. Mfg, Kurt
Ok, bin gerade vom Griechen zurück. Hatte ich übersehen. Ich bau das morgen mal ein und gebe dann eine neue Compilation raus. @branadic Es würde mich mal interessieren ob die 16 bit DAC-Ansteuerung jetzt funktioniert. Gruß Hayo
Der frühe Vogel fängt den Wurm! Alles schläft - einer fährt, oder so ähnlich. Also, hab noch ne Nachtschicht eingelegt und die Korrekturen eingebaut. Gruß Hayo
Hallo Hayo, was heißt hier alles schläft? Bin gerade erst nach Hause gekommen. Die DAC teste ich nachher mal, jetzt ist erst einmal Augen ausruhen angesagt. branadic
Also Hayo, DAC-Kalibrierroutine funktioniert noch nicht korrekt mit dem 16bit DAC zusammen, die Signallinien landen nicht auf 0. Beim Verstellen des DAC-Level wandern Signal und Kanalanzeige (links u. rechts) nicht gleichmäßig sondern die Kanalanzeige wandert gefühlt doppelt so schnell auf dem Bildschirm hoch und runter. Dann hätte ich noch eine Anregung zu den flimmernden LEDs für Trigger Wait und Trigger Event. Wäre es vielleicht sinnvoller die Trigger Event LED solange dauerhaft leuchten zu lassen, solange hintereinander Triggersignale kommen und erst wenn 1s lang kein Triggersignal gekommen ist auf Trigger Wait umgeschaltet wird? Das Flackern ist echt hart, man könnte meinen man schaut einen dieser asiatischen SciFi-Trickfilme. branadic
branadic schrieb: > Also Hayo, DAC-Kalibrierroutine funktioniert noch nicht korrekt mit dem > 16bit DAC zusammen, die Signallinien landen nicht auf 0. Das hab ich mir gedacht. Die Kalibrierroutine ist auf den 14 Bit DAC optimiert. Das müßte ich dann anpassen wenn ich das Teil bei mir einglötet habe. Wie groß ist denn die Abweichung? -> Screebshot > Beim Verstellen des DAC-Level wandern Signal und Kanalanzeige (links u. > rechts) nicht gleichmäßig sondern die Kanalanzeige wandert gefühlt > doppelt so schnell auf dem Bildschirm hoch und runter. Das ist klar, denn die Schrittweite hat sich ziemlich stark geändert. Das muß ich auch noch anpassen. Aber die Verstellung an sich funktioniert korrekt? Wie sieht es mit der Verstellgeschwindigkeit Ansprechverhalten Einstellgenauigkeit aus? Macht der Umbau Sinn? > Dann hätte ich noch eine Anregung zu den flimmernden LEDs für Trigger > Wait und Trigger Event. Wäre es vielleicht sinnvoller die Trigger Event > LED solange dauerhaft leuchten zu lassen, solange hintereinander > Triggersignale kommen und erst wenn 1s lang kein Triggersignal gekommen > ist auf Trigger Wait umgeschaltet wird? Das fände ich persönlich nicht so gut. Die Anzeige macht für mich so schon Sinn, auch wenn es zugegebenermaßen manchmal etwas hektisch blitzelt. > Das Flackern ist echt hart, man könnte meinen man schaut einen dieser > asiatischen SciFi-Trickfilme. Deshalb habe ich die Möglichkeit vorgesehen die LEDs separat abzuschalten. Gruß Hayo
Verstellung ist soweit in Ordnung, Geschwindigkeit etc ebenfalls. Der Umbau macht auf jeden Fall Sinn. Ich möchte daran erinnern, dass wir mit der Huckepackplatine zusätzliche Spannungsbasen von 5mV/div, 2mV/div und 1mV/div dazu gewinnen und spätestens da wird eine feinere Verstellung notwendig sein. Was die LEDs angeht, ich kann dir nur sagen wie das bei Tektronix gelöst ist, Disco-Licht gibt es dort nicht. Übrigens ist es überhaupt nicht notwendig an der Frontplatte herumzuschnippeln oder mit Heißkleber rum zu sauen, wenn man Osram Topleds verwendet. Die sind hell genug auch durch die Frontfolie durch zu leuchten. Für rot verwende ich LS T67B (super-rot) und für grün LT T67C (true green). Das eher matschige grün im Welec scheint die LTG T676 zu sein. branadic
So Branadic, damit Du nicht so gefrustet bist über die Diskobeleuchtung habe ich Dir eine neue Kompilation gemacht mit überarbeiteter 16 Bit DAC-Unterstützung. Eigentlich müßte es jetzt alles korrekt funktionieren. Ich habe die Ansteuerung jetzt so gemacht, dass man auf den Umschalter im Hardwaremenü eigentlich verzichten könnte. Die Ansteuerung ist nämlich eigentlich Sofwarekompatibel für alle drei DAC-Typen ausgelegt, so dass man sie beliebig tauschen kann ohne etwas anpassen zu müssen - vorausgesetzt man hat das von vornherein in der Ansteuerung berücksichtigt. Ich muß wohl nicht erwähnen, dass WELEC das natürlich nicht so implementiert hat. Sollte also jetzt alles korrekt sein werde ich in der nächsten Version den Schalter wieder rausnehmen. Gruß Hayo
By the way - ich habe mir das Hirn zermartert was der 16 Bit DAC eigentlich bringen soll. Mir ist nix eingefallen. Vielleicht kannst Du mir da auf die Sprünge helfen. Die Schrittweite ist nämlich nicht von der DAC-Auflösung abhängig, sondern wird in "Pixelschritten" vorgenommen. Und die sind bei den korrespondierenden Spannungsbereichen (5er/2er/1er) immer gleich. Beim 16 Bit DAC sind dann die Werteschritte einfach nur Faktor 4 größer. Oder hab ich da einen Denkfehler??? Gruß Hayo
Angehängte Dateien:
-
Kanal3_25MS.png
4,9 KB -
Kanal3_250MS.png
3,2 KB
Hallo Hayo, die DAC-Implementierung schaut soweit gut aus, zumindest für Kanal 1 und 2. Kanal3 macht einige Probleme: 1. Kanal3 bekomme ich durch den DAC-Abgleich nicht komplett auf Null, es bleibt ein geringer positiver Offset. 2. Bei Zeitbasen >10µs (<=25MS) entstehen auf Kanal3 und komischerweise nur dort unschöne Störungen, die bei Zeitbasen <=5µs/div (>=250MS) nicht zu sehen sind. Diese sind je nach DAC-Level unterschiedlich stark. Um Null herum füllen sie sogar bei einigen Leveln den halben Bildschirm, wie du den beiden Bildern entnehmen kannst. Was den DAC angeht, so wird eine Verstellung um ein MSB bei Zeitbasen von 1mV/div einem großen Sprung auf dem Bildschirm entsprechen, daher hatte Walter den Tausch vorgeschlagen. Zudem sollte sich der Signal-Störabstand des DAC-Ausgangssignals durch die höhere Auflösung in den anderen Spannungsbasen reduzieren. Immerhin wird jedwedes DAC-Rauschen mit verstärkt, weil das DAC-Signal relativ früh in den Signalzweig eingespeist wird und somit alle Verstärkerstufen durchläuft. branadic
Moin moin,
ich hab mich noch mal drangesetzt und einige Testreihen zum DAC gemacht
bzw. die Werte nachgerechnet und die techn. Specs verglichen.
Grundsätzlich bringt der 16 Bit DAC in den 5er Ranges keinen Vorteil und
in den 2er Ranges nur wenig.
Die elektrischen Eigenschaften der drei Typen sind identisch.
Die Schrittweite beträgt beim 14 Bit DAC in den 5er Ranges 3/Pix und in
den 2er Ranges 1 bzw. 2/Pix.
Beim 16 Bit Dac liegt die Schrittweite in den 5er Bereichen bei 12 bzw.
13/Pix und in den 2er Bereichen bei 5/Pix.
Einen Auflösungsvorteil bringt es in den 1er Bereichen, da hier die
Schrittweite des 14 Bit DAC bei 1/2Pix liegt. Heißt übersetzt, nur alle
2 Pixel wird der DAC um 1 weitergestellt.
Das ist natürlich beim 16 Bit DAC besser. Hier liegt die Schrittweite
dann bei 2 bzw. 3/Pix.
Die Werte kann jeder leicht selbst ermitteln, wenn er sich über ein
Terminalprogramm die Variablenwerte ausgeben läßt (","). Die DAC-Werte
findet man im fünften Abschnitt.
So Branadic,
nun zu Deinem Problem auf Kanal 3. Das scheint mir ein Hardwareproblem
zu sein - kalte Lötstelle, Brücke etc.. Bei mir funktioniert sowohl der
Zero-Abgleich als auch alles Andere. Keine Spikes oder sowas Ähnliches.
Die firmwareseitige Implementierung ist also ok.
Ich werde mir den DAC also auch einbauen um in den 1er Bereichen eine
feinere Auflösung zu erzielen.
In der nächsten Version wird die Ansteuerung so sein dass keine
Umschaltung mehr erforderlich ist und auch ein gemischter Betrieb (bei
den 4 Kanalern) möglich ist.
Gruß Hayo
Hayo W. schrieb: > Das scheint mir ein Hardwareproblem > zu sein - kalte Lötstelle, Brücke etc Das glaube ich nicht Hayo, weil die Spikes sofort weg sind, sobald die Samplerate >25MS beträgt, wie erklärst du das elektrisch? branadic
Geschickter Einwand - aber wie erklärst Du Dir dass es nur bei bestimmten Zeitbasen auftritt obwohl die Zeitbasen keinen Einfluß auf die DAC-Ansteuerung haben? Ich bin gerade bei der neuen Version, damit kannst Du das nochmal prüfen - und alle Anderen auch, da jetzt die DACS immer gleich angesteuert werden. Gruß Hayo
Hallo Hayo, ich behaupte ja nicht, dass es zwangsläufig an der DAC-Ansteuerung liegt, könnte auch was anderes im FPGA o.ä. sein. Ich kann dir nur nicht sagen was es ist, genauso wenig wie jemand beantworten kann, woher die Spikes auf den Kanälen genau kommen, denn im Leon-Design sind sie nicht zu finden. Witzigerweise sind sie auf Kanal 1 in voller Signalhöhe zu sehen, auf Kanal 2 kippen sie um die Hälfte hoch und runter und auf Kanal3 sehe ich sie gar nicht, wenn nicht gerade der DAC-Level auf einer ungünstigen Position steht und die oben gezeigten Störungen produziert. branadic
alex008 schrieb: > Für eine VHDL-Entwicklung ist unbedingt ein Niveau für einen > Digitalchip-Entwickler nötig. Welches Standardwerk empfiehlst du als Lektüre, um auf das Niveau eines Digitalchip-Entwicklers zu kommen? Ich habe bisher noch keinen Chip entwickelt, weiß aber grundsätzlich, wie Chips entwickelt werden und kenne mich zumindest in Assembler und C sehr gut aus. Ich habe auch mal einen Compiler für einen Scheme-Prozessor geschrieben, das war sehr hardwarenah. > Das war der Teil in unserem Studium, bei > welchen die meisten Studienkollegen aufgrund der Fehleranfälligkeit und > der Unüberschaubarkeit teils große Schwierigkeiten haben. > Weiters wollen die meisten im Berufsleben nichts mehr damit zu tun > haben. Das bedeutet also, dass es nur wenig VHDL-Entwickler gibt? Wie sind zur Zeit die beruflichen Aussichten? Muss man sich international orientieren? Und wie sieht es mit Verilog aus? Das würde mich wirklich mal interessieren. Gruß Ingo
Ich arbeite in einer kleineren Chipentwicklungsfirma, bin selbst aber embedded Softwerker. Nachdem was ich so manchmal mitkriege: VHDL ist kaum noch üblich, wird eher als Lehrsprache betrachtet. Die produktive Arbeit wird in Verilog erledigt. Das ist vielleicht so wie Pascal (oder Modula-2) vs. C. War mal anders, als ich anfing war VHDL höher angesehen. Jörg
Ok werte Gemeinde, ich war fleißig und habe die letzten Tage durchprogrammiert. Leider hat die Zeit nicht gereicht alle Punkte auf der Liste abzuarbeiten, aber die neue Version kann sich trotzdem sehen lassen. Hier die Highlights: - automatischer Support für 12/14/16 Bit DAC ohne Umschaltung! Auch gemischte Bestückung. - neue Kalibrierroutine die für die neue DAC-Ansteuerung optimiert wurde und eine neue Kalibrierlogik hat, die jetzt den Offset dynamisch gegen Null approximiert. Weiterhin habe ich den ADC-Abgleich und den DAC-Abgleich zusammengelegt. Es gibt also nur noch einen Button für den Abgleich. Damit Ihr die neue Routine besser testen könnt habe ich die Debug-Ausgaben auf RS232 dringelassen. Ihr könnt Euch also den Abgleichvorgang in einem Terminalfenster ansehen und prüfen ob er wirklich auf Null geht. D.h. der Offset liegt dann unterhalb der Anzeigegenauigkeit in allen Spannungsbereichen! Besser geht es nicht... - Der freie Platz neben dem Kalbrierbutton hat auch schon eine neue Funktion bekommen. Hier kann man zwischen 4 verschiedenen Kalibriersätzen wählen (für branadic und alle die aktive Tastköpfe benutzen) - Main Wheel Support für die Channel Delay Popups und für Average und Noise Filter. - Weiterhin noch einige kleine Änderungen. (siehe changelog und special_functions.txt) Gruß Hayo
Hallo Hayo, ich hab die neue Version mal eingespielt, allerdings ist nach der Kalibrierung mein Kanal3 (über Kanal4 kann ich nichts sagen da teilentstückt) verschwunden. Hab mal zwei Kalibriervörgänge mitgeschnitten, vielleicht kannst du darin was entdecken? branadic
Hallo Branadic, Dein Kanal 4 liefert wie erwartet keine Werte. Aber Kanal 3 wird korrekt kalibrtert. Gruß Hayo
Hallo Hayo, wie ich schrieb habe ich den teilweise entstückt, um Platz für die Huckepackplatine zu machen. Wirkt sich das jetzt etwa negativ auf die Kalibrierung von Kanal 3 aus? branadic
Ah, du hast in der Zwischenzeit dein Posting editiert, auch gut... Ich habe mich einmal durch die Calibration Sets gedrückt und wenn ich dann wieder bei Standard ankomme, dann ist Kanal 3 wieder da. Noch was, Kanal 1 ist zu tief, also unterhalb der gedachten Nulllinie, woran kann das liegen? branadic
Da haben sich unsere Posts wohl überschnitten. Ich hatte beim zweiten Überlesen schon gesehen dass Du den Kanal 4 rausgelötet hast. Hast Du die Kalibrierung mal für alle 4 Kalibrier-Sets gemacht? Deinem Protokol entnehme ich aber, dass mit Deinem Kanal 3 alles genau richtig klappt. Also hakt es wohl woanders. Gruß Hayo
Es könnte sein, dass die DAC-Skalierungsfaktoren für die 16 Bit DACs angepasst werden müssen. Dafür muß ich aber bei mir den 16 Bit DAC einbauen um das zu überprüfen. Gruß Hayo
Okay, jetzt haben wir den zeitlichen Versatz wieder ausgeglichen :) Also, nach der Kalibrierung muss ich mich einmal durch die Sets drücken, damit Kanal 3 wieder dargestellt wird. Vielleicht hängt das irgendwie mit meinem Kanal 4 zusammen, kann gut sein. Kanal 2 und 3 liegen dann sauber auf Null, nur Kanal 1 liegt 6 Pixel unter Null. Hab das mit der Triggerlinie mal ausgezählt. Lässt sich das eigentlich irgendwie über das Terminal manuell erade biegen? Die Testschalter scheinen nicht mehr ganz aktuell zu sein oder irre ich mich da? branadic
Warte mal, ich seh mal kurz nach. Ich hatte die manuelle DAC-Kalibrierung extra drin gelassen. Moment...
Es ergibt sich ein Bild Hayo, die Abweichung hat was mit der Position auf dem Bildschirm zu tun, bei Kanal 1 fällt das nur gleich so extrem auf, weil der Kanal am oberen Bildschirmrand klebt. Kurbel ich Kanal 3 auch nach oben auf die Position von Kanal 1, dann weißt er den gleichen scheinbar negativen Offset auf. Spannungspegel und Bildschirmposition passen nicht 100% zusammen, dass ist alles. In der Bildschirmmitte ist auch bei Kanal 1 alles in Ordnung. branadic
...ok hab's, also mit shift + Z kannst Du den Testkanal verstellen der den wirksamen Kanal vorgibt. Den Spannungsbereich für den kalibriert wird mußt Du von Hand einstellen (5er oder 2er oder 1er) mit der normalen Bereichseinstellung auf dem Frontpanel. Du mußt natürlich auch ein Kalibrierset ausgewählt haben mit dem Du testest. Die kalibrierung kannst Du dann mit Shift + E hochzählen und mit Shift + W runterzählen. Das Ergebnis kannst Du Dir dann mit "," ansehen. Bei mir liegen die Offsetkorrekturen bei: * CH1 DAC correction 1: 406 * CH3 DAC correction 1: 448 * * CH1 DAC correction 2: 478 * CH3 DAC correction 2: 506 * * CH1 DAC correction 3: 400 * CH3 DAC correction 3: 427 * * CH2 DAC correction 1: 358 * CH4 DAC correction 1: 418 * * CH2 DAC correction 2: 422 * CH4 DAC correction 2: 478 * * CH2 DAC correction 3: 373 * CH4 DAC correction 3: 427 * Gruß Hayo
Ok, hast Du mal Dein Hardwaresetting geprüft? Welchen Pre Gain hast Du eingestellt? Das was Du da beschreibst deutet auf die Skalierungsfaktoren hin! Gruß Hayo
Hallo Hayo, ja habe ich geprüft, das passt soweit auch alles, steht auf PreGain 1.25. Messungen mit Multimeter und Oszi an einer Batterie oder an einem Labornetzteil zeigen auch näherungsweise das gleiche Ergebnis. branadic
Hallo Hayo, anbei mal drei Bilder, die verdeutlichen sollen, was Sache ist. Vielleicht hilft das bei der Fehlersuche? branadic
Ok, das sind ganz klar die Skalierungsfaktoren, die nicht passen. Wenn auf Gridmitte die Offsets Null sind aber oben und unten im Grid Aweichungen auftreten dann ist es das. Die sind ja auch nur für den 14 Bit DAC ermittelt worden. Leider kann ich da erst tätig werden sobald ich den 16 Bitter bei mir drin habe. Ich könnte sonst noch versuchen so nach Gefühl die Werte für Dich anzupassen, damit Du was zum Probieren hast. Wie sehen denn die 5er und 2er Bereiche aus? Gruß Hayo
Hast Du die Möglichkeit zu kompilieren? Die Faktoren findest Du in der
tc_vars.cpp ab Zeile 1165.
float DAC_ScaleFactor[3][5] =
gain 1/gain 1.25/24 Ohm/33 Ohm/addon
{{ 2.480, 2.480, 2.6456, 2.520, 2.476 }, // 1er ranges
{ 4.940, 4.940, 5.2912, 4.980, 4.952 }, // 2er ranges
{12.360,12.360,13.2280,12.432,12.432 }}; // 5er ranges
Du könntest sie Dir einfach selbst anpassen.
Hayo W. schrieb: > Wie sehen denn die 5er und 2er Bereiche aus? Kann ich dir heute Abend sagen, muss ich prüfen. Hayo W. schrieb: > Hast Du die Möglichkeit zu kompilieren? Nein, ich habe die Tool Chain nicht installiert, da ich mit Programmierung, die über Matlab/Octave hinaus geht, nicht wirklich was am Hut habe. branadic
Hayo W. schrieb: > Hast Du die Möglichkeit zu kompilieren? Kann ich übernehmen. Welche Werte müssen denn geändert werden? Jeweils der letze in der Zeile? Mfg, Kurt PS: Die Digikey Lieferung ist schon in Köln und müsste morgen ankommen.
Nein etwas anders, am Besten Du suchst Dir eine Spalte aus - z.B. die Letzte. Die läßt sich dann anwählen über das Hardwaremenü Pre Gain -> "Addon". Die drei Werte sind dann für jeweils einen Spannungsbereich. Der Oberste für die 1er Spannungsbereiche, der mittlere für die 2er und der unterste ist für die 5er. Ich vermute, dass die Werte für den 16 Bit DAC einfach noch nicht genau genug sind und nur feinjustiert werden müssen. Zum Justieren muß die Nullposition des Kanals möglichst weit oben oder unten sein um die maximale Abweichung zu haben. Gruß Hayo
Was mich aber etwas wundert, ist der Unterschied zwischen Kanal 2 und den beiden andern Kanälen. Kanal 2 sieht ja eigentlich ganz ok aus. Es sollte bei gleicher Eingangshardware eigentlich keinen Unterschied geben. Ist da was an den Widerständen geändert worden? Gruß Hayo
Hallo Hayo, verdammt, es ist schon so lange her... ich habe auf Kanal 1 und Kanal 3 die 24.9Ohm drin, Kanal 2 hat noch die 0 Ohm drin. Den 150k hab ich allerdings nicht ausgetauscht. Wenn ich jetzt die beiden Kanäle nach oben kurbel wird die Abweichung zur Nulllinie aber noch größer. Hier stoßen wir also auf die erste Problematik, wie die ganzen Hardwareunterschiede gescheit in den Griff bekommen? Ich könnte natürlich hergehen und alle Widerstände wie im Datenblatt vorgesehen bestücken, sprich 2x 24.9 Ohm und 150 Ohm. Das sollte dann aber auch die festgelegte Konfiguration für die Huckepackplatine sein, sonst bekommt man das nicht unter einen gemeinsamen Hut. branadic
Na dann ist ja alles klar. Es liegt also nicht am DAC. Mit der 24/150 Ohm Bestückung passen die Faktoren der 24 Ohm Pre Gain Einstellung. Die habe ich auch drin. Rüste die doch einfach um, das ist vom Aufwand her am einfachsten denke ich. Gruß Hayo
Hallo Hayo, passen tut es ja trotzdem nicht 100%ig, siehe Kanal 2 mit PreGain 1.25 Einstellung. Von den 24 Ohm halte ich ebenso wenig wie von den 33 Ohm, wenn man es richtig machen will, dann müssten es entweder 24.9 Ohm mit kleinster Toleranz und den 150 Ohm am ADC sein oder aber handverlesene 24 Ohm, die nominal 25 Ohm aufweisen mit den 150 Ohm am ADC. Alles andere macht schlichtweg keinen Sinn. Schließlich soll es sich um ein Messgerät und nicht um ein Schätzeisen handeln. branadic
Noch ein Nachtrag, Kanal 2 hatte ich seinerzeit nicht umgerüstet, weil da diese tollen nachträglich eingezogenen Leitungen im Weg waren. branadic
Kanal 2 sieht doch gut aus. Must Dir das mal im 5er Bereich ansehen, da ist weniger Rauschen drauf. Sonst rüste das doch erstmal zurück auf Originalbestückung, dann können wir besser vergleichen. Hayo
Kanal 2 ist doch auf Originalbestückung, sprich auf 0 Ohm Widerstände oder meinst du ich solle die DAC zurücklöten? Das muss dann wirklich nicht sein, zumal die das Auslöten eh nicht überlebt haben, ein Nachteil von bleifrei gelöteten SMD-Bauteilen, wenn man die Leiterplatte beim Auslöten schonen möchte. branadic
Nein, nein, nicht den DAC zurückbauen, nur die Widerstände von Kanal 1 + 3. Oder damit leben, dass nur Kanal 2 richtig anzeigt. Jedenfalls zeigt mir Dein Ergebnis, dass die DAC-Ansteuerung korrekt funktioniert. Ich werde das bei meinen Geräten auch mal umrüsten. Gruß Hayo
Branadic, ein Messgerät mit 8-Bit-Auflösung! Also schön ruhig bleiben. ;-) Auch mit 10 Bit wird es kein Messgerät. Die Werte sind doch nur Empfehlungen und solange die Software auf ein Pixel genau darauf eingestellt werden kann ist doch alles o.k. Gruß, Guido
Guido schrieb: > Also schön ruhig > bleiben. ;-) Vielleicht bleibst du noch ne Nummer ruhiger und schaust mal, wie groß die Abweichung tatsächlich ist? Im Rahmen dessen was möglich ist sollte man auch genau sein! branadic
Schon klar, dass das zuviel ist. Aber mit den Widerständen muss es nicht so exakt sein. Das meinte ich.
Ich nutze das FFT oft für Audio Projekte. Gibt es eine Möglichkeit, das das Spektrum feiner eingestellt werden kann? Das währe bei kleinen Frequenzen sehr sinnvoll.
Die FFT-Sektion ist noch "under construction", d.h hier wird sich noch einiges tun. Was meinst Du denn mit feiner einstellen? Die Auflösung der Spektrallinien ist durch die kleinste Abtastrate (500Sa/s) und die Bildschirmauflösung begrenzt. D.h. ich kann maximal eine FFT mit 1024 Werten machen und habe dann 512 Spektrallinien. War es das was Du meintest? Gruß Hayo
So, für das Wochenende gibt es wieder was zum spielen. Diesmal habe ich mich der Screenshot-Funktion angenommen und einen Rundumschlag gemacht (aufgeräumt und erweitert). Auf der DSO Seite gibt es jetzt keine Unterscheidung mehr zwischen OS und BF-Version. Es gibt nur noch die Möglichkeit zwischen den Zielen PC und USB-Host zu wählen. Für alle Screenshots wird jetzt die schnellere Kompressionsroutine der 0.92.OS Version verwendet. Auf PC Seite gibt es zwei neue Screenshot-Versionen. Beide können wahlweise eingesetzt werden und verwenden beide den gleichen Kompressionsalgorithmus. - die neue OS-Version 0.93 hat sich bei der Parametererkennung über RS232 etwas geändert. Das heißt sie ist weiter abwärtskompatibel zu älteren Firmwareversionen (BF und OS), aber sie läßt sich genauso mit der neuen FW ansteuern und kann wie gehabt auch remote triggern. - die neue BF-Version 2.0 hat jetzt den schnellen Kompressionsalgorithmus der OS-Version. Der Aufruf ist noch schlanker geworden, es kann optional der Port (bzw. das device) übergeben werden, muß aber nicht. Defaultmäßig wird wie bei der OS-Version COM1 bzw. /dev/ttyS0 verwendet. Bei ASCII und CSV Format werden zusätzlich die aktuellen Einstell-Parameter übertragen und ans Ende der Datei gehängt. Die alten Screenshotversionen können nicht mehr verwendet werden!!! Gruß Hayo
Hallo alle zusammen, habe mich gerade mit dem seriellen Update beschäftigt: Für das .ram reicht es aus, das File mit mode com1,115200,n,8,2 leider ist der mode-Befehl sehr buggy, meist geht 115200 nicht copy /b tomcat.ram com1 zu übertragen. Wichtig sind die 2 Stopbits, sonst ist die Übertragung zu schnell. Der Transfer dauert dann 1313562*(1+8+2)/115200=125,426 Sekunden. Alternativ die Übertragungsfunktion (Upload) eines Terminalprogramms verwenden, auch hier 2 Stopbits. Dazu muss man allerdings das Kabel oder die DSUB-Buchse modifizieren, weil sonst ein Error kommt. An der Dsub9-Buchse sind tatsächlich nur die Pins 2, 3 und 5 angeschlossen, nicht einmal Shield liegt auf Gnd. Um den copy-Befehl auf die Serielle zufriedenzustellen, müssen die Pins 1,6,7,8,9 miteinander verbunden werden. Zu der fackernden LED im Stop-Mode: hier wäre ein retriggerbares Monoflop das richtige, d.h. sobald ein Triggerereignis eintritt, wird ein Zähler wieder auf seinen Anfangswert (z.B. 50) gesetzt, um dann jede Millisekunde heruntergezählt zu werden. Solange er ungleich 0 ist. leuchtet die LED. D.h. bei Signalen über 20 Herz soll die LED durchgehend leuchten. Die kurze Leuchtdauer soll auch für das Leuchten bei Triggerauslösung gelten, hier leuchtet die LED etwas zu lange. Lieber Hayo, ich habe großen Respekt vor Deinem Durchhaltevermögen und Deiner Konsequenz. Vielen Dank von meiner Seite, dass Du alle meine Vorschläge umgehend realisiert hast. Ist es möglich, das Menü für die LED-Steuerung zu erweitern? Es wäre toll, wenn man bei der rechten LED zusätzlich auswählen könnte, ob sie bei einem potentiellen Trigger (trigger) aufblitzt oder nur bei einem tatsächlich ausgelöstem Trigger (trig'd = triggered). Der Punkt "use Ch4-LED" sollte eigentlich eine separat aktivierbare Checkbox sein, um die LED umzuleiten, unabhängig von ihrem Modus. Genauso könnte es man auswählbar machen, ob ein Druck auf Single im NORM-Mode - auf single schaltet (wie es momentan ist) oder - einen manuellen Trigger auslöst (was ich bevorzuge, man muss dann über Stop gehen, wenn man auf Single will.) Noch was zur Spannungsanzeige des Triggerlevels: die stimmt nicht exakt mit der Voltage/Division überein. bei 50mV/div und Triggerlinie exakt ein Kasterl daneben wird 52mV angezeigt. Zur Anzeige und Schrittgröße beim Drehen an der PreTrig-Time: die Anzeige sollte immer 3 gültige Stellen haben (ist von 9,0 bis 9,9 ms nicht der Fall) und eine Rastung soll sich immer auf die letzte Ziffer beziehen. Jetzt muss man z.B. 13 Rasten drehen, um von 99,0 auf 100,0 ms zu kommen (oder 2 Rasten von 10,1 auf 10,2). Oder man macht die Einstellung exponentiell, indem die Schrittweite immer z.B. 1% des angezeigten Wertes beträgt. Und diese Schrittweite wünsche ich mir per Druck auf den Drehknopf z.B. zyklisch aus drei-acht Werten auswählen zu können (z. B. 1, 2, 5 digits, 1%, 2%, 5% des momentanen Wertes). Das sind viele Wünsche, ich weiß. Bis demnächst
Angehängte Dateien:
-
bug-2.13-kanal3u4_1.png
4,9 KB -
bug-2.13-kanal3_2.png
5,8 KB
Hallo Hayo, bzgl. Firmware v2.13: Ich habe da einen merkwuerdigen Bug gefunden, den ich wie folgt 100%tig reproduzieren kann: (1) Zeitbasis <= 50ns/Div (2) Kanal 3 oder 4 aktivieren (3) "Center Channel" Softbutton druecken Bildschirmausgabe dann wie im ersten Screenshot. Tritt jedoch nicht bei Kanal 1 u. 2 auf. Verschiebe ich Kanal 3 per Hand ein paar Pixel nach oben, kann ich gar die Ausgabe wie im zweiten Screenshot provozieren. Dies funktioniert jedoch nicht bei Kanal 1, 2 und 4. Verschiebe ich die Kanaele wieder woanders hin sind die Fehler weg. Ob ich im Display Menue bei "Switch Drawing" Line() oder vertical pixel eingestellt habe macht keinen Unterschied. Der Bug tritt auch bei anderen, etwas langsameren Zeitbasen auf, allerdings nicht genau in der Mitte. Default-Setup und Abgleich habe ich vorgenommen. Ich habe das W2024A. Vorherige Firmware-Version war die 2.10, dort habe ich den Fehler nicht beobachtet. Niklas Zusatz: Lasse ich mir den Trace im Bug-Zustand auf RS232 als CSV ausgeben finden sich viele Werte fuer den betroffenen Kanal mit 0 und 254, d.h., vermutlich ist es kein reiner Fehler bei der Zeichnung.
Hallo Ihr Beiden, danke für die Rückmeldung. Ich bin leider dieses Wochennde etwas knapp an Zeit, aber Eure Beiträge sind zur Kenntnis genommen. Ich muß mal sehen ob ich morgen oder übermorgen Abend dazu komme mich damit etwas näher zu beschäftigen. Gruß Hayo
Noch was, vielleicht hilft es Dir, Hayo, bei der Fehlersuche: Die Anzahl, wie oft auf Single gedrückt werden muss, bis ein Trigger ausgelöst wird, hängt von der Zeitbasis ab: 1ms 1x 2ms 2x 5ms 4x 10ms 8x 20ms 16x 50ms 32x 100ms 64x @branadic: auch ich denke, dass man keine Widerstände selektieren braucht, sondern dass die Korrekturfaktoren eingebbar sein sollen. So kann man x-beliebige krumme Verstärkungsfaktoren wählen, um z.B. den ADC-Eingangsbereich optimal zu nutzen. Allerdings weiß ich nicht, ob ohne HW-Mul das von der Performance her sinnvoll ist. Auf jeden Fall freut es mich, dass wieder alle an einem Strang ziehen und es zügig vorangeht. Ich komme ja kaum mit dem Flashen hinterher ;-)
Hallo Niklas, es hat mir keine Ruhe gelassen. Ich habe mal versucht das nachzustellen, aber ich kriege es nicht hin. Welche Hardwareeinstellung hast Du gewählt? Kann das noch jemand hier nachstellen, oder ist das ein spezielles Problem von Niklas? Gruß Hayo
Hallo Hayo, > es hat mir keine Ruhe gelassen. Ich habe mal versucht das nachzustellen, > aber ich kriege es nicht hin. Mhm, gerade, nachdem das Geraet fuer eine Stunde aus war, habe ich es auch nicht sofort wieder reproduziert bekommen, erst nach "Utility->Calibrate Offsets" klappt es wieder 100%tig. (Nach "Warmlaufen" des Oszis kann ich btw. eine Verschiebung der Nullinien gegenueber Kaltzustand feststellen, vllt. ist zum Reproduzieren daher ein frisches "Calibrate Offsets" noetig.) > Welche Hardwareeinstellung hast Du gewählt? Du meinst "Utility->More->Hardware"? ADC -> Factory PreGain -> Factory zudem in "Utility->More": Delays: Ch1: 8ns / Ch2: 0ns / Ch3: 5ns / Ch4: 5ns Das Geraet ist bis auf Schirmblech und zwei SMD LEDs beim Trigger unveraendert. Ich sehe auch gerade das branadic oben in seinem Beitrag vom 19.2.: Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil4)" einen aehnlichen Effekt beobachtet hat. Niklas
Angehängte Dateien:
-
bug-2.10-kanal3u4.png
4,5 KB
Hallo nochmal,
ich habe die alte v2.10 mal ins RAM geladen, um zu schauen,
ob das Problem wirklich dort nicht auftaucht.
Ergebnis: Auch bei v2.10 habe ich den Effekt bei Kanal 3 und 4,
allerdings nicht genau auf der Bildschirmmitte sondern etwas
versetzt (3-10 Pixel) nach oben. Da ich meist "Center Channel" bzw.
"Dispatch Channels" benutze ist es mir wohl bislang nicht
aufgefallen.
Ebenso wie Hayo frage ich mich ob es ein isoliertes Problem bei
mir ist oder auch bei anderen 4-Kanal-Geraeten auftritt.
Wer testen moechte:
(1) Zeitbasis auf 50ns/Div einstellen, Trigger auf "Auto"
(2) Kanal 3 oder 4 auf Bildschirmmitte ("Center Channel")
(3) Pixelweise nach oben (oder unten) verschieben
Weiter frage ich mich, ob es sich um ein thermisches Problem
handeln koennte, da die Anzahl Ausreisser mit Aufwaermen des Oszis
zuzunehmen scheinen. Allerdings erklaert das nicht, warum der Fehler
beim Verschieben des Traces verschwindet bzw. ueberhaupt anscheinend
nur in der Bildschirmmitte auftritt.
Das sieht fuer mich daher eher nach einem Bug in der
Softcore-Firmware aus.
Anbei nochmal ein charakteristischer Screenshot, FW v2.10.
Niklas
Bevor ich verschwinde und bei meinen Schwiegereltern die Bude entrümple noch ein Gedanke: Stell doch mal alle Delays auf 0ns und probier es nochmal. Gruß Hayo
Hallo Hayo,
> Stell doch mal alle Delays auf 0ns und probier es nochmal.
Macht leider keinen Unterschied. Auch die anderen Einstellungen
zu ADC und PreGain scheinen keinen Einfluss zu haben.
Niklas
Niklas O. schrieb: > Wer testen moechte: Hab' ich getan mit 'Default Setup' und dann wie oben. Bei mir am W2024A mit FW BF2.13 ohne Befund. Kommt mir wie ein klemmendes oberstes Bit vor? Hast du mal von außen ein Analogsignal (Sägezahn/Sinus) draufgegeben und beim Nulldurchgang geguckt? Gruß Rainer
Den gleichen Verdacht mit dem verklemmten Bit hatte ich auch schon. Vorschlag zur Fehlersuche: Auf der Platine des geöffneten DSO auf die Chips drücken. Teilweise sind die Lötverbindungen an den SMD-Bauteilen nicht optimal und verursachen dann so komische Effekte. Ich glaube Kurt hatte das mal an den RAM-Bausteinen. Gruß Hayo
Ich kann mir keine Ursache in der Platinenhardware vorstellen, die einen solchen Effekt verursachen sollte. Wenn die Daten digitalisiert und erst einmal im FPGA gelandet sind, wie sollen da die Bit kippen, wenn nicht gerade ein Fehler im FPGA oder in der Firmware vorliegt, das irgendwo irgendwelche Überläufe o.ä. stattfinden. Ich habe bspw. auf Kanal 2 den Effekt, dass die "zufälligen" Spikes nur zur Signalhälfte kippen. Das kann kein Fehler der Platinen-Hardware sein, zumal mit Alex Design derartige Effekte bisher überhaupt nicht beobachtbar sind. branadic
Angehängte Dateien:
-
sinusdurchgang.png
3,4 KB
Hallo Hayo und Rainer, scheint in der Tat ein klemmendes Bit zu sein. Gerade wie vorgeschlagen nen Sinus angelegt. Die Fehlwerte treten genau wie erwartet beim Nulldurchgang auf. Anbei Screenshot. Nicht wundern, ich habe leider hier nichts besseres als 750 kHz aus nem XR2206-basierten Generator und bei Zeitbasen >100ns/Div treten die Ausreisser zu selten auf als das ich das mit einem Screenshot haette aufzeichnen koennen. Die Ursache ist damit wohl geklaert, danke an euch fuer den Tipp. Kalte Loetstellen wuerden dann auch die beobachtete Verschlimmerung bei Erwaermung erklaeren. Aufschrauben und evtl. Nachloeten verschiebe ich aber erstmal bis auf unbestimmt. Niklas Update: Urgs, zweimal den selben Screenshot. Kann man anscheinend auch nicht wieder entfernen.
Niklas O. schrieb: > Anbei Screenshot. Nicht wundern, ich habe leider hier nichts > besseres als 750 kHz aus nem XR2206-basierten Generator und > bei Zeitbasen >100ns/Div treten die Ausreisser zu selten auf > als das ich das mit einem Screenshot haette aufzeichnen koennen. Sieht doch super aus. Meine Interpretation ist, dass das oberste Bit etwas verspätet schaltet und dadurch am Nulldurchgang steigend (0xFF -> 0x00) gerne 0x80 auftritt bzw. fallend (0x00 -> 0xFF) der Wert 0x7F. Das wären dann Peaks nach Minus-FS bzw. nach Plus-FS. Der erste Fall ist genau in deinem Bild zu sehen. Am fallenden Nulldurchgang würde ich entsprechend einen Peak nach "+" erwarten. Das Problem wäre dann an einer Stelle, wo die Werte als 2er-Komplement vorliegen. Die Verzögerung muß natürlich nicht zwingend durch eine schlechte (hochohmigere) Lötstelle entstehen, sondern kann auch an einem Timingfehler und temperaturabhängigen Toleranzen im FPGA liegen, was sich dann mit branadics Interpretation decken würde. Hast du einen anständigen Lüfter drin? Gruß Rainer
Angehängte Dateien:
Hallo nochmal, Rainer schrieb: > Der erste Fall ist genau in deinem Bild zu sehen. > Am fallenden Nulldurchgang würde ich entsprechend > einen Peak nach "+" erwarten. Ich habe das ganze mal >5 Minuten mit "Display->Persist" aktiviert bei 1us/Div aufzeichnen lassen. Deine Erwartung trat dort nicht ein, wobei wie gesagt bei diesen langsamen Zeitbasen die Ausreisser selten auftreten. (Screenshot 1) Ich habe auch mal die Amplitude (und damit die Steilheit auf dem Screen) stark erhoeht und mir den fallenden Nulldurchgang bei 50ns/Div angeschaut. Dort sehe ich dann die von Dir erwarteten "+" Peaks. (Screenshot 2) (Im aufsteigenden Durchgang entsprechend "-".) Was ich nicht verstehe ist aber, warum ich, wenn ich den Trace nach unten verschiebe, die Spikes weiterhin in der Bildschirmmitte, und nicht wie ich erwarten wuerde beim wahren Nulldurchgang, sehe? (Screenshot 3) Jetzt bin ich schon sehr irritiert. Was passiert denn mit den Werten der 4 interleaveten ADCs pro Kanal bis sie irgendwann im Softcore ankommen und gezeichnet werden? (Ich vermute mal dass die Softcore zeichnet, bitte korrigiert mich wenn ich falsch liege, den Teil der Firmware habe ich mir nie angeschaut.) > Hast du einen anständigen Lüfter drin? Originalluefter mit der Klebestreifen-Modifikation, jedoch ohne vergroesserte Schlitze aussen. Also "nein" :) Niklas
Niklas O. schrieb: > Ich habe das ganze mal >5 Minuten mit "Display->Persist" > aktiviert bei 1us/Div aufzeichnen lassen. Deine > Erwartung trat dort nicht ein, ... Mmmh. Da müßte man jetzt wissen, welche der Abtastwerte bei 1us/div für die Darstellung benutzt werden. Die Chancen die entscheidende Wandlung zu verpassen, ist da vielleicht schon zu groß und die Peaks, die da in die "falsche" Richtung gehen, könnten durch Rauschen entstehen, das da gerade in Gegenrichtung läuft (???). > Was ich nicht verstehe ist aber, warum ich, wenn ich den > Trace nach unten verschiebe, die Spikes weiterhin in > der Bildschirmmitte ... sehe? (Screenshot 3) Ohne jetzt in den Schaltplan geguckt zu haben, vermute ich, dass die Signalverschiebung durch Addition eines Offsets aus dem DAC gemacht wird. Die ADCs messen immer bezogen auf die Bildschirmmitte (Man möge mich bitte korrigieren, wenn ich da falsch liege) > Jetzt bin ich schon sehr irritiert. Was passiert denn > mit den Werten der 4 interleaveten ADCs pro Kanal bis sie > irgendwann im Softcore ankommen und gezeichnet werden? Gute Frage. Eine Möglichkeit wäre, dass der Peak immer vom selben ADC kommt. Aber dann wäre mir nicht klar, wieso Kanal 3 und 4 betroffen sind. Werden die Peaks eigentlich plattgebügelt, wenn du ein Noise Filter aktivierst? Als Lüfter bin ich mit dem "NOISEBLOCK 8X1R" von ex. Angelika sehr zufrieden (80 mm und nicht zu hören) Gruß Rainer
Also mein Vorschlag ist immer noch (kostet auch nix) - schraub die Rückwand ab, starte das Gerät und provoziere den Fehler. Dann drückst Du auf den ADCs des dritten oder vierten Kanals etwas herum - die sind da frei zugänglich. Wenn sich da nix ändert würde ich bei Gelegenheit die Chips auf der Rückseite der Platine in Angriff nehmen, aber dazu muß man etwas mehr auseinanderschrauben. Wie gesagt hatte Kurt (wenn ich mich nicht irre) darauf hingewiesen dass das durchaus kein Einzelfall ist. Gruß Hayo
Hayo W. schrieb: > Wie gesagt hatte Kurt (wenn ich mich nicht irre) darauf hingewiesen dass > das durchaus kein Einzelfall ist. Nein, das war wahrscheinlich Bruno. Ich hatte nur mal Lötzinnbrücke zwischen 2 Eingängen eines Schieberegisters.
Hallo, mal was anderes: Man kann ja, wenn man bereits im Mode/Coupling-Menue ist, durch abermaliges Druecken der Taste Mode zwischen Auto, Normal und Combi umschalten. Ich faende es sinnvoll, wenn eine Umschaltung analog dazu auch bei Edge (Rising->Falling->Rising->...) und Pulse Width (Time Qualifier-Variationen), als sowohl fuer Main/Delayed (Main->Delayed->Main->... (nicht X-Y)) moeglich waere. Das ganze habe ich gerade mal in 20 Zeilen eingebaut (alles Ergaenzungen, keine Zeilenaenderungen). Diff ist im Anhang. Vllt. kann Hayo das ja bei der naechsten Version einbauen. Ansonsten, bzgl. Screenshot/Datendump: Mittlerweile benutzen wohl sowohl das Original als auch die abgewandelte BF-Version die selbe Kompression (und wohl auch selbes Protokoll). Unterschied scheint mir nach kurzem Blick eigentlich nur Verhalten gegenueber dem Nutzer und moegliche Optionen zu sein. (Plus Neuerungen wie Ausgabe Einstellungsparameter bei CSV/ASCII.) Ich finde es unschoen, da immer noch zwei Versionen zu haben -- bei fast identischer Codebasis. Wenn nichts dagegen spricht wuerde ich mich daran machen, diese wieder zusammen zu fuehren. Das gewohnte unterschiedliche Verhalten "OS" vs. "BF" gegenueber dem Nutzer kann man sicher durch Mitliefern von zwei Batchdateien mit entsprechend gesetzten Kommandooptionen beibehalten. Niklas
Hi, bin gerade erst zurück. @Niklas Die Funktionen die Du da als Diff mitgeschickt hast baue ich natürlich mit ein, macht ja auch Sinn. Auch das mit der Screenshotversion hab ich mir schon überlegt, da hast Du natürlich recht. Wir könnten die BF-Version auslaufen lassen und die OS-Version auf den Releasestand 1.00 bringen. Mittlerweile ist es ja ein "stable release". Was dann noch übernommen werden müßte ist die Erweiterung bei ASCII und CSV, ansonsten funktioniert die OS genauso wie die BF-Version und kann aber noch zusätzlich remote triggern und Schwarzweiß-Shots machen. Machst Du das? Gruß Hayo
Ach ja, Du könntest den Namen verkürzen wie bei der BF-Version, dann muß man nicht immer so viel eintippen, sondern kann das Teil einfach ohne Parameter im Defaultmodus starten. Gruß Hayo
Hallo Hayo, > [Screenshot/Dump] > [Uebernahme Erweiterungen] > Machst Du das? Ja. Niklas
Hallo Hayo, zur Vereinfachung der Bedienung habe ich folgenden wahrscheinlich einfach umsetzbaren Vorschlag: Wenn man eine Kanal-Tasten (1..4) zur Aktivierung bzw. Deaktivierung eines Kanals drückt, werden in der aktuellen FW die Softkeys für die zugehörigen Kanaleinstellungen angezeigt. Wenn man jetzt einen Kanal deaktiviert, werden automatisch alle Softkeys disabled, was eigentlich niemand wirklich etwas bringt. Sehr viel praktischer wäre, wenn entweder die Taste "Dispatch Channels" aktiv bliebe oder das ganze Menü auf einen der noch aktiven Kanäle geschaltet würde. Das ist immer richtiger/besser als ein komplett deaktiviertes Menü. Gruß Rainer
Hallo Rainer, da hast Du eigentlich recht. Ich versuche das mal zum nächsten Release einzubauen. Gruß Hayo
Hallo, Alex hat das Wiki zum Leon3 etwas aktualisiert. Ich hoffe, dass in den nächsten Tagen weitere Infos und das aktuelle Preview hinzu kommen, vor allem aber die notwendigen Infos für die Programmierer-Fraktion. http://sourceforge.net/apps/trac/welecw2000a/wiki/leon3design Ich habe gestern mal das Design eingespielt und mich ein wenig darin umgeschaut. Macht schon einen guten Eindruck, auch wenn sich das natürlich nicht mit der aktuellen BF-Firmware vergleich lässt. Die Geschwindigkeit ist jedoch beeindruckend. Man sollte dann keine Angst davor haben, dass Design ruhig mal einzuspielen. branadic
Hallo branadic, erstmal verstehe ich nur Bahnhof, muss ich wohl mehrmals durchlesen. Warst du damals mit dem urjtag weitergekommen? Bei mir hatte es ganz vielversprechend ausgesehen.
Guido schrieb: > Warst du damals mit dem urjtag weitergekommen? Was meinst du damit? Kann mich nicht erinnern an der Baustelle tätig gewesen zu sein. branadic
Dann habe ich das wohl verwechselt. Hatte nur in Erinnerung, dass jemand das passende BSDL-File gesucht hat und dachte du warst das.
@brandic > Man sollte dann keine Angst davor haben, dass Design ruhig mal > einzuspielen. Die letzte Previev ist 7 Monate her, gibt es da eine aktualisierte W2000a.SOF und -BIN ? Oder hattest du die vom letzten jahr eingespielt? Gruß Michael
Michael D. schrieb: > Die letzte Previev ist 7 Monate her, gibt es da eine aktualisierte > W2000a.SOF und -BIN ? > Oder hattest du die vom letzten jahr eingespielt? branadic schrieb: > Alex hat das Wiki zum Leon3 etwas aktualisiert. Ich hoffe, dass in den > nächsten Tagen weitere Infos und das aktuelle Preview hinzu kommen, vor > allem aber die notwendigen Infos für die Programmierer-Fraktion. Ich denke die Frage hatte ich bereits beantwortet und im Wiki ist es auch erwähnt. Es handelt sich um eine neue Preview. branadic
Hayo W. schrieb: > Auf der DSO Seite gibt es jetzt keine Unterscheidung mehr zwischen OS > und BF-Version. Es gibt nur noch die Möglichkeit zwischen den Zielen PC > und USB-Host zu wählen. Hallo Hayo, wo schaltet man das denn um? Wenn ich Quick Print drücke passiert garnichts. Mfg, Kurt
Hallo, anbei das vereinigte "OS+BF" W2000A Screenshot Programm in der Version 0.94. In Kuerze das Wichtigste: Es gab einiges aufzuraeumen. Im Wesentlichen sollte sich das Programm wie gewohnt verhalten. Die Dokumentation ist updatet und die Kommandooption -h sollte jetzt wieder der Realitaet entsprechen (wenn nicht ist das ein Bug, bitte melden). Traces werden jetzt als trace-nnnn.suf und nicht als screenshot-nnnn.suf gespeichert. Die Option -r fuer Raw funktionierte in der OS nicht mehr mit der Firmware und fiel weg. Es gibt eine neue Option -a, die, wie bei der BF Version, so sie fuer Windows kompiliert wurde (und dann auch nur bei Screenshots), zweimal \a, also Bell/Piepser, ausgibt nach jeder Uebertragung. Zudem werden wie bei BF Parameter wie Zeitbasis, Ranges, Kopplungen usw. ausgeschrieben. Die .bat/.sh sind updatet, so dass diese auch funktionieren sollten wenn man sie von einem anderen Verzeichnis aus ausruft. Achja, und die Parameter werden jetzt auch weiter uebergeben. Damit zukuenftig klar ist, ob die Programmversion zur Firmware passt, wird dies nun beim Start automatisch abgefragt. Die Windows-EXE konnte ich nicht mit Scope testen. Ansonsten: Wer Ideen hat, was noch eingebaut werden sollte, kann sich gerne hier melden. Wenn alles passt und nichts grossartiges mehr fehlt koennen wir die Version dann demnaechst 1.0 nennen. Niklas
Angehängte Dateien:
@Kurt Es passiert nix? Bei mir sieht es so aus wie auf dem Screenshot, den ich übrigens mit der coolen neuen 0.94 gemacht habe - läuft gut! Wie ist das bei den Anderen? Habt Ihr da Probleme? Hayo
@Niklas bei mir kommt während der Versionsprüfung die Meldung - unknown token: handleInChar(FF), UartRxGuiCmd: 69 Hat das was zu bedeuten? Ansonsten funktioniert aber alles bestens. Gruß Hayo
Hallo Niklas, fleißig, fleißig. Danke Niklas O. schrieb: > > Die Windows-EXE konnte ich nicht mit Scope testen. Da geht der Daumen auch hoch - läuft > Wer Ideen hat, was noch eingebaut werden sollte, kann sich gerne > hier melden. Mit der Formatierung des Headers bei ASCII und CSV kann ich noch nicht ganz warm werden. Wie wäre es mit etwas Kompakterem/Strukturierterem (ggf. <Tabs> vor den Argumenten), z.B. [Header] number_of_channels=4 channel_status=on;on;off;on channel_ranges=5V/div;5V/div;0;5V/div ... timebase=500KSa/s values=Ch1;Ch2;Ch3;Ch4 [Data] 83;130;255;171 83;129;255;172 ... Um die Daten in einer Tabellenkalkulation einfach richtig skalieren zu können und eine Zeitachse zu generieren, wären die Angaben zu 'Ranges' und 'timebase' in zusätzlichen Parametern als reine Zahlen evtl. praktisch. Gruß Rainer
Rainer W. schrieb: > Um die Daten in einer Tabellenkalkulation einfach richtig skalieren zu > können und eine Zeitachse zu generieren, wären die Angaben zu 'Ranges' > und 'timebase' in zusätzlichen Parametern als reine Zahlen evtl. > praktisch. Ja das hatte ich mir auch schon überlegt, da ja die jetzigen Parameterangaben nur informativen Charakter haben, aber nicht gut automatisch auswertbar sind. Hayo
Hallo, @Hayo: > bei mir kommt während der Versionsprüfung die Meldung > - unknown token: handleInChar(FF), UartRxGuiCmd: 69 > Hat das was zu bedeuten? So wie ich das sehe sind in der aktuellen Firmware Debugging-Ausgaben eingeschaltet, zumindest teilweise. (Siehe commif_t.cpp, Zeile 4'181.) Wenn man auf der seriellen Konsole etwas eingibt, z.B. 'h', kommt auch entsprechend 'handleInChar(68)' zurueck, gefolgt von der Hilfe-Tabelle. Dem Screenshot-Program sind die zusaetzlichen Ausgaben an sich egal. @Rainer: > [Formatierung Header] > Wie wäre es mit etwas Kompakterem/Strukturierterem > (ggf. <Tabs> vor den Argumenten), z.B. [..] Ja, das waere sinvoll. Fuer ASCII sieht Dein Beispiel schon gut aus, aber ich frage mich wie man das bei CSV am Besten machen koennte, so dass man nicht manuell nachbearbeiten und formatieren muss. Gibt es vllt. ein nicht zu schwer zu erzeugendes Tabellenformat das Excel, OpenOffice Calc und so weiter einlesen koennen welches einfache Formatierungen erlaubt? @Rainer, @Hayo: > Um die Daten in einer Tabellenkalkulation einfach > richtig skalieren zu können und eine Zeitachse zu > generieren, wären die Angaben zu 'Ranges' und 'timebase' > in zusätzlichen Parametern als reine Zahlen evtl. praktisch. Ja das sehe ich auch so. Sollte man das noch weiter treiben und gleich im Screenshot-Programm (optional) anbieten die 8-Bit-Zahlen in Spannungswerte umzuschreiben? Zudem muessen sicher nicht 16k Samples rausgeschrieben werden wenn die Zeitbasis in Wirklichkeit mit weniger arbeitet. Abgesehen davon: Generell kann ich das Ganze auch so bauen, dass man mit Templates arbeiten kann. Man hat also z.B. eine Datei rainer.tpl, mit Inhalt wie folgt:
1 | [Header] |
2 | number_of_channels=%numchannels% |
3 | channel_ranges=%ch1range_str%;%ch2range_str%;5%ch3range_str%;%ch4range_str% |
4 | [..] |
5 | [Data] |
6 | _FOREACH_%ch1%;%ch2%;%ch3;%ch4% |
...die dann zu Rainers Beispielausgabe expandiert. Allerdings sollten meiner Meinung nach erst die vorherigen Punkte klaeren und dies als zukuenftige Erweiterung ansehen. Niklas
Hallo Niklas, als importfreundlichen Header könnte ich mir soetwas vorstellen: [Header] number_of_channels=<tab>4 channel_status=<tab>on<tab>off<tab>off<tab>off channel_bandwith_limits=<tab>off<tab>off<tab>off<tab>off values=<tab>Ch1<tab>Ch2<tab>Ch3<tab>Ch4 [Data] 160<tab>159<tab>152<tab>188 Excel liest das bei Einstellung Trennzeichen="Tab" gut ein. Für die richtige Skalierung würde ich einfach Sampleabstand in Nanosekunden und Skalierungsfaktoren sowie Offsets als weitere Headerzeilen aufnehmen. Der ASCII-Export mit Templates wäre natürlich der wahre Luxus. Gruß Rainer
Angehängte Dateien:
-
Inverted_Running.png
3,4 KB -
Inverted_Stopped.png
3,4 KB
@Hayo ich bin da gerade noch auf folgenden Bug bei invertierter Erfassung eines Kanals gestoßen: Nach Drücken der STOP-Taste wird der Kanal oft nicht invertiert dargestellt. Gruß Rainer
Rainer W. schrieb: > Für die richtige Skalierung würde ich einfach Sampleabstand in > Nanosekunden und Skalierungsfaktoren sowie Offsets als weitere > Headerzeilen aufnehmen. Der Sampleabstand ergibt sind ja aus der Timebase die bereits übertragen wird. Das mit den Skalierungsfaktoren hatte ich auch auf dem Zettel, hab's aber erstmal verschoben, da man die float Faktoren auf DSO-Seite in Bytes zerlegen muß und auf PC-Seite wieder zusammenbauen muß. Grundsätzlich aber eine gute Idee, kann ich auch noch nachreichen (auf DSO-Seite). > ich bin da gerade noch auf folgenden Bug bei invertierter Erfassung > eines Kanals gestoßen: Nach Drücken der STOP-Taste wird der Kanal oft > nicht invertiert dargestellt. Sehe ich mir an und versuche es zu fixen. Gruß Hayo
Hallo, @Rainer: > Excel liest das bei Einstellung Trennzeichen="Tab" gut ein. Ah, jetzt verstehe ich auch wie Du das mit den Tabs vor den Argumenten heute Morgen meintest. Eigentlich koennten wir das Trennzeichen auch gleich frei konfigurierbar machen. @Rainer und @Hayo: > Für die richtige Skalierung würde ich einfach Sampleabstand in > Nanosekunden und Skalierungsfaktoren sowie Offsets als weitere > Headerzeilen aufnehmen. Ich habe gerade mal geschaut wie ich an die Zero-Offsets (ZeroLevelCh1-4) kommen kann. Irgendwie scheint man da direkt nur ueber USB dranzukommen, ansonsten muesste man bei RS232 den Output von ',' parsen. Uebersehe ich da etwas? Sonst muessten wir das wohl noch einbauen. Ansonsten: Gehe ich richtig der Annahme das ich den Spannungswert ueber Z/(400/(24*8))+32-X/24*R, wobei Z=Zerolevel [0;400] fuer den jeweiligen Kanal, X der ausgelesene Wert und R Range, also z.B. 5V/div, errechnen kann? Niklas
Hayo W. schrieb: > Das mit den Skalierungsfaktoren hatte ich auch auf dem Zettel, > hab's aber erstmal verschoben, da man die float Faktoren auf DSO-Seite > in Bytes zerlegen muß und auf PC-Seite wieder zusammenbauen muß. Kann man da nicht einfach einen passend normierten Int32 übertragen. Das sollte doch reichen, um soetwas wie 1 mV/div bis 500 V/div abzudecken. Gruß Rainer
@Niklas Da zackern wir nicht lange rum. Alle Werte die Du brauchst schieben wir mit über die Schnittstelle als Shot. Sag mir was Du brauchst, ich bau das ein. Gruß Hayo
Das Problem mit dem fehlenden Quick Print Menü ist erledigt. Nachdem ich nochmal die 2.12 und dann nochmal die 2.13 installiert hatte war es wieder da.
Nanu, ein scwarzes Loch für Menüs? Is ja strange. Aber wenn's jetzt geht ist ja alles ok. Gruß Hayo
Hallo, ich habe die Umrechnung zu Spannungswerten am Laufen. Die noetigen Skalierungsfaktoren und die Zero-Offsets uebertrage ich im Rahmen der anderen Parameter nach dem Tracedump. Es stellen sich jetzt fuer mich, bevor ich weiter mache, folgende grundsaetzliche Fragen: (1) Die unkonvertierten Werte sind ja invertiert, d.h., fuer eine positivere Spannung sinken die Werte und vice versa -- was beim direkten Zeichnen dann natuerlich auch invertiert ist gegenueber dem Scope-Bild. Soll dies so bleiben (es kann ja sein, dass es dafuer einen guten Grund gibt) und nur optional umkehrbar sein, oder sollten wir, wo wir gerade dabei sind, das auch "beheben"? (2) Schon immer uebertragen wir stets stur 4x16kSa, auch wenn wir weniger Kanaele haben und auch wenn wir eine Zeitbasis eingestellt haben die nur mit 4kSa pro Kanal arbeit (<=25MSa/s). Das sollten wir meines Erachtens auch gleich beheben und dem Programm vom DSO sagen lassen, wie viele (aktive) Kaenele und wie viele Samples es empfangen wird. Ansonsten: Ich wuerde vorschlagen eine neue Kommandooption einzubinden die festlegt, wie die Daten bei einem Tracedump (vor)verarbeitet werden. Ich stelle mir hier folgendes vor: -o [i][mv] wobei: i -> invertieren (siehe oben) m -> Werte in mV als ganze Zahlen, v -> Werte in V mit 3 Nachkommastellen Niklas
Hallo Niklas, * Bei den unkonvertierten Werten wäre ich generell für Invertierung, d.h. hohe Werte oben. * Die Ausgabe würde ich auf die genutzte Speichertiefe beschränken und die Kanalanzahl steht ja sowieso schon als Parameter "number of channels" im Header. Unter "Values" würde ich immer die originale Gerätekanalnummer nennen, damit man ggf. immer die Hardwarezuordnung hat. * Bei der Skalierung kann ich mir vorstellen, dass ganzzahlige mV mit dem neuen Frontend knapp sind. * Bei der Ausgabe von Float gebe ich zu bedenken, dass die Dateien dann zumindest unter Windows nicht mehr austauschbar sind, wenn auf den Rechnern verschiedene Dezimaltrennzeichen eingestellt sind. Ich würde das vermeiden. * Beim unkonvertierten Tracedump würde ich im Header die Skalierungsparameter für jeden Kanal in Form von zwei Werte A und B (jeweils Integer) angeben, so dass gilt Y = ( X + B ) * A / N mit z.B. N = 1 / uV Evtl. ist auch Y = ( X * A + B) / N günstiger. Dann hätte man keine Floats und die Umrechnung wäre elementar. Gruß Rainer
Hi Niklas, ich sehe schon da geht was. Verstehe ich das richtig, dass Du auch gleich die DSO-Seite mit abfackelst? Dann brauche ich da nichts zu machen und nur die fertigen Sourcen von Dir einzupflegen? Den Invert-Bug habe ich übrigens schon behoben. Morgen habe ich tagsüber etwas Zeit, da werde ich mal die bisher aufgelaufenen Punkte abarbeiten. Ich sag ja, nach der Winterpause geht es wieder richtig los! Gruß Hayo
Wie steht es denn um die Ansteurung der Huckepack Platine?
Hallo Rainer, > * Die Ausgabe würde ich auf die genutzte Speichertiefe beschränken und > die Kanalanzahl steht ja sowieso schon als Parameter "number of > channels" im Header. Allerdings wird dieser erst am Ende uebertragen (Hayo hat das so gemacht damit die OS und aeltere Versionen weiter funktionieren), aber das koennen wir ja gleich auch aendern. > Unter "Values" würde ich immer die originale Gerätekanalnummer > nennen, damit man ggf. immer die Hardwarezuordnung hat. Da stimme ich zu. > * Bei der Skalierung kann ich mir vorstellen, dass ganzzahlige mV mit > dem neuen Frontend knapp sind. Sollten wir bei -o dazu noch u fuer uV anbieten? > * Bei der Ausgabe von Float gebe ich zu bedenken, dass die Dateien > zumindest unter Windows nicht mehr austauschbar sind, wenn auf den > Rechnern verschiedene Dezimaltrennzeichen eingestellt sind. Ich würde > das vermeiden. Mhm, das ist wirklich unschoen. Gerade geschaut: ist bei OpenOffice unabhaengig von Plattform auch so. (Beim Oeffnen der CSV ist im Konfigurationsdialog auch gleich die Sprache auswaehlbar, mit entsprechend spezifisch gesetztem Default.) > * Beim unkonvertierten Tracedump würde ich im Header die > Skalierungsparameter für jeden Kanal in Form von zwei Werte A und B > (jeweils Integer) angeben, so dass gilt > Y = ( X + B ) * A / N mit z.B. N = 1 / uV > Evtl. ist auch Y = ( X * A + B) / N günstiger. > Dann hätte man keine Floats und die Umrechnung wäre elementar. Mhm. Ich waere fuer die erste Variante, da man mit -B dann den unskalierten Nullpunkt haette. Fuer einfache Analysen und Zeichnung reicht dieser Wert zusammen mit den unkonv. Werten aus. Niklas
Noch ein Nachschlag zu den übertragenen Kanälen, grundsätzlich kann und sollte die Datenmenge anhand der schon jetzt übertragenen Parameter Timebase und channel_x_active eingeschränkt werden. Ab Zeitbasis 10µs bis 500ms werden ja nur noch 4K pro Kanal abgetastet und wenn man noch die aktiven Kanäle abfragt sollte das die Geschwindigkeit im Schnitt doch deutlich erhöhen. Ich bin gespannt auf die Neuerungen... Hayo
Hallo Hayo, > ich sehe schon da geht was. Verstehe ich das richtig, dass Du auch > gleich die DSO-Seite mit abfackelst? > Dann brauche ich da nichts zu machen und nur die fertigen Sourcen von > Dir einzupflegen? Ja. Ich gebe Dir dann fuer die Firmware ein Diff. > grundsätzlich kann und sollte die Datenmenge anhand der schon jetzt > übertragenen Parameter Timebase und channel_x_active eingeschränkt > werden. Ja. Kann man sich natuerlich auch drueber streiten ob das Programm die Grenze fuer 4kSa vs. 16kSa kennen muss oder nur die Timebases an sich... Wie gesagt, bislang wird der Header erst am Ende uebertragen, daher der erste Schnellschuss. Niklas
Niklas O. schrieb: > Wie gesagt, bislang wird der Header erst am Ende uebertragen, daher > der erste Schnellschuss. Ja das hatte ich wegen der Abwärtskompatibilität so gemacht. Dadurch verträgt sich das auch mit alten Versionen die nur die Werte übertragen. Den Zopf können wir aber auch abschneiden... Hayo
Hayo W. schrieb: > Den Zopf können wir aber auch abschneiden... Wer etwas dagegen hat, möge jetzt sprechen oder für immer schweigen Gruß Rainer
Schon mal vorab - ich habe heute eine ganze Menge geschafft (viele kleine Baustellen). Wenn dann noch die Erweiterungen von Niklas dazu kommen kann ich nur sagen es gibt wieder viel auszuprobieren :-) Wenn Niklas das zeitlich hinbekommt könnte das neue Release evtl. Sonntag fertig werden. Gruß Hayo
Hallo, anbei die neue v0.95 vom W2000A Screenshot Program mit dem voellig ueberarbeitetem Tracedump. Dazu das Diff gegen die Original Firmware v2.13. Dieses enthaelt auch die Aenderungen aus Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil4)" Zum Ausprobieren dann noch ein Kompilat zum Einladen ins RAM. Notizen: - Leider konnte ich die Windows-EXE auch bei diesem Release nicht mit dem Scope testen. - Zum Einbau der Ausgabe der A und B Skalierungswerte, wie Rainer sie im letzten Punkt von Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil4)" vorgeschlagen hat, bin ich nicht mehr gekommen. - Mit dem Parameter -p und den darin gueltigen Flags v (Volt), m (mV), u (uV) sowie q ("quiet", keine Ausgabe des Headers) koennen die Daten bei der Ausgabe entsprechend vorverarbeitet werden. Bsp.: ./w2000a-screenshot -d -t ascii -p mq schreibt eine trace-0000.asc mit mV-Skalierung ohne Header. - Da -p v mit ganzzahligen Werten wenig Sinn ergibt werden bei diesem Modus Stellen nach Komma (Punkt) ausgegeben. (Siehe auch Rainers Hinweise bzgl. Float und CSV.) Niklas
Hallo Niklas,
unter Win klappt mit der 0.94 / 2.14 Ram anscheinend bei der Übertragung
irgendetwas noch nicht. Wenn ich bei 1ms/div einen Kanal aktiv habe, und
Save to CSV oder ASCII im QP-Menü drücke, bekomme ich zu sehen:
* Found Data Start Marker after 10s
- Receiving trace data...
4100 bytes..._
Der Cursor bleibt hinter "bytes..." stehen und es wird eine leere
Ausgangsdatei angelegt. Bei vier aktiven Kanälen läuft der Zähler
entsprechend bis 16400 bytes und dann passiert nichts weiter.
Der Screenshot in eine PPM-Datei ist ok.
Gruß
Rainer
P.S. In der Hilfe (-h) habe ich die Optionen für die Skalierung noch
vermißt
Hallo Rainer, > unter Win klappt mit der 0.94 / 2.14 Ram anscheinend bei der Übertragung > irgendetwas noch nicht. Wenn ich bei 1ms/div einen Kanal aktiv habe, und > Save to CSV oder ASCII im QP-Menü drücke, bekomme ich zu sehen: > * Found Data Start Marker after 10s > - Receiving trace data... > 4100 bytes..._ Kann es sein, dass Du tatsaechlich, wie Du schreibst, versehentlich die v0.94 benutzt statt der neuen v0.95? Die Ausgabe waere bei der neuen Version auch anders. > P.S. In der Hilfe (-h) habe ich die Optionen für die Skalierung noch > vermißt. Die sollte unter Misc erklaert sein. Starte mal bitte die .exe mit -v. Niklas P.S.: Ich frage mich gerade ob wir nicht auf DSO-Seite fuer Screenshot und Tracedump eine Header-Version ausgeben sollten. Wenn die Version neuer ist als das Programm kennt, verweigert es den Dienst. Im Moment prueft das Programm nur ob die Firmwareversion den Mindesanforderungen genuegt und nicht neuer als 10 Versionen ist.
Hallo Niklas, Gutes Argument. Kaum macht man alles richtig - schon geht es. Ich hatte irgendwie die alte Version ausgepackt. Nun ist auch die Hilfe vollständig. Anscheinend ist es schon ein bisschen spät. Sorry. Hat es eigentlich einen besonderen Grund, dass du auf der Schnittstelle am Zeilenende immer 0x0a 0x0d überträgst, während sonst eigentlich 0x0d 0x0a üblich ist (z,B, auch die Bootmeldung vom DSO)? Eine Ausgabe der Versionsnummer ist vielleicht eine gute Idee. Gruß Rainer
Hallo Rainer, > Hat es eigentlich einen besonderen Grund, dass du auf der Schnittstelle > am Zeilenende immer 0x0a 0x0d überträgst, während sonst eigentlich 0x0d > 0x0a üblich ist (z,B, auch die Bootmeldung vom DSO)? Mhm, wo mache ich das denn? Meinst Du vllt. die printf() in Schleifen mit \r (0x0d) vorne? Das dient dazu, dass ich dieselbe Zeile in der Ausgabe mehrfach schreiben kann, z.B. um eine Statusanzeige hochzuzaehlen. Niklas Update: Ich glaube Du meintest Hayo.
Kurt Bohnen schrieb: > Wie steht es denn um die Ansteurung der Huckepack Platine? Ist wohl untergegangen.
Niklas O. schrieb: >> Hat es eigentlich einen besonderen Grund, dass du auf der Schnittstelle >> am Zeilenende immer 0x0a 0x0d überträgst, während sonst eigentlich 0x0d >> 0x0a üblich ist (z,B, auch die Bootmeldung vom DSO)? > > Mhm, wo mache ich das denn? Die unüblichen <lf><cr>s war mir direkt in den Daten auf der Schnittstelle bei den Versionstexten aufgefallen. Da hast du wohl Recht, ist wohl Hayo's Baustelle. (siehe Anhang) Zum Datenformat habe ich noch folgende Anmerkungen: 1) Díe Kanalnamen (CHx) würde ich als Parameter (z.B. channel_name) in den Header nehmen, damit unter /[Data]/ reine Zahlen stehen 2) Bei channel_delays würde ich channel_delays_ns angeben, auch damit hinten reine Zahlen stehen (Wer weiß wozu?) 3) Bei channel_vzero_levels ist es vielleicht intuitiver, wenn man das Vorzeichen ändert, weil man "+" irgendwie doch mit "nach oben verschoben" assoziiert. Wenn man die Daten in einer Tabellenkalkulation skaliert, spielt das sowieso keine Rolle ob "+" oder "-". Dann bin ich gespannt, wie das mit den fertigen Skalierungsfaktoren wird. Insgesamt - superschnell und großer Fortschritt auf der Baustelle. Gruß Rainer
Rainer schrieb: > Hat es eigentlich einen besonderen Grund, dass du auf der Schnittstelle > am Zeilenende immer 0x0a 0x0d überträgst, während sonst eigentlich 0x0d > 0x0a üblich ist (z,B, auch die Bootmeldung vom DSO)? Nein, hat keinen Grund, ich mache das frei von der Leber weg, da dort auch keine Kompatibilitätsprobleme zu befürchten sind. Ob ich erst den Wagenrücklauf mache und dann die neue Zeile oder umgekehrt bleibt unterm Strich gleich. Gruß Hayo
Kurt Bohnen schrieb: > Kurt Bohnen schrieb: >> Wie steht es denn um die Ansteurung der Huckepack Platine? > > Ist wohl untergegangen. Ja sorry die Frage hatte ich übersehen. Da ich noch keine Zeit hatte die Platine bei mir einzubauen ist das noch in Warteposition. Als Erstes wollte ich auch mal den 16 Bit DAC einbauen um zu prüfen ob das richtig funktioniert. Bei branadic ist ja nicht so richtig klar geworden ob das ok ist. Gruß Hayo
@Niklas Super wie schnell Du vorankommst und was die Screenshot-Schnittstelle inzwischen alles kann. Ich freue mich schon auf das nächste FW-Release. Noch eine Bitte, kannst Du mir zusätzlich zum Diff auch noch die Sourcen zukommen lassen? Dann kann ich mir das im Kontext vorher ansehen. Gruß Hayo
@Niklas Diff ist eingebaut und getestet - läuft gut! Gruß Hayo
Angehängte Dateien:
-
Datatrans.gif
57 KB
Hallo Ich verfolge dieses Projekt seit längerer Zeit als stiller Leser. Daher ein Dankeschön an alle die Ihre Freizeit für dieses Projekt opfern. Ich hätte eine Frage an die Experten. Ich bin gerade dabei meine Lautsprecherboxen zu verbessern und müsste daher Impedanz Messungen durchführen(über den gesamten Frequenzgang). Ich möchte die Auswertung und Darstellung mit LabView machen. Dafür brauche ich vom Oszilloskop kontinuierliche Messdaten. Gibt es eine Möglichkeit diesen Datentransfer durchzuführen? Kann man vielleicht im w2000a_schreenshot Programm (v. Niklas) eine Funktion hinzufügen die, die selektierten Messdaten von der Funktion „Qick Meas“ übernimmt. Und über die Datenschnittstelle an den PC weitergibt. Welec W2012A Gruß August
Hallo Rainer, > Zum Datenformat habe ich noch folgende Anmerkungen: > 1) Díe Kanalnamen (CHx) würde ich als Parameter (z.B. channel_name) in > den Header nehmen, damit unter /[Data]/ reine Zahlen stehen Beim naechsten Release, bei diesem hatte ich das vergessen. > 2) Bei channel_delays würde ich channel_delays_ns angeben, auch > damit hinten reine Zahlen stehen (Wer weiß wozu?) Ja. > 3) Bei channel_vzero_levels ist es vielleicht intuitiver, wenn man das > Vorzeichen ändert, weil man "+" irgendwie doch mit "nach oben > verschoben" assoziiert. [..] Dann bin ich gespannt, wie das mit > fertigen Skalierungsfaktoren Der channel_vzero_levels und channel_scale_factors Kram faellt eh komplett weg sobald ich die Skalierungswerte A und B eingebaut habe, von daher keine Anpassung mehr daran. Niklas
@Niklas ich hatte vermutet, dass die channel_vzero_levels und channel_scale_factors schon die Anfangsstrukturen für die neuen Skalierungsfaktoren sind. Aber dann ist ja alles auf gutem Wege. @August Die Idee mit der Meßdatenübertragung an den PC finde ich sehr gut. Eine Sache die ich mir vorstellen kann, wäre ein Kommando, dass man vom PC an das DSO schickt und dann kommen die aktiven Quick Measure Werte zurück. Wäre das LabView-tauglich? Hayo, was sagst du dazu? Und wie sieht das eigentlich mit einer Fernsteuerung des gesamten W2000A vom PC aus aus?
Hallo August, > [..] Impedanz Messungen durchführen(über den gesamten Frequenzgang). > Ich möchte die Auswertung und Darstellung mit LabView machen. > Dafür brauche ich vom Oszilloskop kontinuierliche Messdaten. > Gibt es eine Möglichkeit diesen Datentransfer durchzuführen? > Kann man vielleicht im w2000a_schreenshot Programm (v. Niklas) eine > Funktion hinzufügen die, die selektierten Messdaten von der Funktion > „Qick Meas“ übernimmt. Und über die Datenschnittstelle an den PC > weitergibt. (1) Zur "Quick Measure"-Datenuebertragung: Ja, das ist eine gute Idee, schaue ich mir an. Welches Format waere da interessant? Aehnlich wie es bei den Tracedaten ablaeuft? Also z.B.: <code> [Measurements] frequency_str=<tab>2.5MHz frequency_num=<tab>2500000 [..] </code> Das Ganze dann zusaetzlich zu einem Trace? Optional? (2) Zu LabView und kontinuierliche Messdaten: Ich selbst habe leider keine Ahnung von LabView. Ich weiss nicht, ob sich hier jemand aus dem Forum vllt. schon einmal daran gemacht hat, einen LabView-Treiber zu implementieren, um das DSO darueber zu steuern. Bzgl. der kontinuierlichen Uebertragung der Daten ist zu sagen das dies zwar bei "Quick Measure" noch gut funktionieren wuerde, es aber unmoeglich wird bei den Traces, aufgrund (a) der begrenzten Speichertiefe des Oszis (16kSa/Kanal) (b) der Schnitstelle und nicht zuletzt (c) wegen des langsamen Softcores. Ich glaube auch nicht dass das bei USB grossartig besser wird. Ob es bei 4 Traces alle 6s noch sinnvoll ist diese "kontinuierlich" zu uebertragen weiss ich nicht. Niklas
> Hayo, was sagst du dazu? Und wie sieht das eigentlich mit einer > Fernsteuerung des gesamten W2000A vom PC aus aus? Ist alles machbar. Eine Fernsteuerung gibt es bereits. Zum einen gibt es eine einfache Implementierung, die auf Tastatureingaben eines Terminals reagiert, zum Anderen gibt es eine aufwändigere Remotesteuerung von Falk, die recht umfangreiche Möglichkeiten bietet. Diese Remotesteuerung hat auch schon jemand für sein Projekt benutzt (Kurt Du?). > Ich möchte die Auswertung und Darstellung mit LabView machen. > Dafür brauche ich vom Oszilloskop kontinuierliche Messdaten. > Gibt es eine Möglichkeit diesen Datentransfer durchzuführen? Ist auch machbar und war auch mal für USB von WELEC implementiert - leider so schlecht dass man es rausnehmen mußte. Nur wie Niklas schon sagte wird die Wiederholrate extrem langsam wenn zu viele Daten übertragen werden. Eine Lösung wäre vielleicht wenn nur die 600 Werte des aktuellen Screens übertragen würden. Gruß Hayo
Hallo Hayo, >> Hayo, was sagst du dazu? Und wie sieht das eigentlich mit einer >> Fernsteuerung des gesamten W2000A vom PC aus aus? Das funzte mal mit der originalen Soft von Wittig, allerdings nur mit der FW 1.4, hatte aber nur funktioniert, wenn sie dazu Lust hatte, dann trampelte die Software manchmal auf der Stelle und es regte sich nichts mehr! > Ist alles machbar. Eine Fernsteuerung gibt es bereits. Zum einen gibt es > eine einfache Implementierung, die auf Tastatureingaben eines Terminals > reagiert, zum Anderen gibt es eine aufwändigere Remotesteuerung von > Falk, die recht umfangreiche Möglichkeiten bietet. Diese Remotesteuerung > hat auch schon jemand für sein Projekt benutzt (Kurt Du?). ...wo liegt die denn rum??? Gruß Michael
@Niklas Es gibt noch zwei Werte, die evtl. für die Parameterübergabe interessant wären: - die Pretriggerposition im Speicher (Memory Index 0....16383 / 0....4095) Format ist Integer. - der Pretriggerwert als float. Während dieser vorher nur lokal berechnet wurde habe ich Ihn jetzt global deklariert, so dass er jederzeit zur Verfügung steht. Ich habe die Variablen mal auskommentiert in die CSV-Routine eingetragen falls das von Interesse sein sollte. Hayo
Hallo Niklas Ich habe eher an eine einfache Übertragung wie bei Digital-Multimeter mit RS232 Schnittstelle gedacht. Die im „Quick Measure“ angezeigten Messwerte ( max 3) könnten zum Beispiel mit dem Voltcraft Protokoll übertragen werden. Ist zwar nur für einen Messwert, könnte man aber erweitern. [[http://blog.dest-unreach.be/2009/05/01/voltcraft-vc-940-protocol-reverse-engineered]] Ich werde mich in den nächsten Tagen umschauen welche Protokolle wir verwenden könnten. Der LabView Dateneingang kann an das jeweilige Protokoll angepasst werden. Gruß August
Angehängte Dateien:
-
Trigger_Submenu.jpeg
41 KB
Es ist soweit, wie versprochen die neue Version bei der sich einiges getan hat. Die Highlights sind: - Natürlich die neue Screenshot-Version von Niklas mit neuer CSV-Übertragung - neue double push Funktionalität bei Edge-Button, Pulswidth-Button und Main-Button ebenfalls von Niklas - invert Bug ist gefixt - neuer stabil arbeitender manueller Trigger - neues Trigger-Submenü mit diversen Einstellmöglichkeiten, zu finden im Mode/Coupling Menü. Da sollte für jeden Geschmack was zu finden sein. Weitere Details entnehmt bitte dem changelog und der Datei Special Functions.txt @eProfi Die Schrittweite der Pre Trigger Einstellung habe ich nicht auf die letzte Stelle des Zeitwertes bezogen, sondern auf die Zeitauflösung pro Pixel, da mir das sinniger erschien. Gruß Hayo
Hayo W. schrieb: > Eine Fernsteuerung gibt es bereits. Zum einen gibt es > eine einfache Implementierung, die auf Tastatureingaben eines Terminals > reagiert, zum Anderen gibt es eine aufwändigere Remotesteuerung von > Falk, die recht umfangreiche Möglichkeiten bietet. Diese Remotesteuerung > hat auch schon jemand für sein Projekt benutzt (Kurt Du?). Die Remotesteuerung wurde seinerzeit von Bruno im FFT-Screener (Matlab) verwendet. Leider wurde an dieser Baustelle nicht weitergearbeitet und ich komme derzeit nicht dazu mich damit zu beschäftigen, zumal ich eh nur auf Arbeit daran werkeln könnte, da der FFT-Screener nicht kompatibel zu Octave ist. branadic
Hallo Hayo, Hayo W. schrieb: >> ... Und wie sieht das eigentlich mit einer >> Fernsteuerung des gesamten W2000A vom PC aus aus? > > Ist alles machbar. Eine Fernsteuerung gibt es bereits. Zum einen gibt es > eine einfache Implementierung, die auf Tastatureingaben eines Terminals > reagiert, zum Anderen gibt es eine aufwändigere Remotesteuerung von > Falk, die recht umfangreiche Möglichkeiten bietet. Mit "Tastatureingaben..." meinst du das Remote Control Protokoll, was im Moment als "suggestion" unter http://sourceforge.net/apps/trac/welecw2000a/wiki/RemoteControlAPI beschrieben ist? Dast ist ja noch arg rudimentär und Zukunftsmusik. Das von Falk außeinandergedröselte USB Protokoll bietet da ja schon einiges mehr. Gibt's da Quellcodebeispiele, wie man das unter Win vom PC aus nutzen kann? http://sourceforge.net/apps/trac/welecw2000a/wiki/USB-Protocol "Set timebase" über Terminal habe ich gerade probiert (mit BT.2.13 FW). Da tut sich auch etwas, aber außer Debugausgaben kommt nichts weiter zurück. Dabei bin ich auf folgende offene Baustelle gestoßen: Die Umschaltung ist etwas "eigenwillig", d.h. die Kommandowirkung hängt von der vorher eingestellten Zeitbasis ab. Wenn man z.B. <stx>ET<0x18>... schickt, schaltet das DSO auf unterschiedliche Bereiche um, je nachdem wo es vorher stand. (z.B. 5us/div -> 5s/div, 20s/div -> 1s/div, 100ns/div -> 500ms/div). Außerdem kommt man nicht in die ganz langsamen Bereiche, weil Parameter über <0x1F> nicht angenommen werden. Aber ich vermute mal, dass die Baustelle z.Z eher brach liegt, oder? Schönen Sonntag Rainer Edit: Danke für die neue Wochenend-Edition
Ciao, sul sito (a proposito ho cambiato indirizzo: www.cheap-hack.com), un utente mi ha chiesto se Hayo e voi altri accettate donazioni per supportare il progetto, magari tramite paypal o simili, non sono sicuro così chiedo qui. Hello, on the site (recently changed the address: www.cheap-hack.com), a user asked me if you Hayo and other, accepted donations to support the project, perhaps through paypal or similar, I'm not sure so I ask here. By, Gyppe.
gyppe schrieb: > Ciao, sul sito (a proposito ho cambiato indirizzo: www.cheap-hack.com), > un utente mi ha chiesto se Hayo e voi altri accettate donazioni per > supportare il progetto, magari tramite paypal o simili, non sono sicuro > così chiedo qui. > > > Hello, on the site (recently changed the address: www.cheap-hack.com), a > user asked me if you Hayo and other, accepted donations to support the > project, perhaps through paypal or similar, I'm not sure so I ask here. > > Bie, Gyppe.
Hi, ich vergaß noch anzumerken, dass ich aufgrund der umfangreichen Änderungen gezwungen war die Flasheinstellungen zurückzusetzen. Also nicht vergessen das Gerät neu zu kalibrieren und die Hardwareeinstellungen neu zu machen. Please notice that I had to reset the flash. So calibration and hardware adjustment is recommended. @gyppe - no donation, it is just for fun! Hayo
Sapevo avresti risposto così, ma ho comunque chiesto per correttezza. Complimenti sei davvero una persona da ammirare, grazie! :)
This new firmware version was so good that no one have yet posted!!! I've try it to my welec and that's incredible...Thanks at all the staff!! Paolo
Leider habe ich noch einige Bugs entdeckt. Z.B. arbeitete der manuelle Trigger immer noch nicht so richtig unter allen Umständen. Jetzt sollte er es aber tun. Daher noch mal ein Update in dem nur einige Fixes sind aber sonst nix Neues. Hayo
Hallo zusammen! Ich hab seit ein paar Monaten eure Firmware(s) auf meinem Welec-Oszi und möchte mich bei allen Entwicklern hier, vor allem Hayo, mal herzlich dafür bedanken, dass ihr in eurer Freizeit unentgeltlich die Arbeit macht, die die Fa. Wittig leider nicht macht! Die originale Software mit der Wittig die Geräte immer noch ausliefert ist eigentlich eine Frechheit! Inzwischen nehme ich aber doch immer öfters mal das Welec anstatt meines 20 Jahre alten Hameg's, das ich eigentlich mit dem Wittig ablösen wollte... Vielen Dank! Gruß, Michael
New 2.15 version tested. On the welcome screen appear to be a "beta" version... Anyway all the functions that i've can tested are ok. Very good job with the filters!! Thanks again, Hayo and all!! What's the next step? Excuse me for the question, but i don't understand German language and google translate make a bad job: What are the benefits on ADC/DAC substitutions that is described on some previous messages? Ciao, Paolo
Paolo schrieb: > New 2.15 version tested. On the welcome screen appear to be a "beta" > version... don't worry, I just forgot to delete the "beta" > What's the next step? Several little improvements at math-functions and FFT. Hardwaresupport for the new input stage of branadic. > Excuse me for the question, but i don't understand German language and > google translate make a bad job: > What are the benefits on ADC/DAC substitutions that is described on some > previous messages? the 16 Bit DAC has a finer division at zerolevel adjustment. This is only relevant to the 2/0.2/0.02 and 1/0.1/0.01 ranges. It is not really necessary but nice to have. I got the LT2602 as free sample from Linear Technology. They are very small and You need to have some experience in soldering SMD parts if You want to replace them. Kind regards Hayo
>Several little improvements at math-functions and FFT. Hardwaresupport >for the new input stage of branadic. Great! :)
Angehängte Dateien:
-
Left_Edge.png
3,9 KB -
Left_Edge_1_12.png
3,9 KB
Hallo Hayo, die neue Auto-Pre-Trigger Funktion finde ich ausgesprochen praktisch. Beim Messen in der Einstellung "Left Edge" hat sich aber gezeigt, dass es vielleicht günstiger wäre, das "Left" nicht ganz wörtlich zu nehmen, sondern den Trigger auf den ersten Grid Raster zu legen (Left_Edge_1_12.png). Meistens interessiert doch ein bisschen, was vorne los ist ;-) Gruß Rainer
Hi Rainer, gleich vorweg - ich sehe mal zu dass ich das noch als extra Menüpunkt mit einbaue. Zum "Left Edge": Das ist ja den alten Analog-Oszis nachempfunden. Man stellt ja normalerweise die Zeitbasis so ein, dass nach dem Triggerdurchgang etwas mehr als eine Periode auf dem Schirm zu sehen ist. Dann hat man nämlich auch den am Anfang fehlenden Teil der nächsten steigenden Flanke locker mit auf dem Screen. Dazu kommt, dass viele Signale auch nicht so steil ansteigende Flanken haben, so dass auch vom Triggerlevel an die ganze Flanke zu sehen ist. Gruß Hayo
Etwas Anderes, ich mache mir gerade Gedanken über die Ansteuerung der Addon Platine. Hat schon jemand das Teil eingebaut und kann mir gegebenenfalls Testergebnisse liefern? Hayo
Angehängte Dateien:
-
Test01.jpeg
44 KB -
Test02.jpeg
38 KB -
Test03.jpeg
41 KB -
Test04.jpeg
47 KB -
Test05.jpeg
37 KB
So ich hab mal wieder was zum ausprobieren für Euch. Ich habe etwas rumgespielt nachdem ich für Rainer den neuen Menüeintrag eingebaut hatte. Dabei sind wieder die Spikes aufgetaucht und ich konnte feststellen dass die Spikes durch das Verstellen der Timebase verursacht werden. Einstellung: - Triggersource Kanal 4 - Combi oder Norm Trigger - Timebase 50ns - Signal auf Kanal 4 Alles ist gut. Dann Zeitbasis auf 50µs verstellt und wieder zurück auf 50ns siehe Bild Test01. Dann Zeitbasis auf 5µs verstellt und dann zurück auf 50ns - siehe Test02. Dann wieder verstellt und so weiter Test03...Test05. Wenn man das Gerät ausschaltet und wieder einschaltet ist alles wieder gut. Ist das bei Euch auch so? Gruß Hayo
Jo, hatte ich letzte Woche und gerade dann, wo ich es nicht brauchen konnte! Allerdings sporadisch, manchmal auf Kanal 1 dann mal auf Kanal 2 (W2022), wie es gerade Lust hat! Gemessenes Signal war 57 kHz Rechteck an einem LM2576 Adj. Dachte schon, jetzt ist er hinuber!! Die Grundlinie über das Display scheuchen, brachte auch keine Besserung. An der Warmlaufphase scheint es aber nicht zu liegen, da das DSO schon über eine Std. lief. Nach neuem hochfahren, war wieder alles hübsch... Gruß Michael
Aha, ich bekomme das nur auf Kanal 3 + 4 hin. Gruß Hayo
Sehe gerade, du hast 16V Sägezahn!?! Ich hatte bei der Restripplemessung dieselbe Einstellung wie du 2V/DIV, 50nS und Combitrigger "AC", ob das bei "DC" auch der Fall ist? Wenn du das provozieren kannst, dann prüf' das doch mal... Gruß Michael
Hallo, ich melde mich mal kurz. Ich hab' am Sonntag die Sache mit Quick-/Cursor-Messungen uebertragen eingebaut, ist zu 80% fertig, fehlt noch Feinschliff. Ich hab' dazu nur zwei kleine Ergaenzungen in floatstr_t.cpp/h gebraucht (Wegspeichern der in RenderText() berechneten Werte fuer Vor-Komma- und Nach-Komma-Zahlen sowie Ausgabe der Dimensionierung). Die Ausgabe sieht dann so aus (echte Werte):
1 | meas-000.txt |
2 | [measurements] |
3 | str=;dX = 5.4 us;1/dX = 185 kHz;dY 1 = 29 mV |
4 | desc=;dX = ;1/dX = ;dY 1 = |
5 | dimension=;u;k;m |
6 | unit=;s;Hz;V |
7 | value_bd=;5;185;29 |
8 | value_ad=;4;0;0 |
9 | value_float=;5.4;185.0;29.0 |
Konkrete Vorschlaege/Anregungen gerne willkommen. Wir sollten dann vllt. noch aus den Softbuttons "Save to BMP", "Save to PPM", "Save to CSV" usw. einfach "Screenshot", "Trace" und "Measurements" machen, wobei dann das Format ueber ein Untermenue konfigurierbar wird. @August: Wenn Du moechtest kann ich Dir kompilierte TomCat.flash/.ram geben damit Du das Ganze schon nutzen kannst. Bezueglich meiner Spikes auf Kanal 3+4 beim Nulldurchgang auf dem DSO: Ich hab' Sonntag auch noch das Geraet aufgeschraubt und mal, wie Hayo vorschlug, auf die ADCs gedrueckt ob sich da was aendert. Negativ. Da das ganze Board ziemlich warm war hab' ich einen starken 80mm Luefter (~6 Watt) rausgekramt und bei offenen Geraet direkt gegen die Platine blasen lassen. Das verminderte die Anzahl Spikes jedoch nur gering. Nochmal komplett Front abnehmen, um auf die andere Seite der Platine zu schauen, will ich erstmal nicht, zu wenig Zeit. Was Hayo zuletzt bei sich auf Kanal 3+4 mittels Saegezahn reproduzieren kann, kann ich mangels schnellem Signalgenerator nicht pruefen. Bei mir treten die Stoerungen aber wie gesagt auch erst bei 50ns sehr haeufig auf. Niklas
Niklas O. schrieb: > Hallo, > > ich melde mich mal kurz. > > Ich hab' am Sonntag die Sache mit Quick-/Cursor-Messungen > uebertragen eingebaut, ist zu 80% fertig, fehlt noch Feinschliff. > Ich hab' dazu nur zwei kleine Ergaenzungen in floatstr_t.cpp/h > gebraucht (Wegspeichern der in RenderText() berechneten Werte > fuer Vor-Komma- und Nach-Komma-Zahlen sowie Ausgabe der > Dimensionierung). Währe es nicht einfacher den Float-Wert global zu deklarieren und dann per Multiplakation als Integer zu übertragen? > Wir sollten dann vllt. noch aus den Softbuttons "Save to BMP", > "Save to PPM", "Save to CSV" usw. einfach "Screenshot", > "Trace" und "Measurements" machen, wobei dann das Format > ueber ein Untermenue konfigurierbar wird. Das wäre eine Möglichkeit, ich mach mir mal ein paar Gedanken dazu > @August: > Wenn Du moechtest kann ich Dir kompilierte TomCat.flash/.ram > geben damit Du das Ganze schon nutzen kannst. > > > Ich hab' Sonntag auch noch das Geraet aufgeschraubt und mal, > wie Hayo vorschlug, auf die ADCs gedrueckt ob sich da was > aendert. Negativ. Da das ganze Board ziemlich warm war > hab' ich einen starken 80mm Luefter (~6 Watt) rausgekramt > und bei offenen Geraet direkt gegen die Platine blasen > lassen. Das verminderte die Anzahl Spikes jedoch nur gering. > Nochmal komplett Front abnehmen, um auf die andere Seite > der Platine zu schauen, will ich erstmal nicht, zu wenig Zeit. Ich habe bei meinem W2022A einen 80iger Lüfter eingebaut der bei 9V so gut wie keine Geräusche macht (drei andere Lüfter die ich ausprobiert hatte waren etwas nervig). Das ist wirklich angenehm und es wird wirklich ordentlich warme Luft aus dem Gehäuse gedrückt. Der Wackler könnte natürlich durchaus auch auf der anderen Platinenseite liegen. Ausprobieren lohnt sich allemal. Beim Abhebeln der teilweise festsitzenden Knöpfe gehe ich immer so vor: von oben in den Spalt zwischen Knopf und Frontplatte linsen während man den Knopf dreht. Irgendwann kommt die abgeflachte Seite der Achse vorbei... Dann mit einem dünnen Schraubendreher dazwischengehen und mit der flachen Seite des Schraubendrehers den Rand an der Achse als Abstützpunkt beim Hebeln benutzen. Dadurch entlastet man den Rest des Drehgebers. > Was Hayo zuletzt bei sich auf Kanal 3+4 mittels Saegezahn > reproduzieren kann, kann ich mangels schnellem Signalgenerator > nicht pruefen. Bei mir treten die Stoerungen aber wie gesagt > auch erst bei 50ns sehr haeufig auf. Es tritt nicht nur bei 50ns auf, aber bei 50ns und kleiner werden alle vier ADC dargestellt und dadurch auch alle Störungen, während bei den TB > 50ns immer nur 1 oder 2 ADC zur Anzeige kommen. Da "verschwinden" die Spikes teilweise scheinbar. Gruß Hayo
Hallo Hayo, >> Ich hab' am Sonntag die Sache mit Quick-/Cursor-Messungen >> uebertragen eingebaut, ist zu 80% fertig, fehlt noch Feinschliff. >> Ich hab' dazu nur zwei kleine Ergaenzungen in floatstr_t.cpp/h >> gebraucht (Wegspeichern der in RenderText() berechneten Werte >> fuer Vor-Komma- und Nach-Komma-Zahlen sowie Ausgabe der >> Dimensionierung). > > Währe es nicht einfacher den Float-Wert global zu deklarieren und dann > per Multiplakation als Integer zu übertragen? Ginge auch, dann wuerden jedoch die Dimensionierung wegfallen. Es sieht im Moment so aus:
1 | void FloatStr::RenderText(void) |
2 | Am Ende: |
3 | // copy values to protected variables for readout via Read_Int(B/A)Dot()
|
4 | Value_BDot = intbd; |
5 | Value_ADot = intad; |
> [..] > Ich habe bei meinem W2022A einen 80iger Lüfter eingebaut der bei 9V so > gut wie keine Geräusche macht (drei andere Lüfter die ich ausprobiert > hatte waren etwas nervig). Das ist wirklich angenehm und es wird > wirklich ordentlich warme Luft aus dem Gehäuse gedrückt. Ja. Rainer hat mir oben auch schon einen leisen Luefter bei Reichelt vorgeschlagen den er bei sich verbaut hat. Das Problem mit dem 80er, den ich Sonntag benutzt habe: Der zieht 0,47A. (Abgesehen davon dass er hoellisch laut ist.) Der Original war iirc. weit unter 0,1A. Bei der naechsten Pollin- oder Reichelt Bestellung bestelle ich einen entsprechenden Luefter mit. > Beim Abhebeln der teilweise festsitzenden Knöpfe gehe ich immer so vor: Beim letzten Mal, Anloeten der zwei Trigger-LEDs, Osrams in SMD, hab' ich da schon viel Freude mit gehabt... (sind btw. hell genug dass die ohne Modifikationen durch den Silkscreen durchscheinen.) Wo wir bei den Drehgebern sind: Bei Yokogawa hab' ich eine nette Vereinfachung bzgl. des Verschiebens der Traces gesehen: Wenn man die Drehencoder schnell dreht springen die Traces von Gridline zu Gridline, bei langsamen Drehen wie gewohnt Pixelweise. Vmtl. haben das die anderen hochwertigen Scopes aber auch. Ich hab' das ganze auch schon mal kurz angetestet, sieht dann im Code so aus:
1 | void UserIF::ON_Zero_Channel_1(void) |
2 | [..]
|
3 | if (Rotary_Direction == 0) //clockwise rotary direction |
4 | [..]
|
5 | else //Main mode TY |
6 | {
|
7 | if (rotbuf > 8) { // rotbuf -> Anzahl Schritte |
8 | int a, b, c; |
9 | // a positiv machen
|
10 | a = Virtual_ZeroLevelCH1 + 4096; |
11 | // naechstgelegene Gridlinie,
|
12 | // vllt. hier noch anders runden
|
13 | b = a/50; |
14 | // zur naechsten Gridlinie springen
|
15 | c = (b+1)*50; |
16 | // Zurueckskalieren und Wert setzen
|
17 | Virtual_ZeroLevelCH1 = c - 4096; |
18 | } else { |
Analog dasselbe fuer die andere Drehrichtung. Der ganze bestehende Code hierzu liesze sich btw. deutlich verkuerzen. ...Und funktioniert soweit. Ist etwas "wackelig", was aber an dem miserablen Response des Scopes liegt, woran wir aber wohl ohne das neue FPGA Design nichts aendern koennen. Ansonsten muss ich wohl eh nochmal an die Front dran, da beim W2024A fuers JTAG eine Loetbruecke fehlt und ich sonst nicht das neue Design ausprobieren kann. Niklas
Hallo Hayo zu den Spikes: (hatte ich schonmal geschrieben) Kannst Du die Frequenz von deinem Generator auch ändern? Bei mir änderten sich die Spikes auch mit der Frequenz bei gleicher Zeiteinstelleung am DSO l.G. Roberto
@Niklas > Ginge auch, dann wuerden jedoch die Dimensionierung wegfallen. > Es sieht im Moment so aus:void FloatStr::RenderText(void) > Am Ende: > // copy values to protected variables for readout via Read_Int(B/A)Dot() > Value_BDot = intbd; Verstehe, Du benutzt die Instanzmethode readout() um Dir den Wert zu besorgen, das scheint mir ganz elegant zu sein. Wenn Du mit Deinen Änderungen soweit bist kann ich das ja mit einbauen. > Wenn man die Drehencoder schnell dreht springen die Traces > von Gridline zu Gridline, bei langsamen Drehen wie gewohnt > Pixelweise. Hört sich interessant an, werde ich mal übernehmen und testen. @Roberto > Bei mir änderten sich die Spikes auch mit der Frequenz bei gleicher > Zeiteinstelleung am DSO Das muß ich mal testen, hört sich ja merkwürdig an. Gruß Hayo
es gibt einen 80er Lüfter von Papst glaube der macht nur 9 dB, habe 2 davon in meiner PC Front die sind nur hörbar wenn man den Kopf an die Front des PCs steckt. Man muss allerdings auch sagen das der nicht ganz so viel Durchsatz hat wie andere 80er Lüfter.
By the way... > was aber > an dem miserablen Response des Scopes liegt, woran wir > aber wohl ohne das neue FPGA Design nichts aendern koennen. Ich habe mal die USTB-Timerwerte nachgerechnet und habe die akute Vermutung, dass unsere Büchse nicht wie bisher angenommen mit 33MHz läuft, sondern nur mit 25MHz. Das würde natürlich auch Einiges erklären... Hayo
Ich hatte auf dem Board einen 25MHz Quartz gesehen. Die Frage ist aber, ob dann das Timing mit den ADCs noch stimmt. Hayo
@Niklas
Ich habe Deine Idee mal aufgegriffen und etwas umgestrickt. Das sieht
dann so aus und funktioniert ganz gut:
else // main mode
{
if (rotbuf > 10)
{
int div, cmp;
div = Virtual_ZeroLevelCH1/50; // in which div we are?
if(Virtual_ZeroLevelCH1 > 0) // positive
{
cmp = div * 50;
if (cmp == Virtual_ZeroLevelCH1){div--;} // zero level was on grid
division before
}
else // negative
{ div--; } // next grid division
Virtual_ZeroLevelCH1 = (div)*50; // set zerolevel to next grid
division
}
Hayo
> also auf ans Übertakten ;-) ist da ein externer Taktgeber drauf oder > taktet der FPGA intern? ...den Vorschlag hatte ich letztes Jahr schon mal gemacht! Im Datenblatt müsste ja stehen, was der Prozessor maximal so abhaben kann. Gruß Michael
Normal ist der für 33MHz ausgelegt (im NIOS I Design). Deshalb bin ich ja auch erstmal davon ausgegangen dass es so ist. Nur haben mich die Timerwerte bei den USTB etwas irritiert, da die iterativ ermittelten Werte nicht zu den vorher berechneten Werten passten. Die jetzt verwendeten Werte passen zu einer Taktfrequenz von 25MHz und einem Timer der mit halber Taktfrequenz läuft. Man könnte ja mal den 25MHz Quarz-Oszillator gegen einen 33iger tauschen und dann mal gucken ob es funktioniert (alle Timerwerte müßte man natürlich anpassen). Evtl. könnte es Problem mit den ADCs geben. Irgend einen Grund muß es ja geben, dass die auf einen Teil der Performance verzichtet haben (man läßt sich ja auch nicht freiwillig ein Bein in Beton eingießen oder?). Gruß Hayo
Angehängte Dateien:
-
Altera_EPSC16_01.gif
40 KB -
Altera_EPSC16_02.gif
28 KB
nun ja, vielleicht wollten die "Welec-Designer", zur Sicherheit unter dem Limit bleiben, damit das Teil nicht abschmiert?!? Ein höherer Takt zieht mehr Leistung und somit auch mehr Wärmeentwicklung, also muß auch mehr Kühlung her, dürfte ja kein Problem sein Den Mega8-16PU, habe ich mal mit 33MHz takten lassen, der wurde nicht mal warm. Ich lege mal 2 Auszüge des Altera EPCS16 bei, schau mal rein. Da steht nur was von der Write Clock Frequency... Gruß Michael
oh, habe ich hier das falsche Datenblatt erwischt???
Hayo W. schrieb: > Man könnte ja mal den 25MHz Quarz-Oszillator gegen einen 33iger tauschen Bei dem jetzt schon extrem kritischen FPGA-Timing? Nach dem Tausch wird garnichts mehr funktionieren! Eine weitere Frage ist, was die DCM(PLL) macht, wenn sie plötzlich übertaktet wird. Mfg, Kurt, der noch lebt, aber krank war und sich nur langsam erhohlt.
> Bei dem jetzt schon extrem kritischen FPGA-Timing? Nach dem Tausch wird > garnichts mehr funktionieren! Das vermute ich auch, aber es wäre vielleicht einen Versuch wert. Ich denke kaputt gehen wird wohl nichts, aber es wird wohl nicht sauber laufen. > Kurt, der noch lebt, aber krank war und sich nur langsam erhohlt. Gute Besserung! Hayo
vielleicht sollte man das neue FPGA-Design gleich auf die höhere Taktrate ausrichten 33 MHz sind immerhin ein Zuwachs über 30%
Im neuen Design arbeitet kein NIOS mehr, daher erübrigt sich die Frage der Taktung desselben...
der Leon braucht keinen externen Takt mehr?
Eure Meinung ist gefragt. Ich habe die Idee von Niklas mit den Rasterschritten beim Verstellen des Zerolevels mal für Kanal 1 und 3 eingebaut. Bei Kanal 2 + 4 ist noch alles beim Alten. Ich bin etwas unschlüssig ob das besser ist als das Alte oder nicht. Wie seht Ihr das? -> Die Triggermenüerweiterung für Rainer ist auch schon drin zum Probieren. Gruß Hayo
Hallo! Um das mit dem Takt noch mal abzuklären: Der CycloneII FPGA hat 4 PLLs. Jede PLL besitzt eigene Takteingänge und einen Taktausgang!. Damit muss man den Quarz zwangsweise an allen vier PLL-Takteingängen anhängen. Es sind neben den vier Takteingängen für die PLLs noch andere Takte vorhanden. Sollte das NOIS I Taktnetzwerk sauber mit der Signalerfassungsnetzwerk kommunizieren können und einen eigenen Takteingang haben (beim LEON3 mache ich das beabsichtigt nicht), dann könnte man die Taktgeschwindigkeit erhöhen. Für die vier zeitversetzten Taktsignale der ADCs ist das nicht empfehlenswert, da dadurch die gleichmäßige Abstastung noch mehr zerstört wird! MfG Alexander
Angehängte Dateien:
-
screenshot-0000.png
3,5 KB
habe gerade das Prellverhalten eines Jalousinenschalters getestet und da sind mir wieder einige Bugs aufgefallen. Und zwar erhalte ich im Single Trigger Modus auf Kanal 1 (Kanal 2 nicht getestet) bei einer eingestellten Horizontalauflösung von 1V/Div und einer Abtastrate von 1 mSek/Div keine Auslösung bei einer fallenden Flanke, das Signal ist 5V DC das wie gesagt über einen Taster geleitet wird. Bei 2mSek/Div löst der Trigger auch häufig nicht aus. Bei den andere Abtastraten geht es einwandfrei, bis auf den Umstand das am Ende der Aufzeichnung die ca. letze 5 Stellen im Display immer ein Spike 5V vorhanden ist. Ich vermute das die Zeichenroutine hier etwas verhaut und sich oder irgendwie ein Überlauf der Adressen stattfindet und wieder Daten aus dem vorderem Speicherbereich gezeichnet werden. Beim laden des gespeicherten Traces ist dieser Spike plötzlich weg. Gespeichert wird also der richtige Bereich, beim Betrachten direkt nach dem Auslösen hingegen passt der Speicherbereich nicht 100%tig Oszi: W2022 Firmwareversion: 1.2.BF.2.7
Kann man in die Screenshot BF1.6 einen Schalter einbauen um den Sound erst damit zu aktivieren oder eine Screenshot.cfg um dort die Einstellung dauerhaft vorzunehmen? Beispiel 1: scrennshot.exe /s = startet die screenshot.exe Datei mit Soundausgabe Beispiel 2: scrennshot.cfg Datei wo Screenshot.exe erst nachschaut was gewünscht wird bevor etwas piepst oder nicht Sound=0 oder 1 Die Familie schläft gerade und nach jeder Dateiübertragung piepst der PC Lautsprecher und da hat man ja leider keinen Einfluss auf die Lautstärke, wenn ich nicht umbedingt einen Poti einbauen will.
Hallo Thomas, > Kann man in die Screenshot BF1.6 einen Schalter einbauen um den Sound > erst damit zu aktivieren oder eine Screenshot.cfg um dort die > Einstellung dauerhaft vorzunehmen? Die BF-Version wurde wieder mit der OS vereint. Die neuen Versionen haben einen entsprechenden Schalter, dieser lautet "-a" (Alarm). Nur wenn "-a" gesetzt ist bimmelt es. Eine Konfigurationsdatei wird ohnehin in Zukunft kommen. Bis dahin kannst Du die Optionen weiter in die .bat eintragen. Die ist jetzt auch so gebaut dass man sie von anderen Verzeichnissen aufrufen kann und ihr zusaetzliche Parameter uebergeben kann. Aktuelle Screenshot-Programme sind wie gewohnt auch in den Firmware-Releases. Niklas
Hallo nochmal Thomas, > [Triggerverhalten] > Oszi: W2022 > Firmwareversion: 1.2.BF.2.7 Probier' mal die .15 oder .16 aus, am Trigger hat Hayo in der letzten Zeit geschraubt. Niklas
Hallo zusammen, ich habe gerade die neue Variante der Zerolevel Einstellung getestet und muss sagen: finde ich klasse. In der Regel setze zumindest ich die Kanäle ohnehin auf einen geraden Spannungswert, sprich ich verschiebe die Kanäle manuell kästchenweise, weil man sich dann mit dem Ablesen leichter tut. Das geht mit der neuen Variante wesentlich einfacher ohne dass man die Möglichkeit verliert, beliebige Spannungen zu setzen - ich bin also sehr für die Einführung auf allen Kanälen! Das einzige was dabei stört sind mal wieder die unsäglichen Bedienelemente, irgendwann werde ich mir da mal neue suchen müssen. Gruß Michael
Hayo W. schrieb: > Gute Besserung! Danke! http://sourceforge.net/apps/trac/welecw2000a/wiki/Vinculum Unter Hardware/aktuellste Daten habe ich mal den aktuellen Schaltplan und ein Bild vom Layout hochgeladen. Layout und Schaltplan sind fast fertig und brauchen nur noch kleine Schönheitskorrekturen. Mfg, Kurt
Allzu viele Rückmeldungen sind ja nicht zu Niklas Idee gekommken. Ich habe das aber jetzt trotzdem mal für alle Kanäle eingebaut mit dem Zusatz, dass ab einer bestimmten Menge Drehimpulse nicht nur ein Raster weiter gesprungen wird, sondern zwei. Dann kann man auch etwas schneller über den Screen hoppeln. Ansonsten mache ich gerade eine Komplettrenovierung bei der Autoscalefunktion und im Timebasecontroller. Gruß Hayo
Thomas O. schrieb: > Oszi: W2022 > Firmwareversion: 1.2.BF.2.7 Hi Thomas, danke für die Rückmeldung. Aber wie Niklas schon sagte bitte immer die aktuellste freigegebene Version bei Firmware und Screenshot verwenden. Gruß Hayo
Hayo W. schrieb: > Allzu viele Rückmeldungen sind ja nicht zu Niklas Idee gekommken. Hallo Hayo, die großen Sprünge beim Offset sind bestimmt nicht verkehrt. Ich war da zunächst etwas unschlüssig, da man sowieso bei großen Wegen immer umgreifen mußte. Aber in der alten Version passierte es auch oft, dass sich beim schnellen Drehen mit der Position fast gar nichts tat (Unterabtastung der Geber?) und das ist jetzt in der 1.6 wesentlich besser. Gruß Rainer
Hayo, noch ein anderes Thema: Triggerlevel Läßt es sich ohne großen Aufwand hinbekommen, dass bei Umschaltung der Y-Verstärkung der Triggerlevel (in mV) konstant bleibt? Im Moment muß man bei Änderung vom Y-Gain immer den Triggerlevel ebenfalls nachstellen, wenn der Bezug von Signalhöhe zu Triggerlevel gleich bleiben soll. Ich finde das eher unpraktisch. Und hast du das vollständig disablete Kanal-Soft-Menü nach Abschaltung eines Kanals noch auf deiner ToDo Liste, wo du gerade beim Renovieren bist? Die neue Auto-Pre-Triggereinstellung "First Grid" ist sehr praktisch. Schönen Sonntag Rainer
Angehängte Dateien:
-
screen-0000.png
3,8 KB -
screen-0001.png
3,8 KB
ok habe die aktuelle 2.16 beta drauf und da gibt es die von mir beschriebenen Probleme nicht mehr. Mir ist aber etwas aufgefallen das schon mal gefixt wurde. Wenn man die Zeitbasis streckt sollte das Signal nach rechts gestreckt werden so das die erste Flanke an der gleichen Stelle bleibt. Ist das jetzt evtl. im Menü irgendwo einzuschalten, wurde das wieder absichtlich entfernt oder wurde es vergessen? Das mit Triggerpunkt finde ich genial so kann jeder das ganze so einstellen wie er es braucht. Triggerpunkt auf erstem DIV oder in der Mitte.... Genauso die Einstellung wie man die Singleshot Taste nutzen will, einfach spitze wenn man die Einstellungen so individualisieren kann. Hier nochmal 2 Screenshots des von mir beschriebenen Verhaltens, dass der Signalbeginn ungewollte nach rechts rutscht wenn man etwas rein zoomen möchte. Wäre es möglich die Dateiübertragung auf den Rechner irgendwie anzuzeigen? Blinkendes "Upload" evtl. sogar mit % Balken im Oszi Screen? Da beim Upload das Oszi nicht reagiert.
Thomas O. schrieb: > Hier nochmal 2 Screenshots des von mir beschriebenen Verhaltens, dass > der Signalbeginn ungewollte nach rechts rutscht wenn man etwas rein > zoomen möchte. Muß ich mir mal ansehen, im Stop-Modus hatte ich das nicht getestet. > Wäre es möglich die Dateiübertragung auf den Rechner irgendwie > anzuzeigen? Blinkendes "Upload" evtl. sogar mit % Balken im Oszi Screen? > Da beim Upload das Oszi nicht reagiert. Beim Screenshot geht es (wahrscheinlich) leider nicht, es sei denn Du möchtest die Anzeige dann auch auf dem Screenshot haben :-) Ich hatte auch schon drüber nachgedacht. Ich wollte nochmal probieren die Textausgabe in die Layer-Zwischenspeicher zu schreiben, evtl. wird es dann nicht mit übertragen. Ich check das nochmal. Gruß Hayo
Hallo, >> (Thomas:) >> Wäre es möglich die Dateiübertragung auf den Rechner irgendwie >> anzuzeigen? Blinkendes "Upload" evtl. sogar mit % Balken im Oszi Screen? >> Da beim Upload das Oszi nicht reagiert. > >(Hayo:) > Beim Screenshot geht es (wahrscheinlich) leider nicht, es sei denn Du > möchtest die Anzeige dann auch auf dem Screenshot haben :-) > > Ich hatte auch schon drüber nachgedacht. Ich wollte nochmal probieren > die Textausgabe in die Layer-Zwischenspeicher zu schreiben, evtl. wird > es dann nicht mit übertragen. Ich check das nochmal. Es gibt doch noch die unbenutzten Memory-Planes. Diese muessten wir doch dafuer verwenden koennen? Falls dies nicht geht koennten wir, da wir Zeilenweise abarbeiten, nach ein paar Zeilen ganz oben eine entsprechende Mitteilung mit Fortschrittsbalken einblenden. Erstere Option waere offensichtlich viel eleganter. Beim kurzen Nachschauen fielen mir gerade die Konstanten Color[7][3] und clYellow, clCyan usw. und clCHI bis clCursor in tc_vars.(h/cpp) auf. Ich haette vermutet dass die dazu dienen die Planes einzufaerben, stellt sich aber heraus, dass die nirgendwo verwendet werden. Koennen also weg. Niklas
Thomas O. schrieb: > Wäre es möglich die Dateiübertragung auf den Rechner irgendwie > anzuzeigen? Blinkendes "Upload" evtl. sogar mit % Balken im Oszi Screen? > Da beim Upload das Oszi nicht reagiert. IMO reicht es, wenn z.B. die LED über dem "Universal"-Regler blinkt. Ich halte es für übertrieben, dafür große Texte im Display einzublenden. Sooo lange dauert es nun auch nicht. Man könnte natürlich in der Zwischenzeit auf dem Screen in einer weiteren Zeichenebene TETRIS spielen. ;-)
Angehängte Dateien:
-
Menue_Disabled.png
2,6 KB
@Niklas Wo du da wieder am forschen bist, läßt sich vielleich auch herausfinden, warum die "Disabled"-Ebene nicht mit den Screenshots übertragen wird. Gruß Rainer
Niklas O. schrieb: > Es gibt doch noch die unbenutzten Memory-Planes. Diese muessten > wir doch dafuer verwenden koennen? Ich dachte da an die Buffer_Planes. Die werden irgendwann vor der Screenausgabe mit den Hauptplanes verodert. >> Beim kurzen Nachschauen fielen mir gerade die Konstanten Color[7][3] > und clYellow, clCyan usw. und clCHI bis clCursor in tc_vars.(h/cpp) > auf. Ich haette vermutet dass die dazu dienen die Planes einzufaerben, > stellt sich aber heraus, dass die nirgendwo verwendet werden. > Koennen also weg. Ist erledigt Hayo
Kleiner Zwischenstand aus dem Hackerkämmerlein, ich bin gerade beim Autoscale. Dass das bislang so einigermaßen funktionierte ist eher Zufall. Das ist ein einziges Rumprobieren was der Kerl da veranstaltet hat. Nichts mit Hand und Fuß - also wie gehabt. Ich bin dran... Hayo
@Rainer W.: Ja deine Idee finde ich auch gut, mir geht es nur darum zu sehen das das Oszi beschäftigt ist. Ob das über eine Screenausgabe oder eine blinkende LED gemacht wird ist egal.
Hallo, Rainer: > Wo du da wieder am forschen bist, läßt sich vielleich auch herausfinden, > warum die "Disabled"-Ebene nicht mit den Screenshots übertragen wird. Ach, da brauch' ich nicht lange forschen. Da diese Ebene beim Schwarz-Weiss Screenshot zu sehen ist und die S/W-Routine auch die Memory Planes (3 Stueck) anschaut, entgegen der Farb-Routine, wird es eine dieser 3 Planes sein. Im Screenshot-Programm hab' ich wohl als Kommentar zu den Memory-Planes geschrieben "not yet determined". Das ist schon laenger her (Mitte 2009 iirc). Ist jedoch kein Problem zu beheben: eine Zeile in der Firmware und vier Zeilen im Screenshot-Programm. Thomas: > @Rainer W.: Ja deine Idee finde ich auch gut, mir geht es nur darum zu > sehen das das Oszi beschäftigt ist. Ob das über eine Screenausgabe oder > eine blinkende LED gemacht wird ist egal. Okay, dann lassen wir eine LED blinken. Niklas P.S.: Bin momentan zeitlich ausgelastet. Ab April ist aber wieder Luft.
Hallo nochmal, bin gerade dabei, mir das Spektrum aus einem Signalgenerator in der FFT anzuschauen und dies zu dokumentieren. Ich habe die Cursor angezeigt um die Grundfrequenz und Amplitude zu vermessen. Jetzt ist der Sinus "leider" so sauber, dass die drei Kaestchen unten die restlichen Frequenzanteile komplett verdecken. Eine Idee: Waere es vllt. sinvoll, diese Kaestchen bei der FFT entweder wahlweise oben/unten oder die Werte gar rechts im FFT-Info Feld anzuzeigen? Im normalen non-Math Modus ist das ja egal, dort schiebt man sich die Traces halt nen Stueck hoeher. Zusatz: Man kann natuerlich durch mehrfachen Druck der Cursortaste die drei Kaestchen ausblenden und sieht die Werte noch ganz unten, aber es gibt sicher auch Situationen wo man die Deltas herausstellen will. Niklas
Niklas O. schrieb: > Eine Idee: Waere es vllt. sinvoll, diese Kaestchen bei der FFT > entweder wahlweise oben/unten oder die Werte gar rechts im FFT-Info > Feld anzuzeigen? Wenn dann würde ich rechts bevorzugen. > Zusatz: Man kann natuerlich durch mehrfachen Druck der > Cursortaste die drei Kaestchen ausblenden und sieht die Werte > noch ganz unten, Das fand ich bislang ausreichend aber man könnte natürlich mal auf die obige Lösung umschwenken. Übrigens müßte durch meinen aktuellen Umbau der Timebasesteuerung der Timebasewert angepasst werden, da jetzt nicht mehr die RealTimebase übertragen wird (gibt es nicht mehr), sondern der korrespondierende Timebase_Idx bzw. TB Index (siehe Timebasetable im Programmers Guide). Machst Du die Anpassung im Screenshotprogramm, oder soll ich da Hand anlegen? Gruß Hayo
Hallo Hayo, > Übrigens müßte durch meinen aktuellen Umbau der Timebasesteuerung der > Timebasewert angepasst werden, da jetzt nicht mehr die RealTimebase > übertragen wird (gibt es nicht mehr), sondern der korrespondierende > Timebase_Idx bzw. TB Index (siehe Timebasetable im Programmers Guide). > > Machst Du die Anpassung im Screenshotprogramm, oder soll ich da Hand > anlegen? Das kann ich machen. Ich schaue mal zu das ich moeglichst bis Mittwochabend eine neue Version vom Screenshot-Programm und den entsprechenden Firmware-Diffs fertig bekomme mit den Features die ich in Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil4)" beschrieben habe. Niklas
So nach mehreren Tagen rumgefrickel mit der Autoscale-Funktion sieht es jetzt ziemlich gut aus. Es werden jetzt alle Arten von Signalen sicher erkannt und je nach Anzahl der Kanäle richtig skaliert und auf dem Schirm einsortiert. Den richtigen Triggerlevel gibt es natürlich auch dazu. Wenn Niklas mit seinen Erweiterungen fertig ist, kann ich das zu einer richtig schönen neuen Version zusammenschnüren. Gruß Hayo
Angehängte Dateien:
-
Math_Scale.png
3,1 KB
Hi Hayo, gut hört's sich an. Hast du folgende Bugs bei der "Math"-Bedienung zufällig schon gesehen/abgestellt? - Wenn im Untermenü "Setting" der "Scale"-Regler aktiv ist, leuchtet die LED überm Universalregler nicht und außerdem ist "Offset" nicht aktivierbar. - Wenn die Berechnungsart "1*2" aktiv ist, taucht im Untermenü "Settings" auf dem "Scale"-Button und rechts davon noch Datenmüll auf. Ganz vielen Danke für deine unermütliche Arbeit an der Firmware. Gruß Rainer
Hallo Rainer, ich sehe mir das mal an. Gruß Hayo
@Hayo: Ließe sich der Roll Mode auch in der 500mSek Zeitbasis aktivieren? In Shift Mode ist mir aufgefallen das immer eine horizontale Linie nach rechts gezeichnet wird, soll das so sein?
Hallo, ich habe die 1.2.BF.2.15 drauf und beim Zoomen im angehaltenen Signal verschiebt sich die Triggerposition, bzw. ich lande ganz wo anderst im Speicherbereich als ich ursprünglich gesehen habe. Ich fände es gut, wenn man hier entweder um den Triggerpunkt oder um die Bildmitte zoomen könnte. D.h. der Triggerpunkt oder die Bildmitte als Fixpunkt. Gruß
Thomas O. schrieb: > @Hayo: Ließe sich der Roll Mode auch in der 500mSek Zeitbasis > aktivieren? Leider nein. Ich hatte das schon mal probiert, aber das Timing ist dann so sensibel dass jede Benutzeraktion am Gerät das Signal verfälscht und außerdem braucht ein ADC-Durchlauf gerade etwas länger, als die Abtastzeit in dieser Zeitbasis erfordert. > In Shift Mode ist mir aufgefallen das immer eine horizontale Linie nach > rechts gezeichnet wird, soll das so sein? Stört das? Man könnte es evtl. ändern wenn das ein Problem ist. Gruß Hayo
Gerd schrieb: > Hallo, > > ich habe die 1.2.BF.2.15 drauf und beim Zoomen im angehaltenen Signal > verschiebt sich die Triggerposition, bzw. ich lande ganz wo anderst im > Speicherbereich als ich ursprünglich gesehen habe. Ich fände es gut, > wenn man hier entweder um den Triggerpunkt oder um die Bildmitte zoomen > könnte. D.h. der Triggerpunkt oder die Bildmitte als Fixpunkt. Hi Gerd, so was Ähnliches hatte auch Rainer schon gepostet. Den Fix gibt es mit dem nächsten Release. Gruß Hayo
Hallo Hayo, > Übrigens müßte durch meinen aktuellen Umbau der Timebasesteuerung der > Timebasewert angepasst werden, da jetzt nicht mehr die RealTimebase > übertragen wird (gibt es nicht mehr), sondern der korrespondierende > Timebase_Idx bzw. TB Index (siehe Timebasetable im Programmers Guide). ich hab jetzt gesucht und gesucht, wo finde ich denn diesen "Programmers Guide"? Ich habe wohl Programming Maps gefunden auf der alten Google Seite, aber die laesst er mich nicht runterladen ("W2000A Programming Maps V3.03.zip The page you navigated to does not exist."). Niklas
anbei Diff gegen FW v2.15 und zu ersetzene Files des Screenshot-Programms. Niklas
Hi Niklas, sorry ich hatte den Namen etwas falsch formuliert. Ich packe die aktulle Version immer in das Doc-Verzeichnis des Downloads. Diese hier gehört zum letzten Release. In der Timebase Table findest Du die Spalten für die Indizes. Gruß Hayo
Hi Hayo, Falk, Guido, rowue, Niklas O., KB, Michael D., and guys all! I am back after a long time, I have to update me on the progress, so I will eagerly read the old messages. But I'd like to write some things. @ Hayo First, thanks You very, very much Hayo for the great job and free time You provided generously to us!!! I installed the new 1.2.BF.2.15 and later beta version release and they work well, so Hayo thank You very much for the really amazing great work done!!! As usual I am speechless, RESPECT to You and all other who contribuited!!! It is impressive, it seems to me to use a new DSO!!! If I did not see at it with my eyes I can not believe at it, really incredible!!! No words, RESPECT to You, branadic, Falk, Guido, rowue, Niklas O., KB, Michael D., Jürgen, eProfi, rawi and all other who contribuited!!! Sorry if I forgot someone, really sorry. As I already wrote I have to update me, and then about the old things I would like to remind you: @ Michael D. Michael D. schrieb: [Beitrag "Wittig(welec) DSO W20xxA Open Source Firmware (Teil3)"] > 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. I think this is really a great idea. Then there would be more, but first I want to document me about past developments in order to avoid repeating what has already been treated. I want to understand better the situation. Vielen Dank!!! Gruß Luc
Luc schrieb: Hi Luc, welcome back :-) > Michael D. schrieb: [Beitrag "Wittig(welec) DSO W20xxA Open Source > Firmware (Teil3)"] > >> 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. > > I think this is really a great idea. This issue is stored in the "development queue". But there are some more points of interest. So we must see which of them are solved first. In the new release coming out soon You will find multiple bug fixes and improvements. Niklas made several improvements for the screenshot function, and I completely redesigned the Autoscale function. Additionally I implemented a new zerolevel behavior inspired by Niklas. So You can look forward to the next release for You will like it! By the way, did You notice the new functions which came with the last releases? If not -> read the "Special Functions.txt". Regards Hayo
Hallo Hayo, > sorry ich hatte den Namen etwas falsch formuliert. Ich packe die aktulle > Version immer in das Doc-Verzeichnis des Downloads. Genau da wo ich nicht gesucht habe :) Anbei w2000a-screenshot.cpp mit nachgetragenen Werten. Dabei fiel mir noch auf das wir nicht konsequent mit den Begrifflichkeiten sind, ich gebe da bislang die Samplingrate als "timebase_str" und "timebase_num" aus. Habe ich jetzt noch nicht geaendert. Niklas
Hi Niklas, Du hast in der Methode void FloatStr::Init() die Parameterreihenfolge geändert (int In_AfterDot, int In_MaxLength). Da ich den Grund nicht nachvollziehen konnte und das auch diverse Auswirkungen haben dürfte, habe ich das erstmal nicht übernommen. Kannst Du mir da einen Tip geben wfür das gut ist? Gruß Hayo
Und noch ein kleines Problem:
Unter Windows bricht der Compiler ab mit fer Fehlermeldung
- 179 ....converting to int from double
Verdächtiger ist hier folgende Konstruktion:
FOREACH(OUTF( ( ( (data[j*p_numchact(para)+i] - 128) /* X - 256/2 */
* (p_chscalef(para, chlist[i]) / 1000.0) /* Factor */
- p_chvzero(para, chlist[i])) /* VirtualZero */
/ 50.0 ) /* 50px/div */
* -1 /* invert */
* p_chrange(para, chlist[i]).d /* Range */
/ rescalef)
, p_numchact(para));
Gruß Hayo
Hallo Hayo, > Du hast in der Methode void FloatStr::Init() die Parameterreihenfolge > geändert (int In_AfterDot, int In_MaxLength). Da ich den Grund nicht > nachvollziehen konnte und das auch diverse Auswirkungen haben dürfte, > habe ich das erstmal nicht übernommen. Da gibt es keinen Grund fuer, ich habe da glaube ich noch die beiden neuen protected Variablen initialisieren wollen und die Uebergabe zwischendurch erweitert und dann offensichtlich falsch wiederhergestellt. In der Eile gestern ist mir das im Diff dann nicht aufgefallen. > Unter Windows bricht der Compiler ab mit fer Fehlermeldung > - 179 ....converting to int from double > Verdächtiger ist hier folgende Konstruktion: > FOREACH(OUTF [..] Zeile 179 ist ganz woanders. Ich kann den Fehler gerade nicht nachvollziehen. GCC 4.5.2 unter MinGW hat nichts auszusetzen. Bitte kompiliere ohne -Werror usw.. Niklas
Alles klar, alles andere habe ich auch schon eingebaut. Es fehlen nur noch einige abschließende Tests. Ich habe übrigens die Autoscale-Funktion mittlerweile soweit, dass sie stabil von 1Hz - 140MHz arbeitet. Damit komme ich erstmal klar (und Ihr hoffentlich auch) ;-) Gruß Hayo
Hallo Hayo, für die Bedienoberfläche habe ich noch zwei Vorschläge, die den neuen Glanz noch steigern könnten: 1. Im "Display" Soft-Menü wäre es im Sinne einer einheitlichen Bedienung eigentlich konsequent, wenn man die Grid-Helligkeit auch durch mehrfaches Drücken der Grid-Taste erhöhen könnte (wie bei der Quick-Measure Parameterauswahl). Außerdem finde ich die Abstufung arg grob, vielleicht wären fürs Drücken 20%-Stufen nicht schlecht oder für den Regler sogar 10%, falls das ohne großen Zirkus umsetzbar ist. 2. Im Eingangskanal Soft-Menü habe ich einen Vorschlag für einen zweiten Modus der "Dispatch" Funktion: a) Analogsignal-Modus (so wie bisher) und b) Digitalsignal-Modus, bei dem die Nulllinien alle eine halbe Kanalbreite tiefer landen. In Hardware::DispatchTraces könnte z.B. abhängig von der Anzahl der aktiven Kanäle (inkl. Math) ein Offset berechnet werden, um den alle Nulllinien nach unten verschoben werden. Aktivieren könnte man diesen Digitalsignal-Modus über Doppel-Push auf "Dispatch Channels". Wie ist die allgemeine Meinung dazu? Gruß Rainer
Hallo Rainer, das sind sehr interessante Vorschläge mit Praxisbezug. Ich prüfe mal was sich davon mit vertretbarem Aufwand umsetzen läßt. Danke für die Anregung Hayo
@Niklas Wie schon hier angemerkt wurde wird die UI_Plane1 (hellgrau) nicht richtig im Screenshotprogramm ausgewertet. Übertragen wird sie auf jeden Fall. Ich habe da mal kurz drübergesehen, konnte aber nichts finden. Hast Du da evtl. eine Idee? Gruß Hayo
Hi, > 1. Im "Display" Soft-Menü wäre es im Sinne einer einheitlichen Bedienung > eigentlich konsequent, wenn man die Grid-Helligkeit auch durch > mehrfaches Drücken der Grid-Taste erhöhen könnte (wie bei der > Quick-Measure Parameterauswahl). Außerdem finde ich die Abstufung arg > grob, vielleicht wären fürs Drücken 20%-Stufen nicht schlecht oder für > den Regler sogar 10%, falls das ohne großen Zirkus umsetzbar ist. Dem Stimme ich zu, das die "Gridabstufung" zu grob ist! Nur die Abstufungen per Knoppdruck zu bediehnen, begeistert mich jetzt nicht so, wenn da jetzt mehrere Helligkeitsstufen zur Verfügung stünden, käme man aus dem tasten garnicht mehr raus, da finde ich das mit dem Drehgeber rationaler, was ja beim Delaymodus schon der Fall ist! Das mit den "Rastersprüngen", wenn man schneller dreht, ist eine feine Sache! ...auch wenn der Drehgeber manchmal rumzickt, klasse Idee!!! Gruß Michael
Michael D. schrieb: > Dem Stimme ich zu, das die "Gridabstufung" zu grob ist! Da muß ich aber erst noch prüfen ob eine feinere Abstufung technisch machbar ist. -> ist in Arbeit > Nur die Abstufungen per Knoppdruck zu bediehnen, begeistert mich jetzt > nicht so, wenn da jetzt mehrere Helligkeitsstufen zur Verfügung stünden, > käme man aus dem tasten garnicht mehr raus, da finde ich das mit dem > Drehgeber rationaler, was ja beim Delaymodus schon der Fall ist! Ich glaube Rainer meinte das als Zusatzoption. Mal sehen... > Das mit den "Rastersprüngen", wenn man schneller dreht, ist eine feine > Sache! > ...auch wenn der Drehgeber manchmal rumzickt, klasse Idee!!! Ja ich hab mich inzwischen auch schon dran gewöhnt, am rumzicken ändert das leider nichts. Der Grund ist auch immer noch nicht ganz klar. - sind es die Drehgeber? - ist es der lahme Prozessor? Wer weiß... Gruß Hayo
Michael D. schrieb: > Nur die Abstufungen per Knoppdruck zu bediehnen, begeistert mich jetzt > nicht so, wenn da jetzt mehrere Helligkeitsstufen zur Verfügung stünden, @Michael, darum kamen mir für Tasten 20%-Stufen ganz passabel vor. Der Regler sollte alternativ funktieren, damit man die Helligkeit auch direkt verringern kann. Die Frage war nur, ob man dabei ohne großen Aufwand für den Regler andere Stufen als für die Taste verwenden kann. Gruß Rainer
Tja das werd ich mal versuchen rauszufinden. Wenn es geht kriegt Ihr es auch... Gruß Hayo
@Rainer > darum kamen mir für Tasten 20%-Stufen ganz passabel vor. Der Regler > sollte alternativ funktieren, damit man die Helligkeit auch direkt > verringern kann. Achso, als zusätzliche Alternative für's "Grobbe" ?!? Das wäre dann auch ok! @Hayo > Tja das werd ich mal versuchen rauszufinden. Wenn es geht kriegt Ihr es > auch... ...au ja Gruß Michael Edit: Hast du was am Quickmeasure was gedreht?
> Edit: Hast du was am Quickmeasure was gedreht?
Nein habe ich nicht. Aber ich habe für Euch was zum Drehen - nämlich am
Helligkeitsregler.
Es ist natürlich nicht die Helligkeit die man da regelt, sondern der
Farbton. Da unser W2000A nicht mit allen Display-Steuerleitungen
arbeitet stehen nur begrenzt viele Farben zur Verfügung.
Um es kurz zu machen - es gibt tatsächlich nur 3 Abstufungen pro Farbe.
Ich kann Euch aber anbieten verschiedene Farbtöne zur Verfügung zu
stellen wenn Euch das interessiert.
Welche Werte da zur Verfügung stehen könnt Ihr mit dieser Version selbst
ausprobieren. Die Farbwerte werden via Terminal ausgegeben.
Die Neuerungen sind natürlich auch schon an Bord. Ihr könnt ja schon mal
testen, vielleich findet Ihr noch Fehler die ich übersehen habe.
Viel Spaß
Hayo
@Hayo ich habe mal ein bisschen Grid-Farben gedreht... Die Auswahl ist ja mehr als besch.... eiden. Zwischen 33% (0x15) und 66% (0x2a) könnte ich mir als Abstufung die 0x1a vorstellen. Im hellen Bereich zwischen 66% und 100% (0x3f) kommt man beim Ausweichen auf bunte Grid-Farben schnell an die Kanalfarben ran, so dass es die Sache eher unübersichtlich macht. Da habe ich nichts gefunden. Kann man die RGB-Werte der LUT irgendwo nachlesen, oder wo kommt die Belegung her? Gruß Rainer
Rainer W. schrieb: > ich habe mal ein bisschen Grid-Farben gedreht... schrill oder...? > Die Auswahl ist ja mehr als besch.... eiden. Zwischen 33% (0x15) und 66% > (0x2a) könnte ich mir als Abstufung die 0x1a vorstellen. ist die 0x1A nicht identisch mit 0x2A? Kam mir jedenfalls so vor. Ich wollte mal ähnliche Farben nebeneinander in ein Array stopfen damit man bein hin und her schalten die Unterschiede besser sehen kann. > Im hellen Bereich zwischen 66% und 100% (0x3f) kommt man beim Ausweichen > auf bunte Grid-Farben schnell an die Kanalfarben ran, so dass es die > Sache eher unübersichtlich macht. Da habe ich nichts gefunden. Ging mir auch so > Kann man die RGB-Werte der LUT irgendwo nachlesen, oder wo kommt die > Belegung her? Ich hab da momentan nichts, aber unsere Hardware Spezis hatten dazu glaube ich was auf SFN veröffentlicht. Da muß ich bei Zeiten mal nach suchen. Aber - gute Nachrichten, mir ist es gelungen beim Screenshot ein Popup einzubauen ohne dass dieses mit übertragen wird. Gruß Hayo
Wer mehr Farben haben will: Beitrag "Re: Welec W20xx Bedienelemente modifizieren: Drehgeber Encoder LED BNC-Buchsen" Mit dem zum nächsten Grid springen: würde mir gefallen, wenn das eine Tastenfunktion wäre - oder die optionalen Encoder-Taster. Weiß jemand, ob die Abfrage der noch freien Pins des U9 74HCT166 möglich ist, um sie mit den Tastern zu verbinden?
Hayo W. schrieb: > ist die 0x1A nicht identisch mit 0x2A? Kam mir jedenfalls so vor. 0x2A ist ein sauberer Grauton, während 0x1A das Gelb zu sein scheint, das auch oben für den Hintergrund der Bereichsanzeigen verwendet wird. Vielleicht wirkt es dadurch ein bisschen dezenter als das 66%-Grau. Unter den gegebenen Umständen sollte man dann da vielleicht im Moment nicht zu sehr drüber nachgrübeln. @eProfi gut zu wissen, aber alleine wegen der Gridfarbe an der Hardware rumzuschrauben ist mir doch etwas viel Zauber Gruß Rainer
Hi Hayo, hier mal eine kleine Rückmeldung! Also, ich finde das ganz witzich, das die Gritfarben veränderbar sind. Jedenfalls, hat man schon mal mehr Auswahl als vorher zur Verfügung. Die Gridfarben werden im Screenshot nicht mit aufgezeichnet? Die "Autoscale-Funktion" funzt soweit prima...schaltet automatisch auf den Combitrigger? Gruß Michael
Michael D. schrieb: > Hi Hayo, hier mal eine kleine Rückmeldung! > > Also, ich finde das ganz witzich, das die Gritfarben veränderbar sind. > Jedenfalls, hat man schon mal mehr Auswahl als vorher zur Verfügung. Ich bau das auch mit ein, dann hat man was für's Auge > Die Gridfarben werden im Screenshot nicht mit aufgezeichnet? Nein, die Farben des Bildes werden vom PC-Programm vorgegeben. Man müßte den Farbwert für das Grid zusätzlich übertragen, dann ließe sich das darstellen. > Die "Autoscale-Funktion" funzt soweit prima...schaltet automatisch auf > den Combitrigger? Korrekt, das hat sich bei meinen Tests am Besten bewährt. Gibt es Bedenken? Und in der Final-Version gibt es das Ganze auch noch mit Fortschrittsanzeige, so wie auch beim Screenshot. Gruß Hayo
Hayo W. schrieb: > Michael D. schrieb: >> Hi Hayo, hier mal eine kleine Rückmeldung! >> >> Also, ich finde das ganz witzich, das die Gritfarben veränderbar sind. >> Jedenfalls, hat man schon mal mehr Auswahl als vorher zur Verfügung. > Ich bau das auch mit ein, dann hat man was für's Auge > ...genau, tut ja nicht weh! >> Die Gridfarben werden im Screenshot nicht mit aufgezeichnet? > > Nein, die Farben des Bildes werden vom PC-Programm vorgegeben. Man müßte > den Farbwert für das Grid zusätzlich übertragen, dann ließe sich das > darstellen. > nun ja, ist ja nicht soo wichtig! >> Die "Autoscale-Funktion" funzt soweit prima...schaltet automatisch auf >> den Combitrigger? > > Korrekt, das hat sich bei meinen Tests am Besten bewährt. Gibt es > Bedenken? > nö, ich find's gut! Der Combitrigger, ist so oder so genial und man ist dann auf der sicheren Seite > Und in der Final-Version gibt es das Ganze auch noch mit > Fortschrittsanzeige, so wie auch beim Screenshot. > Fein, wann kann man denn so damit rechnen? Ich habe die letzte Ram schon als "Flash" drinnen! ...kann das sein, das die Encoder unterschiedlich Empfindlich sind? Ich habe mal ein wenig mit der "Gridhüpperei" (geniale Sache) gespielt und bin der Meinung, das der 2.Kanal nicht so rumzickt, wie der Erste?!? > Gruß Hayo Gruß Michael
> Fein, wann kann man denn so damit rechnen? Ich habe die letzte Ram schon > als "Flash" drinnen! Ich hoffe morgen oder Übermorgen. > ...kann das sein, das die Encoder unterschiedlich Empfindlich sind? Ich > habe mal ein wenig mit der "Gridhüpperei" (geniale Sache) gespielt und > bin der Meinung, das der 2.Kanal nicht so rumzickt, wie der Erste?!? Das würde darauf hindeuten, dass es tatsächlich an den Encodern liegt (Billigschrott???) Gruß Hayo
Ok, damit das Warten nicht zu lang wird: - die Fortschrittsanzeigen für Screenshot und Autoscale sind drin - Double Push Funktionalität beim Autoscale Button - Es gibt einen neuen Button "Send Measure" im Quick Print Menü, dahinter steckt Niklas neue Measure Funktion. - die Farbpalette für das Grid läßt sich durch Druck auf den Grid-Intensitätsbutton ändern. In die Final will ich noch einige Goodies einbauen. Mal sehen wie lange ich brauche. testet schon mal, dann kann ich evtl. Fehler gleich mit wegbügeln. Gruß Hayo
moin Hayo, was iss eigentlich mit der 'vernachlaessigten' singel funktion geworden? ist die jetzt ok ? denn die brauch i am allerwichtigsten ein schoenes & erfolgreiches WE Charly
Charly B. schrieb: > moin Hayo, > > was iss eigentlich mit der 'vernachlaessigten' singel funktion > geworden? ist die jetzt ok ? denn die brauch i am allerwichtigsten Sollte stabil laufen. Im Mode/Coupling Menü gibt es die Möglichkeit im Submenü das Verhalten einzustellen. Probier mal aus und sag Bescheid wenn etwas nicht funktioniert. Gruß Hayo
Hayo W. schrieb: > - die Farbpalette für das Grid läßt sich durch Druck auf den > Grid-Intensitätsbutton ändern. Moin Hayo, verstehe ich das richtig, dass du da jetzt 10 Paletten à 4 Werten vorgegeben hast, zwischen denen man auf Tastedruck umschalten kann? Da hätte ich jetzt einen ganz ketzerischen Vorschlag: - 1 konfigurierbare Palette mit z.B. 4 Werten - Umschalten zwischen den Paletteneinträgen auf Tastendruck (für normale Bedienung) - Festlegung der Paletteneinträge über Drehgeber (zur Konfiguration) - Abspeichern der Palette in den Geräteeinstellungen. Dann könnte jeder sich seine Palette zurechdrehen, wie er möchte. Schönen WE Gruß Rainer
Rainer W. schrieb: > verstehe ich das richtig, dass du da jetzt 10 Paletten à 4 Werten > vorgegeben hast, zwischen denen man auf Tastedruck umschalten kann? Jupp, und hier die Werte: GridColorArray[10][4] = {{0x00, 0x15, 0x2A, 0x3F}, //white {0x00, 0x01, 0x02, 0x03}, //red {0x00, 0x04, 0x08, 0x0C}, //green {0x00, 0x05, 0x0A, 0x0F}, //yellow {0x00, 0x10, 0x20, 0x30}, //blue {0x00, 0x14, 0x18, 0x2C}, //light blue {0x00, 0x11, 0x12, 0x13}, //violet {0x00, 0x16, 0x17, 0x2B}, //pink {0x00, 0x06, 0x0B, 0x1B}, //orange {0x15, 0x1A, 0x2A, 0x3F}}; //test Das sind so ziemlich alle Werte die eine sinnvolle Kombination ergeben. > Da hätte ich jetzt einen ganz ketzerischen Vorschlag: > - 1 konfigurierbare Palette mit z.B. 4 Werten > - Umschalten zwischen den Paletteneinträgen auf Tastendruck > (für normale Bedienung) > - Festlegung der Paletteneinträge über Drehgeber > (zur Konfiguration) > - Abspeichern der Palette in den Geräteeinstellungen. :-) Jetzt willst Du es aber genau wissen... > Dann könnte jeder sich seine Palette zurechdrehen, wie er möchte. Mein Vorschlag ist erstmal für alle die selber kompilieren können: tragt Euch in das Array oben Eure eigenen Werte ein und wenn Ihr eine gute Kombination gefunden habt übernehme ich die gerne in die offizielle Version. Gruß Hayo
Noch ein Hinweis an die unermüdlichen Tester: Beim Autoscale werden alle Suchschritte via Terminal ausgegeben, so dass man alles genau nachvollziehen kann. Gruß Hayo
Hallo Hayo, gerade habe ich ein wenig mit der neuen Beta gespielt, konnta dabei aber den Knopf zum Senden der Messdaten nicht im QuickPrint Menü finden. Die Idee (stammte sie von Niklas?) finde ich übrigens sehr gut. Zu den Screenshots: Was muss ich tun, um per Doppeldruch auf Quickprint wieder BMPs zu bekommen? Mit "save to bmp" klappt es zwar, aber gibt es eine Möglichkeit, das auch für den Doppeldruck als Standard zu setzen? Oder geht das per Paramter auf der PC Seite? Die Autoscale-Funktion hat bei ersten Tests gut funktioniert, natürlich muss man etwas Geduld haben aber das lässt sich beim Nios wohl nicht ändern. Allerdings würde es mir persönlich besser gefallen, wenn die Funktion die Zeitbasis so einstellen würde, dass eine Signalperiode auf dem Display zu sehen ist. Beim Test mit dem Rechteckgenerator des Oszis stellten sich 10ns ein, d.h. 12mal Zeitbasis umschalten bevor man eine Periode sieht. Das ist aber sicher Geschmackssache. Ansonsten habe ich einige neue Funtionen entdeckt, die ich gar nicht mitbekommen hatte, da hat sich in letzter Zeit doch wieder gewaltig was getan - klasse. Achja da fällt mir noch was ein: ich habe meine Tastköpfe fast immer auf 10:1, wie sieht es bei anderen Leuten hier aus? Denn dann könnte man den Default evtl. darauf setzen. GrußKürzlich haben wir übrigend in der Arbeit an unserem Oszi der 40 000 Euro Klasse feststellen müssen, dass der stinknormale Flankentrigger nicht der zuverlässigste ist...da macht unser 300 Euro Oszi gar keine schlechte Figur. Ein schönes Wochenende euch allen! Michael
Hi Hayo I have tested the latest firmware from yesterday. The new Autoscale works great, and the custom grid palette is an excellent idea. Unfortunately I'm not able to use the panning knob when in single shot: I acquire a waveform, I can zoom with the timebase knob, but I'm not able to move around with the smaller delay knob. With 2.15 this was working. Sorry if this issue was addressed before, anbd thank you for all your efforts. Be well, Andrea
Angehängte Dateien:
-
scrhCOM4_batch.gif
8,1 KB
ich noch mal, bei der Autoscale-Funktion, kann man das Signal hoch u. runter bewegen, aber nicht mehr nach links u. rechts, auch wenn ich auf Cursor oder Quickmeasure gehe... Gruß Michael
??? ...wo ist denn mein Beitrag für die Batchdatei hin??? Gelöscht? @Michael H. also noch mal: Schalter "-a" ist der bestätigungsbeep, Schalter "-b" die permanente BMP Ausgabe. "-c4" ist Comport und dem entsprechend anzupassen. noch was, drücke ich "About Oszilloscope" und wieder zurück, ist die Gridfarbeneinstellung hinüber! Wird wohl nicht gespeichert?!? Gruß Michael
Michael D. schrieb: > ??? ...wo ist denn mein Beitrag für die Batchdatei hin??? Gelöscht? komisch - scheint verschwunden zu sein > noch was, drücke ich "About Oszilloscope" und wieder zurück, ist die > Gridfarbeneinstellung hinüber! Wird wohl nicht gespeichert?!? Ist noch beta, daher ist noch nicht alles wie es sein soll. Aber danke für den Hinweis, da muß ich noch ran. Gruß Hayo
moin moin Hayo, hatte heut morgen die 2.18 beta aufgespielt, leider dauert das Calibrate Offsets sehr lange (einige Minuten) und danach war keine X-Linie mehr sichtbar und auch keine Signale werden mehr angezeigt. :( hab die mal einen rs232 output vom start an ueber Calibr. Offsets mitgeschrieben, vielleicht hilfts ja oder hab i was falsch gemacht ? vlG Charly
hab jetzt die 2.16b drauf, scheint gut zu laufen, vlG Charly
Hi Charly, habe die 2.18 drauf und das Calibrieren dauert gerade mal 6 Sek.! Hast du mal Default Setup gedrückt? Aprorpos...ich dachte es liegt am Autoscale, dem scheint aber nicht so. Nach Default Setup, kann ich die Signale trotzdem nicht nach links oder rechts verschieben, hoch u. runter geht, was'n da los? Ist das nur bei mir so, oder kann das noch Jemand bestätigen? Gruß Michael
moin moin Michael, ja, ich habe auch default setup gedrueckt, sieht man auch im Log-File, i denke/hoffe Hayo kann sich da ein Bild machen was schief gelaufen ist. i warte halt auf das naechste release vlG Charly
Hi Hayo, - zur Quick Measure Datenübertragung habe ich gleich eine Fragen: Gibt es schon eine offizielle Protokollbeschreibung für die lachenden Männchen, die einem auf dem Terminal zwischen den Daten entgegenkommen oder ist das noch 'in progress'? - Die fehlende Wirkung des X-Position (Pan) Reglers auf den sichtbaren Signalausschnitt kann ich bestätigen. - Der "Send Measure"-Softkey im Quick-Print Menu ist nur mit "Send" beschriftet. Ist das Absicht? Die Funktion finde ich sehr praktisch. Allerdings macht das Screenshot Programm unter Win direkt einen Abgang, wenn man aus Versehen die "Send Measure"-Taste erwischt. (@Niklas?) Der Fortschrittsbalken beim Screenshot ist super-chic! Schönen Abend und Gruß Rainer
ich habe mir mal die Mühe gemacht und bis hinunter zur 2.12 geflasht. Mit dem FTDI-Dongle dauert das zwar jedes mal 170Sek., aber was soll's... Ab der 2.13 tritt das Problem auf. Mit der 2.12 kann ich mit den Signalen von links nach rechts u. umgekehrt wandern! gruß Michael
Hallo, moin moin, danke für die zahlreichen Rückmeldungen. zur X-Verstellung: - da habe ich doch leider das Coding etwas überoptimiert und eine Zeile zuviel weggehauen bei der ich nicht mehr ganz sicher war wozu ich die gebraucht hatte - jetzt weiß ich es wieder :-) Als Workaround könnt Ihr im Pretriggermenü "Keep Value" einstellen, dann geht es wieder. @Charly Dein Problem konnte ich nicht nachstellen, bei mir funktioniert es super. Dein Log zeigt mir, dass die ADC bei Dir nicht losgelaufen sind - warum kann ich leider nicht sagen. Mich würde interessieren ob das bei Dir reproduzierbar ist. Ich stelle gleich noch mal eine korrigierte beta hier rein die Ihr testen könnt. Gruß Hayo
Moin Hayo, bei Einzeltrigger nach einer TB-Umschaltung sind noch Überreste (?) des alte Kanal 3/4-Problem vorhanden. Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil4)" Beim ersten Trigger nach einer Umschaltung der TB wird auf Kanal 3+4 nichts aufgezeichnet. Hattest du da nochmal drüber nachgedacht? Gruß Rainer
Ja da hatte ich schon etliches ausprobiert - leider ohne Erfolg. Das muß also erstmal schuldig bleiben. Wie bei anderen Bugs kann es aber durchaus sein, dass ich im Rahmen anderer Änderungen darüber stolpere. Hayo
@Hayo nach dem Flashen waren beide X-Lines da nur halt verschoben, dann Calibrate und weg waren sie, hab das geraet mehrfach aus/ein geschaltet und Calibrate versucht, leider ohne erfolg. :( Gibt es eigentlich eine neuere Soft zum Flashen unter W7/64 ?, i hab immer noch einen uralt Programmer v. Wellec und der brauch ewig vlG Charly
Mit dem Support von Win64 bin ich nicht so vertraut. Im Prinzip mußt Du nur Perl zum Laufen kriegen, damit das Upload-Skript funktioniert. Ob es eine 64 Bit Variante von Active Perl gibt weiß ich momentan nicht. Habt Ihr Anderen da Überblick? Hayo
auch moin moin, uns fehlt hier eine Stunde...;) Das "Pre Trigger" Menu habe ich ja voll verpeilt! Da geht ja was. Ich nehme alles zurück, passt schon. Ein kleiner Vorschlag: Ich fände es ganz praktisch die X1, X2 u. Y1, Y2 Achsen im Curser-Menu nach schnellerem drehen, grössere Sprünge machen zu lassen, ist das möglich oder eher unpraktisch? Gruß Michael
Angehängte Dateien:
-
Active-Perl-Release_5.8.gif
5,7 KB
> Mit dem Support von Win64 bin ich nicht so vertraut. Im Prinzip mußt Du > nur Perl zum Laufen kriegen, damit das Upload-Skript funktioniert. Ob es > eine 64 Bit Variante von Active Perl gibt weiß ich momentan nicht. > Habt Ihr Anderen da Überblick? Habe ich mir gerade mal verschafft! Es gibt eine neue Release Ver. von Active-Perl 5.8 Betriebssysteme sind unter Anderem auch 64bit angegeben, siehe Shot! bitteschön... Hier der Link: http://www.activestate.com/activeperl
gibts irgendwo eine Beschreibung wie was wann seriell gesendet wird f. das flashen ? event. kann man das ja selber proggen, oder gehts mitlerweile per USB und i hab das beste verpasst ? vlG Charly
Kleiner Tip für alle die den Überblick über die aktuellen Sonderfunktionen verloren haben: In der Datei "Special Functions" im Doc-Verzeichnis sind alle Funktionen beschrieben. Die Datei wird mit jedem Release upgedatet. Gruß Hayo
Michael D. schrieb: > Ein kleiner Vorschlag: Ich fände es ganz praktisch die X1, X2 u. Y1, Y2 > Achsen im Curser-Menu nach schnellerem drehen, grössere Sprünge machen > zu lassen, ist das möglich oder eher unpraktisch? Gute Idee Gruß Rainer
Angehängte Dateien:
Hi Charly, ich muß mich korrigieren, die letzte Release ist die 5.12, besser man nimmt diese! und nein, es funzt im Moment nur über den Serialport! Aktive-Perl installieren, ausführen und im Perl-Package-Manager das Win32-Serialport-0.22-Package installieren( muß aber auch separat heruntergeladen werden! Anbei mal ein Shot, wie das auszusehen hat Ich hatte mal irgenwo eine Anleitung gepostet, finde die aber im Moment nicht... Gruß Michael
Danke Michael, die 5.12 hab ich eben heruntergeladen, werde mal heute Abend testen mit dem neuen release von Hayo vlG Charly
So, das war jetzt etwas mühselig die ganzen kleinen Bugs zu finden.
Ich habe Eure Hinweise alle abgearbeitet und hoffe dass nicht mehr
allzuviel falsch läuft.
- Autoscale -> sucht jetzt schnellere Zeitbasen damit weniger
Perioden auf dem Schirm sind
-> DC-Offset Erkennung (Digitalsignal)
- Dispatch -> DC-Offset Erkennung (Digitalsignal)
- Grid -> Colorpaletten werden jetzt richtig eingestellt und gespeichert
(mein Favourit ist die hellblaue Palette, das erinnert mich
an mein Analog-Oszi)
-> zum Testen gibt es den Testswitch 2 (shift + Y) der sich via
Terminal umschalten läßt.
aus -> normale Intensitätsverstellung
an -> per Drehgeber können die Farben einzeln eingestellt
werden
- X-Verstellung (panning) geht wieder korrekt
Gruß Hayo
Danke! Jetzt gibt's an dem verregneten Sonntag Nachmittag wenigstens was zum spielen! :) Gruß, Michael
Hallo Hayo, super, dann kann man ja noch mal Grid-Farben drehen. Die "Intelligenz" der Dispatch gefällt mir auch sehr gut. Beim Panning wäre es eigentlich schön, wenn man damit auch bei einem Einzelsignal durch den Speicher rutschen könnte. Siehst du dafür eine Chance. So wie es jetzt funktioniert, muß anscheinend immer ein neues Signal erfaßt werden, damit sich das Signal verschiebt. @Michael - Hier in Stuttgart scheint inzwischen wieder die Sonne :-) Schönen Sonntag Rainer
Hamburg - auch sonnig! Habe gerade meine Sommerreifen draufgezogen... > Beim Panning wäre es eigentlich schön, wenn man damit auch bei einem > Einzelsignal durch den Speicher rutschen könnte. Siehst du dafür eine > Chance. Wie ist das gemeint mit dem Einzelsignal? Habt Ihr noch was gefunden was klemmt? Gruß Hayo
Hayo W. schrieb: > Wie ist das gemeint mit dem Einzelsignal? Damit meint ich ein einmal erfaßtes Event, also kein periodisches Signal. Wenn das DSO auf Norm Trig steht und ein Event erfaßt hat, muß man erst auf STOP-Taste gehen, damit sich das Signal horizontal auf dem Schirm verschieben läßt. Wenn man nicht auf STOP geht, muß man erst ein neues Signal erfassen, damit des Panning eine Wirkung auf die Signalposition hat. Das mit dem STOP hatte ich nicht gepeilt. Ist ein bisschen umständlich, aber nicht so wild. Schönen Abend Rainer
Dafür gibt es eigentlich die Single-Funktion, die schaltet dann automatisch auf Stop und man kann dann das Signal hin und her schieben. Gruß Hayo
Das Drücken der Singe-Taste vor jeder Erfassung wollte ich ja gerade einsparen ;-)
Wie wärs mit nem Mind Interface? Da braucht man dann gar keinen Knopf mehr zu drücken... Gruß Hayo
Hayo W. schrieb: > Wie wärs mit nem Mind Interface? Hähä Hayo, mit der c't schon durch? Wir wollen eine Kinect-Steuerung. Grüße, Guido
Ich hänge mit der ct leider 6 Hefte hinterher - ich programmiere einfach zu viel, da kommt man nicht mehr zum Lesen. Aber ich habe mal eine Frage, bei mir sind die Spikes auf Kanal 3 + 4 teilweise so heftig, dass kein Autoscale auf diesen Kanälen funktioniert wenn diese die Triggersource sind. Ist das bei Euch auch so? Auf Kanal 1 + 2 ist alles ok. Gruß Hayo
Wetere Erkenntnisse: - Die Spikes treten nur bei warmgelaufenen Gerät auf -> also ein thermisches Problem (hatten wir ja früher schon vermutet). Ich werde da mal nachforschen wie man das wegkriegt, habe auch schon eine Idee. - Autoscale -> auf Kanal 3 + 4 bei einer Eingangsspannung größer als 15 Vpp tritt anscheinend eine Übersteuerung der Eingangsstufe auf, die eine Timebaseerkennung verhindert. Auf Kanal 1 + 2 geschieht das nicht. Ich suche noch nach einer Lösung. Gruß Hayo
Hayo W. schrieb: > - Autoscale -> auf Kanal 3 + 4 bei einer Eingangsspannung größer > als 15 Vpp tritt anscheinend eine Übersteuerung der Eingangsstufe auf, > die eine Timebaseerkennung verhindert. Auf Kanal 1 + 2 geschieht > das nicht. Ich suche noch nach einer Lösung. Kann das eventuell mit dem Kanal 3/4 Erfassungsproblem nach TB Umschaltung zusammenhängen. Deine Autoscale Suchroutine wird doch auch an der TB drehen, ein Signal erfassen (wollen) und das dann auswerten. Nur so ein Gedanke ....
Das Problem ist die grundsätzliche Vorgehensweise. Für die Timebasermittlung wird in den 10mV Bereich geschaltet, damit die Flanken möglichst steil sind und man sie besser zählen kann. Das funktioniert auch ganz gut, nur auf Kanal 3 + 4 scheint dann ab 15 Vpp eine Übersteuerung einzusetzen und die ADC sind dann auf Vollanschlag aber nur nach unten. Gruß Hayo
Hayo, zur Entspannung habe ich noch eine "Oberflächenrauhigkeit" für dich: Wenn man "Display Persist" aktiviert hat und dann "Autoscale" startet, bleibt nach dem Ende vom Autoscale der alte Müll auf dem Bildschirm stehen. Da wäre noch ein feines Plätzchen für ein Clear Display nachdem Autoscale seine Arbeit beendet hat. Die Spikes auf 3 + 4 scheinen immer genauso so hoch wie das Signal zu sein, zumindest bei einem Rechteck. Daraus schließe ich eigentlich, dass es sich um ein sporadisches Adressierungsproblem handelt, so dass ab und zu korrekt gesamplete Daten an der falschen Stelle im Speicher landen. Wo auch immer das passiert ... Gruß Rainer
@Hayo, beim Autoscale in der 2.19 beta bin ich gerade noch auf Signale gestoßen, bei denen sich der Algorithmus verläuft: Signale: Probe Comp an 3, Gnd an 4 ergibt: 100 us/div, 500 mV/div, 10 mV/div (ok) Wenn ich die Signale vertausche, also Signale: Gnd an 3, Probe Comp an 4 endet das bei: 50 ns/div, 10 mV/div, 10 mV/div (Unfug) Eigentlich ist das Signal an Ch4 ja vernünftig. Da die Signalamplitude mit 1 Vpp eher friedlich ist, scheint da im Algorithmus noch was schief zu gehen und eher nicht dein 15V-Problem zu sein. Der gleiche Test mit Ch. 2 + 4 führt oft zum gleichen Ergebnis. Schönen Abend Gruß Rainer
Hallo Rainer, danke für Deinen ausführlichen Testbericht. Bin gerade vom Griechen zurück und arbeite schnell noch die Mails ab. Dein geschilderrtes Problem liegt mit ziemlicher Sicherheit an der reihenfplge der Abarbeitung. Der Autoscale der 2.19 arbeitet so: Spannungsbereich auf 10mV, dann den ersten aktiven Kanal (Reihenfolge 1,2,3,4) auf brauchbare Timebases prüfen. Wenn eine brauchbare Timebase gefunden wird, dann übernehmen. Sonst auf Default 50ns einstellen, weitere Kanäle werden nicht geprüft. Dann wird mit dieser Timebase für alle anderen aktiven Kanäle der richtige Spannungsbereich gesucht. In der 2.20 beta kann der Autoscaler schon mehr. Hier werden alle akiven Kanäle solange auf ein triggerbares Signal durchsucht bis er was findet. Die Triggersource wird automatisch angepasst. Wenn kein Sigal gefunden wird dann wird Default eingestellt. Kanäle ohne Triggerbares Signal werden auch nicht mehr auf Spannungsbereich geprüft. Damit ist wahrscheinlich dann auch Dein Problem erledigt. Gruß Hayo
Hayo W. schrieb: > In der 2.20 beta kann der Autoscaler schon mehr. Hier werden alle akiven > Kanäle solange auf ein triggerbares Signal durchsucht bis er was findet. > Die Triggersource wird automatisch angepasst. Ich sehe, du bist schon wieder ein ganzes Stück weiter. Bei der Suche nach einer Triggersource kann man vielleicht davon ausgehen, dass der Benutzer schon den richtigen Triggerkanal gewählt hat. Wenn der Algorithmus auf diesem Kanal anfängt, hat er eine große Chance, dass er schon richtig liegt und die Suche gegenüber blindem Durchlaufen aller Kanäle verkürzt wird. Ich bin gespannt auf die 2.20 Gruß Rainer
Hallo, in der 19er springt der Trigger bei angehaltenem Signal schon viel weniger, wenn ich die Zeitbasis umstelle. Von 10ms auf 5ms wechselt er aber immernoch die Position im Signal. Sonst schon viel besser geworden.
Hallo Leute, es gibt jetzt eine Vorschau auf die Firmware: http://sourceforge.net/apps/trac/welecw2000a/wiki/Vinculum Zur Zeit werden nur SD-Karten unterstützt, obwohl die USB-Geschichte natürlich schon funktioniert! Mfg, Kurt
Angehängte Dateien:
-
tastkoepfe_x1.png
5,1 KB -
tastkoepfe_x10.png
3,9 KB
Hallo, Michael H. schrieb: > gerade habe ich ein wenig mit der neuen Beta gespielt, konnta dabei aber > den Knopf zum Senden der Messdaten nicht im QuickPrint Menü finden. Die > Idee (stammte sie von Niklas?) finde ich übrigens sehr gut. Die Idee stammt von August. > Zu den Screenshots: > Was muss ich tun, um per Doppeldruch auf Quickprint wieder BMPs zu > bekommen? Mit "save to bmp" klappt es zwar, aber gibt es eine > Möglichkeit, das auch für den Doppeldruck als Standard zu setzen? Oder > geht das per Paramter auf der PC Seite? Wie Michael D. schon schrieb: Per Parameter -b > Achja da fällt mir noch was ein: ich habe meine Tastköpfe fast immer auf > 10:1, wie sieht es bei anderen Leuten hier aus? Denn dann könnte man den > Default evtl. darauf setzen. Mhm, ich hab's jetzt nicht ueberprueft, aber sollte nicht die letzte Einstellung des Kanals beibehalten werden, d.h., einmal einstellen auf 10:1 Teiler und damit hat's sich? Ansonsten: Wo Du Tastkoepfe erwaehnst... Wegen eines Analogoszis hab' ich kuerzlich nen "100 MHz" Tastkopf aus China von Dealextreme bestellt. Der ist vor ein paar Tagen eingetroffen, und, da ich dem "100 MHz" Sticker nicht traue und es Angaben bzgl. Anstiegszeig/BW in Stellung x1 und x10 schlicht nicht gibt, hab' ich diese doch gleich kurz mal mit den Original Welec "200 MHz" grob am Rechtecksignal des DSO verglichen. Resultat seht ihr in den Screenshots. Kanal 2 ist der 6 USD (inkl. Versand) Tastkopf. Die Traces sind etwas verschoben, da ich den Versatz nocht nicht wieder ueber die Delays im Utility-Menue kompensiert habe. Man sieht's aber auch "mit blossen Augen" ohne Cursor recht gut ;) Niklas
Rainer W. schrieb: > - Der "Send Measure"-Softkey im Quick-Print Menu ist nur mit "Send" > beschriftet. Ist das Absicht? Die Funktion finde ich sehr praktisch. > Allerdings macht das Screenshot Programm unter Win direkt einen Abgang, > wenn man aus Versehen die "Send Measure"-Taste erwischt. (@Niklas?) Mhm, hast Du die aktuelle Version die ich oben dem Hayo gepostet habe? Eine aeltere wird irgendwas in Richtung
1 | w2000a-screenshot: Internal Error: Unhandled dumptype in retrieve() (at 4): 4 |
sagen. > Der Fortschrittsbalken beim Screenshot ist super-chic! ACK, gut gemacht Hayo ;) Hayo W. schrieb: > Wie schon hier angemerkt wurde wird die UI_Plane1 (hellgrau) nicht > richtig im Screenshotprogramm ausgewertet. Übertragen wird sie auf jeden > Fall. Ich habe da mal kurz drübergesehen, konnte aber nichts finden. > > Hast Du da evtl. eine Idee? Meine Vermutung auf die Beobachtung von iirc. Rainer war ja, dass das in den Memory-Planes gezeichnet wird, und diese werden beim Farb-Screenshot gar nicht ausgewertet/uebertragen. Sollte es die UI_Plane1 sein liegt das Problem schwerer. Ich komme aber erst am Wochenende dazu nachzusehen. Welche GCC-Version hast Du unter MinGW bei Dir eigentlich? Beim Kompilieren kamen bei Dir ja Fehler die ich mit der iirc. 4.5.2 nicht nachvollziehen konnte. Niklas
Niklas O. schrieb: > Rainer W. schrieb: >> - Der "Send Measure"-Softkey im Quick-Print Menu ist nur mit "Send" >> beschriftet. Ist das Absicht? Die Funktion finde ich sehr praktisch. Nein, ist auch schon behoben. >> Allerdings macht das Screenshot Programm unter Win direkt einen Abgang, >> wenn man aus Versehen die "Send Measure"-Taste erwischt. (@Niklas?) Ich habe jetzt eine WIN32 .exe compiliert indem ich die Option -Werror rausgenommen habe. Läuft bei mir ohne Probleme. Ich gebe die beim nächsten Download mit. >> Der Fortschrittsbalken beim Screenshot ist super-chic! > > ACK, gut gemacht Hayo ;) Danke :-) > Hayo W. schrieb: >> Wie schon hier angemerkt wurde wird die UI_Plane1 (hellgrau) nicht >> richtig im Screenshotprogramm ausgewertet. Übertragen wird sie auf jeden >> Fall. Ich habe da mal kurz drübergesehen, konnte aber nichts finden. >> >> Hast Du da evtl. eine Idee? > > Meine Vermutung auf die Beobachtung von iirc. Rainer war ja, dass > das in den Memory-Planes gezeichnet wird, und diese werden beim > Farb-Screenshot gar nicht ausgewertet/uebertragen. Das kann ich ich vorab mal checken. > Sollte es die UI_Plane1 sein liegt das Problem schwerer. Ich komme > aber erst am Wochenende dazu nachzusehen. > > Welche GCC-Version hast Du unter MinGW bei Dir eigentlich? Beim > Kompilieren kamen bei Dir ja Fehler die ich mit der iirc. 4.5.2 > nicht nachvollziehen konnte. Keine Ahnung, hab gerade kein Windows laufen, schau ich mal bei Gelegenheit nach Gruß Hayo
Also die Memory Planes werden überhaupt nicht benutzt, ich habe sie daher gelöscht. Der Einzige UI-Layer der einen Buffer benutzt ist der UI-Layer 2 (schwarz). Es liegt also an etwas Anderem. Gruß Hayo
Angehängte Dateien:
-
Testbild.jpeg
46 KB
Ok Fehler gefunden. Ich habe mal ein Testbild generiert und versendet. Man sieht das alle Planes korrekt übertragen werden. Nur im Screenshot-Programm wird die falsche Farbe zugeordnet. Die Buttons haben dann die gleiche Farbe wie die Schrift. Das ist wie ein Eisbär im Schnee. Also muß nur die Farbe in Grau geändert werden und alles ist gut. Ich werde das mal testweise machen. Gruß Hayo
moin Hayo,
> Ich habe mal ein Testbild generiert und versendet.
Wie hast'n das gemacht?
Gruß Michael
Das Testbild könnt Ihr Euch auch ansehen - das erscheint wenn man übers Terminal shift + C eingibt. Danach muß man das DSO aber resetten, da es dann stehenbleibt. Dieses Testbild habe ich dann einfach mal in einer Testversion in den Screenshot mit eingebaut. Man kann auch schön den Pixelfehler in der UI Plane 1 sehen. Gruß Hayo
So es gibt auch eine neue Screenshot Version. Es doch nicht nur die Farbe, ich mußte auch die Layerreihenfolge ändern. Aber jetzt funktioniert es. Daher werden die neuen Versionen (FW + Screenshot) nicht mehr rückwärtskompatibel sein. Dank Niklas schicker Versionsabfrage aber ja kein Problem. Gruß Hayo
@Kurt ich lade gleich hier das neue Major Release hoch. Du solltest Deine Screenshotversion entsprechend anpassen mit der Layerreihenfolge. Ich habe da auf Firmwareseite aber bei Deinen Routinen noch nichts geändert. Ich würde dann die neue Reihenfolge und die Fortschrittsanzeige einbauen wenn Du das möchtest. Gruß Hayo
Ok hier ist es das neue Release. Was ist neu? - redesigned autoscale function with new TB search strategy setup in the autosacle menu. - new double push oprion for autoscale button for slow TB search - new screenshot version with corrected layers - new progress indicator for screenshot and autoscale - added Flat Top window for FFT - new zeroline adjustment - new grid colors which can be set by pushing grid intensity button in display menu For further details please read the changelog and the file Special Functions.txt Gruß Hayo
Noch ein kurzer Hinweis: Da die neuen Menüs Ihre Startwerte aus dem Flash beziehen kann es sein, dass beim ersten Aufruf falsche Werte eingetragen sind. Das erledigt sich nach dem ersten Aufruf der Menüs aber von selbst. Hayo
Hallo, ich habe mit der neuen 1.2.BF.3.0.zip das Problem das Calibrate offsets nicht geht. Identisches Problem wie bei charly hier Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil4)" Ansonzten saubere Arbeit! Gruß Torsten
Hallo Torsten, ich habe mal die neue Firmware auf mein zweites DSO gespielt und kann auch da die Probleme nicht nachvollziehen. Alles funktioniert bestens. Mein Vorschlag zur Vorgehensweise: - Gerät ausschalten und wieder anschalten - ins Utility Menü wechseln - Default Setup - dann das Calibration Set <Standard> explizit auswählen, auch wenn es schon auf dem Button angezeigt wird - Terminal starten damit man die Ausgaben sehen kann - Kalibrieren Die Terminalausgabe in eine Datei kopieren und hier posten. Was mir aber eben bei meinem zweiten DSO aufgefallen ist, das Autoscale Menu für TB Search ist völlig vergurkt und richtet sich auch nicht selbst. Bei meinem ersten DSO ist das nicht so. Wie sieht das bei Euch aus? Gruß Hayo
Hallo Hayo, hab das mal so gemacht wie vorgeschalgen, im Anhang das Log dazu. Den Fehler im TB Search Menu sehe ich allerdings nicht. Gruß Torsten
Hallo Hayo, welchen Sinn hat das umkopieren der UI_Planes in die Buffer_Planes? Es wäre toll wenn du in alle 3 UC_ Funktionen die Fortschrittsanzeige einbauen könntest und auch bei UC_SCREENSHOT die Änderungen bei den Planes. Der B/W Screenshot hat sich Plane mäßig anscheinend nicht geändert. Die Neuerungen beim DUMPCSV brauchst du noch nicht bei mir einbauen, die muss ich mir nochmal genauer ansehen. Auch beim Send Measure werde ich mal sehen müssen on ich das übernehmen kann. Mfg, Kurt
Hayo W. schrieb: > Was mir aber eben bei meinem zweiten DSO aufgefallen ist, das Autoscale > Menu für TB Search ist völlig vergurkt und richtet sich auch nicht > selbst. Bei meinem ersten DSO ist das nicht so. Wie sieht das bei Euch > aus? Hi Hayo, danke für den inflationären Versionssprung. Bei meinem W2024A gibt es nach einem "Default Setup" weder mit "Calibrate Offset" noch mit dem Autoscale "TB Search" Menü irgendetwas zu meckern. Die Lösung mit TB Search auf Trig Source finde ich sehr gut. Bin gespannt, was sich noch alles so getan hat. Gruß Rainer
Hallo Jungs, danke für die Rückmeldung. Bin gerade vom Training und wie so oft vom Griechen zurück. @Torsten Danke für das Log. Ich habe eine Idee wo ich suchen muß. Wenn ich was finde liefere ich schnellstmöglich einen Fix. Stell mal vor dem Kalibrierungslauf den Trigger auf Auto! Wenn es dann funktioniert weiß ich was es ist. Gruß Hayo
Hallo, gerade die v3.0 ins Flash geladen. Sieht gut aus! Was womoeglich auch fuer die anderen relevant sein koennte (obgleich ich da nicht wirklich einen Erklaerung fuer habe): Nach manchen Firmwareupdates habe ich ploetzlich staerkeres Rauschen (ich meine nicht die fiesen Spikes auf 3 und 4) auf den Kanaelen, insbesondere scheint das bei 1 und 2 zu sein, wie es auch gerade wieder passiert ist. Das laesst sich bei mir dann beheben durch Laden eines Komplettdumps vom DSO im Auslieferungszustand von den Wittigs. Danach dann die neue Firmware, Rauschen ist weg. Das Screenshotprogram warnt wegen des unverhofft hohen Versionssprungs zwar, das kann aber getrost ignoriert werden. Rainer W. hatte glaube ich auch noch nach einer Protokollbeschreibung gefragt. Ich werde das in der naechsten Zeit mal im Wiki bei Sourceforge dokumentieren. @Hayo: > [Testbild] > Man kann auch schön den Pixelfehler in der UI Plane 1 sehen. Oeh, Pixelfehler? Apropos, sag mal: Ganz am Anfang hatte ich das ja so gebaut das die Layer einzeln in Dateien abgelegt wurden, so dass man diese dann bei Darstellungsproblemen einzeln untersuchen kann. Das ist dann irgendwann weg gefallen. Macht es Sinn das als Spezialfunktion wieder einzubauen? Ansonsten: Da vor kurzem auch nochmal was wegen ActivePerl hochkam, was viele unter Windows nur wegen der GERMSloader.pl bei sich installiert haben: Besteht Interesse an einem einfachen Flash/RAM-Loader fuer Windows als .EXE? Das liesse sich ohne grossen Aufwand realisieren. Es gab aber auch mal ein Tool fuer Windows mit GUI, was ist eigentlich daraus geworden? Niklas P.S.: Irritiert es egtl. nur mich dass der billig-Tastkopf aus China in Stellung 1:1 eine hoehere Bandbreite hat als die Welecs?
Ab sofort nehme ich die Vorbestellungen für den USB-Host an. Weitere Infos auf http://sourceforge.net/apps/trac/welecw2000a/wiki/Vinculum#Sammelbestellung (Der Rest des Artikels wurde auch aktualisiert, insbesondere die Eagle Dateien!) Bei Fragen oder Anregungen meldet euch bitte hier im Forum oder per mail (SF Adresse). Mfg, Kurt
Hallo! Ich hätte enormes Interesse an der USB Erweiterung! (sorry dass ich so reinplatze, aber ich verfolge die Entwicklung immer mal wieder nebenbei, tausend Dank an alle Beteiligten!) Fragen: - Werden USB-Sticks > 2GB unterstützt (Habe das Problem regelmäßig an mittelalten Teks) - Welche Gehäusemodifikationen muss ich vornehmen? Habe gerade keine Vorstellung, wie die Platine in "echt" da reingehört. Aber ich habe jetzt den HW-Thread auch nur überflogen - steht das irgendwo? Sorry, wenn ich das übersehen habe, ich dachte nur ich melde mich gleich bevor die Dinger weg sind ;) Bzw. - Wenn ich schon "blöd" frag: Vllt. gibt es ja wieder mal "huckepacks" in der nächsten Zeit. Gäbe es vllt. jemanden mit mehr "Fingerspitzengefühl" und "Ästhetik" wie mir, der mir mein 2Kanal Gerät umrüsten würde? Selbstverständlich gegen anständiger Bezahlung. Hab leider keine anonyme E-Mail, aber wer evtl. Zeit für sowas hat kann hier ja eine Möglichkeit der Kontaktaufnahme Posten :) Beste Grüße, Pat
Hi pat, reinplatzen darfst du, ich habe ja ausdrücklich darum gebeten. ;-) pat schrieb: > Werden USB-Sticks > 2GB unterstützt Höchstwahrscheinlich ja, die VNC2 Firmware untestützt auch FAT32. Ich kann es aber noch nicht testen da ich meinen großen Stick irgendwo verbummelt habe. pat schrieb: > Welche Gehäusemodifikationen muss ich vornehmen? Wenn du ein externes 12V Netzteil verwendest, keine. Willst du den USB-Host vom Oszi aus versorgen musst du eine kleine DC-Buchse einbauen und irgendwo an die 12V Leitung löten. pat schrieb: > Habe gerade keine > Vorstellung, wie die Platine in "echt" da reingehört. In ein externes Gehäuse. Siehe o.g. Link (über deinem Post) auf den SF-Artikel. pat schrieb: > Vllt. gibt es ja wieder mal > "huckepacks" in der nächsten Zeit. Wird es definitiv geben. Als Teilesatz von mir, evtl. inkl. Platine. Das muss ich aber noch mit Bernhard klären. pat schrieb: > Hab leider keine anonyme E-Mail, Das ist schlecht. Ich brauche eine mail mit der Vorbestellung von dir, sonst verliere ich den Überblick. Mfg, Kurt
Hi Niklas, Niklas O. schrieb: > Nach manchen Firmwareupdates habe ich ploetzlich staerkeres > Rauschen (ich meine nicht die fiesen Spikes auf 3 und 4) > auf den Kanaelen, insbesondere scheint das bei 1 und 2 zu sein, > wie es auch gerade wieder passiert ist. Das laesst sich bei > mir dann beheben durch Laden eines Komplettdumps vom DSO > im Auslieferungszustand von den Wittigs. Danach dann die > neue Firmware, Rauschen ist weg. Hattest du vor dem Rückspielen der Orig-FW die üblichen "Default Setup" und "Calibrate Offset" einmal durchlaufen lassen? > Rainer W. hatte glaube ich auch noch nach einer Protokollbeschreibung > gefragt. Ich werde das in der naechsten Zeit mal im Wiki bei > Sourceforge dokumentieren. Das wäre prima, eilt aber nicht. Die Quick Measure Ausgabe macht schon wieder Lust auf mehr. Zwei Dinge fallen mir da spontan ein: - Ausgabe mehrerer Messungen in eine Datei mit Time-Stamp, jeweils eine Messung pro Zeile - Automatische Ausgabe bei jedem Trigger -> eine Datei > P.S.: Irritiert es egtl. nur mich dass der billig-Tastkopf > aus China in Stellung 1:1 eine hoehere Bandbreite hat > als die Welecs? Von der 1:1 Messung war ich schwer beeindruckt und habe mich nur gewundert, das die W2022 im Moment in der eBucht ohne Tastköpfe für um die 200 über'n Tisch gehen.
Hi Kurt, auch ich melde hiermit Interesse an. Ich bin zur Zeit nur noch unschlüssig ob ich einen oder zwei haben möchte. Auch ich hatte geplant das Teil ins Gerät einzubauen. Gruß Hayo
Hallo Hayo, hab mal mit der Triggereinstellung etwas herumgespielt, leider ohne Erfolg. Als nächtes spiele ich mal das Orginaldump (wenn ichs noch finde) auf und dann die 3.0. Gruß Torsten
@Hayo, bitte schicke mir eine mail! Mfg, Kurt
Niklas O. schrieb: > Nach manchen Firmwareupdates habe ich ploetzlich staerkeres > Rauschen (ich meine nicht die fiesen Spikes auf 3 und 4) Das liegt daran, dass ich bei manchen FW-Versionen das Flash zurücksetzen muß um neue Variable zu initialisieren. Das betrifft aber nur die Hardwareeinstellungen und die Offsets (ADC + DAC). Dadurch wird dann das Rauschen stärker. Da muß man nur einfach die Hardwareeinstellungen neu machen und einmal kalibrieren - fertig. > @Hayo: >> [Testbild] >> Man kann auch schön den Pixelfehler in der UI Plane 1 sehen. > > Oeh, Pixelfehler? Ja, die UI_Plane1 hat einen Pixelversatz von 32 Pixeln im Videospeicher, die am Ende (rechts) abgeschnitten werden und vorne (links) eingefügt werden. Das sieht man aber nur auf dem DSO, nicht im Screenshot, da im Screensh. die Pixel korrekt wiedergegeben werden. > Apropos, sag mal: Ganz am Anfang hatte ich das ja so gebaut > das die Layer einzeln in Dateien abgelegt wurden, so dass man > diese dann bei Darstellungsproblemen einzeln untersuchen kann. > Das ist dann irgendwann weg gefallen. > > Macht es Sinn das als Spezialfunktion wieder einzubauen? Ja unbedingt. Das war ein Grund, warum ich solange an der BF-Version festgehalten habe. > Ansonsten: Da vor kurzem auch nochmal was wegen ActivePerl hochkam, > was viele unter Windows nur wegen der GERMSloader.pl bei sich > installiert haben: Besteht Interesse an einem einfachen > Flash/RAM-Loader fuer Windows als .EXE? Ach hier ein unbedingtes ja! Denn viele etwas unerfahrene User scheuen sich davor das Perl zu installieren. > P.S.: Irritiert es egtl. nur mich dass der billig-Tastkopf > aus China in Stellung 1:1 eine hoehere Bandbreite hat > als die Welecs? Ich dachte zuerst Du hättest Dich mit der Angabe der Kanäle vertan. Aber dann stimmte das also doch! Strange! Gruß Hayo
Torsten W. schrieb: > Hallo Hayo, > hab mal mit der Triggereinstellung etwas herumgespielt, leider ohne > Erfolg. > Als nächtes spiele ich mal das Orginaldump (wenn ichs noch finde) auf > und dann die 3.0. Warte noch mal. Ich habe gerade die zweite Compilation fertig. Da sollte der Fehler behoben sein, genau wie das Menüproblem im Autoscale-Menü, das aber nur bei 2-Kanalgeräten auftritt! Da habe ich wieder eine Altlast unseres WELEC-Programmierers gefunden die mir bislang nicht aufgefallen war. Gruß Hayo
Kurt Bohnen schrieb: > Hallo Hayo, > welchen Sinn hat das umkopieren der UI_Planes in die Buffer_Planes? Da die Fortschrittsanzeige direkt in den Videospeicher geschrieben wird aber nicht mit übertragen werden soll, kopiere ich den Inhalt des Videospeichers vorher in die Bufferplanes und übertrage dann statt des Videospeichers die Bufferplanes. > Es wäre toll wenn du in alle 3 UC_ Funktionen die Fortschrittsanzeige > einbauen könntest und auch bei UC_SCREENSHOT die Änderungen bei den > Planes. Ich habe die Fortschrittsanzeige nur in die Screenshot-Routinen eingebaut, da die Datentransferroutinen so schnell sind, dass es hier überflüssig ist. > Der B/W Screenshot hat sich Plane mäßig anscheinend nicht geändert. Hatte ich nur vergessen, da ich die B/W Funktion selbst nicht nutze - hab ich aber jetzt nachgerüstet. Gruß Hayo
Second compilation out now! I'm sorry for the bugs I didn't saw in the first comp. In der zweiten Kompilation sollten jetzt alle gemeldeten Fehler beseitigt sein. @Kurt Deine Screenshot-Routinen habe ich auch erweitert. Gruß Hayo
Hi, @Niklas > Das laesst sich bei > mir dann beheben durch Laden eines Komplettdumps vom DSO > im Auslieferungszustand von den Wittigs. Danach dann die > neue Firmware, Rauschen ist weg. Wie weg? Weg ohne Filter? Hattest du die Widerstände (33 Ohm u. 150 Ohm) modifiziert? > Ansonsten: Da vor kurzem auch nochmal was wegen ActivePerl hochkam, > was viele unter Windows nur wegen der GERMSloader.pl bei sich > installiert haben: Besteht Interesse an einem einfachen > Flash/RAM-Loader fuer Windows als .EXE? Das liesse sich ohne > grossen Aufwand realisieren. Ja, immer her damit! Mit dem Germsloader scheint es bei manchen Usern immer noch Probleme zu geben, da wäre das eine gute Alternative! Perl nimmt jede Menge Platz weg und es ist auch ein wenig umstandlich mit der Installation. Gruß Michael
Hallo Hayo, die C2 funktioniert nun auch bei mir bestens. Herzlichen Dank auch! Woran lag es das das gerätespezifisch war? Gruß Torsten
auch hallo Hayo, ...hast du jetzt was am Quickmeasure gedreht? Jetzt habe ich ohne Signal auf Kanal 1 -Pk-Pk 1,04V und auf Kanal 2 sogar Pk-Pk 1,14V ! Wenn man mal schnell was messen will, ist das schon ein bißchen viel, oder? Voher hatte ich so um die 160mV, schwankend...aber über 1Volt, finde ich heavy. Anbei mal ein Shot LG Michael
Angehängte Dateien:
-
Quickm_PeaktoPeak1.14V.png
4,3 KB
...hmm, der wollte nicht mit, jrtzt aber! Eingeschaltet ist der Smooth-Filter
Nein, da war ich nicht dran. Hast Du Dein Gerät hardwaremäßig richtig eingestellt und auch kalibriert? Gruß Hayo
Angehängte Dateien:
-
fw_v3.0_before.png
4,8 KB -
fw_v3.0_after.png
4,8 KB
Hallo, @Michael: > Wie weg? Weg ohne Filter? Hattest du die Widerstände (33 Ohm u. 150 Ohm) > modifiziert? Ich meinte mit "weg" natuerlich das zusaetzliche Rauschen. Die Eingangsstufen sind unmodifiziert. Auch kein Averaging oder Noise Filter eingeschaltet. @Hayo, Rainer: Default-Setup habe ich gemacht. Calibrate Offset benutze ich dauernd da der GND-Level staendig wegdriftet. Ich habe gerade mal gemacht was ich beschrieben habe, das Ergebnis seht ihr in den Screenshots. Der Unterschied ist minimal. Vllt. haengt es auch gar nicht damit zusammen. Ich hatte das vor laengerer Zeit aber schonmal heftiger. Ob ich davor wirklich Firmwareupdate gemacht habe weiss ich nicht mehr. Insgesamt hab' ich die Prozedur auch erst 2-3mal gemacht. Niklas
> Besteht Interesse an einem einfachen > Flash/RAM-Loader fuer Windows als .EXE? Das liesse sich ohne > grossen Aufwand realisieren. Wäre gut. Ich hatte große Schwierigkeiten mit dem GERMSLoader ein Backup der org-Firmware zu erstellen. Die Verbindung brach dabei x-Mal mit Timeout ab. Irgendwann, ich kann nicht mehr nachvollziehen warum, lief es dann aber doch noch durch. Ein Aufspielen der 1.2.BF.3.0 Flash war überhaupt nicht machbar, so ab 7% war immer wieder Schicht. Mir z.Z. unverständlich, die Ram-Version konnte ich aber einwandfrei uploaden und sie funktionierte. Das Skope bootete jetzt aber nicht mehr in die alte Version, ein paar Zeilen waren ja bereits überschrieben. Nichts ging mehr. Nach etlichen weiteren vergeblichen Anläufen mit dem GERMSLoader die Flash-Variante doch noch hochzuladen, probierte ich endlich den WelecUpdater. Dieser spielte, zum Glück, die TomCat.flash ein. Zu evtl. Fehlern in dieser Version kann ich nichts sagen, dazu fehlt mir im Moment noch die Erfahrung mit dem Gerät.
Ich hoffe Du die neue 3.0 C2 eingespielt, da in der ersten Compilation bedauerlicherweise doch noch etliche Zinken drin waren. Gruß Hayo
Hayo W. schrieb: > Ich hoffe Du die neue 3.0 C2 eingespielt, da in der ersten Compilation > bedauerlicherweise doch noch etliche Zinken drin waren. Meinst Du mich damit? Das war nicht die C2, noch die 3.0 von gestern. Niklas
Torsten W. schrieb: > Hallo Hayo, > die C2 funktioniert nun auch bei mir bestens. Herzlichen Dank auch! > Woran lag es das das gerätespezifisch war? Beim Autoscale Menü lag es daran, dass für die 2-Kanalgeräte bestimmte Menüeinträge bei der Initialisierung geändert werden (z.B. werden bei den Sourcen Kanal 3 + 4 gelöscht weil nicht vorhanden). Dabei hat der WELEC-Programmierer aberr nicht aufgepasst und mittels Bufferoverflow Werte in benachbarten Speicherbereichen überschrieben. Bei der Kalibrierung war es nicht geräteabhängig sondern eher zufallsbedingt. Ich hatte bei den Leseroutinen nur einige Kleinigkeiten "optimiert". Da bei mir der Fehler nicht auftrat hab ich natürlich auch nicht weiter gesucht. Durch Deinen Beitrag bin ich aber dann drauf gestoßen, dass ich da einen Fehler eingebaut hatte. Gruß und danke Hayo
Niklas O. schrieb: > Hayo W. schrieb: >> Ich hoffe Du die neue 3.0 C2 eingespielt, da in der ersten Compilation >> bedauerlicherweise doch noch etliche Zinken drin waren. > > Meinst Du mich damit? Das war nicht die C2, noch die 3.0 von gestern. Nein ich meinte stone. Aber auch Dir sowie allen Anderen würde ich empfehlen die C2 zu verwenden und nicht mehr die erste Kompilation. In SFN habe ich die auch schon gelöscht, hier geht das leider nicht. Gruß Hayo
stone schrieb: > Ich hatte große Schwierigkeiten mit dem GERMSLoader ein Backup der > org-Firmware zu erstellen. Die Verbindung brach dabei x-Mal mit Timeout > ab. Irgendwann, ich kann nicht mehr nachvollziehen warum, lief es dann > aber doch noch durch. > [..] > doch noch hochzuladen, probierte ich endlich den WelecUpdater. Dieser > spielte, zum Glück, die TomCat.flash ein. Mhm, was fuer ein Kabel verwendest Du? USB-seriell-Wandler? Klingt fuer mich mehr nach Problem mit Verbindung als dass der GERMSLoader etwas falsch macht. Probier mal nen anderes und kuerzeres Kabel. Den WelecUpdater hab' ich als episch langsam in Erinnerung. Ich weiss nicht was der da veranstaltet, wenn er das aber saulangsam rueberschiebt erklaert das dann vielleicht dass es mit dem bei Dir funktionierte. Niklas
Angehängte Dateien:
-
accu_charge.jpg
52 KB
Aber mal was ganz Anderes. Ich habe um ein neues Akkuladegerät auf korrekte Funktion zu testen mal eine Ladekurve aufgezeichnet. Probant war ein 1,2V Mignon Akku. Man sieht schön die Entladekurve in den ersten drei Divs, dann die Ladekurve und zum Schluß die Erhaltungsladung nach dem Delta U Buckel. Die Spannung die da vom Cursor angezeigt wird stimmt natürlich nicht. Der untere Cursor liegt bei ca. 1V der obere bei ca. 1,6V. Ergebnis Ladegerät funktioniert - und das DSO auch ;-) Gruß Hayo
> Mhm, was fuer ein Kabel verwendest Du? USB-seriell-Wandler? > Klingt fuer mich mehr nach Problem mit Verbindung als dass der > GERMSLoader etwas falsch macht. Probier mal nen anderes und > kuerzeres Kabel. Ist ein normales RS232 Kabel von meinem AVR STK500 Board an einer RS232 Schnittstelle. Damit gab es bisher keine Probleme. Aber das es an dem Kabel liegt ist trotzdem nicht auszuschliessen. Ein Gegentest ist z.Z. nicht möglich da ich leider noch kein andres habe. Mich wundert dann aber warum es mit der .ram ohne Probleme funktioniert. Mit dem Welec-Updater habe ich grad die C2 raufgespielt. Stimmt, es ist damit langsam, hat aber funktioniert. Nur z.Info, die Versuche liefen mit: WinXP Pro SP3 ActivePerl 5.12.3 Build 1204 und Win32-SerialPort-0.22.
@Niklas ich habe mal bei mir das Rauschen analog zu Deinem Screenshot getestet. Nach dem Kalibrieren liegen die Werte im gleichen Rahmen (so um 6mV). Hat also wohl eher nichts mit dem Rückspielen des Flashs zu tun denke ich. Gruß Hayo
Angehängte Dateien:
-
Messung_Ch1_inv.png
4,1 KB -
Pan_Ch1_inv.png
4,1 KB
Hallo Hayo,
mit der aktuelen BF 3.0 C2 bin ich bei der inversen Erfassung mit Kanal
1 auf ein sehr merkwürdiges Feature gestoßen. Zum Vergleich liegt das
selbe Signal am normal dargestellten Ch2.
Am linken Rand taucht ein falscher Wert ("Flanke") auf (Bild:
Messung...) und wenn man auf STOP geht und das Anzeigefenster nach
rechts verschiebt, kommen merkwürdig nach unten versetzte Daten ins Bild
(Bild: Pan_...).
Eingangssignal ist Probe Comp (passiert aber genauso mit anderen
Signalen). Wenn man dagegen Ch2 invertiert, ist alles gut. :-)
Gruß
Rainer
p.s. Die Screenshots wurden mit w2000a-screenshot 0.97 erstellt und
nicht nachbearbeitet - sicher ist sicher. ;-)
Oha, das ist ja merkwürdig. Da muß muß ich wohl mal ran. Danke für den Tip Hayo
Angehängte Dateien:
-
W0000287.png
1,2 KB
@Hayo, denke bitte daran mir die mail wegen dem USB-Host zu schicken. ;-) Ich wollte gerade die neuesten Änderungen in meine Firmware übernehmen. B/W funktioniert aber nicht richtig. Da schon in der UC_SCREENSHOT_BW() die Schwarz/Weiß Werte zusammengebaut werden vermute ich den Fehler dort. Die Gegenprobe mit dem screenshot zum PC scheitert leider daran:
1 | - Receiving a monochrome screenshotError: screenshot data version newer on DSO than known here in receive_screen(), exiting. |
Ok Kurt, ich check das mal. Die Mail kriegst Du morgen. Gruß Hayo
hmpf, > Nein, da war ich nicht dran. Hast Du Dein Gerät hardwaremäßig richtig > eingestellt und auch kalibriert? kennst mich doch, mach das jedes mal, auch resette ich das Teil mehrmals bevor ich pöpel! Wie sieht's denn bei den Anderen so aus? Apropos kalibibrieren, Im Kalibriermenu steht Standart= is' klar, Active Probe= Is' auch klar, Set 3 und 4= is' nicht klar! Sind das die Einstellungen für die 24 u. oder 33 Ohmler? Zum Germsloader über die RS232 Schnittstelle: Ich selbst habe Win XP auf dem Lappi sowie auf dem Hauptrechner Athlon Phanom 9500, SP2(Laptop) SP3 (Athlon) funzt mit der eingebauten RS232 sowie mit dem Adapter(FTDI)! Wichtig sind die Comport-Einstellungen!!! Diese müssen oder sollten immer überprüft werden, d.h. 115kb , Datenbits=8, Parität=non(keine), Händshake(Flussteurung)= none(keine), Stopbit=1 Hat mal ein Gerät darauf zugegriffen, kann es vorkommen, daß der Port nicht, oder noch nicht freigegeben ist, dann zickt das Ganze und man muß den Rechner komplett neu hochfahren!!! Das sind jetzt meine Erfahrungen, die ich hier weiter gebe kann. ...habe bis jetzt jedes Miststück zum laufen gebracht, unter Anderem auch das LEON3 Design! Wie ist denn da eigentlich der Fortschritt? Das was ich bisher aufgespielt hatte, war schon sehr beachtlich, schade, wenn das einschlafen würde... Gruß Michael
Angehängte Dateien:
-
screenshoot1.jpg
41 KB -
screenshoot2.jpg
41 KB
Hi Hayo, Niklas O. and all! I take just peeping through, I am in a hurry, so apologize me. First: @Hayo and all who involved in the Welec project: I installed the new 1.2.BF.3.0_C2 release and I'm trying it. I have few time and I was able to give only a superficial glance, but this new release seem to me very, very impressive!!! Modifications and improvements are so many and such that I make it hard to use the oscilloscope. It is as if I were using a new DSO and I have to read the instruction manual for understand how to use it. Options and settings are significantly increased compared to a few previous versions, have been added feature that I couldnt even imagine could be implemented in the Welec DSO!!! The DSO seem me to be more fast and especially for me now it is less noisy, a lot less noisy!!! Then the calibration is now super precise than ever on mine W2022A and W2012A. For me also the trigger behavior is better now. I repeat, very, very impressive!!! Over the weekend I'll try to find time to do some testing instrument. That said, Hayo and all who involved I thank You very, very much for this new jewel, I have no words, RESPECT, RESPECT, RESPECT!!! Niklas O. schrieb: >Wo Du Tastkoepfe erwaehnst... Wegen eines Analogoszis hab' ich >kuerzlich nen "100 MHz" Tastkopf aus China von Dealextreme bestellt. >Der ist vor ein paar Tagen eingetroffen, und, da ich dem "100 MHz" >Sticker nicht traue und es Angaben bzgl. Anstiegszeig/BW in Stellung >x1 und x10 schlicht nicht gibt, hab' ich diese doch gleich kurz mal >mit den Original Welec "200 MHz" grob am Rechtecksignal des DSO >verglichen. > >Resultat seht ihr in den Screenshots. Kanal 2 ist der 6 USD >(inkl. Versand) Tastkopf. Die Traces sind etwas verschoben, >da ich den Versatz nocht nicht wieder ueber die Delays im >Utility-Menue kompensiert habe. Man sieht's aber auch >"mit blossen Augen" ohne Cursor recht gut ;) About this I tried with the W2012A probe in CH1 and W2022A probe in CH2 of my W2012A (screenshoot 1) and then I exchanged them in the channels (screenshoot 2), both are set x1 so like also the DSO's channels: W2012A's probe win on the W2022A. The square wave is the inner DSO probe calibrator and both probes are correctly matched. I have to investigate further, I have to try with the W2022A. Now I run away. Hayo again many thanks to You and all, really thanks very much to all You!!! Vielen Dank!!! Luc
Angehängte Dateien:
-
BW_Sample_1.jpeg
54 KB -
Invert.jpg
54 KB
Hallo Kurt, hab es schnell noch mal gerichtet. Die UI Planes 3 + 4 dürfen nicht mit übertragen werden, da sie die anderen Planes überdecken. Weiterhin habe ich das Übertragungsprotokoll für B/W an die neueste Version angepasst - sollte also keinen Abbruch mehr geben. Ergebnis der aktuellen Änderungen siehst du auf den Screenshots. Anbei das korrigierte Coding und die Kompilation 3. Gruß Hayo
Hayo W. schrieb: > Oha, das ist ja merkwürdig. > Da muß muß ich wohl mal ran. Vielleicht war das Problem doch vor dem Oszi und du mußt da nicht noch mal ran. Mein letztes "Default Setup" war vor dem Einspielen der 3.0 C2. Nachdem ich das jetzt nachgeholt habe, benimmt sich auch der invertierte Kanal 1 anscheinend richtig. Dafür bin ich drauf gestoßen, dass bei im Single Shot mit Einstellung "Invert" erfaßten Signalen das Invertieren anscheinend auf allen Kanälen ignoriert wird. Beim STOP, wo der gleiche Effekt auftrat, hattest du das ja schon repariert. Gruß Rainer
Hayo W. schrieb: > Ergebnis der aktuellen Änderungen siehst du auf den Screenshots. Anbei > das korrigierte Coding und die Kompilation 3. Super. Danke! Gute Nacht.
Angehängte Dateien:
-
Mess_ch123_inv.png
5,1 KB -
Pan_ch123_inv.png
5,2 KB -
Single_ch123_inv.png
5,2 KB
Moin Hayo, Hayo W. schrieb: > Oha, das ist ja merkwürdig. > Da muß muß ich wohl mal ran. Gestern Abend war es wohl doch schon etwas spät. Langer Rede kurzer Sinn: Der Fehler mit den falsch dargestellten invertierten Daten beim Pan ist doch echt und betrifft alle 4 Kanäle in gleicher Weise, was schon mal beruhigend ist. Reproduzieren läßt sich das (jetzt mit BF 3.0 C3) wie folgt: ProbeComp an Ch1..4 - Default Setup - Autoscale - AutoPreTrigger "Trace Middle" - Invert Ch1..3 (Bild Mess...) - STOP - Pan nach links oder rechts (Bild Pan...) bringt dann falsche Daten zur Anzeige. Das Ding mit der normalen Darstellung eines invertierten Kanals beim Single Shot sieht man ebenfalls mit obigen Einstellungen. (Bild Single...) Für die ScreenShots habe ich Ch4 als Referenz nicht invertiert, der Effekt tritt dort aber genauso auf. Gruß Rainer
Hallo Rainer, das Problem sitzt nicht vor dem Gerät. Es ist tatsächlich ein Fehler, den ich auch schon gefunden habe. Auch die Lösung habe ich mir schon überlegt. Leider ist es ein grundsätzliches Problem und die Lösung erfordert einen etwas größeren Umbau. Bin ich aber dran... Gruß Hayo
@Michael
> man muß den Rechner komplett neu hochfahren!!!
Das kann es sein!
Ich hatte nur die Schnittstelle im Gerätemanger ausgetragen und dann
neue Hardware suchen lassen. Auf die Parameter habe ich geachtet.
Ich reiche mal den Fix für den Invertion Bug nach. Es gibt da zwei Lösungsansätze. Zum Einen die einfache Lösung die Performance kostet aber gut und problemlos funktioniert, zum Anderen die aufwändige und auch fehlerträchtigere Variante die aber deutlich performanter ist. Ich habe erstmal die langsamere Lösung eingebaut um auf die Schnelle eine fehlerfreie Lösung biten zu können. An der Optimierung arbeite ich dann in der nächsten Zeit. Gruß Hayo
Angehängte Dateien:
-
Inv_C4fix.png
3,9 KB
Hayo W. schrieb: > Ich reiche mal den Fix für den Invertion Bug nach. Das ging ja fix mit dem Fix. Wenn du an der optimierten Lösung arbeitest, hast du dann ein Auge auf das letzte Byte am Ende vom Speicher, dass im Moment bei invertierten Kanälen im Display als unschöner Spike erscheint, wenn man das Fenster ganz nach rechts schiebt. (Ch1 im Anhang) In den CSV-Daten konnte ich mir das nicht ansehen, weil die letzte w2000a-screenshot 0.97 beim Drücken von "Save CSV" oder "Save ASCII" die Zusammenarbteit mit dem Argument: " - Receiving trace... * Receiving parameters...Error: trace parameter format newer on DSO than known here in receive_trace(), exiting." verweigert. Und noch etwas (wahrscheinlich aber bekannt): Die großen Spikes auf Ch3/4 scheinen immer synchron zu kommen. Schönes Wochenende Gruß Rainer
Hallo Rainer, > In den CSV-Daten konnte ich mir das nicht ansehen, weil die letzte > w2000a-screenshot 0.97 beim Drücken von "Save CSV" oder "Save ASCII" die > Zusammenarbteit mit dem Argument: > > " - Receiving trace... > * Receiving parameters...Error: trace parameter format newer on DSO > than known here in receive_trace(), exiting." > > verweigert. die Header-Groesse die das DSO dem Programm uebermittelt ist um ein Byte zu klein. Als Version liest es jetzt den Index des Pretriggers. Wie das jetzt zustande kam weiss ich nicht. Ob mein letzter Patch gg. Firmware von mittlerweile anno dazumal, versionsgeschichtlich gesesehen, schon den Fehler hatte oder zwischendurch noch was geaendert wurde weiss ich nicht, ist aber auch egal. Workaround, ohne Firmware neu zu kompilieren, waere nen para_len++; in receive_trace() vom Screenshotprogramm vor dem malloc(). Niklas
Was war eigentlich der letzte Stand bezüglich des DAC LTC2602? Wird der jetzt korrekt unterstützt, auch auf Kanal 3+4? Die Nulllinien kleben bei mir immer am oberen, manchmal auch am unteren Rand. Kanal 1+2 sind OK.
Kurt Bohnen schrieb: > Was war eigentlich der letzte Stand bezüglich des DAC LTC2602? Wird der > jetzt korrekt unterstützt, auch auf Kanal 3+4? Wird komplett unterstützt, automatisch! > Die Nulllinien kleben bei mir immer am oberen, manchmal auch am unteren > Rand. Kanal 1+2 sind OK. Dann ist beim Einlöten was schiefgelaufen. Hayo
Hayo W. schrieb: > Dann ist beim Einlöten was schiefgelaufen. Stimmt. Ein Pad hatte kein Zinn angenommen. Ich hätte nicht nur per Lupe, sondern auch per Mikroskop kontrollieren sollen. Dafür habe ich aber die alten LTC2612 nicht so bestialisch geschlachtet wie du. ;-)
Niklas O. schrieb: > Workaround, ohne Firmware neu zu kompilieren, waere nen > para_len++; in receive_trace() vom Screenshotprogramm vor > dem malloc(). Danke für den Tip. Das läßt sich vielleicht hinkriegen. Wahrscheinlich ist Hayo mit dem nächsten Update aber wieder schneller. ;-) Rainer
Kurt Bohnen schrieb: > Dafür habe ich aber die alten LTC2612 nicht so bestialisch geschlachtet > wie du. ;-) Na prima, was machst Du jetzt damit? Klebst Du Ihn in einen Bilderrahmen und hängst eine Lupe daneben damit man ihn sich ansehen kann? ;-) Übrigens gehe ich immer nach dem Motto vor: Für eine gute Sache muß man auch mal Opfer bringen! Den zweiten hab ich übrigens heil raus gekriegt, aber was ich damit machen soll weiß ich auch nicht... Gruß Hayo
Rainer W. schrieb: > Danke für den Tip. Das läßt sich vielleicht hinkriegen. Wahrscheinlich > ist Hayo mit dem nächsten Update aber wieder schneller. ;-) Ich arbeite dran :-) Hayo
Angehängte Dateien:
-
80MHz.jpg
49 KB -
25MHz.jpg
64 KB -
12_5MHz.jpg
71 KB
Gute Sonntag Hayo and guys all! @Hayo and all who involved in the Welec project: I installed the new 1.2.BF.3.0_C4 release and I played with it. For the way I use the DSO I have not found defects, the new 1.2.BF.3.0_C4's release works like a charm. It is fast, stable and for me it is also a lot less noisy and much more precise. Even AUTO SCALE works well, but I must point out something perhaps already You know. As usual, I specify that this report is not intended as a critique of the good work You Hayo and all who involved in the project have done, but only like a remark. In most cases the AUTO SCALE works very well, quickly and accurately, but the signals in a particular range of frequencies are displayed incorrectly. I tried with my RF sine wave generator and for example with 80MHz, 25MHz and 12.5 MHz frequency's signals I got the screenshots You can see. This actually is not much of a problem, You can fix it by manually adjusting. I must stress that AUTO SCALE's function in previous releases never worked so well, so even like it is now it still a huge leap forward from the original Welec/Wittig's implementation! So Hayo and all who involved I thank You a lot for this new bug fix release that make me happy in the DSO usage, again I have no words, RESPECT, RESPECT, RESPECT!!! Good also for Grid Intensity / Grid Color and Quick Print menu. Very well and much impressive the Auto Pretrigger / Pre Trigger Setup and Manual Trigger / Single Trigger Setup menu where settings's number and improvements are so many and such that them are not commonly available even in high-end DSO! In the end just one last thing, I did not understand how use the "Send Measure" button, how it work? Vielen Dank!!! Gruß Luc
Wie versprochen, Pixelfehler bei Invertion behoben, .csv funktioniert auch wieder. @Luc Thanks for Your detailed report. I will check it! >In the end just one last thing, I did not understand how use the "Send >Measure" button, how it work? When using the Cursor or Quick Measure function there are displayed additional values on the screen. These values are sent to a file if You push the Send Measure button. This is working only with activated cursors! Gruß Hayo
Hi Hayo, die inversen Signale sehen ja jetzt aus wie eine eins. Da habe ich mit meiner Bemerkung doch deinen Ehrgeiz geweckt. Die Bemerkung war aber nicht als Aufforderung gemeint, jetzt sofort den Compiler anzuschmeißen. Ich hoffe, du hast das nicht falsch verstanden. Vielen Danke Gruß Rainer
Nein nein, Du muß jetzt kein schlechtes Gewissen haben. Aber so ein Fehler in der Firmware ist wie ein unausgedrückter Pickel. Irdendwie muß man da ran und das beseitigen ;-) Davür gebe ich mir jetzt auch die Badewanne - verdienterweise. Gruß Hayo
seht ihr irgendwie eine Möglichkeit den Spannungsabfall an einem Shunt über 2 Kanäle zu messen (also Kanal 1 vor dem Shunt und Kanal 2 nach dem Shunt) und am Oszi dann eine Stromkurve anzuzeigen?
Angehängte Dateien:
-
NORMAL.jpg
41 KB -
INV.jpg
44 KB
Guten Abend Hayo and guys all! Hayo W. schrieb: >Wie versprochen, > >Pixelfehler bei Invertion behoben, .csv funktioniert auch wieder. Hayo, super danke für blitzschnelle Updates!!! Klasse!!! Hayo You really are tireless and very kind, so thanks You very, very much Hayo for the great job and free time You provided generously to us!!! I immediately installed the newest 1.2.BF.3.0_C5 version. For me the problem with the INVerted channels is solved, thank You, really thank You very much Hayo!!! RESPECT!!! However, at the risk of appearing rude, I would like to point out one thing. I do not know if it also happened with previous versions, I do not even know if it happens only with my DSO. But I have noticed that when I activate the INV's function then the tracks suffer from a certain offset, especially in my case the CH2. Please look at the screenshot. The two images refer to the CH1 and the CH2 shorted to GND. The NORMAL image shows the tracks that are superimposed on the zero line. The INV image shows the tracks set to INVerted mode that are not on the zero line, especially the CH2's track even if also CH1's track is a little bit raised by the zero line. The oscilloscope was switched on for about 2 hours and it had reached thermal equilibrium when I made the two screenshots As usual this my report is not intended as a critique but only like a remark. @Hayo, @Niklas O. Hayo, really thank You very much for your kind explanation about the "Send Measure" function. Now I understand and I must to say it is a very usefull function. Of course I also thank Niklas O. for it because if I am not wrong, He has suggested it. So, Niklas O. RESPECT! Vielen Dank!!! Gruß Luc
bin jetzt heute erst dazu gekommen habe jetzt die 3.0_C5 drauf, die Fortschrittsanzeige ist echt klasse. Bin auch der Meinung das die Anzeige noch einen Tick schneller geworden ist. Mir ist noch ein Fehler aufgefallen, kurze Beschreibung: Ich habe im Singlemodus auf die ansteigende Flanke getriggert, Pretrigger ist egal hatte verschiedenen Werte zw. 200 nSek und 4µSek(Standart) ausprobiert. Alle paar Messungen hat man diese negativen Spikes auf Kanal 1. Auf dem nicht mal ein Tastkopf angeklemmt war. Zu der Übertragung der BMP. Ich finde die Dateigröße sehr groß also ich habe es gerade als PNG umgewandelt aber als BMP ist die 640x480 Pixel Datei 901kb groß. Kann man hier die Farbtiefe begrenzen? Denke 4 Bit wäre doch absolut ausreichend. Dann habe ich noch einen Wunsch bezüglich des Screenshot Programms. Ich fände es gut wenn man die Übertragenen Dateien in einen festgelegten Ordner speichern könnte. Im Moment ist es ja so ich lade mir eine neue Firmware runter entpacke sie und es wird ein neues Verzeichnis erstellt, wenn ich jetzt die dazugehörige Screenshot.exe aus diesem Verzeichnis starte landet das Bild in diesem Verzeichnis. Beim nächsten Firmwareupdate dann wieder in einem anderen Verzeichnis. Vielleicht könnte man das Programm so gestalten das es eine Systemvariable durchsucht und sich dort ein festgelegtes Verzeichnis ausliest. Mit Systemvariable meine ich z.B. die Festlegung wie temp=C:\TEMP tmp=C:\TEMP SCREENSHOT=C:\Eigene Dateien\Thomas\Bilder\Screenshot so wäre es egal aus welchem Verzeichnis ich die Screenshot.exe aufrufe oder welche Version sie hat, die Shots landen immer im vorgegebenen Verzeichnis.
Thomas O. schrieb: > Firmwareupdate dann wieder in einem anderen Verzeichnis. Vielleicht > könnte man das Programm so gestalten das es eine Systemvariable > durchsucht und sich dort ein festgelegtes Verzeichnis ausliest. Hi Thomas, mit der -f option geht das Abspeichern von Screenshot in einem festen Verzeichnis auch ohne Systemvariable. Beispiel für den Aufruf, um unter Windows die Dateien in C:\bilder abzuspeichern, wäre z.B. w2000a-screenshot.exe -a -f c:\bilder\ Gruß Rainer
Hello, Luc schrieb: > About this I tried with the W2012A probe in CH1 and W2022A probe in CH2 > of my W2012A (screenshoot 1) and then I exchanged them in the channels > (screenshoot 2), both are set x1 so like also the DSO's channels: > W2012A's probe win on the W2022A. > The square wave is the inner DSO probe calibrator and both probes are > correctly matched. This is especially strange because according to the specs that came with the Welec probes, the 100 MHz and 200 MHz versions should both have the same rise time/bandwidth on 1:1. The 200 MHz probe seems to perform poorly. I don't have the means to fuly measure the 1:10 bandwith, but I strongly suspect it isn't quite 200 MHz as advertised. I don't have the Welec probes spec sheet at hand at this moment, I will have to scan and upload it at a later time. Niklas
Hallo, Thomas O. schrieb: > Zu der Übertragung der BMP. Ich finde die Dateigröße sehr groß also ich > habe es gerade als PNG umgewandelt aber als BMP ist die 640x480 Pixel > Datei 901kb groß. Kann man hier die Farbtiefe begrenzen? Denke 4 Bit > wäre doch absolut ausreichend. Ja, 4 Bit mit Palette waere ausreichend. Der Grund, warum das Screenshot-Programm aus den proprietaer RLE komprimierten Daten, die das DSO sendet, ueberhaupt BMP macht, statt das fuer diese Anwendung praedestinierte PNG-Format, ist allein, dass dies der einfachste Weg ist. BMP, PPM und so weiter sind sehr einfach ohne Hinzunahme von externen Libraries usw. zu schreiben. Ich hab' mir nicht angesehen, in welcher Groessenordnung es Aufwand waere 4-bittige BMPs zu schreiben, dennoch halte ich das fuer einen Schritt zu kurz. Die Dateien waeren immer noch 150kB gross, satte 145kB groesser als noetig. Wenn, dann sollten wir eine Loesung ueber externe passend lizensierte Libraries suchen und konsequent PNG schreiben. > Dann habe ich noch einen Wunsch bezüglich des Screenshot Programms. Ich > fände es gut wenn man die Übertragenen Dateien in einen festgelegten > Ordner speichern könnte. [..] Wie Rainer auch schon schreibt gibt es genau dafuer den Schalter -f. > Mit Systemvariable meine ich z.B. die Festlegung wie > temp=C:\TEMP > tmp=C:\TEMP > SCREENSHOT=C:\Eigene Dateien\Thomas\Bilder\Screenshot Systemvariablen, wie geht man da unter Windows eigentlich mit um? Soweit ich weiss muss man da unter Windows auf "My Computer" rechts klicken, dann "Properties", dann im neuen Fenster auf den Reiter "Advanced" wechseln, dort dann "Environment Variables" anklicken und im neuen Fenster kann man dann endlich den Kram setzen. Was ich sagen will: Zu kompliziert. Angesichts dessen, dass ich, wie schonmal angedeutet, in Zukunft plane, auch eine Konfigurationsdatei zu benutzen, suche ich noch nach ner Moeglichkeit den Standort dieser irgendwie global festzulegen. Unter unixoiden Betriebssystemen ist btw. systemweit /etc und per-User in Dotfile unter ~/ bzw. in ~/.config/ Standard. Vorschlaege? Niklas
Luc schrieb: > I do not know if it also happened with previous versions, I do not even > know if it happens only with my DSO. > But I have noticed that when I activate the INV's function then the > tracks suffer from a certain offset, especially in my case the CH2. Hi Luc, the offset of inverted signals is not specific to your DSO. To me it looks like a gain error. The offset depends on the position of the trace. Traces at the top don't show any offset, those at the bottom do. I am confident Hayo will catch it. Gruß Rainer
Niklas O. schrieb: > Was ich sagen will: Zu kompliziert. Angesichts dessen, dass > ich, wie schonmal angedeutet, in Zukunft plane, auch eine > Konfigurationsdatei zu benutzen, suche ich noch nach ner Moeglichkeit > den Standort dieser irgendwie global festzulegen. Unter > unixoiden Betriebssystemen ist btw. systemweit /etc und per-User > in Dotfile unter ~/ bzw. in ~/.config/ Standard. Hi Niklas, unter Windows gibt es z.B. die vordefinierte Environmentvariable "APPDATA" die auf das Verzeichnis "Anwendungsdaten" des Benutzers zeigt. Mit C kommt man an den Pfad vermutlich über Aufruf von getenv("APPDATA") dran. Die Alternative wäre ein Eintrag in der Registrierdatenbank. Gruß Rainer
Hi Niklas O., Rainer W. and guys all! Niklas O. schrieb: >This is especially strange because according to the >specs that came with the Welec probes, the 100 MHz and 200 MHz >versions should both have the same rise time/bandwidth on >1:1. The 200 MHz probe seems to perform poorly. I don't >have the means to fuly measure the 1:10 bandwith, but I strongly >suspect it isn't quite 200 MHz as advertised. In the parallel to the 1Mohm oscilloscope input impedance there are for example, 30pF (the value is written on the oscilloscope) and even in parallel you still have the capacitive value of the cable (such as another hundred of pF). Do not put any attenuation, this total capacitive value will in parallel with the voltage to be measured. To reduce the capacitive load (cable + oscope), the first thing you can think is to put an R in series, for example a 9Mohm, so the measured circuit sees a more high impedance and the signal is divided by 10. But this only works in DC. In AC, the two R and two capacitors form a low pass filter that cuts to about 1.4 Mhz. To extend the system bandwidth (ie to put on the oscilloscope a tension that is 1/10 of what is measured with the probe even at high frequency) it must be put in parallel to the 9Mohm R a capacitor of 130 pF divided by the ratio of resistors (9 in this case). In this way a capacitor of about 15pF removes the low-pass effect and the probe can work until at frequencies far greater (about hundreds of megahertz). The 9Mohm R and the compensation capacitor are in the probe. To fix the exact capacitive ratio's values (which must be equal to that of the resistors), need somewhere to put a small variable capacitor with which to calibrate the tolerances that may to exist. If instead of divide by 10 should be divided by 100, the values become 99Mohm and 1.5 pF: this explains why often the probes that go (were) to more high frequency had an attenuation of 100:1 and so why the x1 probes have a frequency response limited compared to the x10 probes. Said that, perhaps the behavior of the W2022A probes is caused from an incorrect setting of the second trimmer. In fact, according to the instructions of my analog oscilloscope probes (they are x10 probes with a 300Mhz bandwidth), they must be tuned by a 1Khz and 1Mhz square wave with not more than 4ns's rise time. In my case the problem may depend on this but I must investigate further. I will try to use the W2022A probes that are credited as 200Mhz bandwidth on my 150Mhz analog oscilloscope who is provided with 300Mhz probes and which has a suitable calibrator for calibration. However, the probes provided by Welec / Wittig with the W2012A are the same as those provided by LeCroy with its WaveAce series DSO. I'm sure because I use them where I work. Niklas O. schrieb: >I don't have the Welec probes spec sheet at hand at this moment, >I will have to scan and upload it at a later time. Me too I have not the data sheet handy. I think it would be useful and interesting. Thanks in advance Niklas O. Rainer W. schrieb: >the offset of inverted signals is not specific to your DSO. To me it >looks like a gain error. The offset depends on the position of the >trace. Traces at the top don't show any offset, those at the bottom do. >I am confident Hayo will catch it. Thank You very much for the useful information and explanation Rainer W.! I hope someone can fix the problem. Vielen Dank!!! Gruß Luc
Hello Luc, the entire "operator's manual" for the probes is attached. According to it, the rise time on x1 should be 23.3ns for both types of probes. > Said that, perhaps the behavior of the W2022A probes is caused from an > incorrect setting of the second trimmer. Since there's no description how to use those I never touched them. (I've got two seperate ones in the box near the BNC.) The attached manual contradicts itself, it mentions that the input capacitance can be compensated "Within the box cover located near the BNC (W202 Probe)", but on the next page under "Compensation and Adjusting the Probe" it explicitly tells to compensate with the trimmer on the body of the probe. It fails to mention that the probe needs to be put into 1:10 divider. Niklas
Hi Luc, the INV-offset is the result of the combination of the DAC-scale factor and screen drawing scale factor. It has to be adjusted more precisely. But this is not so easy because of thermal drift and differences between the DSOs. If You want to measure precisely You have to center the trace in the screen middle. In this positon there are no offsets because it is the virtual zero. Regards Hayo
@Niklas Ich hätte noch mal einen Wunsch bzw. Vorschlag zum Screenshot: Bei der Aufnahme meiner Akku-Ladekurve hätte ich mir gerne die aufgezeichneten USTB-Werte runtergeladen. Das ist aber momentan nicht implementiert. Im USTB-Modus liegen die Werte nicht im normalen Signalspeicher, sondern in einem separaten USTB-Speicher. Es sind 600 Werte (Bytes), also eine recht schnelle Sache. Man müßte nur das Flag mit if (USTB_Mode != USTB_OFF) abfragen und dann anstatt des normalen Signalspeichers den USTB-Speicher übertragen. Die übertragene Länge wird jetzt ja schon zwischen 4K und 16K unterschieden. Käme noch 600 hinzu. Was sagst Du? Gruß Hayo
Hallo Hayo, Hayo W. schrieb: > Ich hätte noch mal einen Wunsch bzw. Vorschlag zum Screenshot: > > Bei der Aufnahme meiner Akku-Ladekurve hätte ich mir gerne die > aufgezeichneten USTB-Werte runtergeladen. Das ist aber momentan nicht > implementiert. > > Im USTB-Modus liegen die Werte nicht im normalen Signalspeicher, sondern > in einem separaten USTB-Speicher. Es sind 600 Werte (Bytes), also eine > recht schnelle Sache. > [..] > Was sagst Du? Ja, das werde ich einbauen. Bei USTB-Sachen waere vllt. auch die Aufnahme ueber noch laengere Zeitraeume interessant, also sowas was ein Trace Recorder macht. Es gibt da z.B. Leute die ueber Tage hinweg Daten von einer Heizungsregelung loggen. Bei einem 4-Kanal Geraet kann das durchaus schon interessant sein. Ich hab' noch nicht auf unserem DSO mit der USTB gearbeitet, ich nehme an die 600 Werte sind im Moment zugleich das Maximum was gespeichert werden kann (Hartverdrahtet im FPGA), danach wird dies durch neue Werte ueberschrieben? Hier koennte man zum einen die Werte direkt "Realtime" mit dem Screenshot-Programm aufzeichnen lassen, zum anderen muesste doch auch die Moeglichkeit bestehen, da die Werte bei langen Aufzeichnungen im Flash abzulegen und am Ende abzurufen? Mein Plan sieht nun wie folgt aus: - zunaechst Flash-Upload-Programm fuer Windows erstellen mit minimaler GUI (File-Open Dialoge usw.), erst einmal wirklich nur Upload-Funktion, kann dann spaeter um Download/Backup-Funktionen erweitert werden - im Screenshot-Programm: - kontinuierliches Loggen von den Measurement-Daten - USTB-Speicher download - Evaluation bzgl. direktes Speichern als PNG - Dokumentation Uebertragungs-Protokolle (in absteigender Prioritaet) Niklas
Niklas O. schrieb: > zunaechst Flash-Upload-Programm fuer Windows erstellen mit > minimaler GUI (File-Open Dialoge usw.), erst einmal wirklich > nur Upload-Funktion, kann dann spaeter um Download/Backup-Funktionen > erweitert werden Warum war der Welec Updater so langsam, kann man den nicht beschleunigen? Niklas O. schrieb: > - Evaluation bzgl. direktes Speichern als PNG Auch BMPs haben eine Lauflängenkodierung. Die funktioniert nur nicht bei BottomUp-BMPs. Das sollte aber für den PC-screenshot kein Problem sein.
ja wenn die Konfigurationsdatei global festgelegt wird wäre das super. Sonst muss man immer die config.ini vom alten ins neue Screenshot-Verzeichniss verschieben oder die Screenshot.bat jedesmal um das eigene Verzeichniss ergänzen. Es wäre wünschenswert diese Globale festlegung ändern zu können da nicht jeder mit den Standart APPDATA Verzeichnissen arbeiten. Meine Eigenen Dateien sitzen z.B. auf einem 2ten Laufwerk.
Niklas O. schrieb: > - Evaluation bzgl. direktes Speichern als PNG Kennst du das Netpbm Toolkit? Möglicherweise sind die im PnmToPng Konverter (Umwandlung PPM in PNG) genutzen Bibliotheken auch hilfreich, um direkt die PNGs abzuspeichern. http://netpbm.sourceforge.net/ Gruß Rainer
Kurt Bohnen schrieb: > Niklas O. schrieb: >> zunaechst Flash-Upload-Programm fuer Windows erstellen mit >> minimaler GUI (File-Open Dialoge usw.), erst einmal wirklich >> nur Upload-Funktion, kann dann spaeter um Download/Backup-Funktionen >> erweitert werden > Warum war der Welec Updater so langsam, kann man den nicht > beschleunigen? Wir sprechen doch von dem Ding der Wittigs, oder? http://sourceforge.net/apps/trac/welecw2000a/wiki/FWupload Da steht auch was von 25 Minuten. Ich hab' das Wittig-Ding zuletzt Anfang 2009 oder so gearbeitet, also kurz nachdem ich mein Scope bekam. Haben wir davon ueberhaupt den Sourcecode? > Niklas O. schrieb: >> - Evaluation bzgl. direktes Speichern als PNG > Auch BMPs haben eine Lauflängenkodierung. Die funktioniert nur nicht bei > BottomUp-BMPs. Das sollte aber für den PC-screenshot kein Problem sein. Ja, das habe ich mir auch noch nicht angesehen. Ich weiss nicht, wie effizient die wirklich ist. Ein kurzer Versuch in Gimp mit Reduzierung auf 16 Farben Palette und RLE zugeschaltet bringt mir ein File mit 36kB Groesse. Ob das noch mit zu rechtfertigem Aufwand zu Fuss gemacht werden kann, oder man da besser eine externe Library nimmt, muss ich schauen. Notieren wir also mal "Evaluation BMP mit optimierter Palette u. RLE" in meine ToDo-Liste. Niklas
Thomas O. schrieb: > ja wenn die Konfigurationsdatei global festgelegt wird wäre das super. > Sonst muss man immer die config.ini vom alten ins neue > Screenshot-Verzeichniss verschieben Hi Thomas man kann doch einfach eine Batch-Datei irgendwo ablegen, in der eine einzige Zeile mit dem aktuellen Screenshot Programmverzeichnis und dem Bilderverzeichnis drinstehen, ohne irgendetwas zu verschieben und zu kopieren, z.B. "C:\Programme\Screenshot-0.97\w2000a-screenshot.exe" -a -f C:\Bilder\ IMO ist man damit flexibler, da man sich für jeden Zweck eine passende Start-Datei zurechtlegen kann.
Rainer W. schrieb: > Niklas O. schrieb: >> - Evaluation bzgl. direktes Speichern als PNG > Kennst du das Netpbm Toolkit? Möglicherweise sind die im PnmToPng > Konverter (Umwandlung PPM in PNG) genutzen Bibliotheken auch hilfreich, > um direkt die PNGs abzuspeichern. > http://netpbm.sourceforge.net/ Ja, kenne ich (hab' ich glaub' ich auch in der README.txt empfohlen zur Konvertierung ;)), jedoch bislang nur mit den Kommandozeilen-Tools gearbeitet. Niklas
im Moment sieht es bei mir z.B. so aus E:\Treiber\Welec\1.2.BF.3.0_C5\Screenshot_0.97 davor war es E:\Treiber\Welec\1.2.BF.3.0_C2\Screenshot_0.97 und da man ja immer die neueste/dazugehörige Screenshot.exe nutzen will startet man die Scrennshot.exe aus dem neuerem Verzeichniss. Oder evtl. wirds ja mal E:\Treiber\Welec\1.2.BF.3.0_C6\Screenshot_0.98 und dann darf man jedesmal die .bat Datei anpassen. Deswegen würde ich mir wünschen das jede zukünftige Screenshot.exe sich am gleichem Punkt im System die gewünschten Einstellungen holt. Hat nichts mit faul zu tun sondern eher mit Comfort das man nicht immer alles anpassen muss. Was sagen denn die anderen dazu, vielleicht gibt es ja bessere Vorschläge das ganze zu lösen.
Mein Ansatz war, die aufrufende(n) Batch-Datei(en) an einem festen Ort stehen zu haben, so dass man bei irgendwelchen Updates mit dem Verzeichnis der neuen Version gar nicht weiter in Berührung kommt, sondern nur einmal den Programmpfad in der Batch-Datei anpassen muß. Wenn das Bilderverzeichnis an einer festen Stelle im System liegt, verbaut man sich den Weg zu projektbezogenen Speicherorten und ist dann bei jedem Screenshot am rumschieben. Es ist halt die Frage, ob man öfter Screenshots macht oder öfter Updates vom Programm einspielt. Gruß Rainer
Hallo zusammen, wie wäre es denn, das Screenshot-Programm zuerst nach einer ini-Datei z.B. in "Eigene Dateien" (bzw. $HOME) suchen zu lassen und die Parameter dahin zu verlegen. Wenn es da keine passende ini-Datei gibt, sucht man noch im lokalen Verzeichnis (des Programms) und Vorrang haben immer die mitgegebenen Parameter. Damit kann man z.B. die exe auch per Doppelklick aufrufen und die Einstellungen bleiben unabhängig von der Version gleich. Viele Grüße, Rainer
Niklas O. schrieb: > Wir sprechen doch von dem Ding der Wittigs, oder? > > http://sourceforge.net/apps/trac/welecw2000a/wiki/FWupload Die Wittig Software lief über USB. Unser Welec Updater aber über RS-232. Sourcecode haben wir auch: http://sourceforge.net/apps/trac/welecw2000a/browser/pc/WelecUpdater
Hallo, (sitz' im Zug und habe keine Zugangsdaten, daher Post als Gast) Kurt Bohnen schrieb: > Niklas O. schrieb: >> Wir sprechen doch von dem Ding der Wittigs, oder? >> >> http://sourceforge.net/apps/trac/welecw2000a/wiki/FWupload > > Die Wittig Software lief über USB. Unser Welec Updater aber über RS-232. > Sourcecode haben wir auch: > http://sourceforge.net/apps/trac/welecw2000a/brows... Okay. Da gibt's dann das Problem dass ich weder Pascal beherrsche noch die Entwicklungsumgebung dafuer habe. Wie sieht es jetzt aus? Reicht uns das Programm, moechte vllt. jemand anderes sich dem annehmen der entsprechende Moeglichkeiten besitzt, oder soll dennoch ein weiteres Upload-Programm her? Niklas
Niklas O. schrieb: > Hallo Hayo, > Ja, das werde ich einbauen. Bei USTB-Sachen waere vllt. auch die > Aufnahme ueber noch laengere Zeitraeume interessant, also sowas > was ein Trace Recorder macht. Ja das ist machbar. > Ich hab' noch nicht auf unserem DSO mit der USTB gearbeitet, ich nehme > an die 600 Werte sind im Moment zugleich das Maximum was gespeichert > werden kann (Hartverdrahtet im FPGA), danach wird dies durch neue > Werte ueberschrieben? Nein, es ist nicht das Maximum und auch nicht hart verdrahtet. Die USTB-Funktion ist ja eine reine Softwarefunktion die ich nachgerüstet habe. Zur Zeit steht ein 1200 Byte Buffer pro Kanal zur Verfügung von dem aber nur 600 Byte genutzt werden. Ich könnte aber auch deutlich mehr zur Verfügung stellen. Ich hatte auch schon überlegt ob es Sinn macht dass man durch den Speicher scrollen kann (so wie in den normalen TB) > Hier koennte man zum einen die Werte direkt "Realtime" mit dem > Screenshot-Programm aufzeichnen lassen, Ja, ist auch eine Möglichkeit, jeden Abtastwert einzeln zu übertragen um eine Langzeitmessung zu realisieren. > zum anderen muesste doch > auch die Moeglichkeit bestehen, da die Werte bei langen Aufzeichnungen > im Flash abzulegen und am Ende abzurufen? Ebenfalls eine Möglichkeit... Platz ist im Flash noch genügend vorhanden! Gruß Hayo
Hi Niklas O., Rainer W., Hayo and guys all! Niklas O. schrieb: >the entire "operator's manual" for the probes is attached. Thank You Niklas O., at this time my DSO packaging is not handy. The document is very interesting. Niklas O. schrieb: >According to it, the rise time on x1 should be 23.3ns for >both types of probes. I had forgotten these values. 23.3nS means something like a 15MHz bandwidth, seem to me quite optimistic. Even more curious the x10 values where the bandwidth is precisely 100MHz and 200MHz just like the W2012A and W2022A to which the probes are provided with. For the W201 I'm sure it is very similar or the same Chinese manufactured probe supplied by LeCroy DSO with its WaveAve 224 model DSO. The model provided by LeCroy is called PP016 and it is claimed as a 300MHz probe. The only visual difference between the W201 and PP016 is a sticker label on the latter where it says the 300MHz bandwidth. The PP016 is not a good probe, it is quite fragile, often it breaks even though it is always handled with care: where I work has happened twice within the first month of use. I have to make checks. Niklas O. schrieb: >Since there's no description how to use those I never touched them. >(I've got two seperate ones in the box near the BNC.) About the second capacitor on the W2022A probe, I know for a fine adjustment I must set two capacitor for RF compensation with my analog oscilloscope's probes. These two capacitors are on BNC plug, a third capacitor is located on the probe body and it is for the LF compensation. The probes adjustment need a 1KHz and 1MHz square wave with a rise time no more than 4nS and it is done in this way: 1) Connect probe to a 1 kHz square wave signal and adjust LF compensation trimmer for optimum square wave response. 2) Connect probe to a 1 MHz square wave signal and adjust HF compensation trimmer(s) for optimum square wave response. I guess also with W202 Welec's probes is the same. I have to check. Unfortunately my oscilloscope analog probes are fixed at x10 and can not be switched to x1. However I have other probes switchable x1 and x10. I was also thinking of building a pulse generator with rise and fall times of about 300ps. With an such instrument would be simple to evaluate the probes bandwidth. It could also be used to assess the bandwidth of W201xA and W202xA DSO without worrying too much about the linearity lack of the front-end, thing that makes hard performing a such measure in the Welec DSO. But perhaps this is not a suitable place for this because there is a "hardware section", so apologize me. Niklas O. schrieb: >The attached manual contradicts itself, it mentions that the >input capacitance can be compensated "Within the box cover located >near the BNC (W202 Probe)", but on the next page under >"Compensation and Adjusting the Probe" it explicitly tells to >compensate with the trimmer on the body of the probe. The welec's manuals are always a little foggy. ;-) Niklas O. schrieb: >It fails to mention that the probe needs to be put into 1:10 divider. This is really a serious lack! But who is not a newbie should know it. @Hayo. Very well Hayo, thank You very much for the kindly explanation. Now with the Rainer W.'s help and your help I understand how it works and I know there is a way to avoid it. I understand is not so easy to fix the problem due the thermal drift and differences between the DSOs, but now I know a simple way to avoid it. I can say the problem is gone for me, so thanks very much to Rainer W. and You Hayo: RESPECT!!! Vielen Dank!!! Gruß Luc
@Niklas Bau mal noch nichts um im Screenshot. Ich habe mir was überlegt wie ich den USTB-Betrieb etwas "aufbohren" kann und den 16K Signalspeicher nutzen kann. Und der wird ja schon übertragen. Dazu kommt dann noch die Möglichkeit durch den USTB-Speicher zu scrollen. Das Konzept dazu habe ich schon fast fertig. Mal sehen wie schnell ich das eingebaut kriege. Gruß Hayo
Kurzer Tipp an alle die Windows 7 64 Bit einsetzen: Dieser USB- Seriell Adapter funktioniert einwandfrei und auch die Screenshot- Funktion läuft damit super: http://www.amazon.de/gp/product/B003AVQ00A/ Digitus DA-70156 Da ich mir selber einen abgesucht habe bis ich einen Adapter gefunden wurde der unter W7 gut läuft denke ich dass das dem einen oder anderen nützlich sein könnte.
Das ist ein guter Tip und sollte auf der SFN-Seite untergebracht werden. Gruß Hayo
Hallo zusammen, Hayo W. schrieb: >> zum anderen muesste doch >> auch die Moeglichkeit bestehen, da die Werte bei langen Aufzeichnungen >> im Flash abzulegen und am Ende abzurufen? > > Ebenfalls eine Möglichkeit... > > Platz ist im Flash noch genügend vorhanden! > > Gruß Hayo Haupsache es bleibt noch genügend Platz im Flash für Save und Restore der Kurven! Da brauche ich nämlich keine extra Hardware, bis ich mal wieder an einem PC vorbei komme :-) Gruß Jürgen
Hi, > Apropos kalibibrieren, Im Kalibriermenu steht Standart= is' klar, Active > Probe= Is' auch klar, Set 3 und 4= is' nicht klar! Sind das die > Einstellungen für die 24 u. oder 33 Ohmler? mein Anfrage ist wohl etwas unter gegangen?!? ---Set 3 und Set 4, wüsste ich gerne, was es damit auf sich hat.--- Gruß Michael
Jürgen schrieb: > Haupsache es bleibt noch genügend Platz im Flash für Save und Restore > der Kurven! Da brauche ich nämlich keine extra Hardware, bis ich mal > wieder an einem PC vorbei komme :-) Keine Sorge, die haben Ihre eigenen reservierten Segmente. Es sind aber noch einige 64K Segmente frei. Gruß Hayo
Michael D. schrieb: > > ---Set 3 und Set 4, wüsste ich gerne, was es damit auf sich hat.--- Ist einfach nur eine Bezeichnung, mir fiel nichts Besseres ein. Es sind einfach nur vier verschiedene Kalibriersets die man auswählen kann. Die ersten Beiden habe ich einfach mal Standard und Active Probe genannt. Es ist einfach nur so, dass die Kalibierung unter dem gerade eingestellten Set abgespeichert wird. Man kann auch eine kalt/warm Kalibrierung abspeichern oder eine mit einem vorher auf den Eingang gelegten DC-Offset, was auch immer. Mann kann dann ohne neue Kalibrierung zwischen den Werten hin und herschalten. Du kannst auch als Standardkalibrierung Set 3 verwenden, das ist echt egal. Ich habe bei mir auf allen 4 Sets die normale Kalibrierung drauf, damit ich da nicht versehentlich falsche Werte eingestellt habe. Gruß Hayo
Hi Niklas O. and guys all! @Niklas O. About the W2022A's probe, I will be brief because this is not the right place. I did the tests and in the x1 position the rise time is about 30nS (10MHz bandwidth) while the rise time is about 15nS (about 20MHz bandwidth) with the W2012A's probe. In the x10 position the W2012A's probes are like my 250MHz Hameg's probes, so about 200MHz bandwidth. Instead in the x10 position the W2022A probes are best of my 250MHz probes by Hameg, they have better rise and fall time response, so they are a 200MHz probes for sure. The W2022A probes are optimized to high frequencies work and W2012A probes for low frequencies. The W201 probes by Welec/Wittig and PP016 probes by LeCroy are the same, same rise and fall time. LeCroy claim they like a 300MHz bandwidth probes, their performances are same of my 250MHz bandwidth probes by Hameg, so no bad. But W202's probes for the W2022A are better than both PP016 and W201, great! Vielen Dank!!! Gruß Luc
Hallo, anbei der erste Wurf des Firmware-Upload-Programmes fuer Windows. Schaut mal ob das funktioniert. Niklas
Ich hab auch noch eins, irgendwie war ich wohl zu langsam :-( Aber eins wird ja nun funktionieren, bei Bedarf könnte ich das dann auch für Linux anbieten. Viele Grüße
Mit TomCat.ram getestet. * Opening COM1 (115200,8,N,1)... success * Asking the user to put the DSO into GERMS loader, if not already done... * Uploading firmware to DSO - @line 134 |writing to DSO| |reading response| Bis dahin funktionierte es bei mir, dann hängt er sich auf. Die Verbindung ist ok, Gegentest mit GERMSloader.pl hat funktioniert.
@Fritz Hat mit der TomCat.ram funktioniert. 122secs. Evtl. mal die Adressausgabe rausnehmen, der Fortschrittsbalken reicht doch finde ich.
Hallo nochmal, Hayo W. schrieb: > @Niklas > [16K Samples fuer UTSB] > Dazu kommt dann noch die Möglichkeit durch den USTB-Speicher zu > scrollen. Das Konzept dazu habe ich schon fast fertig. Mal sehen wie > schnell ich das eingebaut kriege. Das klingt doch gut! @Luc: Thank you kindly for your explanations and tests! It is good to know that the W202 probes actually are usable for high frequency. stone schrieb: > [..] > - @line 134 |writing to DSO| |reading response| > > Bis dahin funktionierte es bei mir, dann hängt er sich auf. > Die Verbindung ist ok, Gegentest mit GERMSloader.pl hat funktioniert. Du warst der mit den Uebertragungsproblemen, oder? Ich hab' da noch kein Timeout eingebaut und keine erneuten Uebertragungsversuche wie (ich glaube) der GERMSloader.pl macht, auch fange ich Schreibfehler nicht ab. Bei Dir wartet das Programm nach Uebertragung von Zeile 134 auf das '+' von GERMS. Wenn da 100% CPU Usage sein sollten liegt das daran das ich da noch die ComTools.cpp nutze (wie das Screenshot-Programm unter Windows auch) was nur Polling kann (in ner Schleife dauernd fragen "ist jetzt was da?"). Ich wuerd' daher noch gerne Berichte von anderen hoeren. (Selber testen kann ich nicht weil ich keinen Windows-Rechner mit serieller Schnittstelle habe und jegliche USB-seriell-Wandler die ich habe nicht unter Windows tun (oder ich stelle mich zu bloed an). Fritz Richter schrieb: > Ich hab auch noch eins, irgendwie war ich wohl zu langsam :-( > Aber eins wird ja nun funktionieren, bei Bedarf könnte ich das dann auch > für Linux anbieten. Haettest Dich vorher melden sollen dass Du auch was vorhast, dann haette ich mir das Suchen in MSDN heute Nachmittag sparen koennen :) Bei einer kurzen Suche zu Deinem Namen hab' ich diesen interessanten Beitrag von 2009 gefunden: Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware" Hast Du das danach noch weiter verfolgt? Bei Deinem Programm koenntest Du noch einbauen dass es in der Dropdown-Liste nur Ports anzeigt die auch existieren, zudem kann der Fall dass ein Port existiert aber schon durch ein anderes Programm geoeffnet ist abgefangen werden und evtl. entsprechend angezeigt. Womit hast Du das entwickelt, btw.? Wundert mich gerade warum es so gross ist. Wenn Du Lust/Zeit/Interesse hast koenntest Du eine GUI fuer das Screenshot-Programm machen. Die Core-Funktionalitaet wollten wir eh ausgliedern. GUI bzw. Konsolen-Variante wuerden dann auf entsprechende C-Funktionen zugreifen die dann Trace, Screenshot, usw. liefern. Niklas
Niklas O. schrieb: > Schaut mal ob das funktioniert. Hallo Niklas, die Übertragung einer .ram unter WinXP SP3 über einen Prolific USB-Seriell Wandler (Treiber V. 2.0.13.130) hat gut funktioniert. Gruß Rainer
Niklas O. schrieb: > Bei einer kurzen Suche zu Deinem Namen hab' ich diesen > interessanten Beitrag von 2009 gefunden: > Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware" > Hast Du das danach noch weiter verfolgt? > > Bei Deinem Programm koenntest Du noch einbauen dass es > in der Dropdown-Liste nur Ports anzeigt die auch existieren, > zudem kann der Fall dass ein Port existiert aber schon > durch ein anderes Programm geoeffnet ist abgefangen werden > und evtl. entsprechend angezeigt. > > Womit hast Du das entwickelt, btw.? Wundert mich gerade > warum es so gross ist. Du meinst das USB? Ich war damals ziemlich entsetzt über die erreichbare Geschwindigkeit, es war deutlich langsamer als seriell, deshalb hatte ich es erstmal frustriert sein gelassen. Deinen Vorschlag mit den existierenden Comports habe ich noch eingebaut. Programmiert habe ich das mit Delphi, weil ich gerade nix anderes zur Hand hatte, deshalb wahrscheinlich die Größe.
Hi Niklas, > Hallo Niklas, > die Übertragung einer .ram unter WinXP SP3 über einen Prolific > USB-Seriell Wandler (Treiber V. 2.0.13.130) hat gut funktioniert. > Gruß > Rainer ...dito, habe das Teil von HAMA mit dem FTDI drinnen, funzt wunderbar und es gibt kein gezicke! Ganz hilfreich wäre noch die Angabe der verbleibenden Downloadzeit in Sekunden, wie es beim Germsloader der Fall ist?!? Gruß Michael
Hallo! Mich würde mal interessieren, was es beim NIOS Design für Debugmöglichkeiten gibt. Ich bin in der Firma zufällig beim RTEMS Betriebssystem auf einen gdb Stub gestossen und überlege, dass ich den gdb stub und RTEMS für das LEON3-Zeug benutzen werde. Falls es was besseres oder einfacheres beim NOIS Design gibt, wäre ich dem gegeüber auch sehr offen. Übrigens scheint das Changelog im Trac nicht mehr ganz am neuesten Stand zu sein. MfG Alexander
Hallo Nochmal! Ich habe jetzt mein zweites Preview Version 1.1 auf im Sourceforge zum Download bereit gestellt. Das Ausprobieren ist gefahrlos, da ich den FLASH-Speicher nicht benutze oder verändern kann. Nach dem man das Gerät komplett Ausgeschalten hat, ist alles wieder wie es vorher war. Ausprobieren auf eigene Gefahr (, die es praktisch nicht gibt)! Das FPGA-Design ist jetzt schon in einem sehr brauchbaren Zustand. Die Firmware ist hingegen noch in einen sehr frühen Stadium und für den normalen Einsatz nur bedingt geeignett. http://sourceforge.net/projects/welecw2000a/files/LEON3%20FPGA%20Design/Previews/ Dennoch bietet sie eine GUI, manuelles Einstellen der Zeitbasen, der analogen Spannungsbereiche, und es kann der DAC-Offset analog eingestellt werden. Die digitalen Filter HW-Filters und die 8kSamples Speichertiefe pro Kanal sind die größte Verbesserung gegenüber dem NIOS-FPGA-Design. Da ich nur ein 2-Kanalteil habe, unterstütze ich hier auch nur 2 Kanäle. Die Sprünge der Offsets bei den 5er,2er und 1er sind durch das analoge Frontend bedingt und fehlen hier noch im Gegensatz zu der Firmware für den Nios Softcore. Im AUTO Trigger Mode ist die Bildwiderholrate langsam, falls nichts zum Triggern gefunden wurde. Die Spannungsverstärkung ist auch noch nicht kalibriert. MfG Alexander
Gute Sonntag an alle und Niklas O. Niklas O. schrieb: >anbei der erste Wurf des Firmware-Upload-Programmes fuer Windows. >Schaut mal ob das funktioniert. Niklas, thank You very much for the masterpiece and free time You kindly provides to us: RESPECT!!! I have tried your software and it works like a charms both through direct serial connection than via MANHATTAN's usb to serial converter. My equipment are: computer Pentium IV@3GHz with operating system Windows XP Home Edition SP3 and hardware version 8C7.0.C of W2022A's model DSO. Through a usb to serial converter it is little slower than direct serial connection, but this even with Perl Script, so it is normal. I do not want to appear rude and I do not want to criticize your excellent work, but I would say that the software is very detailed in describing the operations to be done but it not warn you when it ended (the Perl Script at the end thank for the fishes so the user understands the operations are successfully completed). Repeat, this my reporting is not intended as a criticism but it is simply for knowledge, so apologize me. Niklas O. RESPECT! Vielen Dank!!! Gruß Luc
Und noch ein längeres als Bedienungshinweis! MfG Alexander
Wow, is ja Wahnsinn, was sich inzwischen überall getan hat. Beim Leon Design erscheint es jetzt langsam sinnvoll, wenn Hayo und Kollegen mal schauen würden, ob sie die Firmware portiert bekämen. Das Leon-Design selber hat ja ein unglaubliches Potenzial!!! Als reiner Nutzniesser noch einmal einen besten Dank an alle. Ist schon echt klasse, dass das Welec jetzt inzwischen voll brauchbar ist und mit dem Leon Design sogar noch Best-Of-Class werden könnte (mal vom analogen Teil abgesehen). Michael
Hallo, Michael D. schrieb: > Ganz hilfreich wäre noch die Angabe der verbleibenden Downloadzeit in > Sekunden, wie es beim Germsloader der Fall ist?!? Jupp. Baue ich noch ein. Luc schrieb: > [..] but I would say that the software is very detailed in > describing the operations to be done but it not warn you when it ended > (the Perl Script at the end thank for the fishes so the user understands > the operations are successfully completed). Yes. It will open a MessageBox saying that the operation is finished but I forgot to write that info on the console, too. Michael schrieb: > Wow, is ja Wahnsinn, was sich inzwischen überall getan hat. > > Beim Leon Design erscheint es jetzt langsam sinnvoll, wenn Hayo und > Kollegen mal schauen würden, ob sie die Firmware portiert bekämen. Das > Leon-Design selber hat ja ein unglaubliches Potenzial!!! Ich stimme zu, allerdings glaub' ich nicht, dass wir da an ein "Portieren" der Firmware denken koennen. Ganz abgesehen vom unterschiedlichen FPGA-Design ist da immer noch jede Menge Furcht erregende Altlast drin. Ich finde aber, dass es nun an der Zeit ist mitzuwirken und die GUI aufzubauen. Da ich ein 4-Kaeneler habe muss ich zum Ausprobieren des Leon-Designs nochmal auf und Front ab und Loetbruecke rein. Ich hoffe ich komme mal die naechste Zeit endlich dazu. alex008 schrieb: > Die digitalen Filter HW-Filters und die 8kSamples Speichertiefe pro > Kanal sind die größte Verbesserung gegenüber dem NIOS-FPGA-Design. Mhm, nur 8kSa? > Da ich nur ein 2-Kanalteil habe, unterstütze ich hier auch nur 2 Kanäle. Im FPGA-Design generell oder nur in der Firmware? Niklas
Hallo Niklas! Die 8 kSamples ergeben sich im Moment aus der Firmwarekonfiguration. Sie ist auf 2 Kanäle mit 16 Bit Daten eingestellt. Falls man auf 8 Bit, 1 Kanal umstellt hat man 32kSamples. Mehr geht nicht, da der Cyclone II "nur" ca. 56 kByte zu Verfügung hat, und der LEON3 mit seinen Registerwindows und seinem Cache auch eine ganze Menge an RAM-Blöcken braucht. Das 4-Kanalmodell hat den doppelten internen Speicher, da es doppelt so viele FPGAs (2 statt 1) nutzt. Das NOIS-Design kann da bei den meisten Samplinraten weniger. Nebenbei unterstützt es hardwaremässig nicht alle Samplingraten, die es anzeigt. Des weiteren ist der Messdatenpuffer auf den Roll-Mode ausgelegt, jedoch wird das von der Firmware noch nicht unterstützt. Ein entsprechender DMA, mit dem 20MSamples/sec beim Roll-Mode theoretisch möglich sind, ist im FPGA-Design angedacht, aber noch nicht drinnen. MfG Alexander
alex008 schrieb: > Die 8 kSamples ergeben sich im Moment aus der Firmwarekonfiguration. Sie > ist auf 2 Kanäle mit 16 Bit Daten eingestellt. Wie machst Du das mit den 16 Bit? > Das 4-Kanalmodell hat den doppelten internen Speicher, da es doppelt so > viele FPGAs (2 statt 1) nutzt. Habe ich das richtig mitgekriegt, dass Kanal 3 + 4 zur Zeit FPGA-seitig noch nicht unterstützt werden? > Das NOIS-Design kann da bei den meisten Samplinraten weniger. Nebenbei > unterstützt es hardwaremässig nicht alle Samplingraten, die es anzeigt. Vor allem gibt es aus unbekannten Gründen einen ziemlichen Sprung zwischen 25MSa und 250MSa was ziemlich unpraktisch ist. da die dazwischenliegenden Samplingraten auf Kosten der effektiven Speichertiefe geht. @Niklas Die effektive Speichertiefe ist beim NIOS-Design nur bei <=50ns/div 16KB. Bei den anderen Zeitbasen sorgt der Zoomfaktor dafür, dass nur ein Teil der 16KB bzw. 4KB im normalen Betrieb genutzt werden. Dafür stehen die ungenutzten Werte im Stopmodus und im Delayedmodus für weitere (schnellere) Zeitbasen zur Verfügung. Gruß Hayo
Alex, klasse! Das sieht ja schon richtig gut aus. Wir müssen dem Alex mal einen 4Kanäler sponsorn... Vorher wird das mit mir und der Leon-Firmware nix. Ich würde echt gern selber dran mitarbeiten, aber mir fehlt die Zeit. Nur am Rande, bestimmt hatte schon mal jemand die Idee, ich frage trotzdem: Wäre es eigentlich möglich, aus dem Welec ein DPO (statt momentan DSO) zu bauen? Also eines was kontinuierlich abtastet und in der Kurvendarstellung statt Einzelwerten entsprechend breitere Verteilung anzeigt? Ich habe zugegeben noch nicht mit sowas gearbeitet, fände ein "analogeres" Feeling gut. Derzeit nehme ich fast immer mein Hameg statt dem Welec, da weiß ich was ich sehe, falle nicht auf Unterabtast-Artefakte rein. Jörg
Angehängte Dateien:
-
Triggerart.png
23 KB
ich habe gerade bei Yokogawa folgende Triggerarten gesehen und wollte mal fragen ob sich das vielleicht auch integrieren lässt. 1. "Oder-Trigger" die erste Flanke triggert egal ob diese auf Kanal 1, 2, 3 oder 4 auftritt. 2. Flankentrigger der in Abhängigkeit von Low/High eines anderen Kanals steht, so könnte man z.B. bei I2C aufs Start Bit triggern.
Hi Niklas O., alex008, Hayo and guys all! Niklas O. schrieb: >Yes. It will open a MessageBox saying that the operation is finished >but I forgot to write that info on the console, too. Niklas O., thanks so much for your kind explanation! @alex008 Alex008, really very impressive your work who it also make user friendly the approach to the LEON 3 Design: RESPECT!!! I will try to explore the question, thank You very much Alex008 and all who are involved with the LEON 3 NIOS design: again RESPECT!!! @all who can answer I update my W2022A to the latest 1.2.BF.3.0_C5 firmware revision and with it I experimented the spikes problem, this is known as spikes that affect both channels simultaneously. Now with the same software release on mine friend's W2012A it seems less noisy, as I already written, and no spikes problem. Instead my W2022A seems to me less noisy also, but there is the spikes problem I never seen before on my W2022A. Normally I could set "Factory" or "Hi Frequency" in the hardware menu without problem, now only "TEST 5" give some improvement but do not entirely eliminate the problem. So I ask myself: My W2022A is hardware version 8C7.0C while my friend's W2012A is hardware version 8C7.0B, but what the difference is? Could this be the cause of the problem? And what means 8C7.0C, 8C7.0B, 8C7.0L, 8C7.0G and so? Are they perhaps the NIOS revision? I know Hayo have W2022A hardware version 8C7.0G or 8C7.0L (http://sourceforge.net/apps/trac/welecw2000a/wiki/usersinstrument), so He test firmware with it and due the differences between the DSOs I understand is not so easy for He to release a firmware that will work on all W202XA and W201XA Welec's revisions, although he usually succeeds in this. @Hayo Hardware's menu settings are used to eliminate ringing problems plaguing some Welec's DSO, precisely the spikes's problems. Broadly, what are the affected parameters? I mean the inside firmware parameters to be adjusted to eliminate the spikes Vielen Dank!!! Gruß Luc
Hallo Hayo, eine Frage zur FFT: Im Zeitbereich schaltet ja zwischen "Ablenkgeschwindigkeit" 5 us/div und 10 us/div die Abtastrate zwischen 250 MSa/s und 25 MSa/s um. In der FFT springt dann die Frequenzskala direkt von 15.62 MHz/div auf 1,56 Mhz/div. Aus der Abtastung ergibt sich natürlich dieser Sprung, aber für die Ablesung wäre es manchmal gut, ggf. per Zoom Zwischenwerte einstellen zu können. Habe ich da etwas übersehen oder geht das (noch?) nicht? Gruß Rainer
@Luc The hardware version consists of three single values: tc_hw_version, tc_production_lot1, tc_production_lot2 Only 8C7 (tc_hw_version)is the real hardware version! This value is read from the FPGA. The values after the dot are stored in the protected flash (tc_production_lot1, tc_production_lot2). This are values which where set by WELEC while programming the flash. Maybe the values after dot are not correct in my W2022A because I restored my flash after an upload crash from another DSO (I think is was from Falk). Do You have a screenshot of Your spike problem? Regards Hayo
Angehängte Dateien:
-
Spike1.jpg
48 KB -
Spike2.jpg
46 KB -
AUTOSCALE_probe.jpg
40 KB -
no_signal.jpg
44 KB -
no_signal3.jpg
42 KB -
no_signal4.jpg
44 KB -
probe_comp.jpg
40 KB
Hi Hayo, Niklas O. and guys all! Hayo W. schrieb: >Only 8C7 (tc_hw_version)is the real hardware version! Hayo as always You are very kind! I thank You very much for the explanation and for your patience! Hayo, You are great! So ultimately be always the same review worked at different times without substantially differences. For me this is very interesting, thank You Hayo! Hayo W. schrieb: >Maybe the values after dot are not correct in my W2022A because I >restored my flash after an upload crash from another DSO Well Hayo, but the batch is not relevant if there are not other differences. If I understand correctly means that comparing different hardware revisions the only difference is related with the production batches fields. Is this correct? This means uploading an hardware revision rather than another in the DSO make no difference. Certainly when the LEON 3 design will be implemented in full there will be a standard environment that perhaps will help the compatibility between the different DSO, this I think. Hayo W. schrieb: >Do You have a screenshot of Your spike problem? Hayo, spikes are very fast and random, very difficult to capture. I unable to get it directly, so in order to capture they I had to enable the persistence of the display. The result is visible in the two attached screenshots named Spike1.jpg and Spike2.jpg. However, I noticed my W2022A has a bit crazy behavior. AUTOSCALE do not work correctly, the AUTOSCALE_probe.jpg pic show the result of the function with the signal for the probes compensation: very crazy! Other pics show the behavior without signal on CH1 and CH2: also very strange. @Niklas O., @Hayo I tried to reload the same firmware via Perl Script but I have not solved the problems. I had updated the W2022A using the fwupload.exe software released by Niklas O. Now, Niklas O. schrieb: >Yes. It will open a MessageBox saying that the operation is finished >but I forgot to write that info on the console, too. But when I upgrade I have no get the message, so I wrote: Luc schrieb: > [..] but I would say that the software is very detailed in > describing the operations to be done but it not warn you when it ended > (the Perl Script at the end thank for the fishes so the user understands > the operations are successfully completed). So, might be this related? I would like to make it clear that I do not write these things to blame Niklas O. or others for what happens to me but only for knowledge because this maybe can help to prevent a recurrence of the problem also to other. I am sure that Niklas O. has done a great job and I thank him again for the amazing fwupload.exe software and for free time He kindly provides to us, Niklas O. RESPECT!!! I hope not to seem rude and above all not be misinterpreted. I even do not expect a solution, I will only document the fact. Repeat this is for knowledge, I do not write these things to blame Niklas O. or others but only because this maybe can help to prevent a recurrence of the problem also to other. I hope all You understand what I mean, what I want to say. However, I'm sure I can certainly solve by loading a previous revision of the Hayo's firmware, so really no problem for me, I do not think my W2022A was permanently ruined ! :-) Vielen Dank!!! Gruß Luc
Hi, bin grad (Ihr ahnt es schon) vom Griechen zurück, diesmal allerdings zwecks 10. Hochzeitstag. Trotzdem ist noch kurz Zeit für eine Antwort (ist halt die beste aller Ehefrauen!). @Rainer Es gibt leider (aus unerfindlichen Gründen) einen Sprung zwischen 250MSa und 25MSa. Das Ganze wird im laufenden Betrieb durch den Zoomfaktor zwischen 10 und 25 kaschiert. Das ist natürlich suboptimal. Ich habe auch schon mit diversen Registerwerten experimentiert, aber ohne Erfolg. Anscheinend haben die Jungs (Wittigs) es voll vergeigt! Die einzige Abhilfe die mir da so in den Sinn kommt ist das LEON3 Design. Mit dem NIOS Design läßt sich da wohl wenig ändern. Gute Nacht Hayo
Hallo! Ich habe eine mögliche Erklärung zu den unterschiedlichen Speichertiefen bei den verschiedenen Samplingraten im NIOS Design. Es scheint mir so, dass beim NOIS Design jeder ADC einen Puffer von 4 kB oder 4 kSamples hat. Bei 500 MS/s werden nur 2 ADCs benutzt, weshalb auch nur 2*4 kB Speicher zur Verfügung stehen. Bei 250 MS/s wird nur ein 4kB Speicher benutzt. Um nun die 1,2,4,10, ... Teilung zu schaffen, ohne dass der vertikale Gridabstand verändert wird, muss wenn nur ein 4kB Speicher verwendet wird, die erste Teilung einen Faktor 10 aufweisen. 250MS/s / 2,5 Samples = 100MS/s geht nicht mit Samples verwerfen, die das NIOS Design sicher nicht hat. Möglicherweise gibt es auch die 50MS/s Teilung nicht, da der 4kB Speicher mit hoher Warscheinlichkeit mit 16 Bit @ 125 MHz beschrieben wird, und das dem FPGA-Entwickler zu schwierig oder zu aufwendig war. Im Unterschied hat das LEON3 design einen 32 kB Puffer, welcher nach der Dezimierung mit oder ohne HW-Filter ist, und kein einziges Sample Jitter auf irgendein Triggerevent hat. @LUC To be shure you do not have a hardware fault (soldering) try the LEON3 design. It does have an glitch trigger which can trigger downto one sample long gliches with every samplingrate (also @ 1 GS/s)! The HW-Filters must be turned off for this! @Thomas Einen OR-Trigger habe ich im Moment noch nicht drinnen, die Triggereinheit ist aber so modular aufgebaut, dass eine Nachrüstung relativ einfach wäre. Die Bandbreitenbegrenzung im DLM2000 unter 100MHz wird laut Aussage eines Yokogawa Vertreters auch mit ähnlichen digitalen Filtern gemacht, wie die HW-Filters bei mir! MfG Alexander
@Hayo: Also hat die Triggerung nicht mit dem Nios Design zu tun, gibs da einen Baustein in Hardware der sich darum kümmert, oder wie meinst du das mit modularer Triggereinheit.
@Axel Wenn ich mit Datenrate und Tracelänge nachrechnet, scheint es so, dass bis einschließlich 10 us/div (25 MSa/s) eine Speichertiefe von knapp 4 kSa pro Kanal verwendet wird, ab 5 us/div (250 MSa/s) komme ich dann auf 16 kSa pro Kanal, d.h. das ist noch eine andere Sache als das Reduzieren des ADC Interleaves von 4..2..1 ADC. Hayo kann das bestimmt bestätigen. @Hayo Da man an den Samplingraten vermutlich erstmal nicht drehen kann, zielte meine Bemerkung zum 1:10 Sprung in der Frequenzachse eigentlich mehr in Richtung Zoom-Funktion für die FFT. Bei 1024 gerechneten Punkten wären ein 2:1 Zoom sicher drin, ein 4:1 Zoom eventuell nicht schön, aber darstellbar. Früher gab es ja schon mal die Frage nach einer Art Frequenzlupe. Ohne neue Berechnung von Frequenzdaten, könnte man sowas vielleich in der Anzeige auf Basis der bestehenden Daten umsetzen. Gruß Rainer
@Thomas die Triggerung ist größtenteils hardwareseitig (ADC, FPGA) implementiert. Das schränkt die Möglichkeiten firmwareseitig etwas nachzurüsten ziemlich ein. Beim LEON3 hat Alex zum Beispiel die Möglichkeit ein Oder-Glied in die Triggerlogik des FPGA einzufügen, diese Möglichkeit habe ich beim NIOS nicht. Ich kann also nur mit dem arbeiten was bei der Firmware ankommt und das ist nur die Triggerung eines einzelnen Kanals zur Zeit. @Rainer Zur Zeit verwende ich für die FFT nur die realen Abtastraten, Daher auch der Sprung zwischen 250 und 25MSa. Ich könnte natürlich stattdessen die virtuellen Abtastraten des Zeitbereichs verwenden, dann hätte man eine feinere Abstufung. Dazu müßte ich dann wie beim Zoom die nicht benötigten Abtastwerte weglasssen. Das wäre machbar. Ich seh mal was da geht. Zur Zeit bin ich noch ziemlich mit dem Umbau der USTB-Funktionen beschäftigt. Gruß Hayo
Hayo W. schrieb: > Zur Zeit bin ich noch ziemlich mit dem Umbau der USTB-Funktionen > beschäftigt. Dann will ich lieber nicht stören. Gruß Rainer
Hallo zusammen, wegen der Sammelbestellung: Es sind immer noch zu wenig Interessenten. Beim USB-Host erst 5 Leute. Dann wollen noch 4 Leute Teile für die Huckepackplatinen und auch noch Platinen. Die Teile sind natürlich kein Problem, wohl aber die <10 Platinen die eine Bestellung unwirtschaflich machen. Ich würde vorschlagen die Sammelbestellung (USB-Host+Huckepack2) solange offen zu halten bis Hayo die Firmware angepasst hat. Dann werden sich sicherlich noch mehr Interessenten melden. Gibt es Meinungen/Einwände dazu? Mfg, Kurt
Mach nur! Ich habe es nicht eilig damit. Grüße, Guido
wird wohl sinnvoll sein, da sicherlich eine Menge Leute abwarten wie sich das ganze fertig implementiert macht. Mich eingeschlossen ;)
Gute Sonntag an alle und alex008, Kurt Bohnen, Thomas O. und Hayo. alex008 schrieb: >@LUC >To be shure you do not have a hardware fault (soldering) try the LEON3 >design. It does have an glitch trigger which can trigger downto one >sample long gliches with every samplingrate (also @ 1 GS/s)! >The HW-Filters must be turned off for this! Thanks for the suggestion alex008! As I have already written, I am sure my W2022A is not dead and it is just a loading error. I already load an old Hayo's firmware release in to W2022A and spikes problem is gone, so I am pretty sure the W2022A is ok and it has no problem. On the other hand I have similar experiences with firmware upgrades asthe my work even covers these issues, so nothing new for me. The problem is due to hardware incompatibility or loading error or both. Returning to your kind suggestion, I have installed the LEON3 design in my W2022A. It is very easy, maybe because I use Quartus and similar software daily when I work but it is very easy to do! To be honest, I was able to easily install the NIOS LEON3 design and its software, but I was not able to do any measure due the fact I am unable to do even simple thing like move traces, so they are always in a bad position on the screen, I am only able to move the trigger level, nothing other. I am able to set some parameters like probe attenuations, time base's factor, vertical amplitude's factor, set the trigger source, set the trigger slope and so, but nothing other. Signal track are very clean and noiseless, but seems to me like they are be fixed. However, I repeat I was unable to make use of the DSO with the LEON 3 design installed on it, I am so sorry. Is there no a user manual that explains how to use it? What mean LEON or FPGA UART setting? For me the LEON 3 DEMO design is really very user friendly to put in to the DSO, although then I was not able to properly use the DSO I invite everyone to try the LEON 3 design, if only because it is very easy and safe to install it in the DSO: You load the LEON 3 in the DSO, You try it and once You turned off and on the oscilloscope everything is back as it was before without a trace! Really very cool, so thank You very much to You alex008 and all who is involved with the LEON 3 design's development: RESPECT!!! However moving forward, to more accurately test the hardware of my W2022A I decided to hurt me and I reinstalled the original 1.4 version by Wittig/Welec! ;-) A blast from the past, a return to youth! ;-)) After having played a little with the good old Wittig/Welec firmware, go running to update the DSO to the latest 1.2.BF.3.0_C5 firmware release! ;-))) Now spikes are come back like in a nightmare! My goodness, this is really a wonderful and unforgettable Sunday! :-) In the end seems the 1.2.BF.3.0_C5 firmware do not like at my W2022A so I make a downgrade! @Kurt Bohnen What is the >Huckepack2? @all Thomas O. schrieb: >ich habe gerade bei Yokogawa folgende Triggerarten gesehen und wollte >mal fragen ob sich das vielleicht auch integrieren lässt. > >1. "Oder-Trigger" die erste Flanke triggert egal ob diese auf Kanal 1, >2, 3 oder 4 auftritt. >2. Flankentrigger der in Abhängigkeit von Low/High eines anderen Kanals >steht, so könnte man z.B. bei I2C aufs Start Bit triggern. In the Wittig(welec) DSO W20xxA Open Source Firmware (Teil3) weitererGast schrieb: >>> Ist eigentlich schon implementiert, dass man auch auf einen Kanal >>> triggern kann der ausgeblendet, aber dennoch angeschlossen ist? Das >>> missfiel mir am Anfang gewaltig. Manchmal muss man wegen der >>> Übersichtlichkeit schlichtweg auch mal den zu triggernden Kanal >>> ausblenden. Antonio schrieb: >> I don't understand, what you mean? >> Also Hayo's answer isn't clear for me, please help about this. Hayo W. schrieb: >What he meant is, that triggering should be possible on channels which >are inactive. But to realize that I have to change the source channel >selection logic because the actual logic switches off the source channel >if it becomes inactive and searches for the next available active >channel automatically. Subject matter in some ways similar. Vielen Dank!!! Gruß Luc
Luc schrieb: > @Kurt Bohnen > What is the >Huckepack2? Hello Luc, it´s the second collective order of the pickabackboard parts (and PCB).
mir ist gerade etwas in den Sinn gekommen und da wollte mal fragen ob das praktizierbar ist. Ein differentielles Signale anzuzeigen also Kanal 1 mit Kanal 2 zu verrechnen und ab einer Differenz größer X das eigentliche Signal darzustellen dazu wäre es vielleicht sinsvoll die gespeicherten Werte rechts zu schieben um die Auflösung zu verringern und dann miteinander verrechen. Viellicht läßt sich sogar eine 3 Oszilinie zw. Kanal 1 und 2 Zeichnen. http://www.kfztech.de/kfztechnik/elo/can/bmw1.JPG
Hm also mir ist jetzt nicht klar, wo der Unterschied zur einfachen Subtraktion der Kanäle liegen soll, kannst du das nochmal erklären? Gruß Michael
ich sehe gerade das die Subtraktions-Funktion dabei ist, muss mal schauen ob sich das so gut auf digitale Signale anwenden lässt.
Hi Leute, ich weiß man hört im Augenblick nicht viel von mir. Aber ich ich bin trotzdem dabei. Zur Zeit bin ich noch an den USTB-Funktionen dran. Vorab noch ein Fix zum Spikeproblem dass Luc gemeldet hatte. @Luc I fixed the spike problem caused by the hardware setting "High Frequ". I changed the register setting and it seems to work. Hayo
Thomas O. schrieb: > ich sehe gerade das die Subtraktions-Funktion dabei ist, muss mal > schauen ob sich das so gut auf digitale Signale anwenden lässt. Zum Glück sind die Digitalsignale eine Teilmenge der Analogsignal. :-)
Hallo Hayo, mal noch eine Frage etwas anderer Natur. Wäre es denkbar die Auflösung des Scopes zu 9bit hin zu treiben? Ich glaube die Diskussion hatten wir schon mal an irgendeiner Stelle. Ich stelle mir das so vor: - Sampledurchgang 1: Es wird gesamplet wie bisher - Sampledurchgang 2: Die Spannung am DAC wird soweit erhöht, dass das Signal am ADC um 1/2 LSB erhöht ist. - Zusammenführen der Daten aus Sampledurchgang 1 und 2 Mir ist klar das das auf dem Bildschirm keinen Unterschied machen wird, jedoch beim Export der Daten auf einen PC wird das einen Unterschied machen, weil dann die höhere Auflösung zur Verfügung steht. Ließe sich das grundsätzlich realisieren? branadic
branadic schrieb: > - Sampledurchgang 1: > Es wird gesamplet wie bisher > > - Sampledurchgang 2: > Die Spannung am DAC wird soweit erhöht, dass das Signal am ADC um 1/2 > LSB erhöht ist. > > - Zusammenführen der Daten aus Sampledurchgang 1 und 2 Das Problem sind das Zusammenführen der Signale und die Wiederholrate. Die Wiederholrate wird massiv einbrechen, da 1. doppelt so viele Sampledurchgänge pro Frame benötigt werden 2. vor jedem einzelnen Sampledurchgang der DAC justiert werden muß, was noch viel mehr Zeit kostet, da vor dem nächsten Sampledurchgang solange gewartet werden muß bis der DAC (und OP Amp) gesetzt und eingeschwungen ist. Das Zusammenführen ist insofern problematisch, dass es einen sehr präzisen Trigger erfordert, da sonst das Signal in Horizontalrichtung unscharf wird. Man erkauft sich dann vertikale Präzision mit horizontaler Unschärfe. Wie das aussieht kann man sich ansehen wenn man ein Signal mit steiler Flanke auf dem Bildschirm hat und dann auf persistente Anzeige schaltet. Gruß Hayo
Hallo Hayo, ich hab mir schon fast gedacht, dass das auf Basis des Nios nicht klappen wird. Es wird wirklich Zeit, dass der Leon das Licht der Welt erblickt, denn da steht auch der Trigger wie eine eins und ließe, aufgrund seiner Geschwindigkeit, solche Spielereien ebenfalls zu. branadic
Hi Hayo, Kurt Bohnen and guys all! @Hayo First, thanks You very, very much Hayo for the free time You provided generously to us and for have fixed the spike's problem!!! Hayo, I installed your latest great job, the new 1.2.BF.3.0_C6. It is very impressive, as always You are right the spikes are gone!: RESPECT!!! I setted hardware configuration as "High Frequency" and "1,25 Gain" and no more spikes! You are great, so thank You very much again for the excellent job done: RESPECT!!!!!!! I know the work must not have been easy, so as usual I am speechless!!! Kurt Bohnen schrieb: >It's (the "Huckepack2") the second collective order of the >pickabackboard parts (and PCB). Hello Kurt Bohnen, thank You for your kind explanation. What You wrote it is very interesting for me and I guess for many other also. How can I place a purchase order? How can I pay the materials? How much is it shipping included? Is there a possibility to purchase a Vinculum VNC2 USB-Host also? And the power supply shield? Please, let me know, I guess it is very interesting also for many other people. Thank in advance. Mit Freundlichen Grüßen, Luc
Hi Luc, I will post more information about the collective order on Sourceforge this weekend.
Hello LUC, sorry for my late answer. I am happy to read you did try the LEON3 design. For your measuring problem: The LEON3 design software is not ready to use for daily operation. Their is no DC offset calibration available at the moment. And because the original analog frontend was made with poor quality you have to set the dc offset with the offset gain button and the offset wheels before you can measure anything. I have put a video about setting the dc offset on a previous entry from 10.04.2011 here. The signal quality can be improved with the HW-Filters. Alexander
Frohe Ostern Euch allen! Details zur Sammelbestellung gibt es jetzt hier: http://sourceforge.net/apps/trac/welecw2000a/wiki/collectiveorder Die englische Übersetzung folgt später. Bis dahin muss google helfen. ;-) Mfg, Kurt
hat außer mir noch jemand Probleme mit Timebase >1s/div mit der 3.0 C6 oder wurde da irgentwas geändert, ich habe einige Versionen übersprungen. Bekomme keine Aktualisierung mehr mit den Sekunden- Einstellungen.
Ja, bei mir geht ab 1s/div auch nichts. Wenn ich Hayo richtig verstanden habe, ist USTB z.Z. Baustelle. Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil4)" Gruß Rainer
Hi BLUE I have a worrying problem on my W2012. While today I tried to adjust the course to display a horizontal drive a TVC suddenly the track of the instrument has become fixed and immobile, but clean (not even a pixel out of place). Of course not display any picture nor the TEST SIGNAL. I say that at the time of the defect, the tip was removed from the circuit. I reinstalled an earlier version that was installed but the defect remains. Channel 2 still works Sorry for the language
wailer schrieb: > Hi Hayo > I have a worrying problem on my W2012. > While today I tried to adjust the course to display a horizontal drive a > TVC suddenly the track of the instrument has become fixed and immobile, > but clean (not even a pixel out of place). Of course not display any > picture nor the TEST SIGNAL. > I say that at the time of the defect, the tip was removed from the > circuit. > I reinstalled an earlier version that was installed > but the defect remains. Channel 2 still works > Sorry for the language
Hi Kurt Bohnen, alex008, wailer, and guys all! Kurt Bohnen schrieb: >Details zur Sammelbestellung gibt es jetzt hier: >http://sourceforge.net/apps/trac/welecw2000a/wiki/... Very well Kurt Bohnen, great job! Kurt Bohnen thank You very much for your kind support! You are really a big one, RESPECT!!! alex008 schrieb: >sorry for my late answer. >I am happy to read you did try the LEON3 design. Hi alex008, no apologies, I must thank You for the great work and free time You provided generously to us: RESPECT!!! alex008 schrieb: >For your measuring problem: >The LEON3 design software is not ready to use for daily operation. >Their is no DC offset calibration available at the moment. >And because the original analog frontend was made with poor quality you >have to set the dc offset with the offset gain button and the offset >wheels before you can measure anything. >I have put a video about setting the dc offset on a previous entry from >10.04.2011 here. Ok alex008, I understand, so thank You a lot for the kindly and useful explanation. alex008 schrieb: >The signal quality can be improved with the HW-Filters. I am currently away from my computer and I have no to hand Quartus, so I can not try but in the weekend I will try for sure. Thank You again alex008! wailer schrieb: > I have a worrying problem on my W2012. > While today I tried to adjust the course to display a horizontal drive a > TVC suddenly the track of the instrument has become fixed and immobile, > but clean (not even a pixel out of place). Of course not display any > picture nor the TEST SIGNAL. > I say that at the time of the defect, the tip was removed from the > circuit. > I reinstalled an earlier version that was installed > but the defect remains. Channel 2 still works > Sorry for the language Hi wailer, seem to me to understand perhaps you damaged your DSO while performing a measurement on a TV color set. Is it correct? I think already I read You somewhere and I guess You are Italian, so I try to write Italian to facilitate the understanding. Italian translation: Ciao wailer, mi sembra di capire che tu hai danneggiato il tuo DSO effettuando una misura su un televisore a colori. E' corretto? Mi pare di averti già letto da qualche parte e che tu sia italiano, per cui provo a scrivere in italiano per facilitare la comprensione. @ all Due to high voltage on some point inside a color television set, is unfortunately possible you damaged your DSO for true. How much is great the signal amplitude on which You done the measure? Was the probe setted x1 or was it setted x10? Sorry, but due to the exceeded in the maximum input voltage for analog inputs is possible the DSO is now broken. Please weiler, tell us more about what you done. Italian translation: A causa dell'alta tensione presente in alcuni punti di un televisore a colori è purtroppo possibile che tu abbia realmente danneggiato il DSO. A quanto ammonta l'ampiezza del segnale sul quale hai effettuato la misura? Come era impostata la sonda, x1 o x10? Spiacente ma a causa del superamento dei valori massimi consentiti per gli ingressi analogici è possibile che il DSO sia adesso guasto. wailer per favore facci sapere di più circa quello che hai fatto. Mit Freundlichen Grüßen, Kind regards, Cordiali saluti, Luc
Luc grazie Preciso che il probe non era a contatto con i circuiti del TVC Sul TVC il trasformatore di EAT era smontato (assente)Quindi non poteva esserci Alta Tensione. Il pilotaggio (driver) di riga ha come Vpp 12-15 volts Il blocco del Input 1 è avvenuto cercando di regolare il Time Base Posso ora dire che il problema era software ed è RISOLTO. Con WELECUPDATER ho reinstallato il firm originale (avevo Backup) e il DSO ha ripreso a funzionare. Successivamente ho aggiornato alla 3.0C6 del grande HAYO .Ora tutto sembra funzionare. Prima del blocco avevo notato che il DSO a volte si bloccava ed era necessario riavviarlo English Version: Thanks Luc Specify that the probe was not in contact with the circuitry of the TVC The TVC transformer EAT was removed (absent), then there could be high voltage. The pilot (driver) has the Vpp line 12-15 volts The input block 1 occurred trying to set the Time Base I can now say that the problem was software and ubuntu. With WELECUPDATER I reinstalled the original signature (I Backup) and the DSO has resumed operation. Then I upgraded to 3.0C6 Hayo's great. Now everything seems to work. Before the block I noticed that the DSO sometimes crashed and had to restart
Hi there, I'm just back from holiday in Spain. In the "outback" (Alicante) where I spent my time, I had no internet connection. This is the reason why my answer is coming a little bit later. @wailer You solved Your problem by yourself - well done! @elec + Rainer Tut mir leid wenn im USTB-Bereich Probleme auftreten. Da sind dann wohl doch schon einige Änderungen mit reingerutscht. Zur nächsten Version wird ohnehin alles im USTB-Bereich umgekrempelt, dann hat sich das auch erledigt. Sonst Notfalls downgraden auf auf eine ältere 3er Version. Die C4 oder C5 müßte doch noch funktionieren oder? @Kurt Muß ich irgendwas machen wegen der Bestellung, oder warte ich bis ich von Dir eine Nachricht bekomme? Gruß Hayo
Hayo W. schrieb: > Tut mir leid wenn im USTB-Bereich Probleme auftreten. Hallo Hayo, kein Problem - mit der C5 läuft USTB wie gewohnt. Bezüglich Spikes - die, die synchron auf Ch3 und 4 auftreten - konnte ich zwischen C5 und C6 übrigens keinen rechten Unterschied feststellen. Gruß Rainer
Die Unterschiede sieht man auch nur bei Hardwareeinstellung "High Frequ". Wenn man dann ein Rechtecksignal mit der steigenden Flanke mittig positioniert (z.B. bei 100ns) und auf persistente Anzeige schaltet dann sieht man die Spikes synchron auf Kanal 1 + 2. Gruß Hayo
Hallo Hayo, wie oben schon geschrieben sind weitere Fakten zur Bestellung auf http://sourceforge.net/apps/trac/welecw2000a/wiki/collectiveorder nachzulesen. Die offene Deadline gibt es damit nicht wieder 10 Nachzügler kommen, nachdem die Huckepackplatine von der Firmware unterstützt wird. Mfg, Kurt
Kurt Bohnen schrieb: > Hallo Hayo, > wie oben schon geschrieben sind weitere Fakten zur Bestellung auf > http://sourceforge.net/apps/trac/welecw2000a/wiki/collectiveorder > nachzulesen. Alles klar, dann warte ich also ab, da Du meine Mail ja schon hast. Gruß Hayo
Angehängte Dateien:
-
A_W2022A_compare.jpg
110 KB -
B_W2012A_compare.jpg
110 KB -
C_LeCroy_compare.jpg
120 KB -
D_Yokogawa_compare.jpg
100 KB -
E_Hameg_compare.jpg
100 KB -
F_TDS220_compare.jpg
100 KB -
G_TDS1012_compare.jpg
100 KB -
H_TDS3052_measure.jpg
56 KB -
I_TDS3052.jpg
46 KB -
L_W2022A_5V.jpg
43 KB -
M_W2102A_5V.jpg
45 KB -
N_W2012A.jpg
45 KB -
O_W2022A.jpg
42 KB -
P_HAMEG_FALL_TIME.jpg
42 KB -
Q_HAMEG_RISE_TIME.jpg
41 KB -
R_HAMEG_1500-2.jpg
39 KB -
S_HAMEG_amplitude.jpg
40 KB -
T_LeCroy_WaveAce_224.jpg
55 KB -
U_YOKOGAWA_DL1540.jpg
36 KB -
V_TDS220.jpg
37 KB -
Z_TDS1012.jpg
33 KB
Guten Abend an alle. With a friend, I'm trying to assess the bandwidth of the W2022A and W2012A. It is not so easy, just completed the measures I will explain the matter in detail in the Hardware forum. At this moment I would to talk about some things maybe to be already known. I built a pulse generator which has Rise and Fall time so fast that I can not measure them with precision. The best oscilloscope I could use to calibrate the pulse generator has a bandwidth of 500MHz, but it is inadequate to measure the Rise and Fall times of pulses, which should be less than 300ps, so I preferred to compare the performance of the W2022A and W2012A compared with those of other oscilloscopes with known characteristics. Seems to me the W2022A is better than the W2012A, better frequency and amplitude response. About this last I am not sure due the linearity lack of the Welec. However I noticed some things. A) With the Welec's oscilloscopes, in order to make better measure I must put the trigger level just below the peak of the pulse otherwise the waveform is continually moving. But in this way the signal amplitude increases considerably compared to when the trigger level is set lower. In short, the size of the displayed signal depends on the position of the trigger threshold, if the trigger threshold is low, the amplitude of the signal is so and the waveform is moving, whereas if the amplitude is high it becomes high itself and the waveform is more steady. I had never noticed this thing before, but maybe it is always been so. B) Seem to me when the Rise or Fall time are less than 1nS, in the Quick Measure is show 0,00S not allowing to know which is the measured in true. Ok, it exist the cursors, but also this thing I had never noticed before, but maybe it is always been so. C) Both W2022A and W2012A have the 1.2.BF.3.0_C6 firmware. About this, I have no more spikes problem, but during the measurements I have noticed that "High Frequency" setting in Hardware menù is good for show the inner probe compensation signal but it is inadequate for the fast pulse, so I must to switch it to Test3 to perform the measure: by setting Test3 I can visualize both slow and fast waveform optimally, for me is the better choise with my W2022A and W2012A. Now, I know the 1.2.BF.3.0_C6 firmware fix the spike's problem caused by the hardware's setting "High Freq" by changing the register setting. Have others noticed this? Seems to me strange the better choice is now other than "High Freq" setting, also "Factory" works well without spikes problem. About this, I tried a downgrade on both W2022A and W2012A and i noticed no spikes when I connect an external signal generator, while there are spikes using the internal probe compensation signal. So, I do not know if it was a case or not, but could spikes really be caused by noise coming from the power supply? Mit Freundlichen Grüßen, Luc
Hi Luc, thanks for Your detailed report about pulse response. It would be interesting to find out how the C5-Version with the old High Frequ. setting is working. Maybe I rename the Test 3 setting like "Pulse" or something in this way as hint to use this for quick signals. In the moment I'm a little bit short in time, so I have to stave You off in relation to the next version. But don't worry - it will go on. Kind regards Hayo @all Hi Leute, bin zur Zeit etwas im Stress und muß Euch leider erstmal etwas vertrösten bis zur nächsten Version. Aber nicht verzagen, es geht auf jeden Fall weiter. Bis dahin genießt das schöne Wetter Gruß Hayo
Hello Hayo, I tested the W2022a with FW c2/C5 at 100 MHz 100mV, the best accuracy occures with these settings: ADC :High freq Pregain 1.25 Filter IIR1 .With C6 the accuracy is 1dB less and settings are different. Just one question ,I can't see anymore the higher resolution in the frequency counter,is it possible to see 1 kHz at 100 Mhz carrier? Regards, Alex
Hi Alex and guys all! Alex schrieb: >I tested the W2022a with FW c2/C5 at 100 MHz 100mV, the best accuracy >occures with these settings: ADC :High freq Pregain 1.25 Filter IIR1 It would be possible to see some screenshots, please? I mean a screenshot for each acquisition mode: noise filter off, noise filter smooth, noise filter strong, noise filter IIR 1 stage, noise filter IIR 2 stage and noise filter IIR 3 stage. Due the filter switch in STOP mode this is easy to do. However, should not the best results be obtained without filters? Alex schrieb: >With C6 the accuracy is 1dB less and settings are different. It would be possible to know how the DSO is set for better performances in this case, please? @Alex Alex, is your W2022A a standard version or a modified version? Thanks in advance. Mit Freundlichen Grüßen, Luc
Hello, my W2022A is standard.About the screenshot Let's wait the next version from Hayo. Without any filter at 50MHz and upper the noise cause a level peak error because,up to now,there isn't a sin interpolation available. I only tried C6 ,anyway works well up to 50MHz and fix some issue, now I'm using the previous on the lab. Sandro(Alex)
Hi Alex(Sandro) and guys all! Alex schrieb: >my W2022A is standard. Thank You for the answer! Alex schrieb: >About the screenshot Let's wait the next version from Hayo. Thank You Alex, You are very kindly, then I will wait. Alex schrieb: >Without any filter at 50MHz and upper the noise cause a level peak error >because,up to now,there isn't a sin interpolation available. I know, it was my intention to talk about this. Alex, You tested your W2022A with a 100 MHz 100mV, I guess a leveled signal generator, so have You noticed that signal amplitude depend on the trigger treshold? I mean, when the trigger treshold is not a bit below the waveform's peak it is then continually moving and lower level than when the trigger level is just below the waveform's peak and it is itself more steady and its level has much more great amplitude. In short, the size of the displayed signal depends on the position of the trigger threshold, if the trigger threshold is low, the amplitude of the signal is so and the waveform is moving, whereas if the amplitude is high it becomes high itself and the waveform is more steady. Maybe it is due sin(X/X) lack, maybe it is for ather reasons... I tested both W2012A and W2022A up to 170MHz and they work well, if it were not for a lack linearity problem and poor representation due up to now there is not a sin(X/X) interpolation available. From my test on high frequencies the W2022A is better than the W2012A. Both W2012A and W2022A I tested are not modified unit, they are standard manufactured by Welec. Alex schrieb: >I only tried C6 ,anyway works well up to 50MHz and fix some issue, now >I'm using the previous on the lab. Can you kindly tell us how your W2022A is set for the better performances with the C6 release? I mean the Hardware menu's settings and the Filter setting in the Aquire menu. Thanks in advance. Mit Freundlichen Grüßen, Luc
Hallo Leute Ich habe vor ein paar Tagen ein Welec W2024A geerbt. Nach der ersten Euphorie kam nach einem Vergleich mit meinen anderen Oszis schnell die Ernüchterung. (Ich Arbeite sonst mit einem Hameg HM1005 und einem Tektronix TDS 340). Gestern habe Ich mich dann getraut die Kiste zu Flashen dabei ist mir aufgefallen das eure Flashsoftware ein Problem mit unterschiedlichen COM Ports zu haben scheint. Zuerst auf COM 1 kam immer wieder die Meldung wie oben beschrieben mal Abbruch in Zeile 30 mal in 234 u.s.w. ein Neustart des PC konnte auch nicht helfen, nach ca. 20 missglückten versuchen habe Ich dann mein Glück mit COM 2 Probiert und da funktioniert es immer. (Die W2000 Update Software funktioniert bei mir überhaupt nicht b.z.w. behaupte immer „File not Found“). Ich habe jetzt die Letzten 3 Versionen eurer Firmware ausprobiert und muss sagen Ihr habt ganze Arbeit geleistet Kompliment!!!! Mir ist aber auch aufgefallen das die angezeigten Spannungen nicht korrekt sind b.z.w. ca. 60% zu hoch angezeigt werden. Aus 10 V PK-PK werden bei mir 16V PK-PK. „Version 3.0_C6“ Mache Ich hier etwas falsch oder liegt das an den (Noch nicht vorgenommenen Hardware Änderrungen)? Ich habe leider keine Bedienungsanleitung und alles was Ich im Netz gefunden habe ist in English und beinhaltet sicher auch nicht eure Änderrungen. Gibt es vielleicht eine Bedienungsanleitung die einem Einsteiger die Funktionen des Geräts erklärt? Ich habe gesehen das ihr eine Huckepack Platine entworfen habt wenn das möglich ist würde Ich mich an der Sammelbestellung noch ganz gerne beteiligen. Ich hoffe meine Erfahrungen helfen euch weiter. Gruss Rudi
Hallo Rudi, unser Wiki kennst du schon? http://sourceforge.net/apps/trac/welecw2000a/wiki Da gibt es auch eine Seite mit Infos zur Sammelbestellung: http://sourceforge.net/apps/trac/welecw2000a/wiki/collectiveorder Mfg, Kurt
Hallo Rudi, > (Die W2000 Update Software funktioniert bei mir > überhaupt nicht b.z.w. behaupte immer „File not Found“). die originale Upd-Software ist Schrott, dauert auch viel zu lange! Am schnellsten ist der Germsloader, da muß aber das komplette Paket heruntergeladen werden... Hier der Link für die neuen Downloader, müssen nicht installiert werden und funktionieren einwandfrei: ---Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil4)" > Mir ist aber auch aufgefallen > das die angezeigten Spannungen nicht korrekt sind b.z.w. ca. 60% zu hoch > angezeigt werden. Aus 10 V PK-PK werden bei mir 16V PK-PK. „Version > 3.0_C6“ Ich habe auch im Leerlauf so um die 400-600mV Pk-Pk(bei jeder Version), egal welchen Filter ich einschalte...Hayo wird's schon richten :-) > Ich habe gesehen das ihr eine Huckepack > Platine entworfen habt... Schick mir mal eine PM, habe einen kompletten Satz inkl. Platinen abzugeben. Gruß Michael
Hallo Ja genau diese Uploader habe Ich benutzt!!! Bei offenen Eingängen ist das mehr oder weniger Normal da kommen natürlich Einstreuungen rein oder Leck ströme an den Sperrschichten der Eingangs OPs bei anliegendem Signal sind 60% Abweichung aber nicht akzeptabel mal schauen wie es nach dem Hardwareupdate aussieht. Rudi
Was für ein Signal hast du denn eingespeist? Das Welec ist zwar kein Präzisionsgerät aber 60% Abweichung hat es definitv nicht solange man sich nicht in höheren Frequenzbereichen bewegt. Gruß Michael
Hallo,
ich habe ein 4-Kanal-Welec (W2014A, sofern das überhaupt eine Rolle
spielt) abzugeben.
Das Gerät besitzt das Schirmblech aus galvanisch verzinntem Stahlblech,
die DACs sind bereits auf die 16 bit Version umgerüstet und Kanal 4 ist
für die Huckepackplatine vorbereitet, sprich die originale Eingangsstufe
ist entfernt.
Die anderen Kanäle besitzen die 24.9 Ohm (0.1%) Widerstände vor den
ADCs.
Zum Scope kommen drei fertig aufgebaute sowie vier nicht bestückte
Huckepackplatinen hinzu.
Zum Gerät gehören die vier Tastköpfe.
Als Bonus gibt es einen meiner selbstgebaut aktiven Tastköpfe V4b dazu.
Bei Interesse mailt einfach an: branadic [ed] users (punkt) sf {punkt}
net
branadic
Müssen wir uns Sorgen machen? Das klingt ja fast nach Projektaufgabe! :-( Alex braucht dringend einen 4Kanäler, finde ich. Wenn das Leon-Design mit 4 Kanälen arbeiten würde wäre ich schon längst mit Feuer und Flamme dran am Software-schreiben. Ich würde Alex auch einen Teil des Gerätes sponsorn. Ich tue schon mal 50€ in den virtuellen Pott. Machen noch mehr mit? Wie stünde Alex dazu? Jörg
Jörg H. schrieb: > Ich würde Alex auch einen Teil des Gerätes sponsorn. Ich tue schon mal > 50€ in den virtuellen Pott. Machen noch mehr mit? Wie stünde Alex dazu? Ich bin dabei, Betrag unbenannt. Warten wir auf Alex.
Ok, ich geb auch was zu (wenn Interesse). Viele Grüße, Egberto
Ach ja, Hayo hatte sich ja irgendwie gegen jedes Sponsering ausgesprochen - da würde ich aber noch viel mehr hin überweisen (wenn Interesse ;-)) Viele Grüße, Egberto
Hallo Das Eigespeiste Signal liegt zwischen 1Hz und 10Mhz Sinus Dreieck Rechteck. also nichts besonderes. Rudi
Jörg H. schrieb: > Müssen wir uns Sorgen machen? > Das klingt ja fast nach Projektaufgabe! Genau das ist es. Ich möchte Projektleichen loswerden und für mich zählt das Welec mittlerweile dazu. Ein kurzer Abriss: Im Oktober/November 2009 haben Walter und ich die erste Version der Huckepackplatine entworfen und gelayoutet, im Februar 2010 wurde die erste Version dann vorgestellt und vermessen. Dieser Version sind drei weitere Versionen gefolgt. Im Dezember letzten Jahres wurde der Einbau der finalen Version dokumentiert und die erzielten Möglichkeiten vorgestellt. Bis heute hat die Huckepackplatine keine Softwareunterstützung erfahren und ich sehe offen gestanden auch nicht, dass sich daran was ändern wird. Auch das Leon-Design wird noch eine ganze Weile brauchen. Alex ist mittlerweile berufstätig und zeitlich eingeschränkt, nicht zuletzt dank Freundin. Im Laufe des Projektes sind unzählige Leute, die anfangs mit Eifer dabei waren, heimlich still und leise untergetaucht und waren nicht mehr gesehen. Als Walter das Projekt verlassen hat gab es einen kurzen Aufschrei und die Unterstützung der Huckepackplatine ist in der Prioritätenliste ganz nach oben gerutscht. Davon ist nicht viel über geblieben. Salz macht aus Wasser noch lange keine Suppe und die Änderungen an der Firmware mögen Hayo wichtig erscheinen, aber mir genügen diese schon lang nicht mehr, zu viel Schein, zu wenig echte Funktionalität, viel zu viel für das Auge. Für mich steht das Projekt seit der Fertigstellung der Huckepackplatine still. Unzähliges Nachfragen, wann die Huckepackplatinenansteuerung in Angriff genommen wird, hat nicht den Erfolg gebracht. Daher meine Entscheidung, ich bitte diese zu verstehen. branadic
Aber das ist doch kein Grund die Flinte ins Korn zu werfen. Ich würde meine Basteleien nie für Geld verkaufen, da steckt ja unbezahlbarer Aufwand drin. In diesem Fall fände ich es auch etwas unfair euren "Kunden" gegenüber. Letztes Wochenende hätte ich meine Huckepackplatinen fast bestückt, wenn mir ein Kollege nicht das Equipment abgezogen hätte. Steht auf jeden Fall noch auf der Liste. Supportest du den Einbau noch, auch wenn du selber keine Platinen hast? Jörg
Jörg H. schrieb: > Aber das ist doch kein Grund die Flinte ins Korn zu werfen. > Ich würde meine Basteleien nie für Geld verkaufen, da steckt ja > unbezahlbarer Aufwand drin. Eben. Und genau das legt die Vermutung nah, dass der plakative Ausstieg eher ein Statement¹ ist. Sowas gibt es (auch) in der Open-Source-Szene regelmässig. Meine Empfehlung: nicht groß drüber nachdenken. /Hannes ¹) Das Statement lautet: "Ihr nehmt mich und meine Arbeit nicht ausreichend ernst/wichtig, also hab ich euch nicht mehr lieb."
Johannes S. (johannes_s94) schrieb: > Das legt die Vermutung nah, dass der plakative Ausstieg > eher ein Statement¹ ist. Sowas gibt es (auch) in der Open-Source-Szene > regelmässig. Stimmt, das scheint bei manchen Leuten an der Tagesordnung zu sein. Beitrag "Projekt: DDS basierter Funktionsgenerator mit AD5930" Aber deswegen nicht entmutigen lassen und vor allem nicht um Gnade winseln. Grüße Klaus Bauer
Jörg H. schrieb: > Aber das ist doch kein Grund die Flinte ins Korn zu werfen. > Ich würde meine Basteleien nie für Geld verkaufen, da steckt ja > unbezahlbarer Aufwand drin. > In diesem Fall fände ich es auch etwas unfair euren "Kunden" gegenüber. Hallo Jörg, die Entscheidung muss man mir überlassen. Ich habe genug Baustellen zu bedienen, da kann ich auf die ein oder andere Dauerbaustelle gut und gern verzichten. Jörg H. schrieb: > Supportest du den Einbau noch, auch wenn du selber keine Platinen hast? Klar, das hat Walter angeboten und das gilt für mich gleichermaßen. Johannes S. schrieb: > Eben. Und genau das legt die Vermutung nah, dass der plakative Ausstieg > eher ein Statement¹ ist. Sowas gibt es (auch) in der Open-Source-Szene > regelmässig. > > Meine Empfehlung: nicht groß drüber nachdenken. > > /Hannes > > ¹) Das Statement lautet: "Ihr nehmt mich und meine Arbeit nicht > ausreichend ernst/wichtig, also hab ich euch nicht mehr lieb." Klaus Bauer schrieb: > Stimmt, das scheint bei manchen Leuten an der Tagesordnung zu sein. > > Beitrag "Projekt: DDS basierter Funktionsgenerator mit AD5930" Noch einmal, ich bin niemandem Rechenschaft schuldig und die Entscheidung treffe ich ganz allein für mich, dazu brauche ich kein Feedback von irgendwelchen Leute die meinen sich nur aktiv beteiligen zu müssen, wenn man mit dem Knüppel auf jemanden hauen kann und sonst nicht konstruktives beitragen. Die Gründe für meine Entscheidung sind auch ganz allein meine Sache und hat euch nicht zu interessieren. Ich euch, lasst jedwede Unterstellung oder Verleumdung meiner Person, das gilt insbesondere für Johannes S. und Klaus! Danke, branadic
branadic (Gast)schrieb: > Ich habe genug Baustellen zu > bedienen, da kann ich auf die ein oder andere Dauerbaustelle gut und > gern verzichten. Frage: Entsteht mal aus den vielen "Baustellen" was produktives, oder muß man mit unfertigen Projekten weiterleben. Ich finde es unfair gegenüber den (nicht technisch Entwicklungsbegabten) Leuten hier Hoffnungen vorzugaukeln, worauf diese sich Bauteile zulegen welche danach nutzlos sind. Darüber sollte mal nachgedacht werden. Gruß Klaus
Klaus Bauer schrieb: > branadic (Gast)schrieb: > >> Ich habe genug Baustellen zu >> bedienen, da kann ich auf die ein oder andere Dauerbaustelle gut und >> gern verzichten. > > Frage: Entsteht mal aus den vielen "Baustellen" was produktives, oder > muß > man mit unfertigen Projekten weiterleben. > Ich finde es unfair gegenüber den (nicht technisch Entwicklungsbegabten) > Leuten hier Hoffnungen vorzugaukeln, worauf diese sich Bauteile zulegen > welche danach nutzlos sind. > Darüber sollte mal nachgedacht werden. > > Gruß > > Klaus Ich kenn dich nicht und habe mir dir nichts zu tun, ich bin dir zu nichts verpflichtet und wenn du der Meinung bist technisch unbegabt zu sein, so steht es dir frei das zu ändern! Aber versuche nicht mich für deine Unfähigkeit in die Verantwortung zu ziehen! Es wurde keine Hoffnung vorgegaulkelt, sondern eine Lösung erarbeitet. Diese Lösung hat bisher keine Unterstützung gefunden und damit ist das Thema Welec für mich beendet. Alle Imformationen zur Huckepackplatine sind veröffentlicht worden und für jedermann frei zugänglich, was willst du eigentlich noch? Hast du auch nur eine Minute mit in die Entwicklung gesteckt? Du hast doch bisher alles mundgerecht bekommen, ohne selbst etwas beigetragen zu haben! Ich versteh gar nicht, warum hier von der "Knüppeltruppe" so ein Wind gemacht wird. Andere Mitwirkende haben sich irgendwann einfach nicht mehr gemeldet. Hat da jemand was gesagt? Als Walter sich vom Projekt verabschiedet hat, hat da irgendwer das Motzen angefangen? Warum wird jetzt wo ich klipp und klar sage das ich keine Lust mehr auf dieses Langzeitprojekt habe, weil ich ein Messmittel brauche und keine Entwicklungsplattform, so ein Wind gemacht? Die Huckepackplatine ist fertig entwickelt und muss nur noch eingebaut und durch die Software unterstützt werden. Noch einmal ganz klar für dich Klaus, lass die Unterstellungen gegenüber meiner Person. Du musst mit keinem meiner Projekte leben, ich bin nicht zu deiner Unterhaltung da. Die Entwicklung der Huckepackplatine ist abgeschlossen!!! Abgeschlossen!!! Das Welec bleibt aber eine Baustelle, solange das neue FPGA-Design mit der neuen Firmware nicht die neue Basis bilden und die Huckepackplatine unterstützen. Ich möchte nicht mehr länger warten bis das so weit ist, weil ich, ich sage das noch einmal, ein Messmittel und nicht länger eine Entwicklungsplattform brauche. Ich hoffe das ist jetzt auch endlich bei dir angekommen. Statt in Foren zu pöbeln solltest du die Energie lieber dazu verwenden, dich in die Themen einzuarbeiten, um selbst auch mal etwas, wie du es so schön formuliert hast, produktives beizutragen! Frage: Ist das jetzt endlich auch bei dir angekommen? branadic
Ich habe großen Respekt vor branadic, hayo, alex und all den andern die dieses Projekt so weit gebracht haben, danke. Ich kann auch nicht verstehen, dass manche Leute jetzt hier rumpöbeln, gerade über Menschen die sich hier besonders eingebracht haben. Ich habe das Projekt gern verfolgt, dass es jetzt vorläufig nicht weitergeht ist bedauerlich. Alle die wie ich bis jetzt sich nicht aktiv an der Entwicklung beteiligt haben, aber Interesse am Fortgang haben, können sich jetzt an die eigene Nase fassen. @branadic: Willst du dein Welec Equipment nicht liebe einmotten, wäre doch schade wenn hier doch noch was zustande kommt und du nicht davon profitieren würdest. Gruß Stefan
Kleiner Vorschlag am Rande: ímmer wenn man veröffentlichte Oszillogramme in Fachzeitschriften oder sonstwo sieht, sieht man auf den ersten Blick dass es sich um ein Bild eines Tektronix Geräts handelt weil in der linken oberen Ecke das "Tek" steht. Wie wäre es wenn sowas auch hier gemacht würde? Ich fänds lustig. Besonders wenn sich manche Leute auf einmal fragen: was ist das denn für ein Hersteller? Das sieht ja richtig gut aus von Funktionsumfang und Design her... Falls es umgesetzt werden sollte fragt sich nur: was für ein Kürzel?
moin,
> Falls es umgesetzt werden sollte fragt sich nur: was für ein Kürzel?
Gute Idee! Als Kürzel käme ja eigentlich nur " WT " in Frage...
Ansonsten fände ich die "Sinuskurve" ganz schick...
Ack kommt wohl von der Antwort in Bussystemen die ein Slave als "zustimmung" sendet. I²C hat dies z.B. soviel ich weiß. Gruß Andi
branadic (Gast) schrieb:
> Frage: Ist das jetzt endlich auch bei dir angekommen?
Antwort : JA, ich hoffe bei all den anderen nicht so technisch
hochbegabten auch.
Klaus
Hayo!! Where are you gone? :-) Regards, Paolo P.S:: since your last firmware update, the WELEC become semi-officially my Laboratory DSO.
Hallo! Ich finde es auch sehr schade, dass wir keine neuen Entwickler für das Open Source Projekt mehr finden. Unsere zwei größten Mankos sind, dass wir einerseits zu wenig im Internet präsent sind, und dass den meisten Open Source Entwicklern die Kompetenzen für so eine Embedded Systems Programmierung fehlt. Leider schauen die meisten Personen nur auf den kurzzeitigen Erfolg, da man mit dieser Strategie die größten positiven Rückmeldungen bekommt. Mit Hayos Verbesserungen der Software mit dem originalen FPGA-Design ist leider die Warscheinlichkeit von Nachschub an Entwicklern für das LEON3-FPGA-Design stark geschrumpft. Hayo hat es geschafft, dass die meisten Nutzer mit dem Oszilloskop zufrieden sind. Was aber klar ist, dass dieses Oszi so niemals überall so gut oder besser wie die Markenoszilloskope sein wird. Branadic hat mit Walter meiner Meinung nach eine sehr gute Arbeit beim analogen Frontend gemacht. Wenn ich bei der Entwicklung des LEON3-Zeug schon weiter wäre, hätte ich das sicher schon integriert. Schließlich sollte man möglichst versuchen, die eingebrachten Fähigkeiten und Arbeitsleistungen anderer möglichst versuchen zu Integrieren und zu Ergänzen, da man sonst irgendwann nur mehr alleine weiter entwickelt. MfG Alexander
Hallo zusammen. Ich hätte folgenden Vorschlag: schreiben wir doch (von mir aus ich) einen Artikel für das embedded projects journal. Da erreicht man Leute, die sich für Open Source begeistern und durchaus auch sehr fähige Menschen, jedenfalls gibt es dort immer wieder ganz interessante Projekte. Man könnte auch versuchen, Alex' Weg fortzuführen und Professoren kontaktieren, um Diplomanden für das Projekt zu gewinnen. Ich z.B. habe nach wie vor guten Kontakt zu einem Professor, der selbst in Sachen VHDL sehr versiert und auch aktiv ist - der könnte evtl. Studenten dafür gewinnen. Denn meiner Erfahrung nach wollen viele was in Richtung VHDL machen, finden aber kein passendes Thema in der Industrie. Mir ging es übrigens auch so, genauso wie einem Masterstudenten den wir zur Zeit in der Arbeit beschäftigen. Leider habe ich selsbt keine Zeit um einen wirklich sinnvollen Beitrag zu leisten aber das könnte doch ein Weg sein... Eure Meinung? Gruß Michael
>Da erreicht man Leute, >die sich für Open Source begeistern und durchaus auch sehr fähige >Menschen Zumindest an der Firmware hier ist es sehr schwer sich zu beteiligen. Die letzte Aktualisierung des Codes in Sourceforge ist 6 Monate her (stammt noch von mir) und den Quellcode hier rauszusuchen wird sich auch keiner antun. Zumindest hatte ich darauf irgendwann keine Lust mehr und habs einfach gelassen. Von daher mach es für mich keinen Sinn, Leute extra für die Firmware anzuwerben. In diesem Sinne.
Hallo Michael! Deine Idee mit dem embedded projects journal finde ich sehr gut. Ich würde mich sehr über so einen Beitrag freuen. Vor allem sollte betont werden, dass sich das Welec Oszilloskop quasi als Open Source Prototyping Plattform sehr gut eignet (Verfügbarkeit, Doppelnutzen,...). Unser langfristiges Ziel ist ein vollkommen offenes Oszilloskop mit hoher Qualität zu schaffen. Zur VHDL- und Firmware-Entwicklung schadet die mäßige Signalqualität nicht. Weiters sollte auf die Möglichkeit der Adaptierung auf hochauflösenenden ADCs hingewiesen werden (Doku dazu gibts aus Mangel an Interesse im Moment keine). Übrigens ist der Zustand des VHDL-Design wirklich schon reif für ein Release. Das größte Manko liegt an der Firmware, die noch weit von einem Release entfernt ist. Die Dokumentation habe ich im Moment auch nur sehr minimalistisch ausgeführt, da den zuküftigen Softwareentwicklern fertig programmierte Hardwareschnittstellen mehr bringen und ich zugleich die von mir geschriebene Hardware testen kann. @Stefan: Die Originalsoftware verbessern bringt nur den Wittigs und den Besitzern des Welec was, sonst niemanden. MfG Alexander
Hallo Alex. Es ist ja toll, dass du das VHDL Design schon zur Einsatzbereitschaft gebracht hast, dafür zolle ich dir meinen größten Respekt! Dann werde ich mal zusehen, dass ich einen Artikel entwerfe. In Bezug auf dein VHDL/Leon3 Design werde ich dann vermutlich aber auf dich zukommen müssen, da ich darüber leider noch nicht sonderlich viel weiß. Ich könnte mir vorstellen, dass einige Leute bei dem Projekt Open Source Oszi hellhörig werden, hoffentlich täusche ich mich da nicht. Wenn die Programmiermaschine Hayo wieder mehr Zeit hat, kann er sich ja vielleicht auch mit dem Thema Leon3 beschäftigen, dann wären Fortschritte garantiert, allerdings wäre es dann natürlich toll wenn es mit svn klappen würde... Ich finde es übrigens ziemlich schade, dass branadic aufgegeben hat. Vielleicht wird es ja trotzdem noch was mit der Huckepack Unterstützung, dann wäre die Arbeit von ihm und Walter nicht vergebens gewesen. Gruß Michael
Ich bestücke gerade meine Eingangsplatinen... Bis später, Jörg
Von mir auch nochmal ein großes Danke an die die hier mitbearbeitet haben und werden. Ihr habt aus dem Scope ein für mich verwendbares Werkzeug gemacht. Ich beschäftige mich mit Elektronik nur als Hobby und nicht beruflich, konnte so leider hier auch nichts beitragen - aber von eurem Einsatz profitieren. Für das Geld, das es mich die Anschaffung gekostet hat, habt ihr und das umsonst, den Nutzen des Gerätes für mich mehr als verdoppelt. DANKE Ich hoffe, dass es weitergeht und wünsche allen hier beteiligten mindestens so viel Spaß am Hobby, wie es mir bereitet.
Hi @ all.sich I'm just alive, so don't worry! Work will go on soon... Hallo allerseits, leider hatte ich in letzter Zeit etwas wenig von selbiger für unser Projekt. Mit Bedauern lese ich, dass Branadic sich aus dem Projekt zurückzieht. Ich weiß, dass sich das mit der Hardwareunterstützung etwas hinzieht. Ich möchte aber nochmals darauf hinweisen, dass zeitweilige Entwicklungspausen kein Grund zur Besorgnis sind. Da ich berufstätig bin ist die Zeit manchmal etwas knapp. Die beste aller Ehefrauen ist da wirklich sehr tolerant, wenn man bedenkt wieviel Zeit ich schon in das Projekt gesteckt habe. Ich möchte ebenfalls darauf hinweisen, dass ich das Ganze aus reinem Spass an der Sache mache. Ich könnte mir ohne Weiteres auch ein 3000,- Euro Gerät kaufen wenn es mir darauf ankäme. Nur würde das keinen Spaß machen! Zu den beschriebenen Problemen: - das mit den falschen Messwerten werde ich mal prüfen und ggf. korrigieren - ich stelle in den nächsten Tagen mal eine weitere Compilation bereit bei der die USTB-Bereiche wieder gehen. Noch einen sonnigen Tag Hayo
So, die Platinen sind bestückt. Hat deutlich länger gedauert als ich dachte, mit Bauteilgröße 0402 ist das doch sehr fummelig. Gut das Kurt etwas Reserve in die Tütchen gepackt hat, ein paar von den Sandkörnern sind mir aus der Pinzette gehüpft, natürlich auf nimmerwiedersehen. Nun habe ich den Compiler vorgewärmt und Hayos Software in der Version C6 zum Üben durchkompiliert. Spricht eigentlich was dagegen, die im Sourceforge-Branch "bf" einzuchecken, zur ggf. gemeinsamen Arbeit? Dort liegen anscheinend ältere Sourcen. Ich kenne die Arbeitsweise hier zugegeben nicht. Ich Noob suche mir gerade zusammen, wie denn die Ansteuerung der Platine zu machen wäre, bin für Starthilfe dankbar. Ist diese Schaltplanänderung von Kurt aktuell? Trägt das auch für 4Kanäler? Beitrag "Re: Wittig(welec) DSO W20xxA Hardware" Wenn ich das recht deute wird aus dem 16-Bit Schieberegister aus U23/U21 dann ein 24-Bit Schieberegister U23/U21/U24. Die Chip-Selects der Eingangsstufen werden daraus gewonnen. Sind die anderen Ausgänge von U24 obsolet? Macht das FPGA auch 24-Bit breite Shifts? Um unsere Chip-Selects wieder wegzunehmen muß U24 neu "befüllt" werden. Machen die Takte dann nicht unsere Daten im LMH651 kaputt? Mir ist auch noch nicht klar, wie SPI von der Software aus bedient wird. Wie werden die von U25 erzeugten Chip-Selects programmiert, wie die Anzahl der Shifts eingestellt? In der Software wird fleißig auf serdata->np_piodata zugegriffen, der Transfer anscheinend mit serstartsw->np_piodata ausgelöst. Jörg
Ich antworte mir mal selbst, mit meinen Forschungsergebnissen von gestern. Bin durch Hardware und Software gekrochen. Die SPI-Hardware im Nios-Design macht mehr selbst als ich dachte. Der Chip-Select Adressdecoder U5 wird vom obersten Hex-Digit des Registerwerts serdata->np_piodata eingestellt, genau genommen Bits 22:20. Die Länge des Schiebetransfers ist entweder immer 24 Bit, oder (was ich nicht hoffen will) von den Bits 22:20 abhängig. Die DACs brauchen 24 Bit, die Schieberegisterketten 8 oder 16. Um das genauer rauszufinden muß ich mir da Drähte anlöten, zum Logic Analyzer, um das im Betrieb zu messen. Den Anschluß der Huckepackplatinen stelle ich mir daher etwas anders vor. Ich hoffe das FPGA schiebt auch 24 Bit an Daten wenn Register Bits 22:20 gleich Null sind, also keiner von den bestehenden Chip Selects aktiv ist. Dann können wir die Platinen direkt an SPI Clock und Data anschließen, nicht hinter ein Schieberegister. Auf den Platinen müssen die Pullups entfallen oder vergrößert werden, denn die SPI-Signale sind wegen der Transistorschaltung Q9,Q10 speziell nach low recht schwach. Den Schieberegistern habe ich ein Stück weit hinterhergemessen. In Brunos Bestückungsplan "Analog-Input-Part_assignment_V3_4.pdf" ist eine Diskrepanz zum Schaltplan, die mich in die Irre führte. Sein U21 ist in Wirklichkeit U23. U21 ist auf der anderen Platinenseite, unter dem Abschirmkäfig von Kanal 1. Wo ich gerade bei den Bauteilbezeichnungen der Schieberegister bin: Das im Plan unbeschriftete MC4094 (unterhalb vom 74HCT238, der U23 wäre) ist U22. Weiter rechts und nicht mehr im Bild sind zwei weitere Schieberegister, wie die heißen weiß ich noch nicht. Wieder auf der anderen Seite, nahe der seriellen Buchse ist U26. Ich bin glücklicher Besitzer eines Stereomikroskops, zum Löten der Platinen sehr nützlich. Gestern habe ich Sittenstrolch damit den Schieberegistern zwischen die Beine geguckt um zu sehen welche Ausgangsleitungen tatsächlich noch unbeschaltet sind. Wir brauchen ja 4 Stück für die Chip Selects der Eingangsplatinen. Der Schaltplan ist da noch recht unvollständig. Auf der den Chips der Oberseite gehen von allen Ausgängen Leiterbahnen weg, die sind also anscheinend alle belegt. Auf der Unterseite sind insgesamt 6 Ausgänge frei, aber ungünstig verteilt, jeweils 3 bei U21 und U26, an verschiedenen Positionen. Dann nehmen wir wohl besser Ausgänge die an die alten Eigangsstufen gehen und deshalb obsolet werden. Wie störempfindlich sind die neuen Eingangsstufen eigentlich? Sollte man die besser mit in die Abschirmkäfige löten? Dann sähe es auf der Platine vielleicht auch nicht so schlimm aus, das Gebastel wäre versteckt. So long, Jörg
Hallo Jörg, ich sehe Du kniest Dich da voll rein. Wenn Du firmwareseitig Unterstützung brauchst sag Bescheid.. Ich kann Dir dann die Stellen sagen an denen Du im Coding eingreifen mußt. Gruß Hayo
@Hayo: Danke, ich melde mich. Du meinst warscheinlich die Funktion Hardware::SetSwitches(). Dort werde ich verzweigen müssen, je nach Eingangsstufe. Gibt es auf der Tastenplatine eigentlich noch freie Eingänge, die man als Kennung anders brücken könnte? Dann brauchen wir keinen Konfigurationsdialog ob alte oder neue Eingangsstufe. @All: Ich messe gerade mit dem Logicanalyzer wie das FPGA denn den SPI bedient. Leider tut es das bereits maßgeschneidert für die jeweilige Empfangskette, nicht generisch. Die Anzahl der erzeugten Bitclocks ist genau passend, 8 Bit für Chip Selects mit einem Schieberegister, 16 Bit für Chip Selects mit zwei Schieberegistern, 24 Bit für die DAC-Chipselects. Für letzere wird Enable während der Bits gehalten, für die Schieberegister ist es ein Strobe hinter den Bits. Von daher klappt es nicht, irgendwelche Register umzuketten oder sich dahinter zu hängen. Für Adressbits = 0 wird gar kein Signal erzeugt. Ich habe aber eine Art Lücke gefunden: Für die eigentlich nicht vorhandenen Adressen 8 und 9 (der Demux kümmert sich nur um 0 bis 7) werden auch Daten rausgetaktet, und zwar 16 Bit wie für 2 Schieberegister. Der Adressdekoder U25 kriegt eine 0, erzeugt dann also keinen verwendeten Chip Select. Eigentlich genau das was ich suchte, außer das wir 24 Bit brauchen. Man muß so eine Adresse also zweimal beschreiben. So long, Jörg
Hallo Jörg! Es freut mich zu lesen, dass du für die nette Huckepack-Platine eine Software-Unterstützung dazufügst. Das ist für mich aus Respekt für die geleistete Arbeit von unseren Analogtechnikern ein muss. Das der NIOS die SPI Ansteuerung in Hardware gemacht hat, schreckt mich ein wenig und erklärt auch ziemlich, weshalb das noch nicht vorher (erfolgreich) in Angriff genommen wurde. - Selbst ich habe nur das eine Oszi und keinen Logic-Analyser zur Hand. Anfangs hatte ich die SPI Ansteuerung auch beim LEON3 Design in Hardware vorgesehen. Während ich die Software-Treiber dafür schrieb, fiel mir aber auf wie blöd so eine zugescheiderte Ansteuerung in einem möglicht portablen FPGA-Design ist, und habe das ganze auf GPOs zurückgebaut. MfG Alexander
Jörg H. schrieb: > @Hayo: > Danke, ich melde mich. Du meinst warscheinlich die Funktion > Hardware::SetSwitches(). Dort werde ich verzweigen müssen, je nach > Eingangsstufe. Jupp, eine (ganz kleine) Verzweigung ist schon drin für Gain 1,25. Ansonsten habe ich alles kommentiert was sich mir so an Funktionen erschlossen hat. Der WELEC-Programmierer war mit Kommentaren und Doku ziemlich geizig... > Gibt es auf der Tastenplatine eigentlich noch freie Eingänge, die man > als Kennung anders brücken könnte? Dann brauchen wir keinen > Konfigurationsdialog ob alte oder neue Eingangsstufe. Keine Ahnung, die Idee ist gut, aber ich finde das mit dem Konfigmenü auch nicht so schlimm. Gruß Hayo
Muss man überhaupt unterscheiden? Wer die Huckepackplatine nicht hat, den stört doch das Bitgewackel nicht. Und wer den ursprünglichen Eingang nicht nutzt, dem kann doch egal sein, wie der eingestellt ist?
Guido schrieb: > Muss man überhaupt unterscheiden? Wer die Huckepackplatine > nicht hat, den stört doch das Bitgewackel nicht. Und wer > den ursprünglichen Eingang nicht nutzt, dem kann doch egal > sein, wie der eingestellt ist? Ich widme eine Steuerleitung der alten Eingangsstufe um, zu einem Chip Select für die neue. Von daher stört es, diese Leitung muß penibel bedient werden. Und wenn man (wie ich) nicht alles auslötet, dann muß der letzte Analogschalter der alten Stufe offenbleiben, sonst muß man ihn entfernen. Die neue Eingangsstufe hat zudem mehr Möglichkeiten, das könnte man in Zukunft nutzen. Die Verstärkung ist fein einstellbar, die Bandbreitenbegrenzung hat mehrere Stufen. Der SPI-Bus kann nicht lesen, nur schreiben, die Einstellungen erfolgen blind. Sonst ginge das damit ganz gut. Man könnte das Oszi theoretisch über das gemessene Signal "erfühlen" lassen, welche Eingangsstufe es hat. Aber erstmal muß es überhaupt funktionieren. Ich komme frühestens am Wochenende dazu. @Hayo: Viele Variablen werden ins Flash geschrieben und davon wieder gelesen, und da gibt es noch auskommentierte Lücken. Ich habe nun 4 Flags neu eingeführt, die pro Kanal anzeigen ob alte oder neue Eingangsstufe. Kann ich mir eine solche Lücke aussuchen, oder muß das aus irgendwelchen Kompatibilitätsgründen frei bleiben? Jörg
Ich such Dir mal 4 raus. bzw. da es ja eine long Variable ist, könnte man natürlich auch alle vier Flags in einen Speicherplatz mergen. -> ich sag gleich bescheid Hayo
Also da es sich ja um eine feste Hardwareinformation handelt gehört das ja eigentlich ins Protected Flash. Du könntest die Flags ab Speicherplatz 80 ablegen. Wenn Du die Flags lieber ins normale Config Flash schreiben willst würde ich empfehlen die Werte in der jeweiligen Kanalsektion unterzubringen. Da bieten sich z.B. an: Speicherplatz 74/92/110/128 -> also nicht zusammenmergen. Gruß Hayo
Ein kleines Statusupdate zur Eingangsplatine: Sie funktioniert, und ich habe sie softwaremäßig "unter Kontrolle". Zwar noch nicht an allen Stellen der Software, bei Spezialitäten wie Autorange arbeitet die nämlich an ihren eigenen Funktionen vorbei. Es sind auch noch keine Kalibrierwerte drin und keine Konfigurationsmöglichkeit. Ich habe die Einstellungen welcher Kanal welche Eingangsstufe hat aber immerhin schon wie von Hayo vorgeschlagen im Protected Flash abgelegt. Der Anschluß an SPI kann leider doch nicht so wie von mir vorgeschlagen erfolgen. Der Chip auf der Eingangsstufe mag es nicht, wenn ich ihm zu lange Datenworte sende. Ich hoffte, er ignoriert die überzähligen Bits, aber stattdessen akzeptiert er das ganze Datenwort nicht. Nun wurde es doch "SPI over SPI", Bitbanging mit den bereits über SPI angesteuerten Registerausgängen. Ist nicht schlimm, nichts wird langsamer, der Zugriff paßt locker in die Zeit die eh auf die Relais gewartet wird. Etwas blöd ist nur, daß man sich 2 Signale von der anderen Seite der Platine holen muß. An der Hardware der Platinen ist noch Feintuning nötig. Momentan sind das kleine UKW-Sender, sie schwingen etwas. Andre und sogar Walter helfen mir netterweise (siehe Skype-Chat), die kriegen das bestimmt hin. Wenn ich in dieser Software rumfummele kriege ich Zustände. Eigentlich wäre das ja ganz einfach, wenn man eine vernünftige Hardwareabstrakion hätte und sich dran halten würde. Aber hier sind die Dinge unnötig kompliziert, vieles ist für die 4 Kanäle 4 mal codiert (schon mal was von Arrays gehört?). Das bläht den Code auf und man wartet lange auf den seriellen Download. Es juckt, da neu anzufangen und eine Codebasis zu schaffen, die bis auf eine Hardwareschicht unverändert auch auf dem Leon-Design laufen könnte. Ich kenne die Features und Spezialitäten beider zugegeben nicht. Hayo, wärst du dabei? Grüße, Jörg
Hey Jörg, ich finde es klasse, welche Fortschritte du erzielst. Nicht nur, dass es mich freuen würde, wenn die vier Platinchen auf meinem Schreibtisch irgendwann einsetzbar wären, es freut mich auch für Walter und branadic, wenn ihre Arbeit Früchte trägt. Tolle Sache! Gruß Michael
Hallo ihr Teilnehmer an der Sammelbstellung der Bauteile für die Huckepackplatine! Es hat seitens Digikey einen Fehler beim abpacken gegeben. Aus diesem Grund sind die Widerstände in 0402 mit 6k8 und 220k vertauscht! Vor dem bestücken solltet ihr zumindest diese beiden Werte nochmal nachmessen. Falls ihr schon bestückt habt und Ersatzwiderstände braucht schicke ich euch diese kostenlos zu. Mfg, Kurt
Hallo an alle, tut mir leid, dass Ihr momentan so wenig von mir hört. Bin die nächsten zwei Wochen in Thailand. Melde mich danach wieder. So muß jetzt zum Flughafen. Bis dann Hayo
Hi there, gruss aus dem sonnigen Thailand - es ist kurz vor 20:00 Uhr und es sind 30 Grad hier - schwitz! Nach einer Woche Strand habe ich jetzt auch den Kopf wieder frei und habe eine menge Ideen bezueglich (Umlaute gibts hier nicht auf der Tastatur) der neuen USTB-Engine. Alles was mir einfiel habe ich natuerlich sofort am Strand direkt auf das gute alte Offlinemedium Papier niedergeschrieben. Wenn ich in einer Woche zurueck bin werde ich mal wieder etwas Bewegung in die Sache bringen. Vielleicht ist dann ja auch Joerg schon soweit das seine neue Hardwareansteuerung mit einfliessen kann (sz gibt es auch nicht). Lasst Euch solange auch die Sonne auf den Bauch scheinen Gruss Hayo
Blessed are you for these holidays in Thailand We can not wait Hello
Don't worry! I got some new ideas in the meantime on the beach... :) I will be be back soon and looking forward to go on with the new version. Be relaxed and enjoy the summer time meanwhile Hayo p.s. going to the beach now to get some more good ideas :)
Hayo W. schrieb: > es ist kurz vor 20:00 Uhr und es sind 30 Grad hier - schwitz! Hallo Hayo, erwartest du jetzt soetwas wie Mitleid? ;-) Gut, dass du neue Kräfte sammeln kannst und eine schöne Zeit in Thailand verbringst. Wenn ich dich so höre, scheint der WAF von Paperwork ok zu sein. Bei Cursor-Anzeige und Delay-Fenster haben sich auch noch ein paar Dinge gezeigt, die sich hoffentlich mit deinem Insiderwissen abbiegen lassen. Gruß Rainer
Rainer W. schrieb: > Hallo Hayo, > erwartest du jetzt soetwas wie Mitleid? ;-) Nicht wirklich - aber fuer einen Norddeutschen ist das hier schon eine harte Nummer mit den Temperaturen. Da heisst es langsam bewegen oder besser garnicht. > Gut, dass du neue Kräfte sammeln kannst und eine schöne Zeit in Thailand > verbringst. Wenn ich dich so höre, scheint der WAF von Paperwork ok zu > sein. Unbedingt! Die beste aller Ehefrauen hat ca. 24 kg Kriminalromane dabei und ist froh wenn sie in Ruhe lesen kann - da eroeffnen sich mir ungeahnte Moeglichkeiten ;-) > Bei Cursor-Anzeige und Delay-Fenster haben sich auch noch ein paar > Dinge gezeigt, die sich hoffentlich mit deinem Insiderwissen abbiegen > lassen. Lass hoeren, welche Probleme gibt es da? Vielleicht kann ich mir da schon ein paar (offline) Gedanken machen. Notfalls kann ich mir hier das Coding mal auf SFN ansehen. Es gab doch vor einigen Wochen die Meldung, dass bei Quickmeasure der RMS-Wert nur die Haelfte anzeigt. Hat das mal jemand ueberprueft? Ich hatte leider noch keine Zeit dazu. Gruss Hayo p.s. es ist garnicht so leicht an nichts zu denken ;-)
Angehängte Dateien:
-
CursorPos_Delayed.png
5,3 KB -
CursorValue_wrong.png
4,7 KB -
CursorValue_ok.png
4,6 KB -
RMS_ok.png
4,3 KB -
CursorPos_Delayed2.png
5,7 KB
Dann will ich mal was gegen mögliche Langeweile tun. Ich habe die BF.3.0 C5 drauf, weil bei der C6 irgendwas (USTB?) gar nicht lief. Hayo W. schrieb: > Lass hoeren, welche Probleme gibt es da? Vielleicht kann ich mir da > schon ein paar (offline) Gedanken machen. Notfalls kann ich mir hier das > Coding mal auf SFN ansehen. 1. Wenn man das (sogenannte) Delayed Fenster geöffnet hat, haben die dort dargestellten Cursorpositionen nichts mit der Realität zu tun. Im Screenshot (CursorPos_Delayed) liegt das Fenster in der rechten Hälfte des Signale. Die beiden Cursur x1 und x2 stehen im Main an der ersten steigen Flanke bzw. 80 µs dahinter, also außerhalb des Delayed-Fensters. Die im "Delayed"-Fenster dargestellten Cursor sind im richtigen Abstand, aber an einer völlig falscher Position dargestellt. Gerade ist mir aufgefallen, das möglicherweise für die Cursordarstellung im Fenster einfach auf die falsche Bezugsposition zugegriffen wird: Ein Cursor, der im "Main" dicht vor dem Fensteranfang steht, wird im "Delayed" kurz vor dem Fensterende eingezeichnet. (CursorPos_Delayed2) 2. Wenn man die Cursorposition verdreht, werden oft die Zahlenwerte nicht aktualisiert (z.b. X2 in CursorValue_wrong). Erst wenn man nach einer Gedenksekunde (gefühlte 3s?) den Universalregler noch einmal etwas dreht, springen die angezeigten Zahlenwerte auf den richtigen Wert (CursorValue_ok.png). Wenn man ohne die genügend lange Pause immer wieder die Position verdreht, findet gar kein Update statt. > > Es gab doch vor einigen Wochen die Meldung, dass bei Quickmeasure der > RMS-Wert nur die Haelfte anzeigt. Hat das mal jemand ueberprueft? Das sieht IMHO gut aus, bei AC-Signal ist RMS = 1/2 Peak-Peak (RMS_ok.png) Ich wünsche euch noch schöne Tage in Thailand und gutes Tüfteln Gruß Rainer
Rainer W. schrieb: > Gerade ist mir aufgefallen, ... Zu spät: p.s. Die Theorie paßt aber nicht immer (im ersten Bild trifft das nicht zu)
So die Angebetete laesst sich am Strand grillen, da hab ich mal die Zeit genutzt um den Hotelrechner zu maltraetieren. Schnell mal die wichtigsten Programme installiert und das Coding runtergeladen - so kann man ja nicht arbeiten ;-) @Rainer Danke fuer die Info. Im Cursor-Modus ist der Werte-Refresh leider grundsaetzlich etwas langsam. Im Delayed-Modus muss man da noch etwas mehr Geduld haben, da noch mehr bremsende Grafikausgabe dazukommt. Die Cursorpositionen kann ich aber leider erst zu Hause am Geraet ueberpruefen - also in 3 Tagen :) @Joerg Jörg H. schrieb: > Wenn ich in dieser Software rumfummele kriege ich Zustände. Willkommen in meiner Welt ;-) Du Solltest Dir mal den Spass machenb und Dir das alte Origanalcoding ansehen. Da bekommt man direkt Ausschlag im Gehirn. Mittlerweile ist das ja schon einigermassen strukturiert. > Eigentlich > wäre das ja ganz einfach, wenn man eine vernünftige Hardwareabstrakion > hätte und sich dran halten würde. Ich hatte mal angedacht einen Hardware Abstraction Layer (HAL) zu bauen, es dann aber aus Performancegruenden wieder verworfen. > Aber hier sind die Dinge unnötig > kompliziert, vieles ist für die 4 Kanäle 4 mal codiert (schon mal was > von Arrays gehört?). Das bläht den Code auf und man wartet lange auf den > seriellen Download. Das war zu Anfang noch viel schlimmer. Ich habe zig hunderte Zeilen "blinden" copy & paste code rausgeschmissen und durch Schleifen bzw. Arrays ersetzt -> to be continued... > Es juckt, da neu anzufangen und eine Codebasis zu > schaffen, die bis auf eine Hardwareschicht unverändert auch auf dem > Leon-Design laufen könnte. Ich kenne die Features und Spezialitäten > beider zugegeben nicht. Hayo, wärst du dabei? Ich hatte davon erstmal abgesehen, weil die Hardware (WELEC FPGA-Design) des NIOS voellig undokumentiert ist und man vorher die Funktionalitaeten genau ermitteln muesste. Um schnell brauchbare Ergebnisse zu bekommen habe ich mir dann immer einige Hotspots gesucht die ich dann Stueck fuer Stueck ueberarbeitet habe. Ich hatte mir das fuer das LEON-Design eine entsprechende Implementierung vorgenommen da es hier wohl eine komplette Doku der Funktionen geben wird. Grundsaetzlich waere ich aber dabei. Das duerfte allerdings eine ganze Zeit dauern bis wir da was lauffaehiges zusammen haben. So muss jetzt Coctails besorgen... Gruss Hayo
Hayo W. schrieb: > Danke fuer die Info. Im Cursor-Modus ist der Werte-Refresh leider > grundsaetzlich etwas langsam. Langsam wäre ja nicht sooo schlimm, aber der Werte-Refresh kommt gar nicht, wenn man den Drehregler nach den mindestens 3 s nicht noch einmal bewegt. Gruß Rainer
Hayo W. schrieb: > ... Im Cursor-Modus ist der Werte-Refresh leider grundsaetzlich > etwas langsam. So, nach etwas Probieren scheint das Update-Problem deutlich klarer. Wenn man den Cursor anfängt zu bewegen, findet einmal ein Update der Werte statt. Beim Weiterdrehen wird dann nur noch der Cursor auf dem Bildschirm bewegt, aber anscheinen kein Flag mehr gesetzt, was das Update anstößt. Erst wenn man die 3s-Pause gewartet hat, wird bei Reglerbegung wieder ein Werte-Update angestoßen. Ich hoffe, der Sun-Downer hat gemundet. Gruß Rainer
Rainer W. schrieb: > So, nach etwas Probieren scheint das Update-Problem deutlich klarer. > Wenn man den Cursor anfängt zu bewegen, findet einmal ein Update der > Werte statt. Beim Weiterdrehen wird dann nur noch der Cursor auf dem > Bildschirm bewegt, aber anscheinen kein Flag mehr gesetzt, was das > Update anstößt. Erst wenn man die 3s-Pause gewartet hat, wird bei > Reglerbegung wieder ein Werte-Update angestoßen. Ok, das ist ein guter Hinweis, da kann ich gleich mal das Coding durchstoebern nach den Verdaechtigen. Hier ist dank Regenzeit bedeckter Himmel mit kraeftigen Schauern - das Ganze bei 33 Grad. Da bietet sich ein kleiner Code-Review geradezu an :) > Ich hoffe, der Sun-Downer hat gemundet. Hat er. Geht doch nichts ueber einen Kaipi bei der Waerme. Nebenbei habe ich mir auch noch Gedanken zum Thema Triggerlevel gemacht. Es wurde ja schon mehrfach kritisiert, dass der Triggerlevel beim Umschalten des Spannungsbereiches nicht konstant bleibt sondern stattdessen die Position auf dem Bildschirm. Das fuehrt dazu das der Level beim Umschalten jedesmal seinen Wert aendert - anders als bei einem analogen Oszi zum Beispiel. Grundsaetzlich liesse sich ein konstanter Level schon implementieren, aber das Problem ist, dass das Triggerlevel-Register nur 8 Bit breit ist sprich 256 Werte abbilden kann. Das wuerde dazu fuehren, dass beim Herunterschalten aus einem hohen Spannungsberech der Trigger in die Begrenzung faehrt und der angezeigte Level nicht mehr mit dem tatsaechlichen Trigger uebereinstimmt. Der Triggerlevel ist also vom Spannungsbereich abhaengig. Daher ist die momentane Loesung also technisch bedingt. Ich hatte mir allerdings ueberlegt ob ich einen "partiell konstanten" Triggerlevel implementiere, der z.B. beim Hochschalten von niedrigen zu hohen Spannungsbereichen konstant bleibt. Das Ganze natuerlich per Triggermenue auswaehlbar. Werd mal sehen ob das brauchbar ist. Gruss Hayo
Hi there! Hayo W. schrieb: >Der Triggerlevel ist also vom Spannungsbereich abhaengig. Daher ist die >momentane Loesung also technisch bedingt. Hi Hayo. Could this be related to the fact that with the Welec's oscilloscopes, the displayed signal's size depends on the position of the trigger's threshold? If the trigger's threshold is low, the signal's amplitude is so and the waveform is moving, whereas if the amplitude is high it becomes high itself and the waveform is more steady. I noticed this when I tested both the W2022A and W2012A for the pulse responce. Please, refer to my previous message here Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil4)" Mit Freundlichen Grüßen, Luc
Hallo Hayo et al, ich bin selber kurz vor Urlaub, da versuche ich doch mal eine Übergabe bevor ich die Software nicht mehr wiedererkenne, mit Hayos neuem Tatendrang! Der Status zur neuen Eingangsstufe ist wie folgt: - Im Gehäuse eingebaut habe ich keine Oszillation oder Einstreuung mehr. Das lag an meinem offenen Aufbau, der hat sich die Signale der Tastenplatine eingefangen. - Die Eingangsstufen sind empfindlich. Wogegen ist noch unbekannt, ESD oder Überspannung. In einem Meßbereich ohne die Relais-Vorteiler habe ich mir bei Kalibrierübungen mit kleiner Gleichspannung je den Eingangs-FET zerschossen. Mittlerweile habe ich von Kurt Ersatzteile und kann die unter kontrollierteren Bedingungen zerstören. ;-) - Jede Platine verbrät etwa ein Watt, größtenteils am Verstärkerchip. Der wird in freier Luft über 100°C heiß, in der engen Gehäuseposition sicher mehr. Wärmekontakt zu dem Stahlblech wäre gut, da liegt er eh fast an. - Die Hardwareansteuerung ist in der Software vollständig (Basis BF 3.0 C6), inklusive Programmierung der verschiedenen Gains (1/2/5) und der Bandbreitenbegrenzung. - die zur veränderten Empfindlichkeit passenden Skalierwerte in den Tabellen "ScaleFactor[]" und "DAC_ScaleFactor[]" fehlen noch. Ich habe Messungen gemacht, hatte aber noch keine Zeit das dort einzubauen. - an der Benutzeroberfläche habe ich nichts gemacht. Man kann also noch nicht einstellen, ob man neue Eingangsstufen hat. Das habe ich mir derzeit hart reincompiliert. - Die Software kann keinen echten "Mischbetrieb" der verschiedenen Eingangsstufen, mit dazu passender Skalierung. Ist zugegeben diskussionswürdig, ob das überhaupt sein soll und kann. An diesem prinzipiellen Problem scheitere ich erstmal und übergebe an Hayo. Ich habe zwar 4 Flags eingeführt (HasNewInputStage[4], die auch ins Flash kommen) und pro Kanal anzeigen, ob neue oder alte Eingangsstufe. Das wird in Hardware::SetSwitches() abgefragt und je nachdem die neue oder alte Routine aufgerufen. Das führt aber nicht so recht weiter, man müßte die Flags überall abfragen, wo derzeit die Variable "GainIdx" bewertet wird. Zu allem Übel wird an GainIdx auch noch "herumgefummelt", in Hardware::AutoScale() wird der vorübergehend auf 1 gesetzt. In einem weiteren Versuch habe ich ein Array GainIdx[4] gemacht, also ein Wert pro Kanal. Damit kam ich bis zu den Lookuptabellen "ScaleLookupTable[]" für die Anzeige, die quasi statisch sind. Ich habe noch nicht verstanden, warum es davon 2 Satz gibt, einen für die 1er und 2er Bereiche, und einen für die 5er Bereiche. (BTW, die Indizes sind ungünstig, wären besser vertauscht, damit der innere Zugriff schnell geht. Der letzte Index sollte die 0..255 Tabelle sein. Ferner würde ich diese Tabelle dynamisch berechnen, bei Bereichsumschaltung neu, und dann alles mit rein, incl. Clipping auf Displaygrenzen. Dann braucht die Zeichenschleife das nicht tun.) Nun ja, auch diese Tabelle müßte ich verdoppeln (einmal pro Eingangsstufe), vor dem Speicherverbrauch schreckte ich noch zurück. Mit einer Tabelle pro Kanal landet man da allerdings auch. Ein paar Bugs habe ich noch gefunden, ohne Rücksprache noch nicht korrigiert: 1.) in Hardware::RestoreFromFlash() statt: Hardware::SetSwitches(2, -1); besser: Hardware::SetSwitches(2, Selected_Voltage_CH2); 2.) Hardware::Start_Up() ruft immer AMDFlash::Write_Config_Flash() auf, das tut dem Chip wohl nicht gut. Nur nebenbei, in meinen Projekten habe ich mir angewöhnt, Flash oder EEPROM erst zu vergleichen, nur echte Veränderungen zu schreiben. Zudem nicht sofort, sondern nach einem Timeout, verhindert versehentliches Dauer-Schreiben. 3.) Die Offsetregler verhalten sich bei Extremwerten komisch, ich weiß aber nicht wo der Bug ist. Bei Kanal 3 kann ich den "überdrehen", die Offsetspannung springt von positiv nach negativ und umgekehrt. Ist wohl ein numerischer Wraparound. Bei Kanal 4 bleibt der Wert wie erwartet am Anschlag kleben, aber ich kann noch in eine Art wirkungslosen Bereich drehen. D.h. weitere Drehung hat zwar keinen Effekt, muß aber auch nach Umgekehr wieder zurückgelegt werden bevor der Offset wieder sinkt. Genug für heute, den Sourcecode hänge ich morgen an. Grüße an nah und fern, Jörg
Hallo, wird mir jetzt zeitlich doch arg knapp, deshalb kann ich hier nur noch einen "Snapshot" hochladen. Ich wollte dass eigentlich noch besser aufbereiten. Jörg
Back from Thailand! Und auch schon wieder aktiv... @Luc I guess it is another matter, but I will check this. Thanks for Your hint. @Jörg Das sind eine ganze Menge Hinweise und offene Fragen. Ich werde die mal durcharbeiten und versuchen alle zu prüfen/beantworten. Mal sehen was ich schon einbauen kann. Schönen Urlaub. Gruß Hayo
Hi there! Welcome back Hayo! @Hayo I guess it also and about another matter, I noticed that waveforms shape are crude and not smooth compare to other DSO when I tested both the W2022A and the W2012A for the pulse responce. Is maybe this due to the sin(X/X)'s lack? I guess the poor graphic representation problem might just to be due up to now there is not a sin(X/X) interpolation available. What about this? Gute Sonntag für alle. Mit Freundlichen Grüßen, Luc
Hallo allerseits,
kurzer Report zum aktuellen Stand. Die neue USTB-Engine läuft bereits.
Zur Zeit mache ich noch Fein-Tuning und implementiere die neuen Menüs.
(den Fehler in der alten C6 der die USTB-Funktion blockiert hat habe ich
gefunden und beseitigt).
Wer das in der Zwischenzeit für sich korrigieren möchte:
- in der hardware_t.cpp -> Methode Start_Record habe da leider was
"kaputt optimiert". Richtig muß es so aussehen:
void Hardware::Start_Record(void)
{
if(acq_ready->np_piodata == 0x01)
{
la_pulse->np_piodata = 0x01; //stop record Port On
la_pulse->np_piodata = 0x00; //stop record Port Off
}
READADC(1);
if (NumberOfChannels == 4) // JK
{ READADC(3); } // JK
ADC_Data_Available = 0;
adc_started = true;
start_acq->np_piodata = 0x01; //start record Port On
start_acq->np_piodata = 0x00; //start record Port Off
//printf("Start Record\r\n");
}
Zu den neuen Errungenschaften von Jörg bin ich noch nicht gekommen, ist
aber im nächsten Final Release auf jeden Fall mit drin.
Auch die Cursor und die Werteanzeige im Delayed Modus stehen noch auf
dem Pflichtenzettel.
@Luc
Hi, I'm sorry but until now I didn't check Your problem because I'm
working on the new USTB engine which is just working with its main
functions. I will check that and - if possible - fix it for the next
main release.
Gruß / regards
Hayo
Hayo W. schrieb: > Vorab noch ein Fix zum Spikeproblem dass Luc gemeldet hatte. Diese FW-Revision hab ich jetzt auf dem 2024 drauf und kämpfe gerade ein wenig mit der Single-Shot-Funktion. Wahrscheinlich verstehe ich nur an der Bedienphilosophie etwas verkehrt, vielleicht kann mir ja einer auf die Sprünge helfen. Ich habe auf Ch1 mit 2V/div und bei 10MSa/s (glaube ich, ich habe da gar nicht so genau drauf geachtet, weil ich einfach nach optischen Gesichtspunkten so lange dran gedreht habe, bis das Signal schön formatfüllend aussieht ;-)) an einem CAN-Bus gehorcht und wollte das Datagramm direkt nach dem Einschalten fangen. Also habe ich den Single-Knopf gedrückt und beim ersten Versuch fängt das Scope die erste Flanke meistens wunderschön (das klappt aber nicht immer, und das auch ganz ohne für mich nachvollziehbares Muster). Wenn ich Single erneut drücke, um die nächste Flanke zu fangen, steht das Scope ewig scharfgeschaltet da und der Singleknopf leuchtet rot. Ich habe es noch ab und zu hinbekommen, dass wieder eine Flanke gefangen wird, wenn ich (teils mehrmals) Run/Stop drücke und dann erst wieder Single. Der Triggerlevel steht ca. bei 60-70% der Signalamplitude. Wenn ich das Ganze mit Tippen des Tastkopfes an Probe Comp versuche, klappt das Fangen auf jeden Fall öfter, aber auch nicht immer. Daraus schließe ich, dass es entweder mit der Abtastrate zu tun hat oder ich irgendwas verkehrt mache. Wo klemmt's?
Hallo Johannes, da ich sowieso gerade die Start/Stop Funktion für die neue USTB-Engine überarbeite, kann ich mir das mal ansehen. Kann sein, dass der Fix den ich oben als Code gepostet hab das Problem schon löst. Ansonsten bräuchte ich noch Deine Triggereinstellungen. Am besten einen Screenshot mit dem Triggersubmenü drauf (Quick Print doppelt drücken) posten. Ansonsten komme ich gut voran obwohl es noch einiges anzupassen gibt. Gruß Hayo
Das große Schweigen im Walde... Um nicht den Verdacht zu nähren ich würde faul rumhängen hier ein kurzer Zwischenstand. Ich bin seit drei Wochen fleißig am Programmieren und es hat sich sehr viel getan. Aktueller Versionsstand ist 3.3 beta. Bis zum Final Relase 4.0 HE gibt es aber noch viel zu tun. Ich hoffe ich bin zum Ende der Sommerpause fertig. Da dürfte wieder für jeden was dabei sein... For our "out country" friends... ;-) I'm working hard on the next final release 4.0 HE. Many things have been changed or fixed. I hope to be ready after german holidays. I think You will like it... Gruß / regards Hayo
der Hayo, es lebt... :-)) und 'nein', du bist wohl das Letzte, der Letzte, was faul rum hängt. :-) Mal eine kleine Kostprobe von dem, was du verändert hast? Ansonsten wünsche ich noch einen schönen Sonntach! Gruß Michael
das wuerden wir doch nieee von dir denken Hayo, ich bin auch fuer eine kleine Kostprobe, und haste auch an mich gedacht ? (STB & Single) vlG Charly
Moin moin, da ich gerade größere Umbauten an der Menüstruktur vornehme, ist die 3.3 zur Zeit nicht lauffähig. Daher hier die 3.2 beta die schon Einiges zu bieten hat. Bitte beachten - da sich recht viel geändert hat mußte ich wieder einen Config-Reset durchführen. Ihr müßt also beim ersten Start neu kalibrieren und die Hardwareeinstellungen neu machen. Hier in Kürze die Neuerungen: - Math gefixt - Zeichenroutinen sind nochmals schneller geworden - es gibt eine neue Funktion "Center Window" im Displaymenü, die den Bildschirmausschnitt bei normalen TB auf den Pretrigger zentriert und bei USTB auf den aktuellen Samplezeitpunkt. - neue USTB-Engine V2.1 mit 16K Signalbuffer. Sehr viel höhere Zeitgenauigkeit, unterstützt Memorybrowser, volle Zerolevelunterstützung, Math-Unterstützung, Quick Print Datenübertragung wird unterstützt, Invertierung wird unterstützt, Details im changelog Über Vorabtestberichte und Fehlerreports freue ich mich natürlich wie immer. Gruß und viel Spaß Hayo
@Charlie Die kleineren Fixes und Änderungen und auch die Hardwareunterstützung von Jörg kommen erst wenn die größeren Umbauten beendet sind. Daher auch der beta-Status. Gruß Hayo
Kann das sein, das die Screenshot 0.97 vom 31.03.2011 nicht mehr so recht will? Es ist egal ob ich Com1 oder Com4 angebe, mit den Parametern habe ich auch schon experimentiert. Das Programm liest kurz aus und geht dann wieder zu! Gebe ich z.B. Com4 an, obwohl das DSO an Com1 hängt, bleibt das Dos-Fenster offen und wartet wahrscheinlich auf eine Antwort vom Oszi. Kann das Jemand bestätigen? Gruß Michael EDIT. Achso, habe die neue Beta druff! ...noch was: Ich wollte gerade die 3.0C6 zurückspielen und habe die Messstrippe abgezogen. Gemessen wurde ein 16MHz Rechteck mit 2V/Div 1GSa/s 50nS, da blieben auf dem rechten Bildrand einige Messreste stehen.
Hallo Hajo, gut dass das Wetter nicht zu sommerlich ist, und du zum Programmieren kommst. Michaels Beobachtung kann ich bestätigen. Da sind sich die Versionen wohl nicht ganz einig. Ich bekomme vom w2000a-screenshot die Meldung
1 | * Connecting to DSO and retrieving version information... done |
2 | - found hardware version: 1C9.0.L |
3 | - found model: W2024A |
4 | Error: This version needs at least firmware version %d.%d, but you've got %d.%d. |
5 | |
6 | Please update your DSO., exiting. |
und das war's dann. Gruß Rainer
Hallo Rainer,
> Michaels Beobachtung kann ich bestätigen.
Da bin ich ja beruhigt.
Sach mal, hast du nix besseres zutun als am DSO rumzuspielen? :-)))
Ok, Spass beiseite...ich habe die C6 noch mal zurück gespielt und da
funktioniert alles wie soll, schade, wollte heute Abend ein paar
Messbilder mit den neuen Funtionen schiessen...
@Rainer,
Hast du auch nach dem Messen(beta), Reste der Messungen auf der rechten
Seite?
EDIT: Ich habe das mit der C6 gleich mal gestest, da bleiben keine Reste
im Schirm!
Gruß Michael
Angehängte Dateien:
wo wir schon dabei sind... Im Quichmeasure werden z.B. die Pk-Pk Werte nicht richtig angezeigt, d.h. schaltet man bei der C6 die Filter ein, von off bis Strong, geht der Pk-Pk Spannungswert hübsch mit runter, während bei der Beta der Peakwert oben bleibt, trotzdem die Spitzen des Signals weggebügelt sind. Beispiel, siehe Shots von der C6. Von der Beta gehen ja leider keine... Gruß Michael
Hallo Michael, Michael D. schrieb: > Hast du auch nach dem Messen(beta), Reste der Messungen auf der rechten > Seite? Ich habe zwar keine 16 MHz hier, aber mit dem Probe Comp Signal bei 5ns/div sehe ich nichts. Beobachtest du damit den Effekt auch? Die Quick Measurements auf Basis der gefilterten Werte halte ich auch für praktischer. @Hayo, USTB ist ja nicht wieder zu erkennen, fein, fein! Kleine Frage: Was ist der Unterschied zwischen Mode "Shift Forward" und "Roll Forward"? So auf ersten Blick fühlt sich das für mich gleich an. Wo du gerade an den Menüs bist: Die Tasten "USTB Mode" und "USTB Disp." könnten eigentlich disabled sein, wenn man nicht im USTB Ablenkbereich ist. Oder bist du noch nicht bei solchen Oberfkächenfeinheiten? Gruß Rainer
Hi Leute, hier ist ja auf einmal wieder richtig was los! Also Eins nach dem Anderen: - die Screenshotfunktion hat sich nicht verändert. Die Versionserkennung läuft irgendwie ins Leere, muß ich mal prüfen. Danke für die Info. Wenn ich da weiter bin stelle ich eine korrigierte Version zur Verfügung. > Kleine Frage: Was ist der Unterschied zwischen Mode "Shift Forward" und > "Roll Forward"? So auf ersten Blick fühlt sich das für mich gleich an. Ja zu Anfang schon, aber sobald das Bufferende erreicht ist fängt der Rollmode wieder von vorn an (circular buffer) während der Shift mode alle Daten je nach eingestellter Richtung nach vorne oder hinten aus dem Buffer rausschiebt. Da das Schieben etwas mehr Rechenzeit braucht kann es bei TB = 1s und 4 aktiven Kanälen etwas hakelig werden. Also möglichst im Schiebebetrieb bei TB = 1s nur 2 Kanäle benutzen oder in den Rollmode umschalten. > Wo du gerade an den Menüs bist: Die Tasten "USTB Mode" und > "USTB Disp." könnten eigentlich disabled sein, wenn man nicht im USTB > Ablenkbereich ist. Die Menüs werden komplett umgebaut, die USTB-Popups verschwinden in einem eigenen USTB-Submenü. > Im Quichmeasure werden z.B. die Pk-Pk Werte nicht richtig angezeigt, hmmm, da hab ich eigentlich auch nichts geändert. Muß irgendein komischer Nebeneffekt sein. Werd ich mal prüfen, danke.
Hi, > Ich habe zwar keine 16 MHz hier, aber mit dem Probe Comp Signal bei > 5ns/div sehe ich nichts. Beobachtest du damit den Effekt auch? das hatte ich auch bei niedrigeren Frequenzen, vielleicht hätte ich das DSO mal aus u. wieder einschalten sollen, evt. könnte das der Grund sein. Ich habe jetzt wieder die C6 drauf. Und da haben wir wieder das alte Problem mit den unterschiedlichen Signalquellen. Und deswegen mein Vorschlag an dieser Stelle: Ich habe hier einen schicken Rechteckgenerator mit einem Mega48 zusammengebaut, der nicht viel grösser ist, als ein 2x16er LCD-Display. Das Teil rennt von 0,1 - 16MHz bzw. 32MHz(aufgepumpt, regulär 10MHz) am Pinout des Mega48/88, TTL-Pegel. Das Rechteck hat eine Rise- u.Falltime von ca.3-4nS. Sehr kostengünstiger Aufbau und sehr genau, vorallem kein Signalgezappel auch bei nicht so Hf-Gerechter Umgebung. Mein Vorschlag wäre, diesen Generator als allgemeines Messequipment für das Welec zu verwenden, dann wären wir nicht immer nur auf die 1kHz beschränkt und würden auf einer breiteren und einheitlichen Linie fahren. Wäre das für euch interessant??? Wenn ja, dann könnte man dafür noch einen separaten Thread aufmachen, wo denn auch z.B. diverse Messergebnisse vom Welec, die mit diesem Generator gemacht wurden, eingestellt werden. ;-) > Die Quick Measurements auf Basis der gefilterten Werte halte ich auch > für praktischer. Das meine ich aber auch, wenn ich meine Filter einsetze, dann möchte ich das auch angezeigt bekommen, also 5,25V und nicht 6,62V Peak to Peak wie auf den Shots weiter oben zu erkennen ist. Gruß Michael
Das hört sich ganz gut an, aber da ich mit umfangreichem Equipment in der Richtung ausgestattet bin ist das für mich erst mal nicht so interessant. Gruß Hayo
Ich noch mal, Ich habe die Beta noch mal aufgesetzt. Nach mehrmaligen 'Default Setup', sowie komplett ein u. ausschalten, sind die oben genannten Effekte plötzlich weg, sehr merkwürdig, aber um so besser! Screenshot geht aber trotzdem nicht, da habe ich jetzt alles Mögliche getestet, ich bekomme keinen Shot. Edit: Die 0.91 geht, allerdings nur beim Doppelpush und Ausgabe BMP. Bei allen anderen Knöppen kommt ein 'internal Error' Gruß Michael Noch mal EDIT: Ich dachte eher daran, das wir dann alle auf der gleichen Ebene wären. Gleiches Oszi, gleiche Messfrequenzen, das war so der Gedanke. Das du natürlich anders ausgestattet bist, war klar, hat aber nicht jeder zur Verfügung.
So, war heute hyperaktiv... ;-) Die übelsten Bugs sind beseitigt. Die neue Menüstruktur ist schon eingebaut. Soweit ich getestet habe ist das stabil. Aber bestimmt ist mir da noch irgendwo was durchgerutscht, wer findet es zuerst? Die neue Struktur könnt Ihr Euch im Programmersguide auf dem Blatt für's Menu ansehen. Alles was gelb ist, ist neu. Zum Screenshot - da hatte ich in der seriellen Kommunikation den Debug Mode abgeschaltet, da dieser immer bei einer Tastatureingabe eine Rückmeldung rausschickt. Anscheinend erwartet das Screenshotprogramm aber diese Rückmeldung immer. Muß ich mal bei Gelegenheit anpassen. Jetzt ist der Debug Mode jedenfalls wieder an. So jetzt gehts mit der besten aller Ehefrauen zum Griechen... (verdient) Gruß Hayo
i hab das file mal zumindest als 1. runtergeladen ;) Danke! Hayo & weiterhin viel spass beim proggen .... und lasst es euch schmecken vlG Charly
Hallo Hayo, bezüglich Unterschied zwischen USTB Roll vs. Shift bin ich mit Blindheit geschlagen. Einziger Unterschied den ich gesehen habe: Wenn ich das DSO auf Ch1 mit 1s/div bei 500mV/div das Probe Comp Signal (Noise Filter off, perm. Display) samplen lasse (ich weiß - wildes Aliasing) passiert nach gefühlten 5-6 min folgendes: Shift Forward Mode: Das Scope friert vollständig ein und hört nur noch auf Reset (z.B. via Soft-Btn) Roll Forward Mode: Springt wieder in den Anfangszustand mit rüberlaufendem T-Marker, um dann normal weiter zu samplen. Tritt das bei anderen auch auf? Michael D. schrieb: > Das Teil rennt von 0,1 - 16MHz bzw. 32MHz(aufgepumpt, regulär 10MHz) am > Pinout des Mega48/88, TTL-Pegel. > Das Rechteck hat eine Rise- u.Falltime von ca.3-4nS. @Michael Am schönsten wäre für Testzwecke, <träum>wenn man hinter Probe Comp den Ausgang eines kleinen DDS Generators rausführen würde, der mit an der DSO Software dranhängt. </träum> Zeig doch mal, wieviel HW-Aufwand du für deinen kleinen Generator betrieben hast? Wie kommst du auf den hohen Takt (Prozessor quälen)? Ich verwende immer gern den miniDSS (KISS) http://www.myplace.nu/avr/minidds/index.htm Gruß Rainer
Jörg H. schrieb: > - die zur veränderten Empfindlichkeit passenden Skalierwerte in den > Tabellen "ScaleFactor[]" und "DAC_ScaleFactor[]" fehlen noch. Ich habe > Messungen gemacht, hatte aber noch keine Zeit das dort einzubauen. Da werde ich erstmal Dummywerte eintragen. Genauere Werte müßtest Du dann nachliefern. > - an der Benutzeroberfläche habe ich nichts gemacht. Man kann also noch > nicht einstellen, ob man neue Eingangsstufen hat. Das habe ich mir > derzeit hart reincompiliert. Das werde ich wie von mir schon vorgesehen über die Einstellung "Addon" im Hardwaremenü machen. > - Die Software kann keinen echten "Mischbetrieb" der verschiedenen > Eingangsstufen, mit dazu passender Skalierung. Ist zugegeben > diskussionswürdig, ob das überhaupt sein soll und kann. An diesem > prinzipiellen Problem scheitere ich erstmal und übergebe an Hayo. Tja das ist die Frage, brauchen wir Mischbetrieb? Das würde einiges verkomplizieren. Ich tendiere erstmal zu nein. > Ich habe zwar 4 Flags eingeführt (HasNewInputStage[4], die auch ins > Flash kommen) und pro Kanal anzeigen, wie Du schon sagtest gibt es diverse Stellen die ebenfalls betroffen wären. > In einem weiteren Versuch habe ich ein Array GainIdx[4] gemacht, also > ein Wert pro Kanal. Damit kam ich bis zu den Lookuptabellen > "ScaleLookupTable[]" für die Anzeige, die quasi statisch sind. Ich habe > noch nicht verstanden, warum es davon 2 Satz gibt, einen für die 1er und > 2er Bereiche, und einen für die 5er Bereiche. Weil 1er und 2er den gleichen Scalierungsfaktor haben und der 5er einen anderen. > (BTW, die Indizes sind > ungünstig, wären besser vertauscht, damit der innere Zugriff schnell > geht. Der letzte Index sollte die 0..255 Tabelle sein. Muß ich mal checken und evtl. anpassen > Ferner würde ich > diese Tabelle dynamisch berechnen, bei Bereichsumschaltung neu, und dann > alles mit rein, incl. Clipping auf Displaygrenzen. Dann braucht die > Zeichenschleife das nicht tun.) Die Berechnung dauert so lange, dass ich befürchte, dass die ohnehin etwas zähe Reaktion auf die Drehregler dann noch zäher wäre. Aber man könnte es natürlich mal testen. Die Clipping-Prüfung könnte man in der Tat verlagern, muß mal sehen ob ich das noch mit in die neue Version reinkriege. > Ein paar Bugs habe ich noch gefunden, ohne Rücksprache noch nicht > korrigiert: > > 1.) in Hardware::RestoreFromFlash() > statt: > Hardware::SetSwitches(2, -1); > besser: > Hardware::SetSwitches(2, Selected_Voltage_CH2); Stimmt, habe ich im Zuge der neuen Startupsequenz mit korrigiert > 2.) Hardware::Start_Up() ruft immer AMDFlash::Write_Config_Flash() auf, > das tut dem Chip wohl nicht gut. Hier wird der Config-Backupsektor refreshed. Das muß daher bleiben. Dem Chip sollte das nichts machen. Bis der davon Schaden nimmt hast Du wohl schon den 100sten Netzschalter verschlissen. Während des Betriebes wird auch bei jeder neuen Einstellung ins Flash geschrieben. Das sollte das Flash locker mitmachen. Ich schreibe bei mir seit drei Jahren so oft ins Flash wie wohl kein normaler User sonst. Da funktioniert aber immer noch alles tadellos. > Nur nebenbei, in meinen Projekten habe > ich mir angewöhnt, Flash oder EEPROM erst zu vergleichen, nur echte > Veränderungen zu schreiben. Zudem nicht sofort, sondern nach einem > Timeout, verhindert versehentliches Dauer-Schreiben. Das ist hier nicht nötig, da nur ins Flash geschrieben wird, wenn sich tatsächlich was geändert hat und dann muß beim Schreiben ohnehin der ganze Config-Sektor neu geschrieben werden da immer nur sektorweise gelöscht werden kann. > 3.) Die Offsetregler verhalten sich bei Extremwerten komisch, ich weiß > aber nicht wo der Bug ist. Bei Kanal 3 kann ich den "überdrehen", die > Offsetspannung springt von positiv nach negativ und umgekehrt. Ist wohl > ein numerischer Wraparound. Bei Kanal 4 bleibt der Wert wie erwartet am > Anschlag kleben, aber ich kann noch in eine Art wirkungslosen Bereich > drehen. D.h. weitere Drehung hat zwar keinen Effekt, muß aber auch nach > Umgekehr wieder zurückgelegt werden bevor der Offset wieder sinkt. Muß ich mal checken, ob ich das nachgestellt kriege. Gruß Hayo
Rainer W. schrieb: > Shift Forward Mode: Das Scope friert vollständig ein und hört nur noch > auf Reset (z.B. via Soft-Btn) Stimmt, da ist noch was buggy. Hat aber schon mal funktioniert. Muß ich mal suchen. > Roll Forward Mode: Springt wieder in den Anfangszustand mit > rüberlaufendem T-Marker, um dann normal weiter zu samplen. Soll ja auch so sein. Am Besten den Memorybrowser dauerhaft aktivierren, dann sieht man immer wo man sich gerade im Buffer befindet. Gruß Hayo
Hayo W. schrieb: > Am Besten den Memorybrowser dauerhaft aktivierren, Guter Tip. Dann ist mir der Unterschied auch klar. Der Hänger im Shift-Mode(bei 1s/div nach 5 min) passiert demnach, sobald das Bufferende erreicht ist. Rainer
Ich hab da nochmal getestet. Der Hänger passiert, weil der Rechenaufwand beim Schieben der 16000 Byte so groß ist, daß in der Zwischenzeit der nächste Interupt vom Acquisition-Timer kommt und damit die weitere Ausgabe unterbindet. Irgendwann gibt es dann wahrscheinlich einen Stacküberlauf. Ich werde wohl den Signalbuffer im Shiftmode drastisch verkleinern müssen, zumindest in den Bereichen 1s 2s 5s. Gruß Hayo
Hayo W. schrieb: > Der Hänger passiert, weil der Rechenaufwand beim Schieben der 16000 Byte > so groß ist Mmmh, über Ringpuffer/Pointer als Lösung hast du wahrscheinlich auch schon nachgedacht. 16k zu schieben ist in der Tat etwas lästig. Wie sieht es eigentlich mit einer Single-Shot Steuerung für USTB aus, d.h. entweder Trigger-Event oder Taste "Single" und dann wird genau ein Puffer voll aufgezeichnet - ohne Einfrieren meine ich ;-) Gruß Rainer
Rainer W. schrieb: > Hayo W. schrieb: >> Der Hänger passiert, weil der Rechenaufwand beim Schieben der 16000 Byte >> so groß ist > > Mmmh, über Ringpuffer/Pointer als Lösung hast du wahrscheinlich auch > schon nachgedacht. 16k zu schieben ist in der Tat etwas lästig. Nachgedacht schon, aber mir war das im ersten Anlauf etwas aufwändig. Eventuell muß ich mir da aber doch noch mal das Hirn verrenken, leider hab ich noch nie so eine Konstruktion machen müssen. Bei meinen Signalprozessoren gab es da immer eine Hardwareimplementierung für. > Wie sieht es eigentlich mit einer Single-Shot Steuerung für USTB aus, > d.h. entweder Trigger-Event oder Taste "Single" und dann wird genau ein > Puffer voll aufgezeichnet - ohne Einfrieren meine ich ;-) Das hört sich nach einer guten Idee an. mit ein Puffer voll meinst Du ein Sample? Oder einen ganzen Pufferdurchlauf? Gruß Hayo
Hayo W. schrieb: >> - Die Software kann keinen echten "Mischbetrieb" der verschiedenen >> Eingangsstufen, mit dazu passender Skalierung. Ist zugegeben >> diskussionswürdig, ob das überhaupt sein soll und kann. An diesem >> prinzipiellen Problem scheitere ich erstmal und übergebe an Hayo. > > Tja das ist die Frage, brauchen wir Mischbetrieb? Das würde einiges > verkomplizieren. Ich tendiere erstmal zu nein. In der Endversion bin ich auch der Meinung das nicht, aber momentan fände ich es schön, vergleichen zu können. Zugegeben kann man das auch nacheinander tun, mit zwei Softwaren. Da habe ich mich etwas in die Ecke gedacht. >> Ferner würde ich >> diese Tabelle dynamisch berechnen, bei Bereichsumschaltung neu, und dann >> alles mit rein, incl. Clipping auf Displaygrenzen. Dann braucht die >> Zeichenschleife das nicht tun.) > > Die Berechnung dauert so lange, dass ich befürchte, dass die ohnehin > etwas zähe Reaktion auf die Drehregler dann noch zäher wäre. Aber man > könnte es natürlich mal testen. Die Clipping-Prüfung könnte man in der > Tat verlagern, muß mal sehen ob ich das noch mit in die neue Version > reinkriege. Dann sollten wir mal an der Berechnung arbeiten, damit die Zeichenfunktion Gas geben kann. Vermutlich braucht sie deshalb so lange, weil sie in Fließkomma rechnet? Da könnte ich mir vorstellen bestenfalls die Endwerte in float auszurechnen und die Gerade dazwischen mit was Bresenham-artigem. Es sind ja nur 256 Werte, das sollte sehr schnell gehen. Könnte ich mich drum kümmern. >> Nur nebenbei, in meinen Projekten habe >> ich mir angewöhnt, Flash oder EEPROM erst zu vergleichen, nur echte >> Veränderungen zu schreiben. Zudem nicht sofort, sondern nach einem >> Timeout, verhindert versehentliches Dauer-Schreiben. > > Das ist hier nicht nötig, da nur ins Flash geschrieben wird, wenn sich > tatsächlich was geändert hat und dann muß beim Schreiben ohnehin der > ganze Config-Sektor neu geschrieben werden da immer nur sektorweise > gelöscht werden kann. Ach so, du vergleichst den Sektor vor dem Schreiben und brichst ab wenn gleich? Sehr gut, dann habe ich nichts gesagt. :-) Jörg
Hayo W. schrieb: > Das hört sich nach einer guten Idee an. mit ein Puffer voll meinst Du > ein Sample? Oder einen ganzen Pufferdurchlauf? Damit meine ich 16k (oder wie viel das z.Z. ist) messen, quasi das was z.Z. beim Shift Mode mit 1s/div bis zum Einfrieren passiert, so dass man Daten aufzeichnen kann, ohne sich darum zu sorgen, dass die ersten Samples wieder überschrieben oder rausgeschoben werden. Gruß Rainer
Hmm, ja das könnte man machen. Ich probier das mal... Gruß Hayo
Hallo, ich meld' mich auch mal wieder. Rainer W. schrieb: > Michaels Beobachtung kann ich bestätigen. Da sind sich die Versionen > wohl nicht ganz einig. Ich bekomme vom w2000a-screenshot die Meldung > * Connecting to DSO and retrieving version information... done > - found hardware version: 1C9.0.L > - found model: W2024A > Error: This version needs at least firmware version %d.%d, but you've got %d.%d. > [..] [zu Firmwareversion 3.2 beta] Hayo W. schrieb: > Zum Screenshot - da hatte ich in der seriellen Kommunikation den Debug > Mode abgeschaltet, da dieser immer bei einer Tastatureingabe eine > Rückmeldung rausschickt. Anscheinend erwartet das Screenshotprogramm > aber diese Rückmeldung immer. Muß ich mal bei Gelegenheit anpassen. Ich hab' mir das gerade mal angeschaut mit der 3.2 beta. Das Problem liegt in der letzten for-Schleife in dsoinfo(). Sonderzeichen, darunter auch \n, schreibe ich als \0 in das info-Array. Nun frage ich ab, ob das gerade betrachtete Zeichen eben \0 ist und teste, ob etwas verwertbares bzgl. Versionsangaben gefunden werden kann. Da mit Debugausgaben anfangs etwas "Muell" kommt, ist der Fall *p == '\0' fuer den ersten vom DSO uebermittelten Nutzdaten-String, naemlich "FW: 1.2.hayos.version", gegeben. Ohne Debugausgaben wird der String ignoriert und erst die darauf folgenden betrachtet. Kurzfristiger Bugfix ist, vor der einlesenden while-Schleife statt:
1 | i = 0; |
2 | while (i < ISIZE-1 && (c = rdchar(com)) != '+') {
|
zu setzen:
1 | info[0] = '\0'; |
2 | i = 1; |
3 | while (i < ISIZE-1 && (c = rdchar(com)) != '+') {
|
Im Anhnang der Quelltext von v0.97 (aus der FW 3.0 ZIP-Datei) mit genau dieser Aenderung. Leider habe ich gerade keine Moeglichkeit das fuer Windows zu kompilieren, liefere ich nach. Niklas
Hi Niklas, danke für die detailierte Analyse. Gruß Hayo
Hallo Hayo, mit der Beta friert ständig mein Schirm ein. Wenn ich das Signal abziehe, bleibt es auch bestehen und, oder es bleiben Reste. Bei den unteren Messbereichen so 250ms bis 50µS gehen die Messungen sehr schleppend und kommen ständig in's stocken. So richtig fix geht es erst wieder bei 1GSa also 500nS los, alles was darunter ist, ist eine Katastrophe. USTB geht und dann wieder nicht. Bleibt einfach stehen und dann irgentwann mal weiter oder auch nicht... Ich wollte dir das nur mal berichten, da ich ja weiß, das du kaum zum Messen kommst. Der Rainer hat dieselben Probleme. Wenn du möchtest, kann ich dir mal ein paar Screenshots schicken, da stehen dann auch alle Werte drinnen. Das jetzt hier zu beschreiben, würde den Rahmen sprengen. Einen schicken Abend noch, Gruß Michael
Hi, bin erst jetzt wieder vom Griechen zurück, durch das viele Programmieren komme ich gar nicht mehr zum selber kochen... Ich habe die USTB-Engine noch mal überarbeitet - die aktuelle Version ist jetzt 2.2. Der Shift-Modus steht jetzt erst ab 5s/Div zur Verfügung und hat eine Puffergröße von 1200 Byte anwachsend zu höheren TB bis 16 KByte. Einfrieren sollte eigentlich nichts mehr. Einige andere Sachen habe ich auch noch optimiert. Weitere Änderungen / Neuerungen stehen noch an. Danke für die Rückmeldungen, wie immer sind weitere Reports von Euch stets willkommen! Gruß Hayo
Hayo W. schrieb: > Der Shift-Modus steht jetzt erst ab 5s/Div zur Verfügung und hat eine > Puffergröße von 1200 Byte anwachsend zu höheren TB bis 16 KByte. Hallo Hayo, die Puffergröße, die im Shift-Mode bewältigt werden kann, müßte doch sowohl von der Samplerate, als auch von der Anzahl der aktiven Kanäle abhängen - so ganz banal gedacht. Würde man beim 4 Kanaler dann nicht ungünstigstenfalls einen Faktor vier bei der Einkanalaufzeichnung verschenken, wenn man das rein an der Samplerate festmacht? Oder hab' ich das zu einfach gedacht? Gruß Rainer
Im Prinzip hast Du recht, aber bei meinen Tests hat sich erwiesen, dass die Anzahl der Kanäle nicht ganz so ausschlaggebend war als dass sich der Aufwand gelohnt hätte die Anzahl der Kanähle zu berücksichtigen. Soll heißen, dass selbst bei noch kleinerer Puffergröße (600 Byte = Screenbreite) im Dreikanalbetrieb die Sache ins Stocken kam (1s/Div und 2s/Div), geschweige denn der Math-Modus ging. Der etwas größere Sprung von 2s/Div auf 5s/Div reicht dagegen um alles stabil bei 1200 Byte Puffergröße laufen zu lassen. So wie es jetzt ist habe ich eigentlich schon das Maximum rausgeholt. Am Memorybrowser könnt Ihr Übrigens immer gut die aktuelle Puffergröße erkennen. Gruß Hayo
Hallo, im Anhang das neue Kompilat des Screenshot-Programms v0.97 mit dem Fix fuer den Bug im Zusammenhang mit abgeschalteten Debug-Modus in der Firmware (v3.2 beta). Hayo kann dann in zukuenftigen Versionen wieder den Debug-Modus abschalten. English: New compilation of the screenshot program v0.97 with a fix regarding a bug that was found when the debug mode is turned off in the firmware (as in v3.2 beta). In v3.3 beta and v3.4 beta Hayo temporarily turned debug back on for this reason. No other changes. For more information and sourcecode see Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil4)" Niklas
Angehängte Dateien:
-
USTB--1s--0_23Hz.png
3,1 KB -
USTB--2s--0_23Hz.png
3,3 KB -
USTB--10s--0_23Hz.png
3,2 KB
Hallo Hayo, die 3.4beta, läuft gut. Ich habe gleich noch mal den USTB-Modus getestet mit einem 0,23Hz Rechteck(Pulsweite 50:50) auf 1s, 2s und 10s. Anbei 3 Shots. Jetzt bleibt aber bei den Smooth und Strong-Filtern das Signal stehen (Test 2kHz). Es friert nur das Signal ein, nicht das komplette DSO. Wenn ich die Filter tausche bzw. ausschalte, läuft's wieder! Getestet habe ich noch die 3 anderen Filter StageI bis StageIII. Da läuft alles so wie es soll. Ich hoffe, es nützt dir was. Hallo Niklas, Die Shots sind mit deiner neuen screenshot-fix gemacht, funzt wunderbar. Tolle Arbeit und ein Lob von mir. Gruß Michael
Ooouuhh, das hatte ich bislang noch nicht bemerkt weil ja im USTB-Mode die Filterung keinen Sinn macht und deshalb bei mir abgeschaltet war. Die eigentlichen Filterroutinen werden auch garnicht angesprungen. Leider verbiegt mir der aktivierte Filtermodus aber die Signalpointer, weswegen da eine Menge Schrott auf dem Bildschirm erscheint. Habe ich jetzt beseitigt. Danke für den Hinweis! Gruß Hayo
Hayo W. schrieb: > Ooouuhh, aaaaahh... > > das hatte ich bislang noch nicht bemerkt weil ja im USTB-Mode die > Filterung keinen Sinn macht und deshalb bei mir abgeschaltet war. Das der da keinen Sinn macht, macht ja Sinn... bei den Messungen weiter oben, war der auch garnicht eingeschaltet, fällt mir gerade ein! Eben habe ich das noch mal provoziert, sobald eines der Filter aktiv ist, geht da nüscht mehr. > > Die eigentlichen Filterroutinen werden auch garnicht angesprungen. > Leider verbiegt mir der aktivierte Filtermodus aber die Signalpointer, > weswegen da eine Menge Schrott auf dem Bildschirm erscheint. Habe ich > jetzt beseitigt. Fein! Jetzt zickt nur noch der 'Smooth' und der 'Strong' Filter, im "nicht" USTB-Mode. Die Stages I-III sind ok! > > Danke für den Hinweis! Bitte! > > Gruß Hayo Gruß Michael
Und hier ist wieder das Sonntagabend-Event! Wie von versprochen habe ich mir das Gehirn verrenkt weil die Lösung mit den kleinen Puffergrößen im Shift Mode etwas unbefriedigend war. Herausgekommen ist eine Lösung mit sich gegeneinander verschiebenden Speicherbereichen statt einer Verschiebung der Daten selbst. Dazu brauchte ich aber viel Speicher, so dass ich die Speicheraufteilung geändert habe. Das Ergebnis kann sich sehen lassen: - 16KB in allen ultra slow TB für den Shift Mode - 32KB sind möglich im Roll Mode! Die Speichertiefe ist einstellbar im USTB-Menü (8KB/16KB/32KB). Von Rainer angeregt habe ich einen speziellen Single Mode für USTB implementiert. Quick Print und Save/Recall unterstützen aber nur (8KB/16KB) Gruß Hayo
Hallo Hayo, ich habe deine 3.5Beta gleich mal getestet. Das mit dem Smooth u. Strong Filter hat sich schon gebessert. Sobald ich aber mehr als eine Flanke, (z.B. 1MHz, 6MHz oder 9MHz Rechteck) auf dem Display habe, kommt die Signalmessung wieder in's stocken. Bei nur einer Flanke geht's ab wie Schmitt's Katze. Die StagesI bis III gehen nach wie vor wunderbar...what's the Different? Ich wünsche dir noch einen schönen Sonntag Gruß Michael
Angehängte Dateien:
-
USTB-274Hz-1s.png
3 KB -
USTB-274Hz-2s.png
3,3 KB -
USTB-274Hz-5s.png
3,1 KB -
USTB-274Hz-10s.png
3,2 KB
Ich noch mal, habe gerade noch den USTB-Mode mit ---275Hz--- getestet und zwar mit 1,2,5 und 10Sek. Irgendwie stimmt da was nicht, 1s ist ein wenig voll? Die 2s sind wieder schön gemalt, 5s füllt sich wieder und bei 10s ist das Signal wieder ok, oder habe ich das Messprinzip nicht verstanden? Anbei die Shots mit den Einstellungen! Gruß Michael
Hi, sowas nennt sich Aliasing. Die Messfrequenz ist viel zu hoch für die Abtastrate. Ich teste da mit 0,05Hz. Heißt ja nicht umsonst Ultra Slow Time Base. Das Andere muß ich noch mal prüfen. Ist auch noch beta Status. Bis zum stable Release muß ich noch ordentlich testen. Je mehr Ihr jetzt schon findet, desto schneller gehts! Bis dann Hayo
Hallo Hayo, ganz große Klasse mit dem radikal geänderten Speicherkonzept in den USTB Modes. Der Single-Shot ist auch sehr fein. Nach ein bisschen probieren sind mir noch folgende Kleinigkeiten aufgefallen: - Beim Shift Mode, speziell beim Single Shot vermisse ich jetzt eine Anzeige, die über den Speicherfüllstand informiert. Ich sehe wohl das konzeptionelle Problem dabei. Vielleicht hat jemand die geniale Idee. Eine Möglichkeit, die mir spontan einfällt, wäre im Browser ein hinterlegter Balken der den Speicherfüllstand anzeigt, aber es wäre natürlich schöner, wenn man dafür nicht wieder etwas neues erfinden müßte. - Bei der Bedienung im Main/Delay Menü finde ich es persönlich unpraktisch, dass es zwei verschiedene Tasten sind, um ins USTB Submenü hinein und heraus zu kommen (Softkey 5 bzw.6). Die Frage ist, ob es nicht ergonomischer wäre, z.B. die Softkeys "USTB" und "Browse" zu tauschen. Und noch ein Punkt: - Im USTB Single Shot halte ich es für sinnvoll, den Speicher zu Anfang zu löschen, damit nicht irgendwelcher Müll in der Aufzeichnung mit drin ist. Nochmal ein dickes Lob für deine tolle Arbeit. Gruß Rainer
Rainer W. schrieb: > - Beim Shift Mode, speziell beim Single Shot vermisse ich jetzt eine > Anzeige, die über den Speicherfüllstand informiert. Ich sehe wohl das > konzeptionelle Problem dabei. Ja sowas ging mir auch schon durch den Kopf - allerdings noch ohne gute Idee > - Bei der Bedienung im Main/Delay Menü finde ich es persönlich > unpraktisch, dass es zwei verschiedene Tasten sind, um ins USTB Submenü > hinein und heraus zu kommen (Softkey 5 bzw.6). Die Frage ist, ob es > nicht ergonomischer wäre, z.B. die Softkeys "USTB" und "Browse" zu > tauschen. Da hast Du natürlich recht, die Idee hatte ich auch schon, war aber noch zu "faul", werde ich aber noch machen. > Und noch ein Punkt: > - Im USTB Single Shot halte ich es für sinnvoll, den Speicher zu Anfang > zu löschen, damit nicht irgendwelcher Müll in der Aufzeichnung mit drin > ist. Da hatte ich auch schon überlegt, hatte aber gedacht, dass es dann nicht möglich ist nachträglich den Single Shot zu aktivieren ohne die bisherigen Ergebnisse zu verwerfen. Kann ich aber noch einbauen. > Nochmal ein dickes Lob für deine tolle Arbeit. Das schlechte Wetter in Norddeutschland machts möglich... Gruß Hayo
Michael D. schrieb: > Hallo Hayo, > ich habe deine 3.5Beta gleich mal getestet. > Das mit dem Smooth u. Strong Filter hat sich schon gebessert. > Sobald ich aber mehr als eine Flanke, (z.B. 1MHz, 6MHz oder 9MHz > Rechteck) auf dem Display habe, kommt die Signalmessung wieder in's > stocken. Ok hab's! In dem Bestreben das letzte Quentchen Performance rauszuholen hab ich leider mal wieder was kaputt-optimiert. Ist schon korrigiert und kommt mit der 3.6 beta. Danke für den Report Hayo
So, hier auch gleich die bereinigte Version. - Filterproblem gefixt - Browser Button und USTB-Button getauscht - Bufferrefresh bei Single Shot Als Nächstes werde ich mal Eure älteren Bug-Reports abarbeiten und dann die neue Hardwareansteuerung von Jörg einbauen. Dann steht dem neuen final Release nichts mehr im Wege. Gruß Hayo
Rainer W. schrieb: > - Beim Shift Mode, speziell beim Single Shot vermisse ich jetzt eine > Anzeige, die über den Speicherfüllstand informiert. Da fällt mir ein, dass der Memorybrowser da schon mal weiterhilft, denn da wird der aktuelle Samplezeitpunkt im Speicher durch das Triggersymbol angezeigt. Wenn das Triggersymbol ans Speicherende läuft wird der Singleshot ausgelöst. Das gilt allerdings nur für den Rollmode. Beim Shiftmode läuft ja das Ende des Signals gegen das Speicherende, und dafür gibt es momentan noch kein Zeichen. Wäre aber eine Überlegung wert. Gruß Hayo
Hallo Hayo, Super***** Arbeit, ich bin begeistert, bekommst 5 Sterne von mir... Die Filter funzen todschick, ich benutze gerade den Smooth-Filter sehr oft und für's Grobbe dann mal schnell den Strong für die obere Müllbeseitigung, denn dafür sind diese sehr praktisch!!! Ok, das mit dem USTB hätte ich mir denken können. Sind denn die Messungen hier: ---Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil4)" dafür ok? Man sieht sieht auf den Shots auch den Browser wie er sich füllt, das dauert schon seine Zeit bis der voll ist, einige Minuten. Was ist denn die oberste bzw. unterste Messgrenze für den USTB-Mode? Auf den Shots messe ich mit z.B. 0,23 Hz. Gruß Michael
Michael D. schrieb: > Super***** Arbeit, ich bin begeistert, bekommst 5 Sterne von mir... Cool, dann bin ich jetzt 5 Sterne Programmierer... ;-) > Ok, das mit dem USTB hätte ich mir denken können. > Sind denn die Messungen hier: > ---Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil4)" > dafür ok? Das kann man nie genau anhand des Bildes sagen. Im Prinzip muß das Signal bezogen auf die Abtastfrequenz bandbegrenzt sein (und zwar auf halbe Abtastfrquenz). > Was ist denn die oberste bzw. unterste Messgrenze für den USTB-Mode? Auf > den Shots messe ich mit z.B. 0,23 Hz. Dazu hat mal ein genialer Mensch namens Nyquist eine schlaue Idee gehabt. Nennt sich Abtasttheorem. Das besagt. das die Abtastfrequenz mindestens doppelt so hoch sein muß wie die höchste auftretende Signalfrequenz, damit das Signal korrekt wiederhergestellt werden kann. Wenn das nicht erfüllt ist entstehen sogenannte Scheinfrequenzen (Aliasfrequenzen) woher auch die Bezeichnung Aliasing stammt. Die Abtastfrequenz wird ja in der Statusleiste angezeigt. Bei 1s/Div ist sie beispielsweise 50Sa/s -> nach der Theorie ist da also die Grenzfrequenz (oder auch Nyquistfrequenz) 25Hz. In der Praxis liegt sie jedoch weit darunter, mindestens bei 1/4 der Abtastfrequenz, da Du sonst auf dem Bildschirm nix Vernünftiges erkennen kannst. Unser Oszi ist Beispielsweise mit einer Abtastfrquenz von max. 1MSa/s gesegnet, hat aber nur eine (theoretische) Bandbreite von 200MHz/100MHz was schon zeigt wie Theorie und Praxis zu bewerten sind. Den Rest kannst Du Dir ja selbst zusammenreimen. Viel Spaß beim nachrechnen. Im Prinzip kannst Du also den USTB-Bereich mit Frequenzen ab 5Hz abwärts sinnvoll testen - mit 0.23Hz bist Du also schon gut dabei! Gruß Hayo
So, ich mal wieder, hallo allerseits. Die letzten Tage habe ich den Fehlerreport von Rainer (11.7.2011) abgearbeitet. Zur Erinnerung, es ging um den (fehlenden) Refresh der Cursor-Daten. Dabei bin ich auf eine Menge Unrat gestoßen. Insofern freue ich mich über die neue Betaversion besonders. Ich habe die Assemblerroutinen für den Menüaufbau komplett überarbeitet und mengenweise performancehemmende Leichen entsorgt. Neben der erfreulichen Tatsache, das jetzt die Cursorwerte prompt und schnell angezeigt werden ist auch der gesamte Menüaufbau beschleunigt worden. Die aktuelle Beta läuft nach meinen bisherigen Erkenntnissen so stabil, dass ich empfehlen würde sie erstmal dauerhaft zu flashen da sie gegenüber den 3.0 Cx Versionen doch deutliche Vorteile zu bieten hat. Über Fehlerreports freue ich mich natürlich trotzdem. Gruß Hayo
Ach ja noch als kleiner Nachschlag, für alle die gerne selbst Performance-Messungen durchführen wollen habe ich einen dauerhaften Framecount eingebaut der gleichzeitig mit der Tastenkombination Shift+K über Terminal ausgegeben und resettet wird. Gruß Hayo
Den ersten Fehler habe ich dann auch selbst entdeckt wie es aussieht. Der Pretriggerwert wird bei TB-Wechsel nicht korrekt refreshed - erst beim Druck auf den Button.. Ist natürlich schon in Arbeit... ...Version 3.8 is coming soon... Hayo
Angehängte Dateien:
Damit die Anderen wissen, was der Hayo meint, habe ich mal 2 Shots gemacht. Im 1. Shot ist das Terminal zu sehen mit all seinen Befehlen, mit denen man das Welec fernsteuern kann. Ausser Shift+k ist noch nicht beschrieben, geht aber und ist auf dem 2. Shot zu sehen! Gruß Michael EDIT: Ach ja, unten auf der Statusleiste sind die Parameter für die RS232 zu sehen. (Stopbit 1, Handshake none)
Doch, der Framecounter ist schon beschrieben, man muß schon genau hinsehen ;-) Einfaches Vorgehen bei der Messung: - Uhr mit Sekundenzeiger bereithalten - bei Nulldurchgang des Sekundenzeigers Shift + K drücken - nach 60 Sekunden erneut Shift + K drücken Als Ergebnis hat man die Frames pro Minute, die je nach Anzahl der Kanäle und zusätzlicher Funktionen variieren. Hayo
Ok, Pretriggerproblem gefixt. Kommt in Kürze... Hayo
man, du hast ja Recht! Das passiert mir jedes mal, das ich mich bei der Funktionsbeschreibung in der Spalte verhaue! "not available" ist Shift+L :-/
Jo Mann, so sieht's aus. Und jetzt werd ich mich schön ins Bettchen kuscheln, bis dann Hayo
Und die nächste beta, die aber jetzt schon recht stabil ist. Was hat sich getan? ich habe den zweiten Teil von Rainers Fehlerreport (11.7.2011, da war ich noch in Thailand) abgearbeitet. Es wurde zu Recht die fehlerhafte Position der Delayed Cursor moniert. Beim Prüfen der Berechnung bin ich auf eine völlig verwurstete Formel gestoßen die um Zehn Ecken mit zig Hilfsparametern die Position extrem rechenaufwändig und falsch berechnet. Die neue Formel errechnet die Position mit drei Parametern viel schneller und richtig! Alle überflüssigen Parameter und Matrix-Arrays habe ich gelöscht, da diese nur hierfür benutzt wurden. Das Ganze gilt ebenso für die QM-Delayed Cursor (z.B. bei Rise Time Berechnung im Delayed Mode). Gruß Hayo
Für die nächste Beta überarbeite ich gerade die Zeichenroutine für das Pretrigger-Zeichen im Haupt und Delayedfenster, da es hier manchmal Darstellungs-/Löschfehler gibt. Gruß Hayo
Fast Vector: - 2 Kanäle -> 475fpm - 4 Kanäle -> 247fpm Accurate: - 2 Kanäle -> 419fpm - 4 Kanäle -> 221fpm Pixel: - 2 Kanäle -> 511fpm - 4 Kanäle -> 262fpm Das ist in allen Bereichen zwischen 10 - 20fpm schneller als bei den 3.0Cx Für fps alles durch 60 teilen. Ansonsten baue ich gerade die Hardwareunterstützung für die neue Eingangsstufe ein. Gruß Hayo
Hallo, schlechte Nachrichten bei mir. Mein 4 Kanaler versagt den Dienst. GUI funktioniert, aber keine Anzeige der Eingangssignale. Alle Traces werden in der Mitte gezeichnet, Verschieben dieser ist auch nicht moeglich. Da mich es wunderte, warum auch die Relais nicht klicken beim Wechsel der Ranges, hab' ich mir mal das Netzteil und das Spannungsversorgungs-Board angeschaut. Dabei fiel auf, dass ein Bauteil, was fuer mich nach einer Induktivitaet/Spule aussieht, abgeraucht ist. Es handelt sich im folgenden Foto um das weisse Bauteil direkt am linken Rand (bei den schwarzen Leitungen die zum LCD-Inverter Board fuehren). Bei mir war das Bauteil schwarz (wohl auch vor dem Abrauchen schon ;)), duerfte aber irrelevant sein. http://sourceforge.net/apps/trac/welecw2000a/raw/attachment/wiki/Hardware/inverter.JPG Vor dem Bauteil liegen 6.2V an. Das ist (bzw. war) bei mir auch Versorgungsspannung vom Original-Luefter (den hab' ich aber bereits durch einen anderen getauscht, welcher direkt an den 12V vom Netzteil angeschlossen ist). Hinter dem defekten Bauteil liegen im Betrieb nur ungefaehr 0.5V an. Frage an Euch: Um was fuer ein Bauteil handelt es sich mit welchen Werten? Wenn jemand das mal ausmessen koennte waere ich ihm sehr dankbar. Niklas
Hallo Niklas, die Frage wäre einfacher zu beantworten wenn der link funktionieren würde. ;-) Abgesehhen davon gehört das doch eher in den Hardware Thread. Beitrag "Wittig(welec) DSO W20xxA Hardware" MFG, Kurt
Hallo Kurt, hast Recht, gehoert in den anderen Thread. Mea culpa. Korrekter Link zum Foto: http://sourceforge.net/apps/trac/welecw2000a/attachment/wiki/Hardware/inverter.JPG Niklas
Hallo Allerseits, ich bin gerade bei den Abschlußarbeiten für das neue Release 4.0 und prüfe die bisher gemeldeten Fehler. Aktuell prüfe ich das Verhalten des Single Shot, da hier einige Meldungen in der Vergangenheit waren. Momentan kann ich aber keine Auffälligkeiten entdecken. Wenn Ihr noch Fehler entdeckt habt dann bitte melden. Bezüglich Trigger bitte immer auch mit den aktuellen Einstellungen des Triggermenüs. Gruß Hayo
Angehängte Dateien:
-
Chan_Menu1.png
4,4 KB -
Chan_Menu2.png
3,8 KB
Moin Hayo, Hayo W. schrieb: > Es wurde zu Recht die fehlerhafte Position der Delayed Cursor moniert. Die synchronisierten Cursor im Delayed Fenster geben ein völlig neues Arbeitsgefühl und die Anzeige der Cursor Position sowieso. Klasse ;-) Hayo W. schrieb: > ich bin gerade bei den Abschlußarbeiten für das neue Release 4.0 Da hätte ich noch die kleine Schönheitoperation mit dem völlig deaktivierten Kanal Menü, falls du da seit der 3.8 nicht schon dran warst: Wenn man einen Kanal abschaltet, wird das Soft Menü völlig deaktiviert. Sinnvoller wäre vielleicht, es auf einen der aktiven Kanäle zu schalten, oder zumindest die "Dispatch Channel"-Taste freizugeben, damit man die verbleibenden Kanäle bequem neu anordnen kann. Frohes Schaffen, wo Hamburg anscheinend von der Wochenendhitzewelle verschont bleibt ;-) Gruß Rainer
Angehängte Dateien:
-
Delayed_Datenbereich.png
4,4 KB
Hallo Hayo, bei der Darstellung im Delayed Fenster gibt es noch einen Bug mit dem Datenzugriff. Wenn man bei aktivem und weit links liegendem Delayed Fenster die TB langsamer schaltet, wird u.U. auf ungültige Daten zugegriffen. Das sieht dann aus wie im beigefügten Screenshot. Der Fehler läßt sich wie folgt provozieren: Default Setup, Signal z.B. ProbeComp an Ch1 mit 200mV/div, TB 1 ms/div, Delayed aktivieren, TB_Delayed 200µs/div, Fenster ganz nach links, TB_Delayed 500µs/div. -> et voilà ... Der Anfang des im Delayed Fenster dargestellten Datenbereichs liegt dann anscheinend vor dem Anfang des Sample-Speichers. Bei TB-Umschaltung muß man evtl. einfach das Fenster so verschieben, damit das nicht passiert. Wenn das Fenster ganz ganz rechts liegt, scheint eine entsprechende Kontrolle stattzufinden. Gruß Rainer
Alles klar, danke. Werd ich mal genauer unter die Lupe nehmen. Allerdings muß ich heute noch unsere Viper spazieren fahren, da morgen schon wieder Regen angesagt ist. Gruß Hayo
Rainer W. schrieb: > Hallo Hayo, > Der Anfang des im Delayed Fenster dargestellten Datenbereichs liegt dann > anscheinend vor dem Anfang des Sample-Speichers. Ja, ist korrekt. > Bei TB-Umschaltung muß > man evtl. einfach das Fenster so verschieben, damit das nicht passiert. Es fehlt ein Limiter, der das Fenster wieder zurückschiebt wenn die Grenze außerhalb des Speichers liegt. > Wenn das Fenster ganz ganz rechts liegt, scheint eine entsprechende > Kontrolle stattzufinden. Nein, das sieht nur so aus weil da noch etwas mehr Speicher am Ende ist der dann dargestellt wird. Aber das ist so auch nicht korrekt. Muß auf jeden Fall korrigiert werden, bin schon dran... Gruß Hayo
Hallo Hayo, ab der 3.7 funktionieren meine screenshot Routinen nicht mehr. Mit der 3.6 geht noch alles. Hast du eine Idee woran das liegen könnte? Mfg, Kurt
Hallo Kurt, was genau funktioniert denn nicht? Bzw. wie verhält sich die Funktion? Ich habe da nichts dran geändert (zumindest bei 3.6/3.7 noch nicht), allerdings habe ich jetzt beim Dump die Pointer auf das Signal geändert weil ich das komplett umgestellt habe. Ach ja, jetzt fällt es mir wieder ein. Ich habe den Debug-Mode im Comm-Interface abgeschaltet. Der hat bei externen Befehlen immer ein Echo zurückgegeben. Das Problem hatten wir ja auch mit unserem normalen Screenshot, der wollte zuerst auch nicht mehr, aber den hat Niklas ja entsprechend angepasst. Kann es das sein? Gruß Hayo
@Rainer Problem ist gefixt, Danke für den Hinweis. Die Menüsteuerung für das Channelmenü wollte ich eigentlich nicht ändern. Dein Einwand dass man erst zum nächsten Kanal umschalten muß ist zwar korrekt, aber der Sinn der Logik ist ja dass man durch mehrfaches Drücken den Kanal ein und ausschalten kann (toggeln) ohne das man zwischendurch in ein anderes Kanalmenü umgeleitet wird aus dem man dann wieder zurückspringen müßte. Die Idee mit der Dispatch-Taste ist nicht schlecht, aber nicht so einfach umzusetzen, da das Menü immer komplett deaktiviert oder aktiviert wird. Gruß Hayo
Hayo W. schrieb: > was genau funktioniert denn nicht? Bzw. wie verhält sich die Funktion? Genau kann ich das noch nicht sagen. Am Mikrocontroller sind die Debug Möglichkeiten leider sehr begrenzt. Ich werde weitersuchen.
Hayo W. schrieb: > Die Idee mit der Dispatch-Taste ist nicht schlecht, aber nicht so > einfach umzusetzen, da das Menü immer komplett deaktiviert oder > aktiviert wird. Das ist ein schlagendes Argument ;-) und spricht für die erste Lösung. Beim (Re-)Aktivieren eines Kanals wird ja auch jetzt schon, egal welches Menü angezeigt wird, automatisch auf das Channel-Menü für den neu aktivierten Kanal gewechselt, so dass das Zurückspringen jetzt schon funktioniert und das Ganze mit der Toogle-Philosophie prima zusammenpasst. Gruß Rainer
Der Gedanke dabei ist, dass der Fokus immer auf dem Kanal bleibt den man gerade bedient, solange bis man den nächsten Kanal bedient. Gruß Hayo
Greetings to everyone, but especially to Hayo I installed the new beta release from 04 to 08. In going from FFT: Fn 500Mhz to: Fn12.50Mhz, the DSO crashes. There is no way to unlock it.
Hi Conte, thanks for Your report, I will check this and try to fix it soon. Regards Hayo
moin moin Hayo, im Singel Mode ist 'Stop' im display immer an. Ist die TB recht langsam merkt man nicht ob getriggert wurde da RUN/STOP erst nach dem Bildaufbau aufleuchtet, waehre es machbar RUN/STOP beim triggern einzuschalten und nach dem Bildaufbau die Single Taste zu loeschen ?, und nochmal die Frage, ist es nicht machbar das man im Single Mode die TB veraendern kann solange noch nicht getriggert wurde ?, immer in den Run Mode zu schalten dafuer ist etwas umstaendlich (und nutzt die Tasten ab ;) ) vlG Charly
Ok, FFT-freezing bug is fixed! Had a little buffer overfow problem which is solved now. Thank You for reporting Hayo
Charly B. schrieb: > moin moin Hayo, Hi Charly > im Singel Mode ist 'Stop' im display immer an. Ja, der Displayaufbau ist so langsam, dass man das nicht genauso schnell darstellen kann wie mit den LED. > Ist die TB recht langsam merkt man nicht ob getriggert wurde > da RUN/STOP erst nach dem Bildaufbau aufleuchtet, waehre es > machbar RUN/STOP beim triggern einzuschalten und nach dem > Bildaufbau die Single Taste zu loeschen ?, Den hab ich irgendwie nicht ganz verstanden. Ich habe mir das mal bei 200ms/Div angesehen und fand eigendlich alles ganz normal. Die Umschaltung von Single nach Stop geschieht genau in dem Moment in dem das Triggerereignis auftritt. Kann man sehen wenn man die Zusatz-LED aktiv hat (oder ersatzweise die Channel-LED) > und nochmal die > Frage, ist es nicht machbar das man im Single Mode die TB > veraendern kann solange noch nicht getriggert wurde ?, immer > in den Run Mode zu schalten dafuer ist etwas umstaendlich (und > nutzt die Tasten ab ;) ) Muß ich nochmal prüfen, ist aber nicht ganz einfach, da sich das unter Umständen mit den virtuellen TB im Stop-Modus beißt. Gruß Hayo
Once again, thank you thank you Hayo, you're amazing! :) Gyppe.
Angehängte Dateien:
-
W0007975.png
3,3 KB
Kurt Bohnen schrieb: > Hallo Hayo, > ab der 3.7 funktionieren meine screenshot Routinen nicht mehr. Mit der > 3.6 geht noch alles. Hat sich komplett erledigt. Da die USB-Host Firmware etwas umfangreicher und anscheinend auch langsamer geworden ist gab es wohl Timingprobleme. Trotzdem habe ich noch 2 kosmetische Fehler gefunden: Bei GND-Kopplung liegt Kanal 2 um 2 Pixel zu hoch. Außerdem befindet sich am rechten Rand für Kanal 2 nicht das GND Symbol sondern eine verstümmelte 3. Das angehängte Bild bitte ausreichend vergrößern. Mfg, Kurt
moin moin Hayo, so kann man den 'Fehler' reprodzieren: utility, Default Setup TB auf 200ms, trigger so einstellen das er vom testsignal triggert, jetzt auf Single, dann kurz mit dem TK das Testsignal antippen und beobachten vlG Charly
Angehängte Dateien:
-
Reste1.PNG
4,4 KB
Kurt Bohnen schrieb: > Außerdem befindet sich am rechten Rand > für Kanal 2 nicht das GND Symbol sondern eine verstümmelte 3. Bei Kanal 3 und 4 setzt sich das dann fort. Das Gnd-Symbol ist immer zu sehen, aber darunter tauchen komische Dinge auf. Debei ist mir aufgefallen, dass direkt unterhalb des schwarzen Zeichenfeldes, also direkt oberhalb der Soft-Menü Tasten oft Reste von den Feldern für die Quick Measurement Daten bzw. die berechneten Curserdaten zu sehen sind. Die Feldreste entstehen z.B. wenn man Quick Measurement aktiv hat und dann über Utility ein Default Setup auslöst. Aber das ist wohl eher etwas für einen langen Winterabend ;-) Gruß Rainer
Rainer W. schrieb: > Debei ist mir aufgefallen, dass direkt unterhalb des schwarzen > Zeichenfeldes, also direkt oberhalb der Soft-Menü Tasten oft Reste von > den Feldern für die Quick Measurement Daten bzw. die berechneten > Curserdaten zu sehen sind. Die Feldreste entstehen z.B. wenn man Quick > Measurement aktiv hat und dann über Utility ein Default Setup auslöst. > > Aber das ist wohl eher etwas für einen langen Winterabend ;-) Ouh, das ist ein ganz alter Fehler, da habe ich noch ein schlechtes Gewissen. Irgendwie geht da das Zählen der Zeilen nicht glatt auf oder sowas.
Nabend, @Kurt > Trotzdem habe ich noch 2 kosmetische Fehler gefunden: Bei GND-Kopplung > liegt Kanal 2 um 2 Pixel zu hoch. Das kann ich bestätigen! Das ist war aber auch bei "fast" allen Vorgängerversionen auch so und ist nicht nur bei der GND-Kopplung so, zumindest ist das bei mir der Fall. Ja ja, die Nulllinie war ja schon immer ein Problem... @Guido, > Ouh, das ist ein ganz alter Fehler, da habe ich noch ein schlechtes > Gewissen. Irgendwie geht da das Zählen der Zeilen nicht glatt auf > oder sowas. ...wieso hast du da ein schlechtes Gewissen??? Das passiert aber auch manchmal bei anderen einstellungen, das da mal ein paar Reste auf dem Schirm bleiben. LG Michael
Hi Leute, danke für die Rückmeldungen. Leider bin ich gestern und heute bei Kundenterminen und komme daher zu nichts. Werde mal morgen alles unter die Lupe nehmen (im wahrsten Sinne). Gruß Hayo
moin, wenn ich meine Satzgebung da oben sehe, ohne Worte... ich sollte um die Uhrzeit nicht mehr schreiben...
Michael D. schrieb: > ...wieso hast du da ein schlechtes Gewissen??? Weil ich da mal dran war. Wenn ich mich recht entsinne habe ich den Fehler nach Abschalten der Cursor noch behoben, beim Quickmeasure und anderen Fällen nicht mehr. Ist arg lange her. Grüße, Guido
Kein Grund das schlechte Gewissen zu bemühen, schließlich war das doch eine echte Hilfe, dass Du die Stellen zum Beheben der Pixelfehler schon mal gefunden hattest. Ich wäre da sicher so schnell nicht zu gekommen. Ich schau mal ob ich das für das neue Release beheben kann. Gruß Hayo
So hab das mal geprüft, Guido - Kopf hoch, alles ist gut. Das Löschen funktioniert einwandfrei, Du bist also rehabilitiert. Nur wenn man direkt aus den Cursorfunktionen ein Defaultsetup auslöst, dann werden die Felder nicht ordnungsgemäß gelöscht, da es ja keine normale Beendigung der Funktion ist. Kann ich aber nachrüsten. Gruß Hayo
So, Überreste sind beseitigt....für immer im Null Device! Und an den Nulllinienmarkierungen bin ich auch grad dran. Ist mir erst jetzt aufgefallen dass da teilweise Nonsense steht. Zum Beispiel ist immer das Groundsymbol auf der linken Seite zu sehen was ja überhaupt keinen Sinn macht. Das muß anders werden... Hayo
... und das wird es auch. Ich habe jetzt alle Bitmaps überarbeitet und die Formate korrigiert. Das sieht schon ganz gut aus. Meine Frau hält mich schon für etwas verschroben, da ich mit der Lupe versuche in den Oszi-Bildschirm reinzukriechen :-) Gruß Hayo
Ha, der Hayo... dafür brauchst du eine Lupe? Die 2 Pixel an der Zerolinie sehe ich von 5m Entfernung!!! Ich weiß, das war jetzt böse... :-) Was is'n mit der Mess-ID. "Welec", so wie "TEK", "Hp", "Rigol" ? Die haben das immer chic oben links in der Ecke, da weiß man gleich, mit was da gemessen worden ist! Kannst du das mit einbauen, oder ist das zuviel Akt? Dachte nur, wo du schon dabei bist... :-/ Was noch total fein wäre, das beim "QM" noch ein viertes Messfenster wäre, hatten wir aber schon mal angesprochen, wollte nur mal in Erinnerung rufen. Gruß Michael
Michael D. schrieb: > Ha, der Hayo... > dafür brauchst du eine Lupe? Die 2 Pixel an der Zerolinie sehe ich von > 5m Entfernung!!! Ich weiß, das war jetzt böse... :-) Respekt, dann hast Du gute Augen. Zugegebenermaßen lassen meine seit zwei drei Jahren immer mehr nach. Deswegen ist mir das mit den falschen Anzeigen auch nicht weiter aufgefallen. Shit... > Was is'n mit der Mess-ID. "Welec", so wie "TEK", "Hp", "Rigol" ? > Die haben das immer chic oben links in der Ecke, da weiß man gleich, mit > was da gemessen worden ist! Kannst du das mit einbauen, oder ist das > zuviel Akt? Dachte nur, wo du schon dabei bist... :-/ Das hab ich nicht so ganz verstanden. Wo willst Du die ID einblenden? > Was noch total fein wäre, das beim "QM" noch ein viertes Messfenster > wäre, hatten wir aber schon mal angesprochen, wollte nur mal in > Erinnerung rufen. Ist nicht vergessen, gibt es aber noch nicht mit diesem Release, ich hoffe Ihr könnt das verschmerzen. Sonst wird die ja auch nie fertig. Ich wollte eigentlich wenn Ihr da nichts Grobes mehr habt heute das neue Release raushauen. Also wenn Ihr noch was habt dann hurtig, bald ist Anzeigenschluß... Gru0 Hayo
Ist die Unterstützung der Eingangsplatinen schon drin? Wenn ja ging das an mir vorbei, deshalb habe ich die Betaversionen bisher noch nicht angefasst. Jörg
Angehängte Dateien:
-
Tek-01.jpg
98 KB -
RIGOL-01.jpg
52 KB
Hallo Hayo,
> Das hab ich nicht so ganz verstanden. Wo willst Du die ID einblenden?
ähem, immer noch oben links, in der Ecke?!?
Ok, ich habe mal auf die Schnelle nach ein paar Beispielen geschaut...
guggst du!
Gruß Michael
Dann hatte Dich doch richtig verstanden. Meine Frage kam weil da an der Stelle kein Platz ist um eine ID auszugeben - guggst Du auf WELEC und siehe da - da stehen die Informationen von Kanal 1. @Jörg Ja die Hardwareunterstützung ist im Final Release drin. Gruß Hayo
Michael D. schrieb: > Wo willst Du die ID einblenden? Das Einblenden auf dem Screen bringt ohnehin keinen Informationsgewinn. Interessant wäre sowas für die Screenshotfunktion. Ob das dann besser am PC oder im Welec vor der Übertragung eingeblendet werden soll kann ich allerdings nicht beurteilen, da ich dazu die SW zu wenig kenne.
Als weiteres Gutie für das final Release habe ich noch am Rotary-Interface rumgeschraubt und die Geschwindigkeit bei TB-Wechsel und Spannungsbereichwechsel erhöht. Bislang war das doch arg zäh, besonders bei langsamen Zeitbasen. Das fühlt sich jetzt schon viel besser an. Gruß Hayo
Hayo schrieb: > Dann hatte Dich doch richtig verstanden. Meine Frage kam weil da an der > Stelle kein Platz ist um eine ID auszugeben - guggst Du auf WELEC und > siehe da - da stehen die Informationen von Kanal 1. ...hab' ich 'geguggt' und weiß ich ja! Vielleicht kann man den Krempel ein Stück nach rechts rutschen?!? War ja nur so eine Idee, weil fast alle DSO's das haben. Wenn es zuviel Aufriss ist, dann lassen wir das... > Das Einblenden auf dem Screen bringt ohnehin keinen Informationsgewinn. Achso? Hm, wenn von DSO's Fotos geschossen werden, weiß man gleich mit was da gemessen worden ist! Finde ich schon informativ. > Interessant wäre sowas für die Screenshotfunktion. Ob das dann besser am > PC oder im Welec vor der Übertragung eingeblendet werden soll kann ich > allerdings nicht beurteilen, da ich dazu die SW zu wenig kenne. Da wäre Beides auch zu begrüssen, da ja Screenshots eh ein kleineres Dateiformat haben, als Fotos. Ist ja jetzt nicht so Lebenswichtig! Gruß Michael
Und hier ist sie, die diesjährige Holiday Edition. Und wieder hat sich sehr viel getan. Dank Eurer Hilfe beim Testen und Analysieren konnte die Firmware wieder ein ganzes Stückchen verbessert werden. Die neuen Funktionen sind in der Special Functions.txt beschrieben. Ansonsten einfach hier fragen. Viel Spaß Hayo p.s. aufgrund der Komplexität kann sich der eine oder andere Fehler natürlich trotzdem noch eingeschlichen haben. Dann gebe ich natürlich kurzfristig eine neue Kompilation raus.
Angehängte Dateien:
Hallo Hayo, Ich habe deine Holiday Edition gerade mal geflasht und schon mal ein wenig getestet. Shot 1: Kanal 2 GND-Coupling, ist die Linie jetzt 2 Pixel zu hoch...die Lupe war staubig! :-) Shot 2: Im Quick Measure steht bei beiden Kanälen Peak to Peak auf 0 Volt beim GND-Coupling, das ist prima! Shot 3: Im Quick Measure steht auf Kanal 1 Peak to Peak 625mV u. Kanal 2 auf 1 bis Teilweise 1,5 Volt, bei AC-Coupling! Ich glaube, das ist too much. Die Spannungen bleiben, egal welchen Filter ich dazu schalte. Kann das noch Jemand bestätigen? Was meinst du? Gruß Michael
Angehängte Dateien:
-
1V-Div-no_Filter.png
5 KB
Ok, es sind die "bösen" einer u. zweier Skalen, die ja das extreme Grundrauschen mitbringen, dann kann das hinkommen. Die Filter werden in dem Fall also nicht berücksichtigt. Wäre es möglich, das die Filter, die ja das Rauschen unterdrücken, bei der Messung mit einzubeziehen? Das soll heissen, wenn ein starker Filter ausgewählt ist, sollte das QM das wissen, ist das möglich? Gruß Michael
Hayo W. schrieb: > @Jörg > > Ja die Hardwareunterstützung ist im Final Release drin. Ich war gerade im Begriff nachzufragen, was denn die "Final Release" ist, ob die "Holiday Edition" (Weihnachtsausgabe?) schon sowas ist. Nun habe ich in den Code geguckt und meine Hinterlassenschaften gefunden. ;-) Es sind eher zu viele (weil ich dir das so hastig abgekippt habe): Der Testcode in hardware_t.cpp kann und sollte raus, das sind die Definition und Aufrufe von porttest(). Ferner ist in ADDON_SetSwitches() noch etwas mit #if 0 auskommentierter Code, der kann auch entsorgt werden, sowie die auskommentierten printf(). Nun sollte ich wohl mal bald die Skalierungsfaktoren bestimmen? Danke und Grüße Jörg
@Michael warum hast Du das nicht vorhin gesagt, das sind doch alte Fehler, dann hätte ich da schnell nochmal einen Fix gemacht. Naja, ich schieb das bei Gelegenheit mal nach. Zur Zeit werden bei QM wohl nach die alten Speicherbereiche gelesen, da stehen aber nur die Rohdaten drin. Da ich QM selten nutze ist mir das nicht aufgefallen. @Jörg Die Addon-Unterstützung ist ja erstmal auch nur für Dich, da außer Dir noch keiner die Teile eingebaut hat. Wenn Du da den Feinschliff gemacht hast übernehme ich das einfach in die nächste Version. By the way - wie findet Ihr die neuen Bitmaps? Achtet auf das schicke Average-Zeichen beim Triggerkanal. Und es wird jetzt auch rechts ein DC-Symbol eingeblendet. Gru0 Hayo
hmm... > warum hast Du das nicht vorhin gesagt, das sind doch alte Fehler, dann > hätte ich da schnell nochmal einen Fix gemacht. Naja, ich schieb das bei > Gelegenheit mal nach. Ich hatte das wohl irgendwo da oben schon mal abgelassen, jetzt hatte ich auch nicht mehr daran gedacht, ausserdem will ich dir nicht ständig auf die "Nüsse" gehen... > Zur Zeit werden bei QM wohl nach die alten Speicherbereiche gelesen, da > stehen aber nur die Rohdaten drin. Da ich QM selten nutze ist mir das > nicht aufgefallen. Ich finde das QM sehr praktisch für das schnelle Ablesen. Beim Analogen muß man ja erst mal die 'Kästen' abzählen! Und ja, manchmal mache ich mir's halt einfacher, dafür ist es ja da. Na klar ist mir das neue DC u.AC-Symbol aufgefallen, ist jetzt schön lesbar! Average-Zeichen??? Wie, wo ist das? Hab' ich da was übersehen? Mach doch mal ein Bildchen...
Angehängte Dateien:
-
USTB-01.png
3,5 KB -
1GSa-s--50ns--Roll.png
3,5 KB
Ok, hier noch ein paar Fehler: 1.Shot: Im USTB-Modus, bleiben Reste auf dem Schirm, wohin ich auch schalte, die bleiben! 2.Shot: Ich gehe auf 1GSa/s 50ns und die Reste bleiben! Ausserdem bleiben die Symbole 'Roll Forward' und 'Step' stehen. Dasselbe passiert auch umgekehrt, gehe ich in den USTB-Modus, bleibt oben der Combitrigger und noch andere Bröckchen stehen. Gruß Michael und jetzt in's Bett!
Angehängte Dateien:
-
Kanal_1_2_.gif
12 KB -
Rollmode.gif
13 KB -
Shiftmode.gif
13 KB
Hallo zusammen, erstmal vielen Dank für den großen, dauerhaften Einsatz für die Firmware. Beim Erforschen der neuen Version sind mir einige Dinge aufgefallen: Die obigen Bilder sind mit GND-Kopplung auf 1 und dem Testsignal an 2 entstanden. Im USTB läßt sich die Kopplung nicht umstellen. Das Menü (GND, DC, AC) verschwindet sofort wieder. Die ganze Bedienung im USTB ist exterm zäh. Das Übertragen eines Screenshots dauert ewig (192s gegenüber 15s normal). Der Shift-Mode (USTB) verschiebt die Nullinie des GND-gekoppelten Signals nach unten (bei Reverse doppelt so weit wie bei Forward). Die Summierung (1+2) verstehe ich, (1-2) ist zumindest nicht das was ich erwarten würde... Oder interpretiere ich was falsch? Viele Grüße, Rainer
Angehängte Dateien:
-
Kanal1minus2.gif
12 KB
Hallo nochmal, die Dateinamen waren wohl ungeschickt gewählt, anbei das noch fehlende Bild. Viele Grüße, Rainer
Ok danke für die Rückmeldungen, ich sehe es gibt noch was zu tun. Mal sehen ob ich dieses Wochenende noch eine bereinigte Version rausgeben kann. Gruß Hayo
Michael D. schrieb: > Average-Zeichen??? Wie, wo ist das? Hab' ich da was übersehen? Mach doch > mal ein Bildchen... Ja, einfach Average einschalten, dann erscheint am Triggerkanal das Symbol. Gruß Hayo
Rainer H. schrieb: > Die Summierung (1+2) verstehe ich, (1-2) ist zumindest nicht das was ich > erwarten würde... > Oder interpretiere ich was falsch? Was würdest Du denn erwarten? Ich finde das sieht doch gut aus, wenn man davon absieht, das die Skalierung etwas ungünstig gewählt ist. die sollte möglichst auch bei 500mV liegen um vernünftige Ergebnisse zu kriegen. Gruß Hayo
Hallo Hayo, wie wäre die Einführung eines Math-Zero-Pfeils? Dann könnte man schneller beurteilen ob die Ergebnisse stimmen. Für die Mathematik werden doch sicherlich die spannungsbezogenen Werte verrechnet und nicht die Binärwerte!? Ohne das jetzt ausprobiert zu haben, aber lässt sich Math aus skalieren? Falls ja wäre eine Anzeige in irgendeiner Ecke praktisch. branadic
Angehängte Dateien:
-
Average-Infinite.png
4 KB
> Ja, einfach Average einschalten, dann erscheint am Triggerkanal das > Symbol. Ha! Ich hab's gefunden... Was heißt "Infinite(unendlich)" in Bezug auf den Average-Mode? Gruß Michael
nimmt man diese Minusfunktion eher für differentielle Signale oder evtl. auch für Strommessungen also Spannung vor und nach Shunt? Lässt sich da vielleicht eine Invertierung einbauen. Beispiel Spannung vor Shunt(0,1Ohm) 1V und danach 0,95V = 0,05V / 0,1 Ohm = 0,5A bei höherem Spannungsabfall (höherer Stromfluss) soll jetzt das Signal auf dem Oszi steigen anstatt ab zufallen oder funktioniert es evtl. einfach die Kanäle zu wechseln so das 0,95-1V gerechnet wird?
Hallo Hayo, Du hast völlig Recht. Irgendwie hab ich die Einstellungen während des Tests unbewußt verändert. Also blinder Alarm. Sorry. Allerdings ist mir beim Testen noch aufgefallen, dass im USTB mein GND-gekoppeltes Signal 1 ziemlich Amok läuft. Viele Grüße, Rainer
Ja die Groundkopplung ist noch nicht für USTB implementiert. Ich habe aber gerade die 4.1 in Arbeit in der alle genannten Punkte bereits behoben sind. Ich mache nur noch schnell etwas Feinschliff, dann gibts die neue Version gleich hier. Gruß Hayo
Hab auch gleich noch ne Kleinigkeit gefunden. Wenn man "About Oszilloscope" drückt wird hinterher nicht alles korrekt wuieder hergestellt. Das ist aber auch schon ein alter Bug. Hat wohl noch keiner so richtig bemerkt. Wird natürlich behoben... Hayo
Angehängte Dateien:
-
QM-StageIII-Filter.png
3,2 KB
Ahhh, das Quickmeasure weiß es jetzt auch, das da ein Filter an ist! Grafikreste gibt es auch keine mehr. Ich bin begeistert, nun gibt's den 7.Stern ******* für Hayo!!! LG Michael
...und das ist noch nicht alles. In der 4.2 die gerade entsteht habe ich auch schon mit der Wiederherstellung nach dem Info Screen (Splash) aufgeräumt. Man startet daher jetzt endlich genauso wie man das Gerät ausgeschaltet hat bzw. wie es vor dem Info-Screen war. Gruß Hayo
The new ustb is very great, thanks :) Gyppe.
Angehängte Dateien:
-
Persist_5V.png
3,3 KB
Hallo Hayo, in der Kombination von USTB mit der Display Einstellung "Persist", wobei jetzt einmal dahin gestellt sei, ob das irgendwofür sinnvoll ist, merkwürdige Signale. Mit festen +5V am Eingang sieht mit Persist-Mode "off" alles normal aus, bis auf den 0 -> 5V Sprung ganz am Anfang. Ungefähr in der Mitte des Bildschirms habe ich dann den Persist-Mode, bei immer noch konstanten 5V am Eingang, aktiviert und erhalte den "Lattenzaun" (Bild). Wenn man dann innerhalb der Aufzeichnung Persist kurz aus- und wieder einschaltet, wird der richtige konstante 5V Pegel angezeigt, bis man einmal kurz das Signal auf 0V runternimmt, dann wird wieder der Lattenzaun aufgebaut. Hast du eine Idee, wo das herkommt? Gruß Rainer
Jupp, hab ich. Am Gridende geht ja der Pegel von 5V wieder runter auf 0V, da am Gridende ja der aktuelle Acquisitionzeitpunkt ist und vorher anscheinend nichts in den Puffer geschrieben wurde. Dieser Sprung von 5 auf 0V wird dann durch die persistente Darstellung weiter durchgereicht. Wenn Du das Ganze machst nachdem Du vorher schon einen kompletten Durchlauf mit 5V hattest wird das sicher nicht mehr auftreten, da ja dann schon der 5V Pegel im "Ringpuffer" steht und es keinen Sprung mehr gibt. Gruß Hayo p.s. ich beiß mir hier gerade die Zähne an der FFT aus. Alles andere kehrt super wieder in den Ursprungszustand zurück nach einem Restart - nur die FFT nicht, die klemmt danach. Soon Mist... Hayo
Angehängte Dateien:
-
Triggerlinie_a.png
6 KB
Hayo W. schrieb: > Wenn Du das Ganze machst nachdem Du vorher schon einen kompletten > Durchlauf mit 5V hattest ... Das stimmt. Dann ist das wohl so ... Dafür hat sich bei mir gerade die Triggerlinie in den oberen Bildschirmbereich mit den Meßbereichsanzeigen verirrt. 1. Wenn man nach Default Setup den Triggerlevel ganz nach oben schiebt, knabbert das "T" ganz links ein bisschen an der "1" in der obersten Zeile 2. Wenn man einen Kanal invertiert und dann den Triggerlevel zu negativen Werten schiebt, wandert die gestrichelte Line und das "T" incl. Pfeil munter hinter den Kanalnummern längs und die Nummer des gleichfarbigen Kanals verschwindet auch ganz. Das sieht so aus, als ob das Clipping für den Triggerlevel die Invertierung nicht berücksichtigt. Nach unten wird die Triggerverschiebung nämlich sauber begrenzt. In dem Inset sieht man das schön vergrößert ;-) Den FFT-Restore wirst du schon knacken. Gruß Rainer
Angehängte Dateien:
-
screen-0000.jpg
71 KB
Hallo Hayo und alle an der Weiterentwicklung unseres Scopes Interessierten. Zuerst meine Gratulation für die neue USTB-Version. Hat bei mir schon nützliche Dienste geleistet. Anbei ein Screenshot mit einem kleinen Bug, der sich sicher leicht beheben lässt. Ich bewundere auch die Geduld mit der Hayo alles anpackt und unser Gerät inzwischen zu einem (zumindest in meiner Werkstatt) nicht mehr wegzudenkenden Instrument gemacht hat. Dafür vielen Dank. Manfred
Manfred,h schrieb: > Anbei ein Screenshot mit einem kleinen Bug, > der sich sicher leicht beheben lässt. Bei mir wird die Periodendauer richtig angezeigt. Wie erzeugst du den Fehler? Gruß Rainer
Hallo Manfred, es freut mich zu hören, dass Dir die Firmware gute Dienste leistet. Danke für den Hinweis, ist natürlich auch schon behoben. Da hatte ich die Rundungsroutine ungeschickterweise erst nach der Einheitenermittlung aufgerufen, das ist aber jetzt korrigiert. Gruß Hayo
Hallo Hayo, erstmal Danke für Deine tolle Arbeit! Ich hab hier noch 2 Dinge aus der 4.1HE: Nach dem Ein- und Ausschalten von "Quick Meas" bleiben die horizontalen Cursoren stehen. Lassen sich aber mit "Cursors" Betätigung löschen. Ich bekomme irgendwie keinen Screenshot mit der 4.1HE mehr hin. Die screenshot.exe beendet sich nach ungefähr 30% der Ausgabe vom Oszi selbst :-( Gruß Jürgen
Moin, moin, ok werd ich mir auch mal ansehen. Hayo
Angehängte Dateien:
-
Statusbar_01.jpeg
51 KB
Jürgen schrieb: > Nach dem Ein- und Ausschalten von "Quick Meas" bleiben die horizontalen > Cursoren stehen. Lassen sich aber mit "Cursors" Betätigung löschen. Ist in der neuen Version behoben -> danke > Ich bekomme irgendwie keinen Screenshot mit der 4.1HE mehr hin. Die > screenshot.exe beendet sich nach ungefähr 30% der Ausgabe vom Oszi > selbst :-( Das kann ich mir leider nicht erklären. Bei mir läuft der Screenshot einwandfrei auf zwei verschiedenen Rechnern und auf Windows und Linux. Was läuft da bei Dir schief??? Anbei ein Screenshot der neuen Version. Ich habe die Statusbar etwas aufgemotzt. Findet dass Euer Wohlwollen, oder ist das zu verspielt? Gruß Hayo
Hayo W. schrieb: >> Ich bekomme irgendwie keinen Screenshot mit der 4.1HE mehr hin. Die >> screenshot.exe beendet sich nach ungefähr 30% der Ausgabe vom Oszi >> selbst :-( > Das kann ich mir leider nicht erklären. Bei mir läuft der Screenshot > einwandfrei auf zwei verschiedenen Rechnern und auf Windows und Linux. > Was läuft da bei Dir schief??? Habe mir das eben nochmal genauer angesehen. Zunächst gleiche Reaktion. Habe dann im Verzeichnis der screenshot.exe eine Datei ".~lock.trace-0001.csv#" gefunden und erstmal gelöscht. Danach geht es wieder :-) Sorry - Hat mich auch gewundert, daß hier Screenshots gepostet wurden.... Übrigens gefällt mir die alte Statusleiste viel besser!!! Die neue ist doch zu verspielt und nicht so "technisch"! Gruß Jürgen
> ".~lock.trace-0001.csv#" gefunden und erstmal gelöscht. Danach geht es > wieder :-) ach, wo kommt die denn her? Wurde die irgendwie generiert? Hallo Hayo, ich habe mir den Screenshot mal 5 Minuten lang angeschaut und mußm dem Jürgen zustimmen! Als Designer, würde ich das aber nicht komplett zerschlagen. Wie sieht's denn aus, wenn man da 3 Blöcke daraus macht? Z.B. ein Block für die Kanäle mit Spannung, der nächste Block 1GS/x 20ns und den dritten Block mit dem Rest? Dann wäre da nicht so viel 'Unruhe' in der Grafik! Gruß Michael
Ich sehe schon, das spaltet evtl. die Gemeinde. Ich kann mal einen Testschalter einbauen, damit man zwischen den Darstellungen auswählen bzw. testen kann. Gruß Hayo
Leider zu früh gefreut :-( Das war nicht die Ursache. Es geht wieder nicht. Habe noch kein Schema entdecken können. Mal funktioniert es und mal nicht. Ich hätte jetzt zwei Verdächtige hier bei mir: Laptop mit Dualcore CPU, besch.. USB-Seriell Konverter am Expresscard/34 - Port. Ich hab mal bei stehendem DSO-Bild mehrere Screenshots mit einem Terminalprogramm aufgenommen. Etwa 1 von 10 Aufzeichnungen hat eine andere Länge ??? Kann das sein? Hajo, halte Dich aber damit erstmal nicht auf. Ich muss das DSO wohl mal zu meinem PC tragen und dort testen.
Moin Hayo, Hayo W. schrieb: > Anbei ein Screenshot der neuen Version. Ich habe die Statusbar etwas > aufgemotzt. Findet dass Euer Wohlwollen, oder ist das zu verspielt? ich finde die alte Version einfach klarer. @Michael Dein Kompromiß wäre eine ernste Überlegeung wert. Noch mal ein dickes Lob speziell für das jetzt endlich richtig benutzbare Delay-Fenster. Gruß Rainer
Hayo W. schrieb: > Anbei ein Screenshot der neuen Version. Ich habe die Statusbar etwas > aufgemotzt. Findet dass Euer Wohlwollen, oder ist das zu verspielt? Hallo Hayo, auch kann mich für das neue Design nicht begeistern. Zu unübersichtlich - es fehlt irgendwie eine klare Linie. Gruß, Bernd
Angehängte Dateien:
-
Parameter_Michael.JPG
49 KB
p.s. Michael, meintest du etwa so? Ich bin weiterhin für die alte.
Jürgen schrieb: > Ich hätte jetzt zwei Verdächtige hier bei mir: > Laptop mit Dualcore CPU, besch.. USB-Seriell Konverter am Expresscard/34 > - Port. Es bleiben die zwei Verdächtigen. Nr.2 würde ich mit Vorurteil(?) als Hauptverdächtigen bezeichnen.. Hab mit einem anderen Rechner getestet: Screenshot geht einwandfrei. Ich bitte um Entschuldigung, weil man ja eigentlich hier erst posten sollte, wenn man solche einfachen Dinge durch Test ausgeschlossen hat ... :-O Freue mich schon auf die neue Version! Gruß Jürgen
@Jürgen Kein Problem, lieber einige Rückmeldungen mehr als weniger. Nur so kommen wir weiter. Ich sehe schon, die Tendenz geht gegen die neue Statusleiste. Ich gebe zu ich bin auch etwas unentschlossen und schwanke zwischen nettem Design und besserem Kontrast. Ich warte nochmal ab, aber es sieht so aus als würde das neue Design wieder sterben....:-( Hat ne Menge Arbeit gemacht. Aber man muß halt experimentieren. Hayo
Rainer W. schrieb: > Dafür hat sich bei mir gerade die Triggerlinie in den oberen > Bildschirmbereich mit den Meßbereichsanzeigen verirrt. Ist erledigt. > 1. Wenn man nach Default Setup den Triggerlevel ganz nach oben schiebt, > knabbert das "T" ganz links ein bisschen an der "1" in der obersten > Zeile Ist erledigt. > 2. Wenn man einen Kanal invertiert und dann den Triggerlevel zu > negativen Werten schiebt, wandert die gestrichelte Line und das "T" > incl. Pfeil munter hinter den Kanalnummern längs und die Nummer des > gleichfarbigen Kanals verschwindet auch ganz. Ist erledigt. > > Den FFT-Restore wirst du schon knacken. Ist erledigt Hier die Vorabversion der 4.2 die schon alle Fixes beinhaltet aber noch mit der neuen Statusleiste daherkommt. Vermutlich die einzige Version mit dieser Statusleiste. Gruß Hayo
mir gefällt auch die alte Version der Statusleiste besser. Ich würde diese gerne mal mit dem Hintergrund zur Schrift invertiert sehen, sieht bestimmt auch nicht schlecht aus. Vielleicht den Schalter dafür einbauen.
Angehängte Dateien:
-
Textfelder.PNG
150 KB
Um das Gute aus beiden Welten (schickes Design und hoher Textkontrast) zu verbinden, habe ich hier mal grob eine Version skizziert, die den bisherigen helleren Farbton als Texthintergrund beibehält und eine dunklere Farbe als Basishintergrund verwendet. Ob Einzelfelder oder Gruppenfelder sei jetzt mal dahingestellt. Die Menüzeile (und Meß-/Cursorparameter) könnten dazu passend eingefärbt werden, wobei man mal gucken muß, ob mit der verfügbaren Farbpalette guter Hintergrundkontrast zum Zeichenfeld und Farben für den 3D-Effekt unter einen Hut zu bringen sind. Gruß Rainer
Angehängte Dateien:
-
Statusleiste_Oszi.png
25 KB
ich habe mir das so vorgestellt wie auf der rechten Seite. Also S/W bietet doch den höchsten Kontrast und viele Professionelle Oszis zeigen das auch so an also ohne eingefärbten Hintergrund. Ich finde es sieht auch geräumiger aus. Und Nachts ist es dann auch nicht so grell umso weniger Helle Balken man auf dem LCD hat.
moin Rainer, deine Version gefälllt mir ganz gut, vielleicht noch ein ganz helles Grau im Hintergrund, mal schauen, wie das kommt... (hast du meine letzte PN nicht bekommen?) moin Thomas, deine Version kommt auch ganz gut! Evtl. noch einen Dunkelgrauen Hintergrund, sodas man sieht, wo der Messbereich vom Schirm aufhört? Wenn das machbar wäre sich die Farbgebung, je nach Lichtverhältnissen anpassen zu können, wäre das ein Highlight. Natürlich nur dann, wenn die Perfomance nicht darunter leidet! Gruß Michael
ich finde die Abtrennung zum Messbereiches ist doch durch das Raster(Rahmen) gegeben. Anderst würde es das ganze optisch drücken wodurch es kleiner aussieht.
...könnte sein. Müsste man mal visuell ausprobieren!
Angehängte Dateien:
-
Statusleiste_Oszi.png
25 KB -
Statusleiste_Oszi_2.png
25 KB
hier nochmal die direkte Gegenüberstellung. Die Spannungsbereiche müssen ja nicht weiß gemacht werden, habs nur mal ausprobiert.
Thomas O. schrieb: > ich habe mir das so vorgestellt wie auf der rechten Seite. Also S/W > bietet doch den höchsten Kontrast und viele Professionelle Oszis zeigen > das auch so an also ohne eingefärbten Hintergrund. Ich finde es sieht > auch geräumiger aus. Und Nachts ist es dann auch nicht so grell umso > weniger Helle Balken man auf dem LCD hat. Also nachts ohne Licht nutze ich das Oszi recht selten :-) Aber ansonsten stimme ich dir voll zu: so ists am besten ablesbar und es sieht nicht so vollgequetscht aus. Ich finde es ohne eingefärbtem Hintergrund am besten.
@Hayo hattest du was gemacht an der 'Triggeranzeige' im Single Mode in der 4.1 ? (geht immer noch nicht) ;( vlG Charly
hallo thomas, der linke Shot sieht gut und aufgeräumt auf. Wo du schon dabei bist, nimm mal verschieden Grautöne und setze die mal als komplette Leiste (ohne die Kästen), hinter die weisse Schrift...mal schauen, wie das kommt! Gruß Michael
welche Kästchen meinst du die der Menüpunkte?
Angehängte Dateien:
-
Statusleiste_Oszi_3.png
25 KB
so habe mal die Menüpunkte auch S/W gemacht gefällt mir ganz gut oder meinst du die Kästchen ganz entfernen.
> welche Kästchen meinst du die der Menüpunkte?
Nö.
Ich meinte die obere Leiste, ohne die Kästchen mit einem mittleren oder
dunklen Grau, aber durchgehend von links nach rechts...vielleicht sollte
man einige Grautöne mal testen?!?
Ich finde den linken Shot auch nicht schlecht! Und überhaupt finde ich
die Schwarz-Weiß-Kombination schon ansprechend, ist nicht so verspielt.
Was mir gut gefällt, ist die '1 Pixel' breite Kontur., die ist schön
dezent und nicht so aufdringlich.
Ich bin schon ganz gespannt!!! Wie machst das denn mit den Shots,
spielst du da im Code?
Gruß Michael
EDIT: Mit der Scwarz-Weiß Kombination, könnte man im Display-Menu
zwischen positiv u. negativ, je nach Sichtverhältnissen hin u.
herschalten?!? Da wäre dann für fast jeden was dabei, oder?
noch mal EDIT: Die Kästchen im unteren Bereich, würde ich auf jeden Fall
lassen...
Hallo allerseits, bin gerade erst nach Hause gekommen. Hier ist ja ganz schön was los. @Michael Die Bilder sind Kopien von meinem Shot. Achte mal auf die Signale. Die Bilder sind einfach mit einem Bildbearbeitungsprogramm manipuliert worden. Ist aber eine gute Idee um mal ein Gefühl für die Farben zu kriegen. @Charly Sorry, da hatte ich noch nichts gemacht, da das bei mir nicht unter Bugfix residiert sondern unter Change Request. Habe ich aber auf dem Zettel stehen. (Du meintest doch die Verstellung der Zeitbasis im Single Mode oder?) @all Ich finde allerdings zuviel schwarz/weiß nicht so gut, da fühle ich mich irgendwie in alte Zeiten zurückversetzt als es nur schwarz/weiß Fernseher bzw. Displays gab. Kennen viele von Euch wahrscheinlich gar nicht :-). Wenn man die Statusleiste in schwarz/weiß realisiert böte sich zusätzlich die Option die weißen Zeichen in den Gridlayer zu schreiben, was die Möglichkeit bietet die Helligkeit zu verstellen und auch die Farbpalette im Display-Menü einzustellen - so wie bei der FFT wenn das s/w Layout aktiv ist. Gruß Hayo
>Wie machst das denn mit den Shots, spielst du da im Code?
Wie Hayo schon sagte, mit dem Bildbearbeitungsprogramm, ich nehme mit
mit der Pinzette eine Farbe und Fülle dann einen Buchstaben oder einen
Bereich mit der selektierten Farbe, etwas unprofessionell, aber
Paint.net was ich gerne benutze, hat keine Funktionen wie Farbe
ersetzen.
Mir gefällt auch dieser verspielte Hintergrund nicht einfach Schwarz
wäre schonmal ein Vorteil, die Schriftfarben sind nebensächlich. Es
erinnert mich immer ein meinen Sat-Receiver mit klicki-bunti Oberfläche.
Hallo allerseits, also ich hab da eben ganz andere Probleme :-( Wieso geht denn nun die Zeitverstellung im Pulse With Modus nicht mehr? Hajo, da scheint etwas durcheinander geraten. Gruß Jürgen
all > Ich finde allerdings zuviel schwarz/weiß nicht so gut, da fühle ich mich > irgendwie in alte Zeiten zurückversetzt als es nur schwarz/weiß > Fernseher bzw. Displays gab. Kennen viele von Euch wahrscheinlich gar > nicht :-). pfff, is' klar! bin auch schon fuffzich und kein Schwarz-Weiß-Denker :-))) Ok, das letze Layout von Thomas finde ich schön übersichtlich. Mein Vorschlag: Die obere Anzeige mit Hintergrundbalken, Schrift ohne Kästchen und die untere Reihe mit Kästchen. Schriftfarbe für unten u. oben in einem Auswahlmenu veränderbar. Hinntergrundfarbe für oben u. unten ebenfalls veränderbar,dann bräuchte man quasi nur 2 Scrollmenus im Displaymenu, geht das? Dann wäre für Jeden was dabei und das Welec wäre in der Klasse schon mal 'einmalig'! Was meinst du, oder ist das zuviel Aufriss? Gruß Michael
> Wieso geht denn nun die Zeitverstellung im Pulse With Modus nicht mehr?
Ich habe das Teil gerade mal an.
Stimmt, da geht erst mal nix! Erst wenn man den entsprechenden Button
gedrückt hat, dann lassen sich die Zeiten verstellen...
Ich hab's jetzt noch mal getestet, immer mal die Knöppe drücken, dann
tut sich was, dauert halt ein wenig bis die Zeiten umspringen...
Ist schon nicht so ganz ohne... Die gelben Buttons habe ich inzwischen schon wieder rausgenommen nachdem die allgemeine Stimmung eindeutig dagegen war. Wie wärs mit einer Testmöglichkeit für den monochromen Status. Die Umschaltung geht mit Shift + D via Terminal. Default ist allerdings die normale Darstellung. Gruß Hayo
@Jürgen sehe ich mir nachher an, muß mal wieder zum Griechen gehen... Gruß Hayo
das will ich jetzt auch mal ausprobieren. Kann mir jemand kurz sagen wie ich dem Welec den Befehl schicke.
na klar! Comterminal öffnen, Parameter eingeben, verbinden, "h" eintippen und da steht alles, ausser Shift+D da steht noch: not available! Auf dem Screenshot steht alles drauf, guggst du hier: Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil4)" Gruß Michael
Michael D. schrieb: > na klar! > Comterminal öffnen, Parameter eingeben, verbinden, "h" eintippen und da > steht alles, ausser Shift+D da steht noch: not available! Wie jetzt? Da steht * Monochrome switch : Shift + D * -> das ist jetzt schon Dein zweiter Aussetzer! Was ist los Michael? Steht der Gang zum Augenarzt an?? ;-) Bitte berücksichtigt, dass in der monochromen Darstellung noch nicht alles 100%ig funktioniert, da ist noch das Stopzeichen das stehen bleibt und die Kanalnummern hinterlassen Spuren... Soll halt zum Testen sein. Wenns gefällt kann ich das immer noch verbessern. @Thomas Du brauchst ein Terminalprogramm. Unter Linux benutze ich immer Minicom. Unter Windows ist Teraterm mein Favorit. Gibt es frei zum Download hier: http://sourceforge.jp/projects/ttssh2/releases/ Gruß Hayo
> Wie jetzt? Da steht * Monochrome switch : Shift + D * ja, steht 'jetzt' da, aber nicht auf dem Link von meinem Shot... > -> das ist jetzt schon Dein zweiter Aussetzer! Was ist los Michael? nö, noch der Erste...dumdidum > Steht der Gang zum Augenarzt an?? ;-) unter Anderem... :-( Schon zurück vom Griechen??? Du isst zu schnell, denk' an deine Vorverdauung!!! Ich habe mal kurz getestet, gefällt mir nicht so. Die Schrift wird mit der Gridhelligkeit heller u. dunkler! Kann man das Grid aussen vor lassen? (Ich denke mal, das das nur mal auf die Schnelle war für's Testen?) Gruß Michael
Michael D. schrieb: > Schon zurück vom Griechen??? Du isst zu schnell, denk' an deine > Vorverdauung!!! Ist zu Fuß nur 10 Minuten entfernt... > Ich habe mal kurz getestet, gefällt mir nicht so. Die Schrift wird mit > der Gridhelligkeit heller u. dunkler! Kann man das Grid aussen vor > lassen? Geht auch, müßte mal sehen welcher Layer sich da anbietet. > (Ich denke mal, das das nur mal auf die Schnelle war für's Testen?) Korrekt, das ist nur um mal zu checken ob das ne Option ist. Der normale Status bleibt auf jeden Fall, alles Andere würde ich optional machen über irgendein Menü oder Schalter. Gruß Hayo
Jürgen schrieb: > Hallo allerseits, > > also ich hab da eben ganz andere Probleme :-( > > Wieso geht denn nun die Zeitverstellung im Pulse With Modus nicht mehr? > Hajo, da scheint etwas durcheinander geraten. Leider habe ich da einen ganz üblen Bug in die Rundungsroutine eingebaut... Danke für den Hinweis, Abhilfe kommt so schnell wie möglich. Gruß Hayo
Moin Hayo, gestern bin ich mal auf FFT gestossen, man hat da keine Darstellungsoptionen mehr, ist das noch Baustelle? Gruß Michael
Wie meinst Du das? Eigentlich sollte alles funktioniern wie bisher - was es bei mir auch tut. Was geht denn bei Dir nicht? Gruß Hayo
für die Spektrum Darstellung, gab es doch mal mehrere Anzeige-Modi (ich glaube so 5 Stck.)die man mit dem Drehgeber auswählen konnte, wo ist das denn hin? Momentan ist da Win: Rectangle als feste Darstellung angegeben. Gruß Michael
Du suchst nicht zufällig das FFT-Menü? Das erreichst Du durch einen zweiten Druck auf den FFT-Button. Ist nicht optimal - weiß ich. Deshalb werde ich auch automatisch ins FFT-Menü verzweigen wenn die FFT gewählt wird. Gruß Hayo
Für alle die nicht so genau wissen wie das mit dem Terminal funktioniert hier eine Beschreibung, die ab jetzt auch bei den Releases mit dabei ist. Hayo
So hier die 4.2 mit dem verbesserten Monochrome Status. Es wird jetzt der cremefarbene Layer benutzt statt des Gridlayers. Der weiße Layer geht leider nicht da dieser einen Darstellungsfehler hat der Probleme auf der linken Seite verursacht. Ich finde ja eigentlich den Gridlayer besser... Gruß Hayo
Hayo W. schrieb: > Leider habe ich da einen ganz üblen Bug in die Rundungsroutine > eingebaut... > > Danke für den Hinweis, Abhilfe kommt so schnell wie möglich. > > Gruß Hayo Hallo Hayo, das wäre super! Ich hab mal im Teil 3 unseres Firmware Threads gesucht, was da noch so alles zur Triggerung anlag und in der 4.2pre schon realisiert ist: Holdoff-value auf <=134ms begrenzen, von rawi 29.10.2010, ist realisiert Bei Pulse Width Holdoff zwingend auf Off setzen, ich 28.8.2010, nicht realisiert bei Pulse Width den Pretrig auf Softbutton 6 setzen, von rawi 12.09.2010, nicht realisiert und als "nice to have": auch den aktuellen Triggerkanal nur aus der Anzeige ausblenden zu können, von weitererGast 30.09.2010 Nur, damit es nicht vergessen wird :-) VG Jürgen
Jürgen schrieb: > Hallo Hayo, das wäre super! Schon geschehen - s.o. > Ich hab mal im Teil 3 unseres Firmware Threads gesucht, was da noch so > alles zur Triggerung anlag und in der 4.2pre schon realisiert ist: Ja hab ich auch schon, aber das ist schon etwas unübersichtlich. > Holdoff-value auf <=134ms begrenzen, von rawi 29.10.2010, ist > realisiert Korrekt, das ist schon drin > Bei Pulse Width Holdoff zwingend auf Off setzen, ich 28.8.2010, nicht > realisiert Oh, den hatte ich allerdings nicht mehr auf der Pfanne -> nehme ich auf > bei Pulse Width den Pretrig auf Softbutton 6 setzen, von rawi > 12.09.2010, nicht realisiert Den auch nicht -> kann ich einbauen > und als "nice to have": > auch den aktuellen Triggerkanal nur aus der Anzeige ausblenden zu > können, von weitererGast 30.09.2010 Den hatte ich noch auf der Pfanne, bin aber noch am überlegen wie man das am sinnvollsten einbaut. > Nur, damit es nicht vergessen wird :-) Alles klar, danke. Gruß Hayo
> @Charly > > Sorry, da hatte ich noch nichts gemacht, da das bei mir nicht unter > Bugfix residiert sondern unter Change Request. Habe ich aber auf dem > Zettel stehen. > (Du meintest doch die Verstellung der Zeitbasis im Single Mode oder?) ja das waehre mir am alllerwichtigsten, aber i dachte mir schon das da noch nix ist, aber die anzeige das ein Triggerevent da war im Single mode sollte zeitnah sein, im moment ist es so das es angezeigt wird wenn der Schirm geschrieben wird, so kann man den 'Fehler' reprodzieren: utility, Default Setup TB auf 200ms, trigger so einstellen das er vom testsignal triggert, jetzt auf Single, dann kurz mit dem TK das Testsignal antippen und beobachten, erst nach ueber 2 Sekunden wechselt run/stop auf Rot und die "LED4" Flackert, meiner meinung nach sollte run/stop direkt beim Triggern auf Rot und wenn alles aufgezeichnet ist Single von rot auf gruen Da ich viel im Single Mode arbeite hab i im moment keinen anhaltspunkt zu sehen ob schon getriggert wurde oder ob das Oszi noch wartet. So, i hoffe i habe mich nicht zu kompliziert ausgedrueckt vlG Charly
Angehängte Dateien:
-
MonoStatus.jpg
100 KB
Ok, danke Charly, ich sehe mir das noch mal genau an. Anbei übrigens mal ein Monochromer Status mit Gridlayer als Textlayer und das Ganze mit meiner Lieblingspalette. Nur so als Demo wie es aussehen könnte. Hayo
Da die Pulsweitentriggerung hier einige Male aufkam habe ich die mal getestet (hab ich sonst nie benutzt) und festgestellt dass die bis auf die "Größer" Funktion überhaupt nicht funktioniert. Da ich nicht weiß wie weit oder ob überhaupt diese Funktionen hardwareseitig implementiert sind kann ich höchstens mal versuchen das softwaremäßig nachzurüsten -> schade eigentlich. Hayo
Danke für die neue Version, Hayo! Allerdings funktioniert die Pulsweitentriggerung noch nicht wie gewünscht. Irgendwelche Ausgaben fehlen noch an die Hardware. Z.B. funktioniert die Triggerung am besten nach einem "Center Channel x". Danach kann die Nulllinie des Kanales nur ca. +- 100 mV nach oben oder unten verschoben werden. Danach erfolgt keine Triggerung mehr. Am Besten geht es, wenn man die Triggermarke auf 0,0V stellt und danach die Nullinie hoch oder herunter kurbelt. Danach drückt man "Edge" und "Pulse Width" und es funzt wieder. Ich denke es fehlt da noch die Nachführung des DAC bzw. die Nachführung des Triggerwertes. Gruß Jürgen
Angehängte Dateien:
-
pulse-width.JPG
97 KB
Hayo, hab gerade Deinen Post gelesen. Die Pulsweitentriggerung funktioniert sehr wohl. Es funktioniert ausser "kleiner" normalerweise alles recht gut. Also bitte nicht in SW nachrüsten sondern gangbar machen! :-) Ich habe oben ja versucht anzudeuten, woran es hängt. Die im Bild gezeigte Impulsform wird überwiegend stabil angezeigt. Gruß Jürgen
Leider sind aber die Register überhaupt nicht dokumentiert. Da heißt es zu experimentieren. Gruß Hayo
Hayo W. schrieb: > Leider sind aber die Register überhaupt nicht dokumentiert. Da heißt es > zu experimentieren. Nun, abgucken ist hier aber erlaubt. Habe mir vorhin die originale Welec V1.4 nochmal "angetan" und vergleiche damit die Registerbelegungen. Unterschied z.B. V1.4 ctrl_reg: 1807 BF4.2 : 1207 Die Funktion "<" geht dort auch nicht. Zumindest fängt diese Version sogar den ganz kleinen Impuls aus meiner Beispielimpulsfolge stabil. Das hängt aber sicher auch mit der Signalhöhe, Triggerpunkt usw. zusammen, da der FPGA ja etwas zum Auswerten braucht. In der V1.4 läßt sich aber .B. die Triggerung in beiden Richtungen durch Verstellen von Triggerhöhe und/oder Pulsweite wieder starten. Gruß Jürgen
Hallo Hayo, ich hatte mal versucht zu dokumentieren. Ist lange her... Vielleicht hilft's weiter? Gruß Jürgen
Hi Hayo, > Du suchst nicht zufällig das FFT-Menü? Das erreichst Du durch einen > zweiten Druck auf den FFT-Button. Ganz zufällig, habe ich mir da einen Wolf... :-( ...und genau, das habe ich gesucht! Nicht zu fassen, wäre ich nie drauf gekommen. Wo ist das dokumentiert? Die obere Leiste in Monochrome kommmt gut, gefällt mir! Die setzt sich noch schön vom Grit ab. Gruß Michael
Jürgen schrieb: > Allerdings funktioniert die Pulsweitentriggerung noch nicht wie > gewünscht. Irgendwelche Ausgaben fehlen noch an die Hardware. > Z.B. funktioniert die Triggerung am besten nach einem "Center Channel > x". Danach kann die Nulllinie des Kanales nur ca. +- 100 mV nach oben > oder unten verschoben werden. Danach erfolgt keine Triggerung mehr. > Am Besten geht es, wenn man die Triggermarke auf 0,0V stellt und danach > die Nullinie hoch oder herunter kurbelt. Danach drückt man "Edge" und > "Pulse Width" und es funzt wieder. > Ich denke es fehlt da noch die Nachführung des DAC bzw. die Nachführung > des Triggerwertes. So, ich hoffe ich hab das Problem gefunden :-) Hab mal die Variablen bei Edge und Pulse Width verglichen, wenn man nur den Kanal hoch und hinunter schiebt. Ich denke es fehlt das Update des trg_val_CHI_reg. Dieser Triggerwert bestimmt die Stelle im Signal, wo die Pulsweite verglichen wird?! Hajo, ich denke Du weisst eher wo da was zu ergänzen ist ? Gruß Jürgen
Das ist dokumentiert in Special Functions.txt - wie meistens. War aber etwas ungünstig vom Handling gebe ich zu. Ab jetzt verzweight er direkt ins Menü wenn FFT aufgerufen wird. Der zusätzliche Druck führt aber immer noch ins Menü. @Jürgen Die Doku kannte ich noch nicht, da werde ich mal sehen ob ich da was machen kann, danke. Gruß Hayo
Hayo W. schrieb: > Anbei übrigens mal ein Monochromer Status mit Gridlayer als Textlayer > und das Ganze mit meiner Lieblingspalette. Nur so als Demo wie es > aussehen könnte. Die Darstellung der Statuszeile mit dunklem Hintergrund scheint mir auch sehr gelungen. Allerdings halte ich es für nicht so praktisch, den Text in den Gridlayer zu packen, da das Grid doch oft dezent in den Hintergrund gedreht wird, man aber die Angaben zum Meßbereich eigentlich doch immer in voller Schönheit sehen möchte. Gruß Rainer
Michael D. schrieb im Beitrag #2329221: > Man kann ebenfalls ein beliebiges "NULL-MODEM" Kabel verwenden, sollte > nur nicht zu lang sein, könnte Übertragungsfehler geben! Das mit dem "Null-Modem" Kabel halte ich für ein Gerücht. Für die Verbindung vom PC zum DSO ist das IMHO ein ganz normales serielles 1:1 Kabel bzw. USB-Seriell Adapter mit Stecker DE-9 male auf DSO-Seite ohne irgendwelche Adernvertauschungen. ... und das funktioniert bestens. ;-) Gruß Rainer
Nullmodem würde mich jetzt auch wundern, das hat doch Buchse - Buchse während man fürs WELEC ein normales 1:1 Stecker - Buchse Kabel benötigt. Gruß Hayo
Hallo Hayo, hier die geänderte Funktion SetupTrigger() zur Übernahme. Feinschliff (ext. Trigger usw.)und weitere Tests (Ch.2-4) dann später. War doch einfacher als gedacht :-) Jetzt kann man den Ch1 mit Pulse Width- Trigger über den Schirm jagen und die Triggerung bleibt erhalten. GN Jürgen
> Nullmodem würde mich jetzt auch wundern, das hat doch Buchse - Buchse > während man fürs WELEC ein normales 1:1 Stecker - Buchse Kabel benötigt. Ihr habt natürlich Recht! Das war Blödsinn. Ich habe beim Mod die Löschung beantragt.
Hallo Hayo, drückt man im Utility Menü auf Default Settings, werden in der Kopfzeile die Kanalnummern in einem runden Hintergrund gezeichnet. Hier ist das Menüupdate wahrscheinlich noch nicht durchgelaufen... ;-) Nach längerer Abwesenheit tut sich wieder ziemlich viel hier. Das Scope entwickelt sich wirklich klasse weiter. War schon kurz davor, es zum Höker zu geben... <All> Gibt es eigentlich schon ein Handbuch für das Scope? Sicher, hier tüfteln viele Cracks aber nach den Meldungen sind doch auch Einige dabei (wie ich), die nur so hobbymäßig rumlöten. Und da fehlt's so manches Mal an Infos, was das Teil alles kann und wie man's effektiv einsetzt... Michel
Hayo W. schrieb: > Nullmodem würde mich jetzt auch wundern, das hat doch Buchse - Buchse > während man fürs WELEC ein normales 1:1 Stecker - Buchse Kabel benötigt. > > Gruß Hayo Ich habe ein USB-Seriell Interface im Einsatz, welches ich nur mit einem zusätzlichen Kabel zum Laufen bekommen habe - ohne dies Kabel ging gar nichts in Sachen Kommunikation PC <-> Scope. Bin schon ein wenig lange raus aus dem Projekt: Wie war das nochmal mit dem USB - Anschluss? wozu war der da? Ist über den die Kommunikation mit dem Scope möglich? Besteht vielleicht die Möglichkeit darüber das Flashfile von der Firmware aus einzulesen und den Flashvorgang von dort aus zu initiieren? (Nicht hauen, wenn die Frage zu blöd ist. Wahrscheinlich ist das das Henne - Ei Problem, oder?) Michel
also wie tuts das Serielle Kabel mit welchen ich die Firmware aufspiele oder nicht. Habs noch nicht durchgemessen ob Nullmodem oder normal. Zum Terminal habe ich es zeitlich noch nicht geschafft, werde das am WE mal nachholen aber die obere Statusleiste sieht schon um einiges besser aus. Ich wollte mein Scopy auch schon dahin tuhen wo es herkam. Aber da hat sich die letzte Zeit wirklich was getan, man kann garnicht so oft "Danke" sagen wie man will.
Ja es tut sich wirklich wieder was. Ich möchte auch nochmal (hab ich ja schon öfters) darauf hinweisen, dass zeitweilige Pausen hier nicht zu bedeuten haben dass das Projekt nicht mehr läuft. Bei mir ist es z.B. so dass ich abhängig von meinen beruflichen Projekten manchmal keine Zeit habe , besonders wenn es Auslandsprojekte sind. Da kann es dann einfach mal mehrere Wochen Funkstille geben. Das Ganze hier ist aber ein langfristiges Projekt und geht auf jeden Fall weiter. Sobald ich wieder Luft habe bin ich dann auf jeden Fall wieder dran. Also gebt Eure Büchse nicht gleich weg wenn es hier mal ruhig ist. @Jürgen Klasse, werd ich mir mal ansehen und einbauen. Vielleicht können wir den PW-Trigger ja doch noch wieder brauchbar machen. Ich habe mir auch schon überlegt nur die Funktionen per Software nachzurüsten die per Hardwareansteuerung nicht realisierbar sind, so dass wir aber die volle Funktionalität haben. Gruß Hayo
Michael W. schrieb: > Ich habe ein USB-Seriell Interface im Einsatz, welches ich nur mit einem > zusätzlichen Kabel zum Laufen bekommen habe - ohne dies Kabel ging gar > nichts in Sachen Kommunikation PC <-> Scope. Das ist aber sehr speziell und anscheinend ein Einzelfall. Du kannst ja mal genau dokumentieren was da bei Dir im Einsatz ist (Kabel, Interface) damit andere da nicht dran verzweifeln wenn sie die gleichen Prbleme haben. > Bin schon ein wenig lange raus aus dem Projekt: Wie war das nochmal mit > dem USB - Anschluss? wozu war der da? Ist über den die Kommunikation mit > dem Scope möglich? Besteht vielleicht die Möglichkeit darüber das > Flashfile von der Firmware aus einzulesen und den Flashvorgang von dort > aus zu initiieren? Der USB-Anschluß ist momentan für (fast) nichts zu gebrauchen. Ich habe noch ein neues USB-Interface in Planung (bzw. auch schon teilweise implementiert). Es gab auch mal jemanden der sich das übernehmen wollte, da habe ich aber nichts mehr von gehört. Zur Zeit kann man die mitgelieferte WELEC PC-Software in begrenztem Umfang benutzen, aber leider ist auch die etwas buggy und es gehen nicht alle Funktionen. > (Nicht hauen, wenn die Frage zu blöd ist. Wahrscheinlich ist das das > Henne - Ei Problem, oder?) Die Frage ist durchaus berechtigt. Aber zur Zeit ist die RS232 einfach die Schnittstelle der Wahl beim WELEC. Gruß Hayo
Hayo W. schrieb: > Ich habe mir auch schon überlegt nur die Funktionen per Software > nachzurüsten die per Hardwareansteuerung nicht realisierbar sind, so > dass wir aber die volle Funktionalität haben. > > Gruß Hayo Hajo, die Idee ist schon gut. Größer">" und Range"><" funktioniert ja nun ganz gut. Ich hab bloß Bedenken, wie Du per SW das Timing bei "<" einhalten willst? Im Prinzip kann man ja bei PulseWidth kleiner als ("<") durch Range ("><")ersetzen, weil lt. Welec Spezi im Handbuch der Zeitbereich auch bei "<" nur von 16ns bis 100ms gehen darf. Ich hab heute noch etwas experimentiert. Tatsächlich scheint die untere Grenze auch bei Range eher bei 72ns zu beginnen. Man könnte also bei der Einstellung von "<" einfach im Hintergrund "><" parametrieren... Oder man läßt das "<" einfach weg ("temporär"grau machen):-) Auf der anderen Seite ist meine Zusammenfassung der Kommentare "registers_nios.pdf" aus den Sourcen noch mit sehr vielen Fragezeichen versehen. Vielleicht muß nur ein Bit richtig gesetzt werden und alles funktioniert? Habe vorhin übrigens mit dem Mode(Auto/Normal/Combi)noch etwas gespielt. Was spricht eigentlich dagegen dies generell in SetupTriggers() freizugeben und nicht nur für Edge? Beste Grüße Jürgen
@Hayo hab grad festgestellt die Freq. messung zeigt immer 0.00 an ;( Periodenmessung geht (letztes release) vlG Charly
nachtrag: freq. kleiner 1 khz werden gemessen vlG Charly
Angehängte Dateien:
-
QM-1kHz-01.png
4,5 KB -
QM-1kHz-02.png
4,6 KB
Stimmt! Und Bilder sagen mehr als Worte... ;-)
Bei der Version 1.2.BF.4.2Mono funktioniert die Freq.-Messung mit QM noch, vielleicht hilft dir das. Gruß Michael
Danke für den Tip, übrigens, die neue Version wird Euch gefallen. Da habe ich die Menüstruktur wieder umgebaut und es gibt eine Menge Spielereien. Muß allerdings noch Feinschliff machen und dann die Bugs noch fixen. Gruß Hayo
Hier die überarbeitete Version mit QM > 999 Hz und Pulse Width, um die Wartezeit zu verkürzen :-) Gruß Jürgen
Hi bin gerade erst von meiner Viperausfahrt zurück. @Jürgen - woran lags mit der Frequenz? Bevor ich jetzt lange suche... Gruß Hayo
Hayo W. schrieb: > Hi bin gerade erst von meiner Viperausfahrt zurück. > > @Jürgen - woran lags mit der Frequenz? Bevor ich jetzt lange suche... > > Gruß Hayo Hi, bin gerade erst von der Party zurück. In der floatstr_t.cpp hast Du ab k(Hz) versehendlich in Rendertext das Komma anstatt den Punkt in einer Floatzahl verwendet ( und der Compiler hat es dann falsch verstanden ). GN Jürgen
Jo, danke. Werd ich gleich mal ändern. Hayo
Angehängte Dateien:
-
Holdoff_err.png
3,8 KB -
Holdoff_ok.png
4 KB
Moin Hayo,
beim Trigger gibt es - zumindest in der BF4.1 - noch ein
"Anfangswertproblem" bei der Benutzung der Holdoff Funktion.
Wenn man den Holdoff verändert, wird der neue Wert bei der ersten darauf
folgenden Messung ignoriert. Erst bei den nächsten Messungen verschiebt
sich der Triggerpunkt für die Signalaufzeichnung entsprechen.
Dabei bin ich auf die Frage gestoßen, ob zusätzlich zu dem Zeit Holdoff
nicht auch ein Event Holdoff ganz praktisch wäre?
Solange man in Pulsfolgen mit halbwegs festen Pulspositionen einen
bestimmten Puls genauer ausmessen möchte, geht das mit dem Zeit-Holdoff
ganz gut (falls das 134 ms-Limit nicht stört). Das scheitert aber,
sobald die Pulse sich zeitlich zu deutlich verschieben. Man müßte also
statt einer Totzeit die triggerwürdigen Ereignisse zählen, die ersten
(n-1) ignorieren und erst auf den n-te Puls wirklich triggern.
__|-|__________________|-\_________|\_________________
T ^
1 2 3
Hauptsächlich interessant wäre das für den Single Shot. Auf einem Regler
müßte man dann das n einstellen können. Wie siehst du die Möglichkeit
soetwas zu implementieren? IMHO müßte die Totzeit des Zeit Holdoffs
durch einen Zähler ersetzt werden, der dann für die Triggerfreigabe
sorgt, oder sehe ich das zu einfach bzw. ist das im FPGA verkapselt?
Gruß Rainer
Rainer W. schrieb: > Moin Hayo, > > beim Trigger gibt es - zumindest in der BF4.1 - noch ein > "Anfangswertproblem" bei der Benutzung der Holdoff Funktion. > Wenn man den Holdoff verändert, wird der neue Wert bei der ersten darauf > folgenden Messung ignoriert. Erst bei den nächsten Messungen verschiebt > sich der Triggerpunkt für die Signalaufzeichnung entsprechen. Da werde ich vermutlich nichts machen können wegen s.u. (ich prüfe das) > Dabei bin ich auf die Frage gestoßen, ob zusätzlich zu dem Zeit Holdoff > nicht auch ein Event Holdoff ganz praktisch wäre? Unbedingt eine gute Idee. > oder .... ist das im FPGA verkapselt? Leider ja. Da wäre wieder nur der Versuch möglich das in Software nachzubilden - schwierig! Gruß Hayo
Angehängte Dateien:
-
Display_Setup.jpeg
36 KB
Schon mal ein kleiner Vorgeschmack was man in der neuen 4.3 so alles einstellen kann. Die Farbe ist allerdings in Echt mehr Hellrot als Orange. Da hat das screenshotprogramm wohl noch nicht so ganz den richtigen Farbton erwischt. Hayo
moin moin Hayo noch eine bitte: druckst du den trigger Mode/Coupling button ist unten im softmenu die 3, stelle frei, kann da SOURCE hin zum wechseln des trigger Kanal ?, tnx! ps. und halte uns nicht soooo lange 'angefuettert' ;) vlG Charly
Hallo Charly, hier kommt schon die 4.3, wollte nur sichergehen dass bei all den Neuerungen nicht noch ein Bug mit reingerutscht ist, wie es immer gern mal passiert. Leider konnte ich Deinem Wunsch mit dem 3. Button nicht entspechen, da dieser Platz jetzt anders belegt ist. Dafür kriegst Du jetzt aber Deine änderbare Timebase im Single Shot Modus. Denkt dran das Ihr neu kalibriert, da ich alle Einstellungen zurücksetzen mußte. Die Puls Width Triggerung von Jürgen konnte ich nicht mehr testen, aber das sah eigentlich so gut aus, dass ich das einfach so übernommen habe. Es gibt ein neues Display Setup-Menü in dem man nett rumspielen kann. Die Änderungen am Menü findet Ihr wie immer gelb markiert im Programmers Guide auf dem Menü-Tab. Viel Spaß Hayo
Ach ja einen hatte ich noch vergessen, ich glaube das war Rainer, der gerne die Kanalanzeige unterdrücken wollte z.B. wenn der Kanal als Triggersource genutzt wird. -> Kannst Du jetzt! Guckst Du im Display-Menü. Gruß Hayo
moin moin Hayo, das iss ja super, da weiss i was i die Nacht teste ;) vieeelen Dank! laut meinem 1. Test haste an der Triggeranzeige im Single Mode noch nix gmacht, richtig ? noch eine Frage, wozu ist im Mode/Coupling menu der Button PROBE ? vlG Charly
Hm bei mir gibt es einige Menüprobleme mit der neuen Version (default setup habe ich gemacht). Es werden an einigen Stellen nur die roten Pfeile für den Drehknopf unten im Menü angezeigt, aber kein Text. Immer wieder bleiben auch Artefakte in der unteren Menüleiste stehen. Eben habe ich auch etwas nach der FFT gesucht - gibt es einen logischen Grund, warum sie nicht im Math Menü steckt? Alles was ich von mir gebe soll konstruktive Kritik sein, also bitte nicht in den falschen Hals kriegen. In letzter Zeit hat es wieder tolle Fortschritte gegeben - weiter so! Gruß, Michael
Michael H. schrieb: > Eben habe ich auch etwas nach der FFT gesucht - gibt es einen logischen > Grund, warum sie nicht im Math Menü steckt? Guck mal ins Main/Delay Menü. Gruß Rainer
Hi, das mit den roten Pfeilen hatte ich vorhin schon bemerkt. Da werden die alten Bereiche nicht gelöscht. Ich gebe noch eine Korrekturkompilation raus. Hayo
Ich hatte die FFT schon gefunden, ich wollte nur anmerken dass ich es recht unintuitiv finde wenn sie nicht im Math Menü steckt.
Die FFT habe ich aus mehreren Gründen verlegt: - es gab immer etwas Probleme mit den unterrschiedlichen Betriebsmodi. Die FFT und die normalen Math-Funktionen arbeiten völlig unterschiedlich. - jetzt konnte ich die zugehörigen Steuerparameter sauber voneinander trennen. - dadurch konnte ich im Math-Menü eine Menüebene einspaaren. - ich finde die Bedienung viel intuitiver wenn alle Betriebsmodi in einem Menü nebeneinander zu finden sind Und hier ist die korrigierte Kompilation Gruß Hayo
Hallo Hayo, erstmal vielen Dank an dich und die anderen Entwickler. Habe vorige Woche mein W2022A für nur 125€ bei eBay erstanden und dank eurer Firmware bin ich echt zufrieden damit. Mir ist noch eine Kleinigkeit aufgefallen: Drücke ich auf Utility und gehe auf "More" wird ja der Drehregler weiß beleuchtet, da aktiviert. Gehe ich jetzt in das "Hardware"-Untermenü und wieder zurück bleibt die LED hingegen aus. Firmware 1.2.BF.4.3 Viele Grüße, Cazwo
Stimmt, da hakt es noch etwas. Auch wenn man erst More drückt und wieder zurückspringt, dann bleibt die LED an. Wird natürlich korrigiert. Viel Spaß mit Deinem Schnäppchen Gruß Hayo
Die möglichen Optikoptionen gefallen mir richtig gut. Klasse. Was mir aber aufgefallen ist. Wenn ich ins Aquiere Menü gehe und dort der Drehschalter weiß leuchtet um Average bzw. die Noise Filter zu ändern ist die Bedienung meiner Meinung nach invertiert. Wie seht ihr das? Ich bin es gewöhnt mit einem Rechtsdreh in Menüs nach unten zu gehen und mit links nach oben, dort ist es aber anderst rum. Beim ersten mal drehe ich immer in die Flasche richtig bis ichs bemerke.
Hallo zusammen, mir ist gerade aufgefallen, dass in FFT-Modus beim Umschalten der Quelle Zeichenfragmente in der Kopfzeile verbleiben. Scheinbar sind die Spannungsanzeigen "länger" als sie gelöscht (übermalt??) werden. Ist aber nur eine optische Kleinigkeit. Ausserden erscheint beim Umschalten von der FFT-Menüzeile nach "oben" der Text "USTB" fürs Untermenü. Viele Grüße, Rainer
Danke. ;) Mir ist gerade aufgefallen, dass das Problem mit dem roten Pfeil mit der korrigierten Kompilation noch nicht ganz behoben ist. Nach einem Neustart des Oszi kann ich mit der korrigierten Fassung zwar im Utility Menü zwischen den Untermenüs hin und her springen, ohne das es Probleme gibt. Das hat mit der unkorrigierten so nicht geklappt. Wenn ich dann aber etwas in den Menüs Display, Aquire und Quick Measure ändere und dazwischen hin und her springe gibt es immer mal wieder Probleme (Pfeil, wo aktuell keine Schaltfläche ist (Aquire-Menü); sich überlappende Pfeile (Quick Measure)). Gruß Cazwo
Alles klar, danke für die Hinweise, ich werde mal heute eine korrigierte dritte Kompilation reinstellen. @Cazwo Du kannst nicht zufällig einen Screenshot beisteuern? Gruß Hayo
Thomas O. schrieb: > Die möglichen Optikoptionen gefallen mir richtig gut. Klasse. > > Was mir aber aufgefallen ist. Wenn ich ins Aquiere Menü gehe und dort > der Drehschalter weiß leuchtet um Average bzw. die Noise Filter zu > ändern ist die Bedienung meiner Meinung nach invertiert. Ja die Richtung habe ich (glaube ich) bei den anderen Menüs auch. Ist die normalerweise andersrum? Dann kann ich die auch ändern, das wäre kein Problem. Gruß Hayo
Hallo zusammen, noch was Kleines: Bei der Displayeinstellung erscheint beim 2-Kanal-Scope unter "No Display": Off, Channel 1, C 2, C 3+4 (Channel 1+2 ist ausgegraut). Ist das so gemeint? Viele Grüße, Rainer
Angehängte Dateien:
-
screen-0000.png
3,6 KB -
screen-0001.png
3,4 KB -
screen-0002.png
4,7 KB
Hier die Screenshots...
Bei screen-0000.png befindet man sich im Quick Measure Menü (passiert
auch direkt nach dem Start / Default Setup). Man sieht den überlagerten
Pfeil bei "Select: Average".
Das zweite Bild ist vom Aquire-Menü. Hier tritt der Fehler nicht direkt
nach dem Start auf, ruft man aber vorher das Utility-Untermenü ("More")
auf und geht dann auf Aquire bleibt der Pfeil erhalten.
Den Bug den Rainer hat, habe ich auch (W2022A) - es gibt Channel 1,
Channel 2 und Channel 3+4 zur Auswahl... Siehe screen-0002.png.
CaZwo schrieb: > Den Bug den Rainer hat, habe ich auch (W2022A) - es gibt Channel 1, > Channel 2 und Channel 3+4 zur Auswahl... Siehe screen-0002.png. Ja den Fehler hatte ich auch schon bemerkt - ist schon behoben. Danke für die Screenshots, da finde ich die Fehler schneller. Gruß Hayo
Rainer H. schrieb: > Ausserden erscheint beim Umschalten von der FFT-Menüzeile nach "oben" > der Text "USTB" fürs Untermenü. Das ist kein Fehler, sondern da ist momentan tatsächlich das USTB-Menü drunter, auch wenn FFT aktiv ist. Ich plane da aber eine dynamische Belegung. Gruß Hayo
ich habe das jetzt in anderen Menüs nicht getestet, vielleicht wäre eine globale Variable eine Lösung um es in allen Menüs gleichzeitig zu ändern, wird bestimmt viel Aufwand machen aber dann stünde auch eine benutzerdefinierten Richtung nichts im weg. Was sagen die anderen zu der Richtung ist das bei anderen Herstellern auch so oder wie findet ihr es ergonomischer?
Hallo nochmal, zum USTB bei Main/Delayed: Da hatte mich irritiert, dass USTB als Untermenü (durch den Pfeil) angezeigt wird. Faktisch ist auch FFT ein Sprung in ein Untermenü, oder? Wenn ich aus dem FFT-Untermenü kommend den Softkey für Main oder Delayed drücke, bleibt die rechte Bildhälfte mit den FFT-Daten überlagert, der Rest wird darunter (scheinbar korrekt) angezeigt. Viele Grüße, Rainer
CaZwo schrieb: > Hier die Screenshots... > > Bei screen-0000.png befindet man sich im Quick Measure Menü (passiert > auch direkt nach dem Start / Default Setup). Man sieht den überlagerten > Pfeil bei "Select: Average". Das ist kein Fehler, sondern hierr wird ein anderes (größeres) Symbol verwendet. > Das zweite Bild ist vom Aquire-Menü. Hier tritt der Fehler nicht direkt > nach dem Start auf, ruft man aber vorher das Utility-Untermenü ("More") > auf und geht dann auf Aquire bleibt der Pfeil erhalten. Hast Du schon die C2 drauf? Bei mir tritt der Fehler nicht mehr auf. Hat jemand von den Anderen noch das Problem? Gruß Hayo
Angehängte Dateien:
-
XH_Triggerpegel.JPG
120 KB
Hajo, bitte auch die Triggerpegelanzeige in der oberen Statuszeile um ein paar Pixel nach rechts rücken. Beim External HF Reject löscht diese Ausgabe sonst den rechten senkrechten Strich des Buchstaben "H". Ich hoffe nur eine Kleinigkeit... :-) VG Jürgen
Angehängte Dateien:
Uups, und was ist das jetzt? Der Name des Screenshots sagt alles. Ich hab nur die Batchdatei beendet...
mir ist gerade aufgefallen wenn man einen Singelshot durchführt das man nicht rauszoomen kann um also ein längeres Signal sichtbar zu machen, so muss man mehrere Zeitbasen durchprobieren bis man es richtig auf den Schirm bekommt, da der Speicher aber für einen Singelshot ausreichend groß ist könnte man ja gleich sehr schnell auszeichnen und danach passend rauszoomen. Ein kleiner optischer Schönheitsfehler ist mir aufgefallen wenn ich Oszi einschalte taucht Info Screen ist unten rechts einen kleine Vertikale Linie etwa 10 Pixel hoch 1 Pixel breit auf.
Thomas O. schrieb: > mir ist gerade aufgefallen wenn man einen Singelshot durchführt das man > nicht rauszoomen kann um also ein längeres Signal sichtbar zu machen, so > muss man mehrere Zeitbasen durchprobieren bis man es richtig auf den > Schirm bekommt, da der Speicher aber für einen Singelshot ausreichend > groß ist könnte man ja gleich sehr schnell auszeichnen und danach > passend rauszoomen. Rauszoomen hakt aus irgendwelchen Gründen noch, daher habe ich die Funktion noch nicht freigeschaltet - ist aber in Arbeit. Ich hoffe in einem der nächsten 4er Releases. > Ein kleiner optischer Schönheitsfehler ist mir aufgefallen wenn ich Oszi > einschalte taucht Info Screen ist unten rechts einen kleine Vertikale > Linie etwa 10 Pixel hoch 1 Pixel breit auf. Ja hat mich auch schon ewig genervt, aber hatte noch keine Zeit mich drum zu kümmern. Jetzt kille ich das Ding aber... Hayo
Hayo W. schrieb: > > Hast Du schon die C2 drauf? Bei mir tritt der Fehler nicht mehr auf. Hat > jemand von den Anderen noch das Problem? > > Gruß Hayo Hallo Hayo, ich hatte erst die Variante von Sourceforge drauf (noch bevor du gestern Abend die korrigierte gepostet hast), dann die von deinem Beitrag gestern um 22:54 installiert. Was mir auffällt, beide TomCat.flash-Dateien haben die gleiche MD5sum (20578432d849ba19e2d0b51198f24ccd) und beide wurden "Gestern, 4. September 2011, 19:04:02" geändert (laut Windows). Kann's sein, dass du da irgendwie nochmal die alte Variante hochgeladen hast? Gruß Cazwo
Will ich nicht ausschließen. Aber gleich gibts ohnehin die C3 mit allen Fixes. Gruß Hayo
So da ist sie... Die Drehrichtung hab ich mal einfach umgedreht. Fühlt sich auch ganz ok an. Gruß Hayo
Gerade geflasht - sieht gut aus... Der Bug mit den Pfeilen, wo sie nicht hingehören ist weg und die weiße Beleuchtung des Drehreglers funktioniert auch so wie sie soll. Super Arbeit, danke!
Habe auch gerade die C3 ausprobiert und die Richtung getestet dabei ist, mir ist noch ein kleiner "Käfer" aufgefallen. 1. Aquire Menü aufrufen 2. Nun ist entweder das Symbol für Noise Filter oder Average rot. Angenommen Noise Filter ist rot. 3. Ich drücke auf Average das Symbol wird aber nicht rot auch wenn ich nun drehe nicht, erst wenn das Menü wieder verschwunden ist wird das Symbol rot.
@Hayo Erstmal ein großes Dankeschön für die bisher geleistete Arbeit und die Zeit die Du in das Projekt so reinsteckst. Ich habe eine Frage zu der 1.2.BF.4.3C3: Display->NoDisplay: Welche Idee steckt hinter dem NoDisplay -> Ch1+2 (beim W2022)? Macht m.E. keinen Sinn, daher die Frage. Ch3-Ch4 sind gegraut, sollte das nicht auch für NoDisplay -> CH1+CH2 beim W2022 so sein? Dann dazu noch evtl. ein Käferchen: Wenn man das Gerät in dieser Einstellung ( NoDisplay -> Ch1+2 ) aus- und dann wieder einschaltet werden beide CH's nicht dargestellt, das hat er sich sauber gemerkt. NoDisplay steht aber auf Off. Es bedarf eines erneuten Tastendrucks auf NoDisplay.
Robert schrieb: > @Hayo > Ich habe eine Frage zu der 1.2.BF.4.3C3: Display->NoDisplay: > Welche Idee steckt hinter dem NoDisplay -> Ch1+2 (beim W2022)? > Macht m.E. keinen Sinn, daher die Frage. > Ch3-Ch4 sind gegraut, sollte das nicht auch für NoDisplay -> CH1+CH2 > beim W2022 so sein? Nein, die Idee ist, dass man dann den Math-Channel ohne die Source-Kanäle darstellen kann. > Dann dazu noch evtl. ein Käferchen: > Wenn man das Gerät in dieser Einstellung ( NoDisplay -> Ch1+2 ) aus- und > dann wieder einschaltet werden beide CH's nicht dargestellt, das hat er > sich sauber gemerkt. NoDisplay steht aber auf Off. Es bedarf eines > erneuten Tastendrucks auf NoDisplay. Du hast recht, da vergißt er noch etwas. Werde ich mal in Ordnung bringen Gruß Hayo
Thomas O. schrieb: > Habe auch gerade die C3 ausprobiert und die Richtung getestet dabei ist, > mir ist noch ein kleiner "Käfer" aufgefallen. > > 1. Aquire Menü aufrufen > 2. Nun ist entweder das Symbol für Noise Filter oder Average rot. > Angenommen Noise Filter ist rot. > 3. Ich drücke auf Average das Symbol wird aber nicht rot auch wenn ich > nun drehe nicht, erst wenn das Menü wieder verschwunden ist wird das > Symbol rot. Ja daws ist etwas schwierig, da der Drehregler-Interrupt die Statusaktualisierung unterbindet. Mal sehen ob mir dazu was einfällt. Gruß Hayo
Angehängte Dateien:
-
Ausgangssituation.JPG
140 KB -
1x100nFparallel_C37.JPG
120 KB -
Ext_Trig_V1.2..JPG
33 KB
Hallo Hayo, ich hab mich heute nochmal um die externe Triggerung gekümmert. Zunächst hab ich mal die Hardware geringfügig modifiziert, indem ich ein C 100nF/0603 parallel zu C37 gelötet hab. Die zwei Screenshots zweigen die Wirkung: vorher ca 425mV pp, gemessen am Eingang des Comparators U6/Pin4. Wie ich vor längerer Zeit schon gehofft hatte, ergibt sich damit eine verringerte Welligkeit des externen Triggerpegels von ca 18mV. Damit ist endlich eine stabile Triggerung bei HF Reject zu erreichen! Leider bin ich auf einen simplen Fehler hereingefallen: Im Stromlaufplan V1.1 ist zwar unten die Pinbelegung des MAX4707 gezeigt, im Plan ist aber trotzdem Pin 3 + 4 verwechselt :-( Also: Hajo, bitte die Ansteuerung im Setuptrigger() für HFReject und LFReject austauschen. HF Reject ist jetzt die Einstellung unserer Wahl für Signale << 50kHz. LF Reject reagiert dann auch erst auf Signale > 50kHz. Ich wollte dann die Triggerpegel stufenweise messen und die Tabellen aktualisieren... Hab mich aber dann für eine direkte Gleichung entschieden, die nur 1x in den Sourcen berechnet wird: voltoff = ( Trigger_POS_CHE * 0.1943 - 11.852) * vfactor Neuer Startwert für 0.00V ext. Triggerpegel ist jetzt 61. Damit können die zwei Tabellen entfallen. Paßt auch bei meinem 2.Gerät. Gruß Jürgen
Wo wir gerade bei bisher nicht dokumentierten Features sind, da hätte ich auch noch was: Bei den Arbeiten zur neuen Eingangsstufe habe ich die Schieberegister mal vollständig abgeklopft, was davon ggf. noch frei ist. Ergebnis ist die Tabelle im Anhang. Hoffentlich kann da so unaufbereitet auch jemand außer mir was mit anfangen... So richtig neu ist jetzt nur Bit 5 von U21. Ist an den Eingang !T/B der ADCs angeschlossen, damit könnte man die zwischen Zweierkomplement und vorzeichenlos umschalten, warum auch immer. Ferner war Bit 2 von U26 glaube ich noch nicht so bekannt, scheint den externen Trigger zwischen AC und DC umzuschalten. Mit U24 können merkwürdige Terminierungen an den Eingangskanälen ausgewählt werden. Gibt es den TV-Trigger in der Software eigentlich schon, bzw. funktioniert die Hardware dafür? Grüße Jörg
Uuups, kaum ist man vom Griechen zurück wird man hier schon mit Hardcorefakten konfrontiert. Das muß ich mir morgen noch mal in aller Ruhe zu Gemüte führen. @Jürgen Die Korrekturen werde ich dann mit der 4.4 raushauen. @Jörg Bit 2 von U26 könnte natürlich als neues Feature in die externe Triggerung Einzug halten wenn das denn so funktioniert wie vermutet. Den TV Trigger gibt es eigentlich schon, ist aber angesichts der aktuellen Technik wohl eher als antiquiert zu bezeichnen und daher auch nicht mehr in der aktuellen FW aktiv (zumal die Funktion im Original nicht richtig arbeitete). Gruß und gutes Nächtle Hayo
Jörg H. schrieb: > Ferner war Bit 2 von U26 glaube ich noch nicht so bekannt, scheint den > externen Trigger zwischen AC und DC umzuschalten. Hallo Jörg, bin gestern auch beinahe über dieses Bit 2 gestolpert. Die Verbindung vom Schieberegister zum Transistor hab ich nur aus den Fotos geahnt. Gut, daß Du das gleich in Hardware bestätigen kannst. Es ist offenbar die gleiche Hardware mit Transistor, AQY usw., wie an den Kanälen eingebaut. >Gibt es den TV-Trigger in der Software eigentlich schon, bzw. >funktioniert die Hardware dafür? Hab das unlängst herausgesucht und in die SW eingepflegt, kann da aber nicht wirklich helfen. Ist nicht mein Terrain :-) Kannst Du das testen? Gruß Jürgen
Ah, Hayo, der Grieche :-) Hayo W. schrieb: > @Jürgen > > Die Korrekturen werde ich dann mit der 4.4 raushauen. > Wäre schön, zumal es nur 5 Zeilen sind. > > @Jörg > > Bit 2 von U26 könnte natürlich als neues Feature in die externe > Triggerung Einzug halten wenn das denn so funktioniert wie vermutet. Ist schon lang drin und funktioniert sogar. GN JK
Hayo W. schrieb: > Ja daws ist etwas schwierig, da der Drehregler-Interrupt die > Statusaktualisierung unterbindet. Mal sehen ob mir dazu was einfällt. vielleicht den Status gleich ändern nachdem die Menütaste für Noise oder Average gedrückt wird also beim Aufklappen des Menüpunktes
@Jürgen Hast Du da schon fertiges Coding, das ich mit copy and paste übernehmen kann? @Thomas Ja sowas in der Art hab ich mir heute Nacht schon überlegt. Schaun wir mal... Gruß Hayo
Hayo W. schrieb: > Hast Du da schon fertiges Coding, das ich mit copy and paste übernehmen > kann? @ Hayo Hab nur in der hardware_t.cpp und display_t.cpp geändert. Ich hab noch einige Kommentare eingearbeitet und bin inzwischen an einem Problem des Updates des Triggerpegels in der Statuszeile dran: Falls bei EDGE extern eingestellt ist, und man wechselt zu PULS, wird der Pegel nicht mehr upgedated bzw. es wird der falsche Pegel (von extern) angezeigt. ( könnte Zeile 2398 in dispplay_t.cpp sein?? ) Steige aber in dem Menü-Kram noch nicht wirklich durch. :-( Scheint wohl die Altlast PULS mit Extern zu sein.... Hier die zwei Dateien. Kannst ja mal mit dem Stand 4.3C3 vergleichen. Muß ausserdem jetzt leider erstmal weg... Gruß Jürgen
Hallo Hayo, alles klar, oder soll ich noch etwas nachlegen? Hatte vorhin, trotz Urlaub, leider keine Zeit mehr ;-) Gruß Jürgen
Hi Jürgen, hatte noch keine Gelegenheit reinzugucken, da ich zur Zeit am Button-Menü herumoptimiere. Als kleines Gutie habe ich z.B. die Buttonmimik überarbeitet und wieder aktiviert. Gruß Hayo p.s. habe zur Zeit die originale 1.4 auf einem meiner DSOs und hab mal einiges gecheckt. Ist schon ernüchternd wenn man liebgewonnene Funktionen auf einmal nicht mehr hat... Die Pulsweitentriggerung funktioniert jedenfalls in der 1.4 nicht besser als in der BF.4.3 - eher schlechter, denn ich meine die größer/kleiner Werte sind vertauscht in der 1.4. Sehe ich das richtig?
Hayo W. schrieb: > Die Pulsweitentriggerung funktioniert jedenfalls in der 1.4 nicht besser > als in der BF.4.3 - eher schlechter, denn ich meine die größer/kleiner > Werte sind vertauscht in der 1.4. Sehe ich das richtig? Die 1.4 wollte ich mir eigentlich nicht noch mal antun, aber ich check das gleich nochmal..
Hayo W. schrieb: > denn ich meine die größer/kleiner > Werte sind vertauscht in der 1.4. Sehe ich das richtig? Nein, kann ich nicht bestätigen! In meiner 3-er Impulsfolge (s.o.) wird bei größer auch stabil auf den längsten Impuls getriggert. Auch die Kodierung im ctrl_reg ist so, wie jetzt in der 4.3.C3. Gruß Jürgen
Angehängte Dateien:
-
wo_ist_C37.JPG
54 KB
Als Nachtrag noch die Position C37 und dazu parallel den zusätzlichen 100nF-C für die externe Triggerung. Sitzt direkt neben dem seriellen Interface. Gruß Jürgen
Jürgen schrieb: > Hayo W. schrieb: >> denn ich meine die größer/kleiner >> Werte sind vertauscht in der 1.4. Sehe ich das richtig? > > Nein, kann ich nicht bestätigen! In meiner 3-er Impulsfolge (s.o.) wird > bei größer auch stabil auf den längsten Impuls getriggert. Auch die > Kodierung im ctrl_reg ist so, wie jetzt in der 4.3.C3. Stimmt, ich hab's nochmal geprüft, es verhalten sich beide gleich, mit einer Ausnahme - wenn bei der 4.3 der Combi-Trigger an ist, dann gibt es immer wieder einen Refresh wenn der Timeout kommt. Ist manchmal ganz praktisch. Die 1.4 kennt sowas ja nicht... Jetzt aber schnell die 1.4 wieder runterlöschen, da kriegt man ja Ausschlag. Gruß
Angehängte Dateien:
-
Recall_GridLine.png
3,6 KB -
Recall_Chan1.png
4,8 KB -
ScreenShot_vor.png
5,5 KB -
ScreenShot_nach.png
4,6 KB -
Math_Strich.png
3,6 KB
n'Abend Hayo, der aktuelle BF 4.3 C3 habe ich gerade in Bezug auf Save/Recall etwas auf den Zahn gefüllt. Beim Recall werden anscheinend manche Einstellungen nicht richtig aktualisiert, z.B. 1. Wenn beim Save die Gridlines auf "solid" standen, man dann "dotted" einstellt und anschließend über Recall die gespeichten Einstellungen wieder abruft, wird das Grid richtig mit durchgezogenen Linien dargestellt, aber wenn man unter Display * Setup nachguckt, steht dort "Dotted" (Recall_GridLine.png) 2. Nicht aktive Kanäle werden beim Recall nicht abgeschaltet. Wenn beim Abspeichern z.B. nur Kanal 1 aktiv war, vorm Recall aber mehrer aktiv waren und man dann den Speicher abruft, bleiben die Traces der inaktiven Kanäle in der Anzeige, sind aber in der Statuszeile richtig ausgeblendet (Recall_Chan1.png). Auch wenn vorm Recall z.B. Math aktiv war, bleibt die Kurve stehen, hat dann aber nichts mit den abgerufenen Daten zu tun. Und dann stellt sich das QuickMeas Menü neuerdings (?) etwas zickig an. Außer, dass der rote Pfeil auf dem zweiten Softkey etwas ungewohnt aussieht (ScreenShot_vor.png, Absicht?), verschwindet nach einem Screenshot (mit Double Push ausgelöst), fast die komplette Tastenbeschriftung des QuickMeas Menüs (ScreenShot_nach.png). Bisher dachte ich immer, das der Screenshot verlustfrei funktioniert ;-) Hat der zweite Pfeil auf dem QuickMeas Select Button irgendwas mit dem machnmal vorhandenen "verlorenen" roten Strich im Math Menü (Tastenplatz 2) zu tun. Beides wirkt etwas deplaziert. Ich will dich damit aber nicht von den wirklich wichtigen Dingen abhalten ;-) Danke für deinen unermüdlichen Einsatz Gruß Rainer
Hallo Rainer, keine Sorge Du hälst mich nicht von wichtigen Dingen ab. Ich bin ja auf Eure Fehlerreports angewiesen um die Firmware nachhaltig zu verbessern. Das ist insbesondere dann wichtig wenn ich größere Umbauten vorgenommen habe. Die ganzen Quereffekte kann ich selbst gar nicht alle testen. Allerdings weiß ich überhaupt nicht warum jetzt der arme QM-Pfeil so ins Fadenkreuz geraten ist. Der gehört nämlich zu den wenigen Dingen die ich nicht geändert habe und die auch in der originalen WELEC-Firmware genauso aussehen. Die anderen Punkte versuche ich mal in die 4.4 mit einzuarbeiten. Gruß Hayo
Hayo W. schrieb: > Allerdings weiß ich überhaupt nicht warum jetzt der arme QM-Pfeil so ins > Fadenkreuz geraten ist. Der gehört nämlich zu den wenigen Dingen die ich > nicht geändert habe und die auch in der originalen WELEC-Firmware > genauso aussehen. Da hast du irgendwie Recht - der merkwürdige Strich im Math Menü war's. Die andere Darstellung des QuickMeas Pfeils halte ich eigentlich für überflüssig. Man kann natürlich einen Sinn darin sehen, wenn sie symbolisieren soll, dass die Bedienung wahlweise per Taste über Pull-Down als auch über den Universalregler möglich ist. Also bleibt's erstal so ... Gruß Rainer
Rainer W. schrieb: > Man kann natürlich einen Sinn darin sehen, wenn sie > symbolisieren soll, dass die Bedienung wahlweise per Taste über > Pull-Down als auch über den Universalregler möglich ist. So ist es. Ich hätte das Symbol auch bei den anderen Pulldowns verwendet, um da homogen zu bleiben, aber ich hatte da weniger Platz wegen der längeren Bezeichnung (Delay-Einstellung). >Also bleibt's erstal so ... Würde sagen ja Hayo
Ok hab leider nicht viel Zeit. Habe eine Menge korrigiert und verbessert -> changelog. Viel Spaß Hayo
Hi zusammen, ab und zu komme ich dazu, hier hereinzuschauen. Ein Feature, das mir sehr abgeht (auch beim LeCroy), das mein alter 453 aber konnte: wenn man die Helligkeit genug aufdrehte, sah man auch bei nicht ausgelöstem Trigger am linken Bildrand einen Punkt in Höhe der aktuellen Eingangsspannung. Das ist sehr praktisch, um z.B. zu sehen, ob man den Tastkopf gut kontaktiert hat. Ich wünsche mir also einen (per Menü aktivierbaren) 2x2 Pixel-Fleck, der immer bei x=0 den aktuellen DAC-Wert anzeigt. Was mir immer wichtig ist: die Triggerung. Da hat sich in letzter Zeit viel getan, ich bin aber noch nicht zum Testen gekommen. Auf jeden Fall ist mir der Unterschied AUTO und COMBI nicht klar. Kann das jemand bitte anhand eines praktischen Beispiels erläutern, wann man was nimmt, mit Vor- und Nachteilen?
Die aktuelle Spannung kann man sich ja erstmal mit Autotrigger ansehen und dann auf Normal oder Single schalten, wo hätte man da mit deiner Variante Vorteile? Stelle ich mir persönlich eher unnütz vor, aber ich lasse mich gern eines Besseren belehren. Der Unterschied zwischen Auto und Combi ist eigentlich der, dass Combi zuverlässig triggert, Auto dagegen nicht - rate mal was von Welec kommt :) Im Prinzip basiert der Combitrigger auf dem Welec Normal Trigger, der gut arbeitet, ist aber um einen Timeout ergänzt, d.h. wenn innerhalb des timeouts kein Trigger kommt dann wird vom Oszi selbst einer ausgelöst. Gruß Michael
Angehängte Dateien:
-
Hieroglyphen.png
5,1 KB
Hayo W. schrieb: > Ok hab leider nicht viel Zeit. Für einen Compilerlauf scheint es ja trotzdem immer noch zu reichen ;-) Bei mir kommt es nach DefaultSetup - Save Trace - Recall Trace - <Menü> zu ungewohnten "Hieroglyphen" in der Menüzeile (z.B. bei Display), als ob sich irgendwer im Speicher verlaufen hat. Bin auch auf dem Sprung... Gruß Rainer
Hi, bin gerade erst zurück und checke gerade die Rückmeldungen: eProfi schrieb: > ...wenn man die Helligkeit genug aufdrehte, sah man auch bei > nicht ausgelöstem Trigger am linken Bildrand einen Punkt in Höhe der > aktuellen Eingangsspannung. Das ist sehr praktisch, um z.B. zu sehen, ob > man den Tastkopf gut kontaktiert hat. > Ich wünsche mir also einen (per Menü aktivierbaren) 2x2 Pixel-Fleck, der > immer bei x=0 den aktuellen DAC-Wert anzeigt. Sorry, das hab ich irgendwie nicht so ganz verstanden. Die Höhe der aktuellen Eingangsspannung in negativer oder positiver Richtung oder wie ist das gemeint. Ich kann mir da nichts drunter vorstellen. Du hast nicht zufällig ein Bild davon? > Was mir immer wichtig ist: die Triggerung. Da hat sich in letzter Zeit > viel getan, ich bin aber noch nicht zum Testen gekommen. Auf jeden Fall > ist mir der Unterschied AUTO und COMBI nicht klar. Was Michael erklärt ist schon ganz richtig, aber Auto und Combi arbeiten im Prinzip gleich. Wenn nach einer bestimmten Zeit kein Triggerereignis eintritt wird das Signal trotzdem ausgegeben. Der Unterschied liegt im Timeout. Der Combitrigger hat einen wesentlich längeren Timeout so daß auch langsamere Signal zuverlässig getriggert werden. Der Autotrigger arbeitet leider nur bei schnellen Signalen ganz brauchbar. @Rainer > Bei mir kommt es nach DefaultSetup - Save Trace - Recall Trace - <Menü> > zu ungewohnten "Hieroglyphen" in der Menüzeile (z.B. bei Display), als > ob sich irgendwer im Speicher verlaufen hat. Oh ja, da läuft noch was schief. Das liegt wohl daran, dass einige Funktionen jetzt im Display Setup Menü untergebracht sind. Ich versuche das mal zu fixen. Gruß Hayo
Moin moin! Hayo, es gibt beim externen Trigger noch einige Fehlerchen: In Hardware_t.cpp, Zeile 1652, muß ext_trig_val_reg = Trigger_POS_CHE + 0x40 gesetzt werden. Ebenso sind einige Initialisierungen noch falsch (0x80 statt 61+0x40=125). In der userif_t.cpp muß die Begrenzung Trigger_POS_CHE geändert werden (Zeilen 8381+8395). Grenzen sind jetzt 0 und 132 und das +-1 kann entfallen, da die zwei Felder ExtTriggerLevel und ExtTriggerDispl entfallen können. OK, das ist mein Fehler. Ich hatte bloß zwei Dateien geschickt :-( Beim Test der Save/Recall Geschichte hatte ich nach dem Flashen ein Memory 0 (Index 0). Da geht gar nichts. Fehlt da eine Initialisierung? Gruß Jürgen PS Die Buttonmimik macht die Kiste nur noch träger. Meine Meinung.
Jürgen schrieb: > Moin moin! > > Hayo, es gibt beim externen Trigger noch einige Fehlerchen: > .... > entfallen können. OK, das ist mein Fehler. Ich hatte bloß zwei Dateien > geschickt Bau ich ein > Beim Test der Save/Recall Geschichte hatte ich nach dem Flashen ein > Memory 0 (Index 0). Da geht gar nichts. Fehlt da eine Initialisierung? Ja so ist es. Ich hab den Wert jetzt ins Flash übernommen, damit man nach dem Neustart nicht immer neu den Speicherplatz wählen muß. Das sollte aber nach dem ersten Verstellen erledigt sein. Gruß Hayo
da kommt mir gerade eine Idee wäre es möglich anzuzeigen ob auf einem Speicherplatz schon Daten abgelegt wurden, evtl. durch eine Farbe auf dem Buttonfeld?
Jürgen schrieb: > Hayo, es gibt beim externen Trigger noch einige Fehlerchen: > In Hardware_t.cpp, Zeile 1652, muß ext_trig_val_reg = Trigger_POS_CHE + > 0x40 gesetzt werden. ist erledigt > Ebenso sind einige Initialisierungen noch falsch > (0x80 statt 61+0x40=125). welche und wo? > In der userif_t.cpp muß die Begrenzung Trigger_POS_CHE geändert werden > (Zeilen 8381+8395). Grenzen sind jetzt 0 und 132 und das +-1 kann > entfallen, ist erledigt > da die zwei Felder ExtTriggerLevel und ExtTriggerDispl > entfallen können. Habe ich erstmal gelassen, stört ja im Augenblick nicht OK, das ist mein Fehler. Ich hatte bloß zwei Dateien > geschickt :-( Kein Problem > PS Die Buttonmimik macht die Kiste nur noch träger. Meine Meinung. Das täuscht, eigentlich ist es jetzt schneller weil nur noch der betroffene Button aktualisiert wird und nicht mehr das ganze Menü. Weitere Optimierungen sind in Arbeit. Gruß Hayo
So die Korrekturen sind drin. Da ich gestern keine Zeit mehr hatte hier noch ein kleiner Hinweis. Die Autoscale-Funktion habe ich überarbeitet. Die Spannungsbereichsfindung arbeitet jetzt zuverlässiger, weil ich die Schwellwertvergleiche jetzt auf Screenwerte umrechne (Skalierung). Dadurch werden auch unterschiedliche Hardwareeinstellungen berücksichtigt und die Schwellwerte sind viel präziser. Gruß Hayo
Hayo W. schrieb: >> Ebenso sind einige Initialisierungen noch falsch >> (0x80 statt 61+0x40=125). > welche und wo? Hardware_t.cpp: zeile 307 und 727 tc_vars.cpp: zeile 556 Thomas O. schrieb: >da kommt mir gerade eine Idee wäre es möglich anzuzeigen ob auf einem >Speicherplatz schon Daten abgelegt wurden, evtl. durch eine Farbe auf >dem Buttonfeld? Die Idee ist garnicht schlecht. Es genügt die Farbe oder ein Zeichen auf dem Button. Natürlich braucht es dann aber einen Menüpunkt, um eine Speicherposition wieder frei zu geben.
vielleicht eine Clear Funktion wenn man den Speicherplatz lange gedrückt hält. Oder kurzer Druck Clear langer Druck Save
Thomas O. schrieb: > vielleicht eine Clear Funktion wenn man den Speicherplatz lange gedrückt > hält. Oder kurzer Druck Clear langer Druck Save Gute Idee. Aus Sicherheitsgründen wäre ich für die Belegung: - kurzer Druck: "Save" - langer Druck: "Clear" Etwas generelles zu den Speicherplätzen: Mir geht es, wahrscheinlich auf Grund meines Alters so, dass nach 10 gespeicherten Kurven mein Gedächnis für die Inhalte der Speicher überläuft, d.h. ich habe nie und nimmer von 80 Plätzen individuell den Inhalt im Kopf. Sinn macht die Zahl der Plätze IMHO nur bei Serienmessungen und dafür wäre ein Autoinkrement-Funktion für die Speicherplatznummer sowohl bei "Save" als auch bei "Recall" sehr praktisch. Wenn man dafür nicht extra eine Menüfunktionen schaffen möchte, vielleicht in der Form, dass ab einem bestimmten Speicherplatz n (z.B. n=10) die Funktion automatisch aktiv ist. Gruß Rainer p.s. Die Belegungsanzeige für einen Speicher könnte man einfach über die "Recall Trace" Taste erledigen: - "Recall" enabled = Speicher belegt - "Recall" disabled = Speicher frei
Hallo Hayo, bei der Trigger Mode/Coupling Taste scheint in der 4.4 irgendetwas mit der Kurzfunktion für die Umschaltung des Trigger Modes durcheinander geraten zu sein. Bei sichtbarem Trigger Menü kann man ja durch Drücken der HW-Taste den Mode (Auto/Normal/Combi) umschalten. Die Umschaltfunktion funktioniert, aber auf dem Softkey "Mode" im Trigger Menü wird die aktuelle Einstellung nicht richtig angezeigt. Gruß Rainer
Hi Rainer, danke für den Hinweis, das liegt an der neuen Button und Menülogik. @Thomas + Jürgen Ich denk mir da mal was aus zu der Belegungsanzeige bzw. zum Löschen der Speicherplätze. > Etwas generelles zu den Speicherplätzen: Mir geht es, wahrscheinlich auf > Grund meines Alters so, dass nach 10 gespeicherten Kurven mein Gedächnis > für die Inhalte der Speicher überläuft, d.h. ich habe nie und nimmer von > 80 Plätzen individuell den Inhalt im Kopf Das geht mir auch so. Ich hatte auch schon überlegt die Anzahl der Speicherplätze auf die Hälfte zu reduzieren zugunsten der Möglichkeit die 32 kbyte Puffer der USTB abspeichern zu können. Alternativ würde ich sonst den restlichen Flashspeicher so aufteilen daß nur die ersten 5 Speicherplätze 32 kbyte aufnehmen können. Was sagt Ihr dazu? Gruß Hayo
Hayo W. schrieb: > Ich hatte auch schon überlegt die Anzahl der > Speicherplätze auf die Hälfte zu reduzieren zugunsten der Möglichkeit > die 32 kbyte Puffer der USTB abspeichern zu können. Alternativ würde ich > sonst den restlichen Flashspeicher so aufteilen daß nur die ersten 5 > Speicherplätze 32 kbyte aufnehmen können. Finde die Idee gut, ein paar extra große Speicherplätze zu haben.
Hayo W. schrieb: > Ich denk mir da mal was aus zu der Belegungsanzeige bzw. zum Löschen der > Speicherplätze. Was hälst du von meinem Anzeigevorschlag über "Recall" enable/disable? > Was sagt Ihr dazu [Speicheraufteilung]? Wie wäre ist mit einer dynamischen Aufteilung mit einem Directory. Den Speicher könnte man in festen Blöcken entsprechend der kürzesten Traces organisieren und in einer Block Allocation Table verwaltet. An jedem Dir-Eintrag hängen dann verkettete Listen mit belegten Speicherblöcken. Das würde deutlich Freiheit geben, was die Länge der Aufzeichnung betrifft, auch wenn es erstmal natürlich etwas Zirkus ist. Gruß Rainer
Rainer W. schrieb: > Hayo W. schrieb: >> Ich denk mir da mal was aus zu der Belegungsanzeige bzw. zum Löschen der >> Speicherplätze. > > Was hälst du von meinem Anzeigevorschlag über "Recall" enable/disable? ich wäge noch ab ob so, oder vielleicht mit einem farbigen Symbol oder Ähnliches. >> Was sagt Ihr dazu [Speicheraufteilung]? > > Wie wäre ist mit einer dynamischen Aufteilung mit einem Directory. Das ist aber schon heftig viel Aufwand. Erstmal würde mich interessieren ob tatsächlich jemand mehr als 40 Plätze braucht. Ich selbst könnte gut damit klarkommen wenn ich dafür auf allen Plätzen 32 kbyte zur Verfügung habe. Ansonsten hätten wir wie bisher 80 Plätze und die ersten 5 hätten 32 kbyte. Gruß Hayo
Hayo W. schrieb: > .... das liegt an der neuen Button und Menülogik. Jedenfalls funktioniert in der 4.4C2 die Anzeige des Triggerpegels (oder Verstellung des externen Triggerpegels?) und die Rückschaltung ext.->CHx nicht mehr :-( Gruß Jürgen PS: Es ist wohl eher die Verstellung ext. Pegel.
Hayo W. schrieb: > Das ist aber schon heftig viel Aufwand. Erstmal würde mich interessieren > ob tatsächlich jemand mehr als 40 Plätze braucht. Das genügt mir vollkommen!
Jürgen schrieb: > Jedenfalls funktioniert in der 4.4C2 ... die Rückschaltung ext.->CHx > nicht mehr :-( Das kann ich bei mir so allgemein nicht bestätigen, zumindest Trig. Norm auf Ch1 - Umschaltung auf Ext - Rückschaltung auf Ch1 funktioniert problemlos. Gruß Rainer
Rainer W. schrieb: >> Jedenfalls funktioniert in der 4.4C2 ... die Rückschaltung ext.->CHx >> nicht mehr :-( > > Das kann ich bei mir so allgemein nicht bestätigen, zumindest > Trig. Norm auf Ch1 - Umschaltung auf Ext - Rückschaltung auf Ch1 > funktioniert problemlos. Das Menü Button3 und 4 (ext. und TV) bleibt aber schwarz. Ein erneuter Druck auf Button 3 graut diese dann erst aus.
Hayo W. schrieb: >> In der userif_t.cpp muß die Begrenzung Trigger_POS_CHE geändert werden >> (Zeilen 8381+8395). Grenzen sind jetzt 0 und 132 und das +-1 kann >> entfallen, > ist erledigt Hehe,nicht ganz! + 1 bzw. -1 natürlich bloß in der Bedingungsabfrage! :-) So: case 5: if (Trigger_Pos_CHE > 0){ Trigger_Pos_CHE = Trigger_Pos_CHE - 1; }else{ Trigger_Pos_CHE = 0; } break; und case 5: if (Trigger_Pos_CHE < 132){ Trigger_Pos_CHE = Trigger_Pos_CHE + 1; }else{ Trigger_Pos_CHE = 132; } break; Dann klappts auch mit der Pegelverstellung. Gruß Jürgen
Ja hatte ich auch schon gefunden, da hatte ich etwas viel gelöscht in der Eile. Ist aber wieder gefixt. Gruß Hayo
ja wahnsinn, was hier los is'... Hallo Hayo, die Drehgeberrichtung ging mir schon lange auf den Nerv, jedes mal drehte ich in die falsche Richtung! Hast du schick hinbekommen, bin begeistert. Wie sieht es mit der horizontalen Signalverschiebung aus, könnte man die auch in die richtige Drehrichtung bringen, d.h. drehe ich nach Links, verschiebt sich das Signal nach Rechts statt nach Links, was meinst du, oder ihr? Gruß Michael
Angehängte Dateien:
-
FFT-Main.png
4,8 KB
Hi Hayo, kannst du bei der Umschaltung von FFT nach Main (Menü Main/Delayed) noch mal nach dem Rechten sehen. Da bleibt die Info-Box mit den FFT Parameter im Moment stehen. Schönen Abend Gruß Rainer
Oh, den kannte ich noch nicht. Mach ich klar. Gruß Hayo
Angehängte Dateien:
-
QM_delay_phase.jpeg
53 KB
Schon mal ein kleiner Ausblick auf die 4.5 Ich habe es schon lange vor mir hergeschoben, aber jetzt habe ich es getan. Ich habe die bisher nicht funktionierenden QM-Optionen Delay und Phase implementiert, ebenso wie die zugehörigen Menüs zur Einstellung von Sourcen und Flanken. Gruß Hayo
Hayo W. schrieb: > Ich habe die bisher nicht funktionierenden QM-Optionen Delay und > Phase implementiert Moin Hayo, das finde ich klasse. Im Journalistendeutsch würde man das wohl als echten Quantensprung in der Funktionalität bezeichnen. Ich hatte mich schon über die ausgegrauten Parameter in der Liste gewundert ;-) Wo du damit die Zeitbezüge ansprichst: Wäre es bei den Cursorpositionen nicht sinnvoller, für die Zeiten X1 und X2 als Nullpunkt die Triggerposition zu verwenden. Der Zeitbezug auf den linken Bildschirmrand hat eigentlich eine relativ geringe Bedeutung. Meßtechnisch ist doch eher der Triggerzeitpunkt ein ausgezeichneter Zeitpunkt, der mir als Referenzzeit geeigneter erscheint. Man müßte eigentlich nur auf die im Cursor Menü angezeigten Werte X1 und X2 den Offset von der Position der Triggermarke draufrechnen. Gruß und frohes Schaffen Rainer
Michael D. schrieb: > ja wahnsinn, was hier los is'... > > Hallo Hayo, > > die Drehgeberrichtung ging mir schon lange auf den Nerv, jedes mal > drehte ich in die falsche Richtung! Hast du schick hinbekommen, bin > begeistert. > Wie sieht es mit der horizontalen Signalverschiebung aus, könnte man die > auch in die richtige Drehrichtung bringen, d.h. drehe ich nach Links, > verschiebt sich das Signal nach Rechts statt nach Links, was meinst du, > oder ihr? Ich habe mir das nochmal angesehen, die Drehrichtung passt schon, da Du nicht das Signal verschiebst sondern das Speicherfenster. Dafür habe ich die Drehrichtung der Zerolevelgeber geändert. Alle neuen Menüs findet Ihr wie immer im Programmer Guide. Und jetzt gehts ab in die Wanne Gruß Hayo
dann danke für die neue Version habe noch einen Bug gefunden. Displaytaste drücken->Grid ist angewählt(rot) und per Drehregler verstellbar->nun drücke ich auf die No Display Taste, das Menü No Display klappt auf ein drehen am Drehregler bewirkt aber ein verändern des Grids nicht das verstellen des aufgeklappten Menüs. Oh sehe gerade das das nur für die Menüs mit dem Drehsymbol funktioniert.
Hallo Hayo, von mir auch gleich ein Report zur neuen Version: Im FFT Menü stellt sich die "Mode" Taste etwas zickig an. Man kann zwar den Berechnungsmode auswählen, aber die Auswahlliste springt beim Drücken der Taste sofort weg... Gruß Rainer
moin moin Hayo, tnx f. die neue Version, aber.... im Quick Meas ist der drehregler falsch herum und der 3. softbutton wird erst beim druecken aktualisiert, die Triggeranzeige im single geht auch nicht ;( vlG Charly
Hallo Hayo, bleib nicht zu lange in der Wanne sonst wird alles schrumpelig! :-))) > Ich habe mir das nochmal angesehen, die Drehrichtung passt schon, da Du > nicht das Signal verschiebst sondern das Speicherfenster. Achso? Na dann bleibt's eben... Charly's Aussage über die Drehrichtung im QM-Menu stimmt aber. Gruß Michael
vielleicht ist es schon zu spaet aber i habe den Eindruck die Regler f. Y Position sind auch gedreht, oder ? vlG Charly
Charly B. schrieb: > .. i habe den Eindruck die Regler f. Y Position sind > auch gedreht, oder ? Sehe ich auch so. CCW = runter, CW=rauf fühlte sich besser an - so wie beim Trigger-Level. Gruß Rainer
Angehängte Dateien:
-
Kathode_D2-ext_syncro.JPG
150 KB
Hallo Hayo, danke, das ist auf jeden Fall die beste Version, die wir je hatten! Hayo W. schrieb: > Dafür habe ich die Drehrichtung der Zerolevelgeber geändert. Hm,das war voll daneben! Das passt einfach nicht. Ich kenn kein Oszi, wo sich das so bewegt. Du schaust auf dem Monitor nach links und drehst mit dem linken Rand des Drehgebers nach oben! So geht das! Noch eine Kleinigkeit zum ext. Trigger. Ich hab mal das Line-Signal an der Kathode D2 gemessen. Es sind nur 142mV / 50Hz an U6/3. Das bedeutet ca. +80mV am Comparator zum sicheren Auslösen des Triggers notwendig. Die notwendige Änderung im SetupTrigger() sind + 3 Inkremente (siehe im Textschnipsel). Das funktioniert sehr gut! Test mit ext. Trigger-> Line und einfach den Tastkopf an der Spitze anfassen. Stehendes Bild im Normal Modus. VG Jürgen
Hi Leute, hier ist ja wieder richtig was los! > bleib nicht zu lange in der Wanne sonst wird alles schrumpelig! :-))) Zu spät!!! @Thomas wie Du schon selbst bemerkt hast - das ist gewollt so -> kein Bug. > Im FFT Menü stellt sich die "Mode" Taste etwas zickig an. Man kann zwar > den Berechnungsmode auswählen, aber die Auswahlliste springt beim > Drücken der Taste sofort weg... Ok, muß ich mir morgen mal ansehen, danke. > im Quick Meas ist der drehregler falsch herum und der > 3. softbutton wird erst beim druecken aktualisiert, > die Triggeranzeige im single geht auch nicht ;( Ok, auch das werde ich morgen gleich mal unter die Lupe nehmen, danke > CCW = runter, CW=rauf fühlte sich besser an - so wie > beim Trigger-Level. Kein Problem, kann ich wieder rückgängig machen. @Jürgen Bau ich natürlich mit ein. Ich versuche mal morgen eine korrigierte Kompilation fertig zu machen. Danke für die schnelle Rückmeldung. Bis morgen Hayo
Angehängte Dateien:
-
Delay_Src1.png
5,1 KB
Hayo W. schrieb: > Ich versuche mal morgen eine korrigierte Kompilation fertig zu machen. Nur keine Eile - es brennt ja nichts. Im neuen QM Delay-Submenü sind noch zwei Dinge: 1. Als Bezugspunkt wird nicht der mit Source1 (Taste1) gewählte Kanal verwendet, sondern der im QM (Haupt-)menü als Source (auch Taste1) eingestellte. Für den Screenshot war im QM (Haupt-)Menü "Source 1" gewählt, so daas mangels Ch1-Signal als Bezugszeitpunkt der Fensteranfang genommen wurde. 2. Im QM Delay-Submenü stimmt IMHO die Beschriftung der Taste 5 nicht. Statt "Measure Frequency" sollte da bestimmt "Measure Delay" stehen. Bei der Anzeige des Meßwertes wäre es noch eine Verfeinerung, wenn man dort beide Bezugskanäle unterbringen könnte, also z.B. in der Form "Delay (2-3)= 13.6 µs". Super Sache mit der funktionierenden Delay Messung. Gruß Rainer
Angehängte Dateien:
-
Cursor_ch1.png
4,9 KB -
Cursor_ch4.png
5 KB
Moin Hayo, im Cursor Menü könnte man die Aktualisierung der Werte noch ändern. Wenn man den Kanal mit Taste 1 "Source" ändert, wird nur der Wert Delta-Y neu berechnet/angezeigt, aber nicht die Y-Meßwerte auf den Tasten 4 und 5, was dann zu inkonsistenter Anzeige wie im Bild Cursor_Ch4.png führt. Gruß Rainer p.s. Die Drehrichtung beim Ch.3 Offset ist ok ;-)
Rainer W. schrieb: > Nur keine Eile - es brennt ja nichts. ...läßt mir aber keine Ruhe! > Im neuen QM Delay-Submenü sind noch zwei Dinge: > > 1. Als Bezugspunkt wird nicht der mit Source1 (Taste1) gewählte Kanal > verwendet, sondern der im QM (Haupt-)menü als Source (auch Taste1) > eingestellte. Für den Screenshot war im QM (Haupt-)Menü "Source 1" > gewählt, so daas mangels Ch1-Signal als Bezugszeitpunkt der > Fensteranfang genommen wurde. Stimmt, das fehlte noch, ist aber jetzt erledigt > 2. Im QM Delay-Submenü stimmt IMHO die Beschriftung der Taste 5 nicht. > Statt "Measure Frequency" sollte da bestimmt "Measure Delay" stehen. Stimmt auch, ich hatte das nicht mit dem Drehregler getestet. Ist auch erledigt. > Bei der Anzeige des Meßwertes wäre es noch eine Verfeinerung, wenn man > dort beide Bezugskanäle unterbringen könnte, also z.B. in der Form > "Delay (2-3)= 13.6 µs". Da das kein Bugfix ist, bleibt das erstmal offen. > Super Sache mit der funktionierenden Delay Messung. Ja gefällt mir auch. Allerdings habe ich jetzt festgestellt, dass das Thresholdsmenü völlig ohne Funktion ist. Dem würde ich gerne abhelfen. @all Hat jemand eine Ahnung wofür das sein sollte? Duty Cycle? Gruß Hayo
Rainer W. schrieb: > im Cursor Menü könnte man die Aktualisierung der Werte noch ändern. Ist erledigt. > p.s. Die Drehrichtung beim Ch.3 Offset ist ok ;-) Bei den Anderen ist sie jetzt auch wieder ok. Hayo
charly schrieb: > im Quick Meas ist der drehregler falsch herum Die Drehrichtung ist genauso wie bei den anderen Pulldowns. Die Richtung hatte ich auf Wunsch hier im Forum geändert. > und der 3. softbutton wird erst beim druecken aktualisiert, Ist erledigt > die Triggeranzeige im single geht auch nicht ;( Das habe ich nicht verstanden. Welche Anzeige geht nicht? (Screenshot?) Gruß Hayo
Hayo W. schrieb: > Hat jemand eine Ahnung wofür das sein sollte? Duty Cycle? Das sollte normalerweise der Quotient aus "+Width" und "Periode" sein, um z.B. PWM-Signale auszumessen. Gruß Rainer
Jürgen schrieb: > Die notwendige Änderung im SetupTrigger() sind + 3 Inkremente (siehe im > Textschnipsel). Das funktioniert sehr gut! Ist eingebaut Hayo
So alle Fixes für die Bugs die seit gestern gemeldet wurden sind drin. Gruß Hayo
Hayo W. schrieb: > Dem würde ich gerne abhelfen. > > @all > > Hat jemand eine Ahnung wofür das sein sollte? Duty Cycle? Ok, habe in der Anleitung zum Agilent alles gefunden. Zum Glück ist ja alles 1:1 abgekupfert, so dass man die Anleitung großenteils für unser DSO benutzen kann. Hayo
Ok nächste Erkenntnis: Es hat doch Auswirkung auf die Messungen, aber die Implementierung ist noch unvollständig und die einstellbaren Werte sind zum Teil sinnlos -> ist in Arbeit. Hayo
moin moin Hayo, das war nix ;) Y pos. ch1 ist falschrum, Y pos. ch2 ist richtig wenn du noch invert einschaltest und bisschen flotter drehst macht er wie ein Kaenguruh :) vlG Charly
i hab den eindruck er springt um doppelte, 'ueberlegt' es sich dann und springt um die haelfte zurueck
Hayo W. schrieb: > Zum Glück ist ja alles 1:1 abgekupfert, so dass man die Anleitung > großenteils für unser DSO benutzen kann. Welchem Agilent Modell ähnelt das Welec denn am meisten? Ich habe das Oszi seit zwei Jahren, mittlerweile ist es tatsächlich sehr nützlich. Dank euch. Dafür ein herzliches Dankeschön!
Keine Ahnung, aber die Anleitung ist für folgende Scopes: Agilent 54621A/22A/24A/41A/42A Oscilloscopes and Agilent 54621D/22D/41D/42D Mixed-Signal Oscilloscopes Wer Selbige nicht finden kann schreibe mir eine PN, dann schicke ich sie zu. Posten kann ich sie hier aus rechtlichen Gründen leider nicht. Gruß Hayo
charly schrieb: > moin moin Hayo, > > das war nix ;) > Y pos. ch1 ist falschrum, > Y pos. ch2 ist richtig Mist, der ist mir irgendwie wieder durchgerutscht. Ist schon korrigiert. > wenn du noch invert einschaltest und bisschen > flotter drehst macht er wie ein Kaenguruh :) Das ist der DAC der sich da einschwimgt und die etwas träge Drehgeberverarbeitung Gruß Hayo
Hallo Hayo, in wie weit wird jetzt die Huckepackplatine eigentlich schon von der neuen Firmware unterstützt? branadic
Angehängte Dateien:
-
Duty-Cycle-01.png
5,1 KB
> Das sollte normalerweise der Quotient aus "+Width" und "Periode" sein, > um z.B. PWM-Signale auszumessen. ...und deren Tastverhältnis. Im obigen Fall ist ein Tastverhältnis von 50%, d.h. 50% der Impulsdauer sind der eingeschalteter Zustand. Hab' ich noch was vergessen? ...ich finde diese Messoption sehr praktisch. Wenn Hayo so weiter macht, kann das Welec in der nächsten Zeit noch fliegen lernen! :-))) > Gruß > Rainer Gruß Michael
Angehängte Dateien:
-
QM-Drehgeber-Select-01.png
5,4 KB
Hi Hayo, im Quickmeasure geht die automatische Messbereichsumschaltung immer noch nicht. Wenn am Drehgeber z.B. "Rise-Time" ausgewählt wird, dann müsste das jetzt an Stelle von "Measure RMS" stehen(siehe Screenshot), tut es aber nicht! Man muß jetzt jedes Mal auf den "Select" Button drücken, erst dann kann der Messbereich ausgewählt werden. Ich dachte du hättest das gefixt? Charly hatte ja auch schon gepöpelt... :-) Gruß Michael
Angehängte Dateien:
-
Restore.png
4,5 KB
Hallo Hayo, so fleißig wie du zur Zeit dabei bist, wird es langsam mühseliger, noch Bugs auszugraben. Aber einen konnte ich trotzdem noch entdecken: Drück mal im Save/Recall-Menü die "Restore Settings"-Taste.... Die Softekeys werden erst beim Drücken aufgebaut und in der Statuszeile wird zwischen den Zeichen die Textfarbe als Hintergrundfarbe gemalt. Beim Recall trat das neulich auch auf, hattest du dann dort aber repariert. Michael D. schrieb: > ...und deren Tastverhältnis @Michael Das meinte ich doch mit dem Quotienten ;-) Gruß Rainer
und im QM ist der Select drehregler immer noch falsch in der Drehrichtung (3. taste auch s.o.) vlG Charly undganzschnellwegbevorespruegelgibt
charly schrieb: > undganzschnellwegbevorespruegelgibt Haha, hier wird niemand verhauen! Viele Softwareentwickler würden sich so hartnäckige Tester wie euch viel Geld kosten lassen. ;-) Das spornt Hayo nur weiter an und ihr müsst die Zeit nutzen, bevor er beruflich wieder gestresst wird. Ich habe gerade eine Bestellung vom C bekommen und den Schalter wieder vergessen :-(. Das Alter! Grüße, Guido
@ Guido > Haha, hier wird niemand verhauen! Viele Softwareentwickler würden sich > so hartnäckige Tester wie euch viel Geld kosten lassen. ;-) Das ist wahr. So frustrierend es im ersten Moment ist wenn was schief läuft, so wertvoll sind aber unter dem Strich all die Hinwweise. Danke dafür! @Charly Der Drehregler ist schon richtig rum. Genau wie die Anderen eben. Oder? @Michael > im Quickmeasure geht die automatische Messbereichsumschaltung immer noch > nicht. > Wenn am Drehgeber z.B. "Rise-Time" ausgewählt wird, dann müsste das > jetzt an Stelle von "Measure RMS" stehen(siehe Screenshot), tut es aber > nicht! Verdammt, das lief doch vorhin. Sehe ich mir morgen mal an. Jetzt bin ich vom Griechen zu angeschickert. Ich war heute auch mehr mit dem Thresholds-Menü beschäftigt. Das sieht schon ganz anständig aus mittlerweile. @all Zum Duty Cycle gibt es auch einen Wikipedia-Beitrag der ganz informativ ist. Gruß Hayo
im QM den Regler CCW gehts in der Liste nach oben, sollte aber nach meinem gefuehl nach unten, oder ? die beiden Y-Pos Regler von Ch1 & Ch2 sind gegenlaeufig (oder ist das nur bei mir so ?) vlG Charly
Charly B. schrieb: > die beiden Y-Pos Regler von Ch1 & Ch2 sind > gegenlaeufig (oder ist das nur bei mir so ?) Wenn man mal dich und Hayo betrachtet, ist das nur bei dir so ;-) Hayo W. schrieb: > Ist schon korrigiert. Gruß Rainer
branadic schrieb: > Hallo Hayo, > > in wie weit wird jetzt die Huckepackplatine eigentlich schon von der > neuen Firmware unterstützt? > > branadic Danke für's Ignorieren. branadic
Hallo Branadic, sorry war nicht mit Absicht, aber die beste aller Ehefrauen drängelte gestern etwas, da habe ich dann lieber Schluss gemacht. Die Unterstützung ist eingebaut. Was wohl noch fehlt ist die korrekte Skalierung. Mir fehlt im Augenblick die Möglichkeit das zu prüfen bzw. die Skalierung selbst durchzuführen. Am Besten direkt an Jörg wenden, da er den aktuellen Stand am Besten kennt. Ich habe ja nur seine Ansteuerung mit eingebaut. Gruß Hayo
Also irgendwie müssten wir uns da mal einigen, wie der Drehregler zu gestalten ist ?!? Im Allgemeinen bedeutet Rechtsdrehung 'mehr' u. nach Links 'weniger', wie beim Lautstärkeregler... Bei den Pullup-down-Menus, würde demnach Links 'runter' u. Rechts' hoch bedeuten, ist doch eigendlich ganz einfach, oder? Bei der Spannungswahl der Kanäle, drehe ich ständig falsch herum, müsste dann auch korrigiert werden... @Guido > Ich habe gerade eine Bestellung vom C bekommen und den Schalter wieder > vergessen :-(. Das Alter! Wenn du den Hauptschalter meinst, da habe ich noch welche da! @Rainer > Wenn man mal dich und Hayo betrachtet, ist das nur bei dir so ;-) der Charly ist bestimmt Australier, da läuft alles falsch herum.. :-))) @branadic > Danke für's Ignorieren. Hayo meinte, das die Platine schon implementiert sei und er noch einige Parameter bräuchte, soweit ich mich erinnern kann. Gruß Michael
Michael D. schrieb: > Also irgendwie müssten wir uns da mal einigen, wie der Drehregler zu > gestalten ist ?!? Versuchsweise habe ich mal als Diskussionsgrundlage ohne Anspruch auf Vollständigkeit eine kleine Tabelle zusammengestellt: CCW CW TB Geschw. langsamer schneller TB Fenster-X links rechts Cursor X links rechts Cursor Y runter hoch Gain unempfindlich empfindlich Y-Position runter hoch Menü runter hoch Triggerschwelle runter hoch Bei invertierter Erfassung der Kanäle, muß man sich noch einigen, ob die Drehreglerrichtung (Offset, Trigger, Cursor) sich auf die Meßwerte oder auf die Bildschirmdarstellung beziehen soll. IMHO wäre BS intuitiver, aber für beide Arten gibt es gute Gründe. Gruß Rainer
ich sitze jetzt leider gerade nicht am Oszi. Ein Beitrag im Wiki wäre nicht schlechte den kann jeder bearbeiten und jeder kann einen Strich setzen wie die einzelnen Dinge auf die Drehrichtung zu reagieren haben. Dann kann das jeder mal in Ruhe vor dem Oszi testen.
ich habe mal auf die schnelle einen Artikel bitte um Erweiterung. http://www.mikrocontroller.net/wikisoftware/index.php?title=Drehrichtung_f%C3%BCr_Wittig_Oszi_Bedienung&redirect=no
ich habe das noch etwas angepasst (und natürlich Striche gemacht)
Signallinie und Triggerlevel sollten zumindestens identisch in der Drehrichtung sein.
So, habe alle Bugs soweit abgearbeitet und auch die Drehrichtung gemäß Wiki angepasst. Neu ist das jetzt funktionierende Threshold-Menü dass es erlaubt für jeden Kanal eigene Schwellwerte einzustellen. Bei Default Setup wird alles wieder auf 10/50/90 zurückgestellt. Gruß Hayo
1.2.BF.4.6 ein Mini-Mini-Bug für die Liste: Display->Setup->Grid Lines Nach dem Betätigen dieses QB bleibt der Rand des Auswahlfeldes kurzzeitig stehen. Bei QB-Grid Color und QB-Status ist die Darstellung ok. Gruß Robert
1.2.BF.4.6 Kann es sein das Grid Color White und Grid Color Gray sich nicht unterscheiden? Bin mir nicht sicher, aber ich erkenne da keinen Unterschied. Gruß Robert
Angehängte Dateien:
-
screen-0000.png
3,6 KB -
screen-0001.png
3,4 KB
Hallo Hayo, hab die 4.6 gerade geflasht, Defaults geladen und mal ein bisschen rumgespielt. Ein paar kleine Sachen sind mir aufgefallen: Siehe screen-0000: Im Math-Menü war erst ein kleiner oranger Strich zwischen auf Softkey 2 da. Wurde hier den ich schon mal erwähnt. Habe dann nochmal auf Math gedrückt (Math deaktiviert) und dann am Drehregler gedreht - das Ergebnis sieht man auf dem Screenshot. Dann hab ich erst ein paar andere Sachen getestet und bin zurück ins Math-Menü. Der Drehregler bzw. dessen weiße LED war an, aber der Pfeil bei Softkey 1 ausgegraut. Drehen hat wieder diesen Wert auf Softkey 2, der da nicht hingehört, geändert. Defaults geladen - nun ist der orange Strich nicht mehr da, das Problem mit dem Softkey 2 immer noch. Nächste Sache ist QM. Drücke ich Setting passiert nichts. Andere Sache, gleiches Menü: Ich wähle Clear Measure aus und die Messungen werden wie gewünscht gelöscht. Deaktiviere ich QM und aktiviere es wieder werden wieder Freq und Pk-Pk gemessen. Kann natürlich auch ein Feature sein. Im Aquire Menü war vorhin noch ein halber Pfeil auf Softkey 6 zu sehen (screen-0001) - keine Ahnung wo der herkam, kann das jetzt so nicht mehr reproduzieren. Ansonsten wie immer: Klasse Arbeit, schön zu sehen, wie unser Oszi hier Tag für Tag besser wird :)
Auf einen falsch rum drehenden Regler bin ich noch gestoßen: Wenn man einen Kanal invertiert, wandert bei CCW-Drehung am Trigger Level die Linie noch nach oben. Gruß Rainer
Danke für die Rückmeldungen, leider komme ich morgen wohl nicht dazu Fixes zu machen da ich tagsüber in der Firma bin. Werde aber trotzdem hier reingucken und mal ob sich was tut. Gruß Hayo
Angehängte Dateien:
-
screen-0000.png
4,1 KB
Sebastian S. schrieb: > Nächste Sache ist QM. Drücke ich Setting passiert nichts. Hab gerade mal in die Programmers Reference geschaut - jetzt verstehe ich, was Setting bewirken soll. Also ist das Problem nur, dass die Settings Softkey bei anderen Einstellungen als Phase und Delay nicht ausgeblendet wird. In den QM Phase Settings ist mir aber auch noch eine Kleinigkeit aufgefallen - hier ist wieder mal der orange Strich zu sehen, wo eigentlich ncihts sein sollte (siehe Screenshot). EDIT: Und noch etwas - im Settingsmenü von sowohl Phase als auch Delay leuchtet die weiße LED am Drehregler, obwohl nix zu drehen ist... EDIT2: Noch zwei kleine Unstimmigkeiten: Die erste ist vermutlich nur ein Fehler in der Programmers Reference / Menu Table. Bei 28 (Display FFT) soll laut Reference F5 ja "Display Layout" sein - am Oszi ist diese Taste nicht belegt. Die andere Unstimmigkeit: F4 wird als "Switch Grid" bezeichnet, ist auch am Oszi vorhanden - nur ändert es nichts, außer das es die Anzeige neu aufbaut. Ich vermute ein Überbleibsel aus Zeiten, bevor es das Setup-Untermenü gab? So, dass war's dann erstmal von meiner Seite. Oszi aus und ins Bett hüpfen ;)
Angehängte Dateien:
-
Select_Reset.png
5,3 KB -
Select.png
5,4 KB
Sebastian S. schrieb: > Sebastian S. schrieb: >> Nächste Sache ist QM. Drücke ich Setting passiert nichts. Um das etwas einzugrenzen: Der Fehler scheint nur direkt nach einem DSO Neustart (Einschalten/Reset) aufzutreten. Wenn man dann in das QM Menü geht, ist die Taste 5 (Setting) nicht richtig ausgeblendet (Select_Reset.png), so wie es sonst der Fall ist (Select.png). Gruß Rainer
Robert schrieb: > Kann es sein das Grid Color White und Grid Color Gray sich nicht > unterscheiden? Bin mir nicht sicher, aber ich erkenne da keinen > Unterschied. Hi Robert, wegen der stark beschränkten Farbpalette gibt es zwischen den beiden Einstellungen einen echten Unterschied nur bei Helligkeit 66%. Gruß Rainer
Hallo @ all, habe hier mal einiges gelesen und gehofft mein altes W2022 (ohne A) in einen brauchbaren Zustand versetzen zu können. Leider ist mir das zuviel Aufwand für zu wenig Nutzen. Vielleicht findet sich aber hier ein Interessent, der mir das Gerät abkaufen möchte. Habe irgendwann mal die Firmware upgedated, aber nicht bedacht, daß die für mein altes Gerät nicht paßt. Nun funktioniert nichts mehr richtig. Zum Zustand: Angezeigt wird: Model: W2022A (aber das Gerät ist ein W2022) Hardwareversion: 3C7.0I Softwareversion: 1.10.03 Seriennummer: 00030004C7 An der Hardware habe ich nichts verändert. Da das Gerät sein Leben bisher im Karton verbracht hat, ist es auch äußerlich unbeschädigt. Ich habe noch den Originalkarton und auch die Tastköpfe. Wenn jemand Interesse hat, kann er sich per PN mit einem Gebot bei mir melden. Gruß Helmut
Hallo Helmut, das mit der PN ist nicht möglich da du dich als Gast eingeloggt hast. Ein Kollege ist von meinem W2022 begeistert und hat jetzt Interesse bekundet eins käuflich zu erwerben, leider ist er bei eBay nicht mehr fündig geworden. Deshalb freut er sich sehr über dein Angebot und würde gerne wissen was du dafür haben möchtest. Kannst deine Preisvorstellungen per PN an mich senden, ich werde es dann weiterreichen. Jan
Na guck mal, da gibt es ja wieder Zuwachs in der W2000 Gemeinde. @Sebastian > Also ist das Problem nur, dass die > Settings Softkey bei anderen Einstellungen als Phase und Delay nicht > ausgeblendet wird. Also eigentlich soll die Setting-Taste bei allen Messungen bis auf Delay und Phase grau sein und auch keine Funktion haben. Nur bei Delay und Phase soll sie in das jeweilige Menü verzweigen. Bei mir tut sie das auch. Habt Ihr nach dem Flashen einen Neustart und dann ein default Setup gemacht? Wenn der Fehler weiterhin auftritt bitte mit Screenshot posten. > im Settingsmenü von sowohl Phase als auch Delay > leuchtet die weiße LED am Drehregler, obwohl nix zu drehen ist... Ok, muß korrigiert werden. > In den QM Phase Settings ist mir aber auch noch eine Kleinigkeit > aufgefallen - hier ist wieder mal der orange Strich zu sehen, wo > eigentlich ncihts sein sollte Das blöde Teil stammt vom QM-Auswahlmenü. Der Pfeil ist etwas größer als die normalen Pfeile und wird deshalb nicht richtig gelöscht. Kümmere ich mich drum... > Die andere Unstimmigkeit: F4 wird als "Switch Grid" bezeichnet, ist auch > am Oszi vorhanden - nur ändert es nichts Bist Du sicher dass nichts passiert? Bei mir wird die Gridteilung in X-Richtung (also die Frequenzteilung) umgeschaltet zwischen 8 und 10 Divs. Gleichzeitig sollte sich auch die Anzeige auf der rechten Seite ändern. @Rainer > wegen der stark beschränkten Farbpalette gibt es zwischen den beiden > Einstellungen einen echten Unterschied nur bei Helligkeit 66%. Korrekt, das sieht sich sehr ähnlich weil nur der eine Wert abweicht. Gruß Hayo
Hayo W. schrieb: > Also eigentlich soll die Setting-Taste bei allen Messungen bis auf Delay > und Phase grau sein und auch keine Funktion haben. Hayo, hast du direkt nach Reset mal geguckt? Rainer W. schrieb: > Um das etwas einzugrenzen: Der Fehler scheint nur direkt nach einem DSO > Neustart (Einschalten/Reset) aufzutreten. ... edit: Mit Screenshot ;-)
Hayo W. schrieb: >> Die andere Unstimmigkeit: F4 wird als "Switch Grid" bezeichnet, ist auch >> am Oszi vorhanden - nur ändert es nichts > Bist Du sicher dass nichts passiert? Bei mir wird die Gridteilung in > X-Richtung (also die Frequenzteilung) umgeschaltet zwischen 8 und 10 > Divs. Gleichzeitig sollte sich auch die Anzeige auf der rechten Seite > ändern. Du hast recht, hab ich gestern Nacht gar nicht mehr bemerkt - war dann wohl doch etwas zu spät ;) Hayo W. schrieb: > @Sebastian > >> Also ist das Problem nur, dass die >> Settings Softkey bei anderen Einstellungen als Phase und Delay nicht >> ausgeblendet wird. > > Also eigentlich soll die Setting-Taste bei allen Messungen bis auf Delay > und Phase grau sein und auch keine Funktion haben. Nur bei Delay und > Phase soll sie in das jeweilige Menü verzweigen. Bei mir tut sie das > auch. Habt Ihr nach dem Flashen einen Neustart und dann ein default > Setup gemacht? > > Wenn der Fehler weiterhin auftritt bitte mit Screenshot posten. Siehe Rainers Nachricht, tritt direkt nach Default Setup und/oder Neustart auf... Screenshot hat Rainer oben ja schon gepostet (select_reset.png). Gruß Sebastian
Hallo Hayo, hab hier doch zwei kleine Sachen: Schau mal im display_t.cpp Zeile 2524. SelectedTriggerSource sollte=6 gesetzt werden? Ich denke, nur TV ist als Triggersource 6 vereinbart. Ich weiß auch nicht, welche "schlimmen" Auswirkungen das hat. Irgendwie hakt es noch im Edge Menü: EDGE drücken 1. Schalte mit F2 von CH1 nach Ext. - angezeigt wird External,LF Reject 2. Schalte mit F3 zu Line - ist auch in der Statuszeile Line 3. Zurück mit F2 zu CH1 - Statuszeile = 1, F3 ist grau-> richtig 4. Zurück mit F2 zu Ext. - über F3 steht LF Reject 5. Drückst 1 x F3 - Häkchen ist bei Line und mit Loslassen F3 schaltet es auch auf Line Du kannst doch sicher feststellen, ob das Menü schon mal aufgerufen wurde?Dann muß nicht nochmal ein Default gesetzt werden. Gruß Jürgen
Ok, stimmt. Bei mir tritt das nach einem Neustart auch auf. Hab's schon repariert. Jetzt suche ich mal nach dem verdammten roten Strich. @Jürgen sehe ich mir gleich mal an. Hayo
Ok, im Prinzip hast Du Recht, aber... das Setzen der Variable an dieser Stelle ist eigendlich völlig sinnlos, da diese in Setup_Trigger sowieso gesetzt wird. Ich werde das also mal rauslöschen. Weiterhin werden Werte über 3 ohnehin nicht in Setup_ADC ausgewertet. Ob da also 5 oder 6 oder 13 drinsteht ist piepschnurzegal. Aber aufräumen werde ich trotzdem mal. Dass Edge-Menü ist gerade in Arbeit. Gruß Hayo
Jürgen schrieb: > Du kannst doch sicher feststellen, ob das Menü schon mal aufgerufen > wurde?Dann muß nicht nochmal ein Default gesetzt werden. Nein leider nicht. Der Wert des Menüs wird beim deaktivieren gelöscht. Ich müßte das also in einer Backup-Variablen zwischenspeichern. Da es ja nur drei Einträge sind finde ich das nicht so schlimm. Ansonsten habe ich dass jetzt repariert. Gruß Hayo
Robert schrieb: > Nach dem Betätigen dieses QB bleibt der Rand des Auswahlfeldes > kurzzeitig stehen. repariert Hayo
Rainer W. schrieb: > Auf einen falsch rum drehenden Regler bin ich noch gestoßen: > Wenn man einen Kanal invertiert, wandert bei CCW-Drehung am Trigger > Level die Linie noch nach oben. Da bist Du leider auf dem Holzweg :-) Die Darstellung ist invertiert, nicht das wirkliche Signal. Daher läuft natürlich auch der Trigger genau andersherum. Ist also kein Bug sondern ein Feature. Gruß Hayo
Hayo W. schrieb: > Die Darstellung ist invertiert, nicht das wirkliche Signal. Daher läuft > natürlich auch der Trigger genau andersherum. Ist also kein Bug sondern > ein Feature. Aber irgendwie guckt man jedes mal doof, wenn man das Signal auf dem Schirm sieht, den Trigger Level nach links dreht und die Trigger-Linie entgegengesetzt zur Drehrichtung (verglichen mit nicht-invertiert Darstellung) wandert. Zumindest ich denke da immer eher in der Bildschirmdarstellung und nicht so sehr in den echten Signalvorzeichen. Gruß Rainer
Ich hätte auch gerne getestet. Bin zwar vom Fach (Elektronik-Ing.), aber leider hab ich zu wenig Zeit und die Versuche und Recherchen im Netz haben schon zuviel Zeit gekostet. Letztlich bin ich jetzt an der Installation von USB-Blaster auf meinen PC's (Win7) gescheitert und hab das Ganze abgebrochen. Falls sich doch kein Kaufinteressent findet, wäre ich für Antwort von den Fachleuten hier auf folgende Fragen dankbar: Angezeigt wird: Model: W2022A (aber das Gerät ist ein W2022) Hardwareversion: 3C7.0I Softwareversion: 1.10.03 Seriennummer: 00030004C7 1. Ist das Gerät trotz der falsch aufgespielten Software mit vertretbarem Aufwand noch zu retten? 2. Wenn ich das richtig sehe, muß ich erst mal das Gerät von W2022 auf W2022A bringen und brauche dafür u.a. USB-Blaster. Läuft das unter Win7? Sonst könnte ich unter einem virtuellen XP noch versuchen. Liege ich so weit richtig? Brauche ich ein alte Original-Firmware? Gruß Helmut PS: Nun bin ich hoffentlich eingeloggt und wer Kaufinteresse hat kann sich hier oder per PN bei mir melden.
Sebastian S. schrieb: > Andere Sache, gleiches Menü: Ich wähle Clear Measure aus und die > Messungen werden wie gewünscht gelöscht. Deaktiviere ich QM und > aktiviere es wieder werden wieder Freq und Pk-Pk gemessen. Kann > natürlich auch ein Feature sein. Eine Frage an die Runde: Legt irgendjemand Wert auf dieses Feature bzw. hält es wenigstens für sinnvoll, oder sollte man diesen Zopf einfach abschneiden? Gruß Rainer
Helmut M. schrieb: > 1. Ist das Gerät trotz der falsch aufgespielten Software mit > vertretbarem Aufwand noch zu retten? Hast du diese Seite schon gefunden? Ist halt was für Windowsuser, deshalb kann ich perönlich nichts dazu sagen: http://sourceforge.net/apps/trac/welecw2000a/wiki/Upgrade Und, da war noch eine Frage an dich, bitteschön: Jan D. schrieb: > Hallo Helmut, > > das mit der PN ist nicht möglich da du dich als Gast eingeloggt hast. > Ein Kollege ist von meinem W2022 begeistert und hat jetzt Interesse > bekundet eins käuflich zu erwerben, leider ist er bei eBay nicht mehr > fündig geworden. Deshalb freut er sich sehr über dein Angebot und würde > gerne wissen was du dafür haben möchtest. > > Kannst deine Preisvorstellungen per PN an mich senden, ich werde es dann > weiterreichen. > > Jan
Michael D. schrieb: > @Guido >> Ich habe gerade eine Bestellung vom C bekommen und den Schalter wieder >> vergessen :-(. Das Alter! > Wenn du den Hauptschalter meinst, da habe ich noch welche da! Klar meine ich den. ich schreibe dir mal eine PN, mitbestellen klappt irgendwie seit Jahren nicht.
Hallo Rainer! Rainer W. schrieb: >> Andere Sache, gleiches Menü: Ich wähle Clear Measure aus und die >> Messungen werden wie gewünscht gelöscht. Deaktiviere ich QM und >> aktiviere es wieder werden wieder Freq und Pk-Pk gemessen. Kann >> natürlich auch ein Feature sein. > > Eine Frage an die Runde: > Legt irgendjemand Wert auf dieses Feature bzw. hält es wenigstens für > sinnvoll, oder sollte man diesen Zopf einfach abschneiden? Ich halte dies für nützlich, und möchte das beibehalten! So kann man kurzzeitig Platz auf dem Schirm schaffen und etwas mehr Performance erreichen und muss sich später nicht wieder durch die Menüs hangeln. JK
Rainer W. schrieb: > Sebastian S. schrieb: >> Andere Sache, gleiches Menü: Ich wähle Clear Measure aus und die >> Messungen werden wie gewünscht gelöscht. Deaktiviere ich QM und >> aktiviere es wieder werden wieder Freq und Pk-Pk gemessen. Kann >> natürlich auch ein Feature sein. > > Eine Frage an die Runde: > Legt irgendjemand Wert auf dieses Feature bzw. hält es wenigstens für > sinnvoll, oder sollte man diesen Zopf einfach abschneiden? Wie sollte es denn dann wieder starten? Mit ohne Messung? Ich finde das nicht so schlecht, da das eigentlich die häufigsten Messungen sind die man macht und die auch am meisten über das Signal aussagen. Es ist ja nur ein Knopfdruck um das wieder zu löschen. Gruß Hayo
Hayo W. schrieb: > Wie sollte es denn dann wieder starten? Mit ohne Messung? Ja. Wenn ich in das QM Menü gehe, habe ich i.A. eine ganz bestimmte Vorstellung, was ich messen möchte - und meist ist das nicht Freq & Pk-Pk, d.h. in den meisten Fällen bin ich erstmal am aufräumen. Das hängt natürlich viel vom Einsatzzweck ab. Bei der Einstellung anderer gewünschten Parameters nützt es nichts und füllt IMHO erstmal nur die ersten beiden Meßwertfelder mit ungebetenen Parametern. Gruß Rainer
Wie schon gesagt, ein Knopfdruck... @All Wie sieht es mit den Anderen aus? Gruß Hayo
Moin zusammen, als Luxuslösung für die QM Defaults könnte ich mir eine Speicherung in den Setups vorstellen. Dann könnte man sich für verschiedene Meßszenarien das komplette Setup incl. QM Parameterwahl über "Save/Recall - Save Trace" im Speicher ablegen. Dazu müßten die aktuell eingestellten QM Parameter bei Save Traces mit gespeichert werden. Nach einem "QM - Clear Measure" könnten die beim letzten "Save/Recall - Recall Trace" vorhandenen Parameter als Default (anstelle von z.Z. fix Freq.(1) und pk-pk(1)) herangezogen werden. Mit "Utility - Default Setup" könnte man auf die jetzig Konfiguration schalten. In jedem Fall wäre es natürlich praktisch, die aktuellen QM Parameter mit beim "Save/Recall - Save Trace" zu berücksichtigen. Hayo, was meinst du? Wäre in der Richtung ohne Neuerfindung der Welt etwas machbar? Gruß Rainer
Helmut M. schrieb: > Letztlich bin ich jetzt an der > Installation von USB-Blaster auf meinen PC's (Win7) gescheitert und hab > das Ganze abgebrochen. machs dir einfach und verwende einen Rechner mit XP sowie einen richtigen onboard- Com Port, besonders auch fürs FW Flashen ist das sonst ein ziemliches gefrickel bis das mit virtuellen/ USB Lösungen mal unter Win7 läuft, wenn überhaupt.
Moin, also bisher hatte ich Cursoreinstellungen und QM-Einstellungen extra aus Save Recall herausgehalten. Man kann das aber ohne großen Aufwand mit abspeichern. Die entsprechenden Stellen sind zur Zeit einfach nur auskommentiert. Wie ist denn da so die allgemeine Meinung? Ich bin davon augegangen, dass man z.B. ein Signal mißt und die Cursor oder QM dazu benutzt. Wenn man jetzt ein Vergleichssignal aus dem Speicher lädt möchte man ja eigentlich so weitermessen wie gehabt und nicht alles umgestellt haben oder? Gruß Hayo
Könnte man die nicht mit abspeichern, und beim recall gefragt werden, ob die aktuellen Cursorwerte etc. überschrieben werden sollen? Nur mal so als Idee. Viele Grüße, egberto
Hayo W. schrieb: > ... Wenn man jetzt ein Vergleichssignal aus dem > Speicher lädt möchte man ja eigentlich so weitermessen wie gehabt und > nicht alles umgestellt haben oder? Mmh. Ist es beim Signalvergleich nicht sowieso so, dass die Geräteeinstellung identisch zur Vergleichsmessung sind? Ich sehe den Speicher ganz wesentlich auch als Möglichkeit, das Gerätesetup für ein Szenario zu speichern, ohne das dabei die Trace-Daten interessieren. Sonst müßte man noch zwischen Save/Recall Trace und Save/Recall Setup unterscheiden, was natürlich auch eine Möglichkeit wäre. Man könnte z.B. ein eigenes Softmenü für z.B. 5 oder 6 Setups machen, mit push für Recall und double-push für Save oder so. Gruß Rainer
elecBlu schrieb: > Helmut M. schrieb: >> Letztlich bin ich jetzt an der >> Installation von USB-Blaster auf meinen PC's (Win7) gescheitert und hab >> das Ganze abgebrochen. > > machs dir einfach und verwende einen Rechner mit XP sowie einen > richtigen onboard- Com Port, besonders auch fürs FW Flashen ist das > sonst ein ziemliches gefrickel bis das mit virtuellen/ USB Lösungen mal > unter Win7 läuft, wenn überhaupt. Danke für den Tip! Das hätte ich dann wohl auch versucht. Hätte aber erst mal einen alten PC suchen müssen mit nativen COM-Ports und dann XP installieren. Beruflich habe ich alle krtitischen Anwendungen mit RS232 über LAN-COM-Server im Griff. Bei den USB-RS232-Wandlern gibt es auch nur wenige die zuverlässig arbeiten. Nun hat der Jan aber mein Verkaufsangebot angenommen und ich bin die Kiste los. Habe ja noch mein schönes Scope von Agilent;-) Danke noch einmal @all!
Angehängte Dateien:
-
screen-0000.png
4,8 KB
Hayo, ich habe eine Frage zu dem Testsignal. Ist es richtig, dass der 2. CH unten abgeschnitten dargestellt wird? (siehe Screen-Shot) Kann es sein, das da die QB-Reihe mit in die Berechnung mit aufgenommen wird und die Null-Linie zu tief sitzt? Um das Signal vollständig zu sehen verschiebe ich den CH2 nach oben. Nach einem Autoscale sitzt das Biest aber wieder zu tief. Ja, das ist nur ein Testsignal, aber irgendwie kommt mir das nicht so ganz richtig vor.
Hi Robert, das Testsignal skaliert leider nicht ganz so wie ein echtes Signal. Außerdem kann Autoscale das Signal nicht "sehen", da dieses an einer anderen Stelle in den Puffer gemischt wird. D.h. Autoscale findet nichts, läßt daher die Spannungsbereiche unverändert, führt dann aber ein dispatch channels aus. Daher diese Reaktion. Bei einem echten Signal sähe das anders aus solange die Möglichkeit besteht in den nächst höheren Spannungsbereich zu schalten. Gruß Hayo
Angehängte Dateien:
-
QM_Math.jpeg
56 KB
Wie würde Euch denn die volle Integration des Math-Channel in QM gefallen? Ungefähr so wie auf dem Bild - ist die 4.7. Und wenn dann Math auch noch um Fakt 4 - 5 schneller wär? Aber das ist ja bloß soon Gedanke... :-) Gruß Hayo
Hayo W. schrieb: > Ungefähr so wie auf dem Bild - ist die 4.7. So wie der Screen Shot aussieht, scheint der Gedanke schon recht weit fortgeschritten. Mit dem Geschwindigkeitsfaktor könnte ich wohl leben ;-) Rainer W. schrieb: > Wäre es bei den Cursorpositionen nicht sinnvoller, für die Zeiten X1 und > X2 als Nullpunkt die Triggerposition zu verwenden. .... Hast du mal über die Sache mit den signalorientierten X-Cursorpositionen nachgedacht? Die Y-Cursor beziehen sich schließlich auch immer auf das Signal und nicht auf den Bildschirm. Gruß Rainer
Angehängte Dateien:
-
Math_Delay.jpeg
48 KB
Hier ein schönes Beispiel bei dem man den Triggerkanal ausblendet um das Delay zwischen Math und Kanal 2 zu messen. Durch das Ausblenden wird natürlich auch die Geschwindigkeit etwas höher. @Rainer > Hast du mal über die Sache mit den signalorientierten X-Cursorpositionen > nachgedacht? Ja hab ich. > Die Y-Cursor beziehen sich schließlich auch immer auf das > Signal und nicht auf den Bildschirm. Nich ganz richtig, sie beziehen sich auf den Zerolevel, was Du wohl auch meintest. Die Idee hat Ihre Vorzüge, aber ich finde die bisherige Lösung besser weil ich mich da besser (am Grid) orientieren kann. Stell Dir vor Du scrollst ungefähr bei Index 14580 durch den Signalspeicher (also am Arsch der Welt bzw. des Signals) und willst dann messen. Da hast Du dann erstens irgendwelche Zeiten die Dir überhaupt nichts sagen, und evtl. durch die großen Werte schon eine oder zwei Nachkommastellen weniger an Genauigkeit. Oder andersherum. Wenn der Pretrigger irgendwo rechts außerhalb des Bildschirms ist, dann hast Du die ganze Zeit negative Werte, die aber keinen sichtbaren Bezug haben. Wie sehen das die Anderen? Gruß Hayo Gruß Hayo
Hayo W. schrieb: >> Die Y-Cursor beziehen sich schließlich auch immer auf das >> Signal und nicht auf den Bildschirm. > Nich ganz richtig, sie beziehen sich auf den Zerolevel, was Du wohl auch > meintest. Na ja, der Zerolevel liegt hoffentlich zumindest bei DC Messungen fest bei Signal=0V. Klar, bei AC muß man da unterscheiden. Mit den Zahlenwerten ist natürlich ein Argument und bei USTB bzw. in den schnelleren 1GSa/s-Bereichen ein ernstes. ;-) Einen festen Zeitbezug der Cursor zum Signal erreicht man jetzt IMHO nur, wenn man den Trigger mit "Pre Trigger / Left Edge" an den linken Bildschirmrand legt und dann weder die Regler für Horiz.Pos. noch PreTrigger anfaßt. Damit man den vollen Zeitbezug hat, ohne Zahlendarstellungprobleme heraufzubeschwören, würde es helfen, wenn die Lage des Fensters bezogen auf den Triggerzeitpunkt als Zahlenwert verfügbar wäre. Da das Fenster sowieso nicht beliebig fein bewegt wird, hält sich die erforderliche Stellenanzahl auch mehr in Grenzen. Rechts neben dem Browse-Balken wäre vielleicht Platz. Man könnte die Anzeige dann zusammen mit dem Balken aktivieren.
Will da jemand in Richtung LA? ;-) Drei Cursor auf der Zeitachse und alle Werte und Differenzen werden angezeigt. Grüße, Guido
Are you working a lot lately! The latest version is wonderful, thanks! Still some problems in the fft, wrapped crashes. Found small display problem in the new menu display/setup, the button (grid lines) have grafic malfunctions. Thanks again for the great work! Gyppe.
Angehängte Dateien:
-
PulsTrigger.png
4,4 KB
Hallo Jürgen bzw. Hayo, ich muß mal fragen, wie ihr den aktuelle Status bei der Puls-Trigger Funktion beurteilt? Ich hatte gerade mal mit der gezeigten Pulsfolge (100, 300, 200 µs) probiert und gehofft, dass das Scope sich dazu bewegen läßt, auf den rechten 200 µs Puls zu triggern, aber da will es so gar nicht ran. Ist das noch FW Baustelle oder nachhaltig im FGPA vermurkst? Gruß Rainer
Rainer W. schrieb: > Ist das noch FW Baustelle oder nachhaltig im FGPA vermurkst? Letzteres. Während Jürgen versucht aus dem vergurkten Design noch was rauszuholen, habe ich auch schon einen zusätzlichen Softwaretrigger im Hinterkopf, mit dem sich auch noch zusätzliche Funktionen wie Mustererkennung (CAN-Bus, I²C und Ähnliches) realisieren ließe. Allerdings ist natürlich grundsätzlich alles vorzuziehen, was man dem FPGA noch aus dem Kreuz leiern kann. @Guido Auch keine schlechte Idee. Aber ich möchte noch mal darauf hinweisen das es auch schon so ziemliche Performance Probleme gibt. Also alles was extra implementiert wird zieht die Framerate nach unten bzw. läßt die Drehregler träger werden. Gruß Hayo
Angehängte Dateien:
-
PulsTrigger2.png
5 KB
Rainer W. schrieb: > ... 200 µs Puls zu triggern, aber da will es so gar nicht ran. Korrektur: Es geht doch, allerdings mit mir völlig unverständlichen Zeitlimits. Solange die Summe der beiden Werte für die Länge des Pulstriggerfensters in dem gezeigten Fall gerade noch unterhalb von 287µs liegt, kriegt die Triggerfunktion den genau genommen 192µs langen Puls zu fassen. Es ist egal, ob man z.B. (<100, >187), (<140, >147) oder gar (>187, <100) einstellt. Einen komischen "Hystereseeffekt" gibt es, wenn man den ">"-Wert in der Nähe der Pulsdauer variiert, d.h. z.B. <50µs fest eingestellt hat und dann 1. von >180 auf >250 drehen. Bei >237 (Summe >287) erfolgt der Sprung vom 192 us Puls auf den längeren Puls. 2. von >250 auf >180 zurückdrehen. Bei >192 (d.h. bei der Pulslänge des kürzeren Pulses) springt der Trigger wieder auf den kürzeren Puls. Gruß Rainer p.s. die Pulsfolge stammt ganz einfach aus einem ATmega8 mit ein paar dahingefuschten delays.
Rainer W. schrieb: > Rainer W. schrieb: >> ... 200 µs Puls zu triggern, aber da will es so gar nicht ran. .... > Es geht doch, allerdings mit mir völlig unverständlichen Zeitlimits. > Solange die Summe der beiden Werte für die Länge des > Pulstriggerfensters in dem gezeigten Fall gerade noch unterhalb von > 287µs liegt, kriegt die Triggerfunktion den genau genommen 192µs langen > Puls zu fassen. Es ist egal, ob man z.B. (<100, >187), (<140, >147) oder > gar (>187, <100) einstellt. > Einen komischen "Hystereseeffekt" gibt es, wenn man den ">"-Wert in der > Nähe der Pulsdauer variiert, d.h. z.B. <50µs fest eingestellt hat und > dann > > 1. von >180 auf >250 drehen. > Bei >237 (Summe >287) erfolgt der Sprung vom 192 us Puls auf den > längeren Puls. > > 2. von >250 auf >180 zurückdrehen. > Bei >192 (d.h. bei der Pulslänge des kürzeren Pulses) springt der > Trigger wieder auf den kürzeren Puls. > Hallo, hier ist ja schon wieder was los...:-) @Rainer Ich hatte eigentlich PW soweit getestet, daß ausser "kleiner als" die Funktionen gut triggern. Allerdings sind diese teilweise sehr empfindlich auf den Triggerpegel, was sie aber auch sollen, wenn die Impulsflanken nicht so steil sind. Teilweise kam es mir vor, daß nur mit positivem Triggerpegel (nicht Impuls, das ist klar) getriggert wird. Aber insgesamt sichere Triggerung, wenn einmal der Wert gefunden ist. Problem war der Wiederanlauf, wenn man die Triggerbedingung einmal verstellt hat.(Ich arbeite meist im NORMAL Mode). Nach einem Hin- und Herschalten zwischen Edge und Pw springt es dann sofort wieder an. Das Weiterschalten des Pulse Width Modus <, >, >< durch mehrfaches Betätigen von PW erscheint mir hier störend. Sollten wir dies hier unterdrücken? In dem Zusammenhang hab ich den Vorschlag die Modeumschaltung AUTO/NORMAL/COMBI generell freizugeben! Gruß Jürgen
@Rainer Deine Messungen sind insofern ganz interessant, als im Welec-Handbuch (was ja recht gut mit einem Agilent-Handbuch übereinstimmt :-) noch andere Startzeiten (z.B.>16ns) angegeben sind und der Welec Programmierer hier falsch verstanden hat oder die Spezi für die Schrittweite im FPGA nochmal geändert wurde. Warum auch immer. Vielleicht sollten wir hier nochmal weiter systematisch forschen. Eine entsprechende Umsetzung zur Fütterung des FPGA im Vergleich mit den jetzigen Werten sollte dann machbar sein.
Angehängte Dateien:
-
Puls_gt.png
4,1 KB -
Puls_gt2.png
4,1 KB
@Hayo, folgender Bug tritt bei USTB noch auf: Die Messung läuft trotz STOP weiter. Es passiert, z.B. wenn im Mode Roll Forward die Messung vorm Pufferüberlauf mit STOP beendet wird und dann mit Quick Print Daten übertragen werden. Nach Ende der Übertragung wird weiter gesamplet, obwohl Run/Stop weiterhin rot ist. @Jürgen Jürgen schrieb: > Ich hatte eigentlich PW soweit getestet, daß ausser "kleiner als" die > Funktionen gut triggern. Ich habe jetzt nur mit satten digitalen Signalen getestet. "Kleiner als" tut bei mir auch gar nichts. "Größer als" funktioniert gut, nur finde ich das Verhalten etwas gewöhnungsbedürftig. Das Triggerereignis wird anscheinend in dem Moment ausgelöst, wo die Logik feststellt, dass ein Puls länger als der eingestellte ">"-Wert ist. Dadurch liegt der Triggerpunkt irgendwo auf dem Puls, genaugenommen um den ">"-Wert hinter der steigenden Flanke (Puls_gt). Irgendwie finde ich es unpraktisch, dass der Triggerpunkt nicht nur von der Pulslänge sondern auch vom eingestellten Limit abhängt. Beim zweiten Bild (Puls_gt2) verstehe ich allerdings nicht, warum der Trigger nicht schon auf den ersten Puls (380µs) erfolgt, der auch die Triggerbedingung erfüllt. Meine Pulspakete haben 50 ms Abstand, was eigentlich reichen sollte Bei "Zwischen ><" scheint mir nur das ">"-Limit richtig zu funktionieren, während das "<"-Limit eher verwirrend auf die Triggerlogik wirkt. Dort ist es im Gegensatz zum "größer als" Mode aber so, dass das Triggerevent am Ende vom Puls liegt, nicht mitten drauf. Das scheint mir vernünftiger. Jürgen schrieb: > Das Weiterschalten des Pulse Width Modus <, >, >< durch mehrfaches > Betätigen von PW erscheint mir hier störend. Sollten wir dies hier > unterdrücken? Ack > In dem Zusammenhang hab ich den Vorschlag die Modeumschaltung > AUTO/NORMAL/COMBI generell freizugeben! Ack Es wäre schon schön, wenn man den Pulsweitentrigger auch hinbekommt, insbesondere über das FPGA. Die Dinger sind (bisher) leider überhaupt nicht meine Ecke. Gruß Rainer
Rainer W. schrieb: > Es wäre schon schön, wenn man den Pulsweitentrigger auch hinbekommt, > insbesondere über das FPGA. Die Dinger sind (bisher) leider überhaupt > nicht meine Ecke. Hi Rainer, wir kommen hier und anderswo eventuell genau in diese Bereiche. Hab auf SVN nachgesehen und Du hast die HW-Version 1C9.0L. Ich habe die 8C7.0H auf meinem W2024A. Kann sein, daß u.a. beim Pulse Width Trigger schon hier eine Unterschied besteht und meine Version vielleicht schon weniger Fehler hat. Wir sollten dies schon beim Vergleich der Funktionen berücksichtigen! Dann hilft nur ein Update der FPGA-Software. Da wir nicht wissen, ob eine fortlaufende Version auch ohne Fehler ist, können wir nur vergleichen. Lt. SVN hat Kurt die "letzte" Version der FPGA-SW. Allerdings sehen wir, daß auch innerhalb gleicher Versionen unterschiedliche Prüfsummen existieren. Kann auch nur z.B. die Seriennummer sein?! Vielleicht haben andere User hier andere Ergebnisse? Gruß Jürgen
Angehängte Dateien:
-
Power_Measurement.jpeg
55 KB
Hallo allerseits, nach viel Fummelei habe ich jetzt auch endlich die Multiplikation hinbekommen, so dass sie endlich richtig skaliert und das Ergebnis richtig herum anzeigt. Anbei ein schönes Beispiel für eine Leistungsberechnung aus einer Spannungs und einer Stromkurve. Leider stimmen die Einheiten (V) noch nicht, hier muß es natürlich entweder V² oder W heißen. Zusätzlich konnte ich die Berechnung deutlich beschleunigen. @Rainer > folgender Bug tritt bei USTB noch auf: Die Messung läuft trotz STOP > weiter. Ok, danke -> ist in Arbeit. Gruß Hayo
@Hayo: Ist das die gewünschte Funktion um den Strom anzeigen zu können? Also mit Kanal 1 vor dem Shunt und mit Kanal 2 nach dem Shunt messen und die Differenz wird dann invertiert und verstärkt(Multipliziert) um den Strom anzeigen zu können?
Nicht ganz, eine Kurve ist die Spannung vor dem Widerstand gegen Masse und die andere ist der Spannungsabfall über den Widerstand (1 Ohm). Multipliziert ergibt das die Leistung die vom Widerstand verbraten wird über die Zeit. Man sieht schön wie die Leistung an den Nulldurchgängen ebenfalls gegen Null geht. Bei kapazitiver oder induktiver Last könnte man auch noch eine Phasenverschiebung sehen. Gruß Hayo
Hi Hayo, Hayo W. schrieb: > Anbei ein schönes Beispiel für eine Leistungsberechnung aus einer > Spannungs und einer Stromkurve. Du machst es ja spannend mit der neuen Version: Das hört sich wieder nach echten Riesenfortschritten an. Hier noch ein kleines Schönheits-"feature" im QM-Menü: In der BF4.6.C2 stimmt in den QM Submenüs für die Settings von Delay- bzw. Phasenmessung bei der Auswahl von Soure1 bzw. Source2 irgendetwas noch nicht. Nach einem Neustart/Reset sind, auch wenn am W2024 z.B. nur Ch. 1 und 2 aktiv sind, alle vier Kanäle als Source anwählbar. Wenn man dann z.B. Ch. 3 aktiviert und Ch. 2 deaktiviert (1, 3 aktiv), sind in der Liste 1, 3 und 4 auswählbar. Nach einem Default Setup benimmt sich die Auswahl anscheinend richtig. Gruß Rainer
Rainer W. schrieb: > Du machst es ja spannend mit der neuen Version: Das hört sich wieder > nach echten Riesenfortschritten an. Ja es wird endlich ein voll benutzbarer Math-Bereich sein. Allerdings ist es viel Klein und Fummelkram der da erledigt werden muß. > Hier noch ein kleines Schönheits-"feature" im QM-Menü: > In der BF4.6.C2 stimmt in den QM Submenüs für die Settings von Delay- > bzw. Phasenmessung bei der Auswahl von Soure1 bzw. Source2 irgendetwas > noch nicht. Hatte ich auch schon bemerkt. Die Logik, die die Verfügbaren Kanäle einträgt bzw. austrägt ist noch etwas buggy. Eine der Altlasten. Werde ich mal überarbeiten. Gruß Hayo
So, hat etwas länger gedauert weil es immer wieder kleine Hindernisse zu Überwinden gab. Jetzt arbeiten die Math-Funktionen recht brauchbar. Die Integration in QM und die Cursor-Logik war nicht so einfach. Viel Spaß Hayo
Vielen Dank für die neue Version, werde sie gleich drauf spielen. Aber warum willst du die Einheit bei Multiplikation in W oder VA ändern? VV ist imho einzig richtig, da du ja nicht wissen kannst, welche physikalische Größe durch die Spannung repräsentiert wird (muß ja nicht der Strom sein). Viele Grüße, Egberto
Ja schon richtig, aber optimal wäre doch die Möglichkeit das einzustellen, oder? Ich denk mal drüber nach. Gruß Hayo
also ne Strommessfunktion wäre schon richtig geil, evtl. mit Einstellung des Shunts 0,01 Ohm; 0,1 Ohm; 1 Ohm;... um den Verstärkungsfaktor zu wählen.
Shunt ist dann aber zu kurz gedacht...ein beliebiger Scalierungsfaktor (float) wäre optimal. Und die Angezeigt Buchstabenkombination müsste auch frei einstellbar sein. Aber das ist alles absoluter Luxus und nicht unbedingt nötig - Fehlerbehebung hat doch Vorrang. Und ein Blick Richtung LA wäre auch toll (mit i2c, rs232,SPI Interpreter)..... Viele Grüße, Egberto
Egberto schrieb: > Aber das ist alles absoluter Luxus und nicht unbedingt nötig - > Fehlerbehebung hat doch Vorrang. Schon richtig, aber das mache ich meistens nebenbei wenn ich durch die Tiefen des Codes pflüge... Momentan gehen mir allerlei weitere Math Funktionen durch den Kopf. So wie Ableitung und Integral, angeregt durch das Agilent-Handbuch. Auch bei der FFT habe ich immer noch einige Ideen nicht umgesetzt. Aber nach und nach arbeite ich das alles ab. Gruß Hayo
Puh, alles in allem ist das ganze mittlerweile sehr undurchsichtig und wenn man nicht stets am Ball geblieben ist - wie in meinem Fall - weiss man mittlerweile nicht einmal mehr, ob die aktuelle Firmware 1.2.BF.4.7.zip noch kompatibel zu einem voellig unverbastelten Geraet ist. Ist sie das? Ansonsten vielen Dank an Hayo und alle beteiligten fuer die hervorragende Arbeit an der Firmware :) Gruessle André
1000! - neuer Thread? (ich kurble mir auf dem iPad jetzt schon nen Wolf beim scrollen)
Hallo, bei der Suche nach dem aktuellem Stand, bin ich auf folgenden Bericht gestoßen: http://www.elektronikpraxis.vogel.de/themen/hardwareentwicklung/messtechnik/labormesstechnik/articles/37742/ Viel Spaß beim lesen.. ;-) Liebe Grüße Philipp
Hayo W. schrieb: >> Aber das ist alles absoluter Luxus und nicht unbedingt nötig - >> Fehlerbehebung hat doch Vorrang. > > Schon richtig, aber das mache ich meistens nebenbei wenn ich durch die > Tiefen des Codes pflüge... > > Momentan gehen mir allerlei weitere Math Funktionen durch den Kopf. So Und warum ist "External Trig" jetzt erstmal gesperrt? Gruß Jürgen
Offtopic: 1,6 Millionen Euro in die Entwicklung für ein Gerät, dass der Hersteller jetzt selbst bei eBay für 100 bis 200€ verschleudert? Irgendwas ist da aber kräftig schief gegangen - vielleicht hätte man sich gleich auf ein gutes, aber für den Hobby-Bastler bezahlbares Hardware-Design beschränken sollen und die Software von Anfang an durch die Community entwickeln lassen sollen - OpenSource kann sich für einen Hersteller lohnen. Ontopic: Hab die 4.7 gerade geflasht - läuft soweit ganz gut, konnte beim fröhlich durch Menüs springen nur eine Sache feststellen: Bei Source sowohl in Edge als auch Pulse Width kann ich Kanal 1, 2, 3 und External auswählen (hab das W2022A), sobald Math aktiviert ist - ist Math aus hab ich nur Kanal 1, 2 und External. Hier wird Math also fälschlicherweise als Kanal 3 bezeichnet, sollte ja besser wie im QM und Cursor-Menü auch Math heißen. Schönen Gruß und wie immer: Danke für deine gute Arbeit! :)
Egberto schrieb: > 1000! - neuer Thread? (ich kurble mir auf dem iPad jetzt schon nen Wolf > beim scrollen) Wenn du dich anmeldest, dürfte das wegen der Seitenaufteilung locker eine Faktor 5 und mehr sparen.
Andre schrieb: > Puh, alles in allem ist das ganze mittlerweile sehr undurchsichtig und > wenn man nicht stets am Ball geblieben ist - wie in meinem Fall - weiss > man mittlerweile nicht einmal mehr, ob die aktuelle Firmware > 1.2.BF.4.7.zip noch kompatibel zu einem voellig unverbastelten Geraet > ist. > > Ist sie das? Hallo Andre, ja sie ist es! Ich entwickle die Firmware grundsätzlich auf einem unverbastelten W2014A. Alle Extras für die Unterstützung alternativer Hardware ist grundsätzlich optional und wird entweder von mir auf meinem "getunten" W2022A entwickelt oder von einigen hier im Forum die mir dann das Coding freundlicherweise zukommen lassen. @Jürgen & Sebastian > Bei Source sowohl in Edge als auch Pulse Width kann ich Kanal 1, 2, 3 > und External auswählen (hab das W2022A), > Und warum ist "External Trig" jetzt erstmal gesperrt? Normalerweise prüfe ich alles was mit den Kanälen zu tun hat noch auf dem W2022A. Hier scheint mir aber was durchgerutscht zu sein. In Display::Init() bzw. in MenuInit() werden die Menüs extra für die Zweikanalgeräte angepasst. Da scheint ein kleiner Fehler drin zu sein. Ich stelle natürlich möglichst schnell eine Korrektur zur Verfügung. Gruß Hayo
>Wenn du dich anmeldest, dürfte das wegen der Seitenaufteilung locker >eine Faktor 5 und mehr sparen. Ach ja, stimmt, hatte ich verdrängt... aber Zeit für Teil 5 ist es aber wohl trotzdem. Viele Grüße, egberto
Jürgen schrieb: > Und warum ist "External Trig" jetzt erstmal gesperrt? Hallo Jürgen, ich wollte das gerade fixen, stelle aber fest das bei mir alles richtig ist und der Eintrag nicht gesperrt ist. Ist das bei Dir noch aktuell? Gruß Hayo
Jürgen schrieb: > Und warum ist "External Trig" jetzt erstmal gesperrt? Bei mir am W2024 ist es im Menü "Edge" freigegeben und in "Puls Width" gesperrt. Gruß Rainer
Ja, das ist korrekt. Ich bin der Meinung dass die Pulsweitentriggerung für Extern nicht funktioniert. Täusche ich mich da? Wenn ja dann gebe ich das natürlich wieder frei. @all Allerdings habe ich gerade festgestellt, dass anscheinend der Math-Channel bei den 2-Kanalgeräten zwar ausgewählt werden kann, aber keine Auswirkungen zeigt bzw. versucht den nicht vorhandenen Kanal 3 zu benutzen. Diese immer wieder auftauchenden Altlasten machen mich echt fertig. Es gibt aber auch keine Ecke die einfach mal funktioniert. Ich werde also die Popupsteuerung mal überarbeiten und das vernünftig machen. Liebe Besitzer eines 2 Kanal Gerätes - nicht böse sein, Ihr bekommt natürlich möglichst schnell Abhilfe. Dear owner of a 2 channel WELEC DSO please don't worry about not working math channel as source for QM and cursors. Correction will come soon. Gruß Hayo
Hayo W. schrieb: >> Und warum ist "External Trig" jetzt erstmal gesperrt? > Hallo Jürgen, > > ich wollte das gerade fixen, stelle aber fest das bei mir alles richtig > ist und der Eintrag nicht gesperrt ist. Ist das bei Dir noch aktuell? > > Gruß Hayo > Das gibt es doch nicht! Jetzt ist es bei Edge freigegeben (W2024A). Ich bin mir ziemlich sicher, daß es gestern beim F2-Button war, d.h. bei Edge. Sorry, vielleicht doch schon das Alter :-( Jedenfalls funktioniert es jetzt. Gruß Jürgen
Hallo Hayo, na also, es scheint bei mir doch noch alles i.O. :-O Nach Default Setup ist bei Edge External gesperrt. Fragt nicht, wie man das dann freigeben kann...
Stimmt, -> wird korrigiert. Bei Pulsewidth lasse ich es aber gesperrt, oder? Gruß Hayo
Hayo W. schrieb: > Bei Pulsewidth lasse ich es aber gesperrt, oder? > > Gruß Hayo Da fehlt meiner Ansicht nach noch ein Stück Programm. Ich kann es auch schlecht testen, wenn ich übers Menü nicht dorthin komme... Vielleicht kannst Du es erstmal freigeben und wir sehen dann weiter? Gruß Jürgen
Jürgen schrieb: > Nach Default Setup ist bei Edge External gesperrt. Fragt nicht, wie man > das dann freigeben kann... Mit Reset/Neustart ;-) Gruß Rainer
Ich habe inzwischen die ganze Popuplogik überarbeitet. Es ist jetzt möglich nicht verfügbare Einträge einfach auszublenden. Dadurch wird die Initialisierung viel einfacher und das Problem mit dem Math-Channel hat sich auch erledigt genau wie die ausgegrauten Einträge im Triggersource Menü. Gruß Hayo
So, diesmal gibt es keine weitere Kompilation, sondern gleich eine neue Version. Ich habe die letzten Tage alles an Popuplogik und Kanalwechsellogik durchforstet was da so drinsteckt und habe etliches neu geschrieben bzw. erweitert oder gelöscht. Da fehlte es an allen Ecken und Enden. Ich hatte bei meinen Tests so den Eindruck als ob das jetzt ganz rund läuft. Ihr seid natürlich aufgefordert das zu überprüfen. Besonderes Augenmerk bitte auf den QM-Slotwechsel legen. Da die Tests recht Zeitaufwändig sind konnte ich nur die wichtigsten Kombinationen testen. Die Sollfunktion ist: Wenn eine neue Messung angefordert wird (mit dem Measure Button), dann wird diese auf den nächsten freien Slot gelegt. Sind alle Slots belegt, dann werden die Messungen von rechts nach links weitergeschoben (first in first out). Die neue Messung bekommt dann den neu freigewordenen Slot zugewiesen. Wird jetzt ein Kanal abgeschaltet der bei einer Messung als Sourcekanal dient, dann muß diese Messung beendet werden, der Slot freigegeben werden und alle restlichen Messungen linksbündig angeordnet werden. Das Ganze ist nicht so ganz ohne, da alle Parameter der Messungen an den neuen Slot übergeben werden müssen. Das ist besonders bei Delay und Phase etwas aufwändiger, da hier eigene Sourcekanäle verwendet werden. Bei aktivem Math-Channel als Source wird bei Abschalten von Kanal 1 oder 2 der Math-Channel ebenfalls deaktiviert. Es müssen dann also alle Slots mit Sourcen des abgeschalteten Kanals und des Math-Channels freigegeben werden. Viel Spaß beim Testen, ich freue mich auf die Rückmeldungen. Gruß Hayo
Angehängte Dateien:
-
USTB-Buffer-8KB.png
4,6 KB
moin moin, Hayo Ich habe deine 4.8er gerade mal aufgespielt und mal den USTB-Modus mit einem ca. 100mHz Sinus gefüttert. Wenn der 8KB Buffer voll ist, wird dieser vor dem nächsten Messzyklus dann nicht geleert? Auf dem Shot war der Buffer voll, hat von vorne begonnen und überschreibt die vorherige Messung, ist das Absicht? Zur Erläuterung: Die Spitze auf dem Shot geht von der neuen auf die alte Messung, also überschreibt diese. Gruß Michael
Sieht doch gut aus? Es sollen doch immer möglichst viele Daten angezeigt werden, deshalb machen das eigentlich alle Speicheroszilloskope so. Grüße, Guido
i bin der Meinung die Vertikale Linie duerfte nicht sein beim Uebergang, aber ansonsten OK vlG Charly
Alles ist richtig und gewollt so! Habt Ihr woanders keine Fehler gefunden? ;-) Gruß Hayo
Angehängte Dateien:
-
USTB-Dreieck-Buffer-8KB.png
4,8 KB
Ok, dann ist ja gut! Hier habe ich noch ein schickes Dreieck. Wenn der Singleshot betätigt wird, ist dann der Speicher leer und das Ganze fängt von vorne an... Das Messen im QM-Menu läuft jetzt auch etwas flüssiger oder bilde ich mir das nur ein? @Hayo, Ich sollte dich noch an das vierte Messfenster im QM-Menu erinnern... :-) Gruß Michael
Ja das vierte Messfenster. Ich hatte das nicht vergessen, im Gegenteil, ich hatte mir schon Gedanken gemacht ob und wie man das implementieren könnte. Ich habe zum Ergebnis nur noch nichts gesagt, um den Aufschrei der Entäuschung zu vermeiden. ;-) Also - folgende Gründe die dagegegen sprechen: - einige der Messausgaben sind so breit, dass schlichtweg nicht vier nebeneinander passen. Nur einige der Ausgaben würden da reinpassen. - Der zusätzliche Verwaltungs und Programmieraufwand wäre nicht unerheblich. - Last but not least - die Rechenleistung unserer kleinen CPU ist mit drei gleichzeitigen Messungen schon so vollauf beschäftigt, dass eine weitere Messung den Ablauf fast ganz zum Stillstand bringen würde. I'm sorry Hayo
moin, wenn dem so ist, dann lassen wir das wohl lieber sonst würden wir von der Performance her, ja rückwärts gehen! Das soll nicht sein und wir werden's wohl überleben. Gruß Michael
Hallo, kennt Ihr die Anschlusseinstellungen ? Ich bekomme keine Verbindung mit dem Updateprogramm von Welec. Es ist allerdings ein RS232-USB-Adapter vor dem Notebook eingesteckt. Verschiedene Baudraten und Einstellungen brachten keinen Erfolg, bleibt wohl nur noch am PC mit RS232-Schnittstelle auszuprobieren ? Danke Gruss Rolf
Ich vergass: es ist Windows7 auf dem Notebook.
teste mal ob du im Terminal Programm mit 115200 was empfangst beim einschalten des Oszi vlG Charly ps. der original updater iss nix, es gibt hier bessere
Nimm den hier! Anleitung und Anschlusseinstellungen gibt's hier: Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil4)" Gruß Michael
Die Einstellungen findest Du in der Datei 'How to use a terminal' im Verzeichnis 'doc'. Hier noch mal in Kurzform: Port: hier den benutzten seriellen Port eingeben, meistens COM1 Baud Rate: 115200 Data: 8 bit Parity: None Stop: 1 bit Flow control: None Auch bekannt unter 8N1 115200. Hast Du den Updater von Markus benutzt? Die beste Lösung ist es das Perlskript zu benutzen. Dazu mußt Du ActivePerl installieren. Anleitung auch im 'doc' Verzeichnis Datei 'How to upload via shell script.txt' Ansonsten hatte noch ein anderer W20xx Besitzer hier Probleme mit einem RS232/USB Adapter, ich glaube er hat ein anderes Kabel mit gekreuzten Leitungen benutzt. Am besten erstmal wie weiter oben empfohlen testen ob mit dem Terminalprogram etwas empfangen wird. Wenn alles funktioniert gibt das DSO beim Hochfahren über die RS232 einige Meldungen aus und nimmt dann Tastaturbefehle entgegen. Wenn das funktioniert, dann geht auch das Update mit dem Perlskript. Wenn Du weitere Fragen hast, nur keine Hemmungen, wir helfen da Schritt für Schritt weiter. Gruß Hayo
der Updater den ich gepostet habe, funzt wunderbar! Wenn er jetzt noch Aktive-Perl installieren soll, sitzt er bis morgen früh, schätze ich. Ich benutze auch einen RS232 Adapter(Hama). Es gibt da keine Probleme, egal ob Notebook oder Tower, die Übertragung dauert nur ein wenig länger. Wenn die Anschlusseinstellungen am Rechner(Comport) geändert werden, muß man den "meistens" neu hochfahren, damit die Einstellungen wirksam werden. @Hayo wer hat denn da ein Kabel gekreuzt??? Gruß Michael
Ich meine ein anderer Michael - Michael W. oder so war das glaube ich. Da funktionierte das Ganze nur mit einem anderen Zusatzkabel. Ist aber wohl eher eine Ausnahme. Bei mir läuft das Ganze sowohl am PC-Port als auch am NoName USB-RS232-Adapter am Notebook problemlos. Die guten alten echten RS232 Ports... Tja auf manches kann man eben doch nicht verzichten. Gruß Hayo
Ach, jetzt hätte ich es fast vergessen: Ich hab heute mit einem alten Studienkollegen gesprochen und Ihm von unserem Projekt erzählt. Ergebnis: Er interessiert sich für ein 4 Kanalgerät von WELEC. Wer also sein Gerät verscherbeln will oder bei Ibähi ein Angot sieht bitte bei mir melden. Hayo
Angehängte Dateien:
-
CORRUPTED_1.jpg
45 KB -
CORRUPTED_2.jpg
51 KB -
CORRUPTED_3.jpg
50 KB -
DIMENSION_div_fN.jpg
40 KB -
DIMENSION_div_fN.jpg
41 KB -
DIMENSION_fN_div.jpg
41 KB -
DIMENSION_fN_div.jpg
40 KB -
FFT_Grid_Level.jpg
40 KB -
ZERO_in__QM_.jpg
44 KB -
ZERO_in_QM.jpg
45 KB -
Factory.jpg
39 KB -
High_Freq.jpg
41 KB -
Test_1.jpg
39 KB -
Test_2.jpg
39 KB -
Test_3.jpg
41 KB -
Test_4.jpg
41 KB -
Test_5.jpg
39 KB -
Trg_Lev_Low.jpg
44 KB -
Trig_Lev_High.jpg
46 KB
Hi Hayo, Jürgen, and guys all! I am back after a long time. I am in a hurry now, but I want to say some things. Necessarily I will be short. ;-) First I have to thanks all You and especially Hayo for the great work You are doing on Welec's oscilloscopes: no words, RESPECT! I installed the latest firmware release 1.2.BF.4.8 and by the way I noticed some things who I report follow here in order to improve them: mine are not critical to the work done but only for knowledge. Again for knowledge, I specify that all screenshots were made with a W2012A. @Hayo When QM is on, changing Time Base sometimes get corruption on the screen who can be removed by setting to default or performing reset sequence or again by switch between measure's screen to the informations screen: please look at the screenhot CORRUPTED_1.jpg, CORRUPTED_2.jpg, and CORRUPTED_3.jpg. I know the FFT have to be finished in order to improve it, but seems to me the division's value for either df, div and fN are wrong: please look at the screenshot DIMENSION div fN.jpg, DIMENSION fN div.jpg, DIMENSION div_fN.jpg and DIMENSION fN_div.jpg. Again for the FFT when You switch to Display in order to change graticule's dimension, then Grid up to 100% without intensity change and turning the knob the grid's intensity increase but never is possible to set it down, it is stuck until perform default setting: please look at screenshot FFT Grid Level.jpg. About the Quick Measure I noticed when some values are below certain levels then zero is showed: is not possible to increase recognized level in order to show a more low level? For some example please look at the screenshot ZERO in QM.jpg and ZERO in QM_.jpg. About the Hardware ADC Setup, I tried some settings because the behavior of both mine either W2022A and W2012A prevents to use Hig Freq's setting. So right choice is a bit difficult to make for me. Please refer to the screenshot Factory.jpg, High Freq.jpg, Test 1.jpg, Test 2.jpg, Test 3.jpg, Test 4.jpg and Test 5.jpg. Is not there a precise way to make a choice? How can I know if an unknown signal actually appears on screen as in real life or only for the wrong setting of the ADC Setup? Can I get trust or I must to hope it is a right setting? @Hayo, Jürgen As I understand You are trying to further improve either the internal trigger and external, I repeat some things I already wrote. Seems when the trigger's threshold is low the waveform is moving and the signal's amplitude is a bit more low compared to when the trigger's treshold itself is high and so the signal's amplitude becomes it itself more high and the waveform is more steady on the screen. Please refer to my former post and here screenshot Trig Lev High.jpg and Trg Lev Low.jpg. @All Is there somebody noted that signal amplitude seems to depend on the trigger treshold? Is there somebody noted that when the trigger's threshold is low amplitude waveforms on the screen are dancing while when it is much higher the waveforms are much more steady on the screen? @Jürgen Can You kindly explain further about the C37 matter? What are the benefits? And contraindications? Seems to me the modification need for a software support, is not so? Thanks in advance Jürgen. Perhaps the C37 modification together with the change of line and termination resistance for the MAX121 are the minimun to do on the original hardware in order to improve the performances if the Piggyback board is not installed. Of course firmware is much important too. Hayo W. schrieb: >- Last but not least - die Rechenleistung unserer kleinen CPU ist mit >drei gleichzeitigen Messungen schon so vollauf beschäftigt, dass eine >weitere Messung den Ablauf fast ganz zum Stillstand bringen würde. I connect here in order to make some considerations. Of course what You say is right, fast response it is fundamental otherwise the device becomes unusable and useless. In the present and in the past all yours efforts were aimed at improving the device without make it unusable. It is can say the goal was reached, infact now the Welec DSO are much more similar to Agilent and other blasonate DSO's brands and I do not only refering at the features but to the performances too. So there was, there is and there will, I hope, a great improve on either estetic and features: I like very much new configurable screen setting as well some killer applications as Overlay, single shot configuration, new mathematical functions and many others. Said this, I think perhaps > 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. it do not kill ours DSO, is not so? I know, this and other things are already in the wish list, but since there was also talk of aesthetic improvements I wanted to remember also this. About the wish list: What about the sin(X/X) interpolation implementation? And centre and span features for the FFT? Now I must to run away, so thank You to all You. Vielen Dank!!! Gruß Luc
Hayo W. schrieb: > Ich meine ein anderer Michael - Michael W. oder so war das glaube ich. > Da funktionierte das Ganze nur mit einem anderen Zusatzkabel. > > Ist aber wohl eher eine Ausnahme. Bei mir läuft das Ganze sowohl am > PC-Port als auch am NoName USB-RS232-Adapter am Notebook problemlos. > > Die guten alten echten RS232 Ports... > > Tja auf manches kann man eben doch nicht verzichten. > > Gruß Hayo Hi, hat sich inzwischen erledigt mit dem Interface: Ich hab's nochmal ohne Zusatzkabel probiert und dann ging's doch. Weiss auch nicht, woran's damals gelegen hat... Zwischenzeitlich hatte ich tatsächlich überlegt, meinen 4-Kanäler zu verjubeln aber dank der wieder erstarkendne Entwicklung bin ich wieder dabei. Inzwischen habe ich noch schöne Aluknöppe gemacht (gibt'n schönen Beitrag im Hardwarethread) und mit der Firmware ist's wirklich gut brauchbar. Leider sind mir die Lötereien für die Huckepackplatinchen zu schwierig, da trau' ich mich nicht so ran, olles Vogelfutter... :-/ Michel
> Inzwischen habe ich noch schöne Aluknöppe gemacht (gibt'n schönen > Beitrag im Hardwarethread) und... War der Beitrag von mir? Zeig' mal deine Knöppe, dann halt im HW-Thread Gruß Michael
Luc schrieb: > Hi Hayo, Jürgen, and guys all! Hi Luc, welcome back! > Necessarily I will be short. ;-) Yes, I know, You are allways short ;-) > @Hayo > When QM is on, changing Time Base sometimes get corruption on the screen Yes I noticed this too and I'm searching for the reason. I hope I can fix it soon. > I know the FFT have to be finished in order to improve it, but seems to > me the division's value for either df, div and fN are wrong: I guess the values are correct. For example: Sample Rate 1GSa/s -> fN (span) = Sample Rate/2 = 500MHz Points = 512 -> Spectrum = 512/2 = 256. Grid width is 512 -> one frequency line is 2 pixels wide. div = fN/10 = 50MHz = 50 Pixel wide. df = div/25 = 2MHz (one line is 2 pixel wide at 512 point FFT) am I right? > > Again for the FFT when You switch to Display in order to change > graticule's dimension... Yes You are right, there is a bug. I'm working on it. Thanks. > About the Quick Measure I noticed when some values are below certain > levels then zero is showed: Hmmm, difficult. I think it is because of the interpolation. I will check if it can be improved. > About the Hardware ADC Setup, I tried some settings because the behavior > of both mine either W2022A and W2012A prevents to use Hig Freq's... Yes this is a Problem. The adjustments with the best HF-behaviour have a problem with spikes which seem to be generated by wrong FPGA timing. So I called them Test 1 and Test 2 because they seem to be more experimental, but may be helpful at very high frequencies. On normal purposes the factory setting should work ok. > @Hayo, Jürgen > Seems when the trigger's threshold is low the waveform is moving correct, trigger is more stable when the level is not zero but a little bit higher. The wave form differs because of the zoom effect of some timebases. at 50ns/div the zoomfactor is 1 and it shouldn't occur. > About the wish list: > What about the sin(X/X) interpolation implementation? I investigated in this theme but it is not trivial. Unfortunately I didn't find a good implemention example (as code), but only theoretic descriptions. I'm working on it... > And centre and span features for the FFT? Yes this is also on my list and also a 2048 point FFT if possible with the CPU performance. Thanks for Your short report, Hayo
Luc schrieb: Hi Luc, > @Hayo, Jürgen > As I understand You are trying to further improve either the internal > trigger and external, I repeat some things I already wrote. > Seems when the trigger's threshold is low the waveform is moving and the > signal's amplitude is a bit more low compared to when the trigger's > treshold itself is high and so the signal's amplitude becomes it itself > more high and the waveform is more steady on the screen. Yes, this is the same on internal and external trigger. When the trigger's treshold is high the waveform is more steady on the screen. On the internal trigger the trigger logic sees more noise and this is why you have more trigger events on a zero trigger level. The waveform is moving on the screen. >@Jürgen >Can You kindly explain further about the C37 matter? >What are the benefits? >And contraindications? >Seems to me the modification need for a software support, is not so? >Thanks in advance Jürgen. On external trigger this new capacitor to C37 reduce the amplitude of the reference voltage of the external trigger comparator U6, because this reference voltage is build by a PWM signal and a low pass filter. So there is with this additional C a more stable timing and the waveforms are not so much "dancing". There are no con's. You can use this hardware modifcation also with the original firmware 1.4. Regards, Jürgen
Hi Hayo and guys all! Hayo W. schrieb: >Yes, I know, You are allways short ;-) Oh man, as usual You are right! :-) You certainly know your chickens! ;-) Hayo W. schrieb: >> When QM is on, changing Time Base sometimes get corruption on the screen >Yes I noticed this too and I'm searching for the reason. I hope I can >fix it soon. For sure you will succeed, I will bet on it! Hayo W. schrieb: >> I know the FFT have to be finished in order to improve it, but seems to >> me the division's value for either df, div and fN are wrong: >I guess the values are correct. For example: >Sample Rate 1GSa/s -> fN (span) = Sample Rate/2 = 500MHz >Points = 512 -> Spectrum = 512/2 = 256. Grid width is 512 -> one >frequency line is 2 pixels wide. >div = fN/10 = 50MHz = 50 Pixel wide. >df = div/25 = 2MHz (one line is 2 pixel wide at 512 point FFT) >am I right? Yes of course I think You are right, but I was referring to numerical values in the lateral table and not to the physical size of the graticule. Looking at screenshot DIMENSION_div_fN.jpg with 1Gsa/s and 512pts it is: df=1.95MHz div=50.02MHz fN=500.24MHz And further looking at screenshot DIMENSION_div_fN.jpg with 500Ksa/s and 512pts it is: div=977.5Hz div=25.01KHz fN=250.12MHz Seems to me that the accounts do not come back, is not so? Maybe I am wrong, otherwise sorry, I do not understand. Hayo W. schrieb: >> Again for the FFT when You switch to Display in order to change >> graticule's dimension... >Yes You are right, there is a bug. I working on it. Thanks. Thank You a lot Hayo! Hayo W. schrieb: >> About the Quick Measure I noticed when some values are below certain >> levels then zero is showed: >Hmmm, difficult. I think it is because of the interpolation. I will >check if it can be improved. You knew the job was difficult when you took it, Hayo! ;-) Ok, no kidding anymore, I know it is not simple because in this case it is to push the measure under the nS value, pratically in the pS's field: really not easy! Hayo W. schrieb: >> About the Hardware ADC Setup, I tried some settings because the behavior >> of both mine either W2022A and W2012A prevents to use Hig Freq's... >Yes this is a Problem. The adjustments with the best HF-behaviour have a >problem with spikes which seem to be generated by wrong FPGA timing. So >I called them Test 1 and Test 2 because they seem to be more >experimental, but may be helpful at very high frequencies. On normal >purposes the factory setting should work ok. Yes, thank You for the explanation, Hayo! The real problem is some setting are ok with waveforms as for example the inner probe compensation's generator but are worst with other kind of waveforms as for example pulses. Not easy set it correctly because could happen with a not suitable waveform. And yes, Factory setting work well apart some spikes problem in some circumstance, but upon a time with a former firmware release High Freq setting was the better choise for all the situations. I am sure one of the setting it is the right answer also this time, I will pursue it! Hayo W. schrieb: >> Seems when the trigger's threshold is low the waveform is moving >correct, trigger is more stable when the level is not zero but a little >bit higher. The wave form differs because of the zoom effect of some >timebases. at 50ns/div the zoomfactor is 1 and it shouldn't occur. Thank You very much also for this explanation, Hayo! I guess this even affects the amplitude. Hayo W. schrieb: >> About the wish list: >> What about the sin(X/X) interpolation implementation? >I investigated in this theme but it is not trivial. Unfortunately I >didn't find a good implemention example (as code), but only theoretic >discriptions. I'm working on it... Hayo, this is really an amazing news, thanks! I guess this implementation can improve a lot the shape of the waveforms shown on the screen. Hayo W. schrieb: >> And centre and span features for the FFT? >Yes this is also on my list and also a 2048 point FFT if possible with >the CPU performance. Oh boys, another great amazing news, thank You Hayo, You are really the best one: RESPECT! Hayo W. schrieb: >Thanks for Your short report, Ok, ok, actually it is not so short! ;-) Instead, thanks to You Hayo for the great patience and kindness and free time You provided generously to us!!! RESPECT!!!!!!! Vielen Dank!!!!!!! Mit freundlichen Grüßen, Luc
Hi Jürgen and guys all! Jürgen schrieb: >> Seems when the trigger's threshold is low the waveform is moving and the >> signal's amplitude is a bit more low compared to when the trigger's >> treshold itself is high and so the signal's amplitude becomes it itself >> more high and the waveform is more steady on the screen. > >Yes, this is the same on internal and external trigger. When the >trigger's treshold is high the waveform is more steady on the screen. On >the internal trigger the trigger logic sees more noise and this is why >you have more trigger events on a zero trigger level. The waveform is >moving on the screen. Thank You very much for the explanation, Jürgen: RESPECT! Jürgen schrieb: >>Can You kindly explain further about the C37 matter? > >On external trigger this new capacitor to C37 reduce the amplitude of >the reference voltage of the external trigger comparator U6, because >this reference voltage is build by a PWM signal and a low pass filter. >So there is with this additional C a more stable timing and the >waveforms are not so much "dancing". >There are no con's. You can use this hardware modifcation also with the >original firmware 1.4. Very well Jürgen, I thank You a lot for these useful informations: RESPECT!!!!!!! For me, and I guess for somebody else also, this is really a very interesting thing. Going ahead, in relation to what You wrote this means there are other capacitors can be modified putting in parallel of them more capacitors in order to get a better behavior of the inner trigger, due C37 improve only the external one if I am no wrong. So, which are the capacitors and what is the final capacitance's value? Jürgen, thank You very much for the kind reply: RESPECT! Vielen Dank!!!!!!! Mit freundlichen Grüßen, Luc
Luc schrieb: > Hayo W. schrieb: >>Yes, I know, You are allways short ;-) > Oh man, as usual You are right! :-) > You certainly know your chickens! ;-) rofl <ot> Ok, I learned: 3 pages and about 20 screenshots are defined as "short" (for Luc). For all the others: 3 lines and max 2 shots, please. ;-) </ot> Have a nice sunday, Rainer
Hayo W. schrieb: >>> About the Hardware ADC Setup, I tried some settings because >I am sure one of the setting it is the right answer also this time, I >will pursue it! The Test 1 is the old High Frequency setting. I only changed the name! The actual High Frequency Setting does not work so good as the old one but doesn't has spikes. Regards Hayo
Hi, here some fixes. > Again for the FFT when You switch to Display in order to change > graticule's dimension, then Grid up to 100% without intensity change and > turning the knob the grid's intensity increase but never is possible to > set it down, it is stuck until perform default setting: please look at > screenshot FFT Grid Level.jpg. Solved > About the Quick Measure I noticed when some values are below certain > levels then zero is showed: is not possible to increase recognized level > in order to show a more low level? Solved -> measuring is now possible with pico second resolution. - Holdoff now is switched off at pulse width triggering Hayo
moin moin Hajo & Co. wenn du die Y pos auf die 2. unterste Linie stellst und dann utility/calib. offset ausfuerst und dann mit Y pos. fast ganz nach oben wanderst verdoppelt (ca.) sich das dargestellte Rauschen ;( ungekehrt ist der efekt aber ebebso (kalibrate ganz oben). vielleicht kann das mal noch jemand testen ob das generell oder nur bei meinem so ist vlG Charly
Hi Charly, > wenn du die Y pos auf die 2. unterste Linie stellst > und dann utility/calib. offset ausfuerst und dann mit > Y pos. fast ganz nach oben wanderst verdoppelt (ca.) > sich das dargestellte Rauschen ;( Stimmt, das war schon immer ein kleines Problem, also auch bei meinem Welec (2022A)! > ungekehrt ist der efekt aber ebebso (kalibrate ganz > oben). Stimmt auch! Das kommmt daher, das dann die Nulllinie nicht hinterher kommt. Ist die Linie ganz unten, sitzt Diese ca. 2 Pixel unter Null, umgekehrt dann 2 Pixel darüber und das Rauschen nimmt ebenfalls zu, weil dann die Kalibrierung für oben u. unten nicht mehr stimmt. > vielleicht kann das mal noch jemand testen ob das > generell oder nur bei meinem so ist und nein, das ist nicht nur bei dir so! Das war aber in der Vergangenheit schon mal Thema, frag' mich jetzt blos nicht, wo das mal war... > vlG > Charly Gruß Michael
Stimmt bei Euch die Nulllinie nicht? Muß ich da die Skalierung noch anpassen? Ich dachte eigentlich das passt ganz gut. Habt Ihr die Eingangswiderstände modifiziert oder so? Gruß Hayo
Hi Hayo, Rainer W., charly, Michael D., and guys all! Hayo W. schrieb: >Solved Hayo, thank You very much for the fix: RESPECT! Hayo W. schrieb: >Solved -> measuring is now possible with pico second resolution. Oh boys, this is really incredible and make me very happy! Hayo You are the best one, no words: RESPECT!!!!!!! I must to say the Welec oscilloscopes are a lot improved and now their are can compete with other blasonate DSO's brands on the market. Today I finally managed to complete some measures with the sole help of my W2022A without necessarily having to use other tools. All this thanks to your great work Hayo and all who are involved in the Welec project, so I thank all You again: RESPECT!!!!!!! Hayo W. schrieb: >The Test 1 is the old High Frequency setting. I only changed the name! >The actual High Frequency Setting does not work so good as the old one >but doesn't has spikes. Great news, thank You very, very much Hayo! Also this information aid me very much, now I know what is the better choice even without necessarily take a look at all the options. This is amazing for me also because I have not all the necessary strumentation in order to investigate the matter. Perhaps is not it better return the name? Anyway thank You again Hayo: RESPECT! @Rainer W. Selbst wenn ich zu spät Ich erwidere den schönen Sonntag. :-) I hope to have been understood. :-) @charly, Michael D. Sorry but I do not understand very well. I even have a W2022A and maybe I can check it, so please can You explain me what is the problem? Thanks! Vielen Dank!!!!!!! Mit freundlichen Grüßen, Luc
Hi Hayo and guys all! @Hayo Maybe I found a little bug in a 1.2.BF.4.8C2 firmware. Setting channel delay in Hardware menu, values are not update by rotary knob but only by push the buttons, but still on this by changing the other delay's channel then get corruption on the screen's tag. DSO is W2022A. Mit freundlichen Grüßen, Luc
@Hajo nullinie stimmt schon, nur das rauschen verdoppelt sich, i werd mal versuchen es mit bilder darzustellen sobald i a bissel zeit habe (im moment muss i auch softw. f. einen kunden anpassen) @Luc i will post a few pics so fast as possible vlG Charly
Hallo Hayo (und Huckepack-Platinenkunden), nach etwas Pause (andere Projekte...) habe ich mir am Wochenende die aktuelle Version von Hayo gesaugt, um für die nun in Alphaversion unterstützte Eingangsplatine die Kalibrierwerte in der Software zu ermitteln. Hier die dafür nötigen Code-Änderungen. Meine Basis ist die Version 1.2.BF.4.8C2. Erst tat sich praktisch nichts, die Platinen wurden nicht sinnvoll initialisiert. Als Ursache habe ich mein zu straffes Timing gefunden, das war grenzwertig. Mitunter war das FPGA mit seinem SPI-Transfer noch nicht fertig wärend ich die nächste Flanke anfordere, es wurden Bits verschluckt. Also bitte anpassen, in Zeile 41 von tc_vars.h:
1 | #define SPI_DELAY16 175 // >150 us for shifting out a 16 bit value
|
Zur Sicherheit habe ich in hardware_t.cpp in Zeile 2908 die Rest-Warteschleife durch folgenden Block ersetzt:
1 | if ((15000-49*SPI_DELAY16) > SPI_DELAY16) // if there's still more time to kill than the shift time |
2 | {
|
3 | Sleep_us(15000-49*SPI_DELAY16); // wait for SPI shifting it out, plus remaining relay settling time |
4 | }
|
5 | else // minimum time |
6 | {
|
7 | Sleep_us(SPI_DELAY16); // wait for SPI shifting it out |
8 | }
|
Das ist falls jemand SPI_DELAY16 so groß definiert, das die Relay Settling Time bereits erreicht wird. Sonst warten wir für eine negative Zeit, das könnte u.U. sehr lange dauern... ;-) Das if() kann bereits der Compiler auswerten, kostet also nichts. So, nun konnte es an die Kalibrierung gehen. Ich habe die letzte Spalte für ScaleFactor[] und DAC_ScaleFactor[] per DC-Messung an einem Kanal ermittelt. Hoffentlich ist die Streuung gering. In tc_vars.cpp ab Zeile 1084:
1 | float ScaleFactor[16][5] ={ {3.25, 2.615, 3.309, 3.875, 1.822}, // 1mV |
2 | {3.25, 2.615, 3.309, 3.875, 1.804}, // 2mV |
3 | {2.095, 2.095, 2.697, 3.125, 1.799}, // 5mV |
4 | {3.25, 2.615, 3.309, 3.875, 1.822}, // 10mV |
5 | {3.25, 2.615, 3.309, 3.875, 1.804}, // 20mV |
6 | {2.095, 2.095, 2.697, 3.125, 1.799}, // 50mV |
7 | {3.25, 2.615, 3.309, 3.875, 1.822}, //100mV |
8 | {3.25, 2.615, 3.309, 3.875, 1.804}, //200mV |
9 | {2.095, 2.095, 2.697, 3.125, 1.799}, //500mV |
10 | {3.25, 2.615, 3.309, 3.875, 1.822}, // 1V |
11 | {3.25, 2.615, 3.309, 3.875, 1.804}, // 2V |
12 | {2.095, 2.095, 2.697, 3.125, 1.799}, // 5V |
13 | {3.25, 2.615, 3.309, 3.875, 1.822}, // 10V |
14 | {3.25, 2.615, 3.309, 3.875, 1.804}, // 20V |
15 | {2.095, 2.095, 2.697, 3.125, 1.799}, // 50V |
16 | {3.25, 2.615, 3.309, 3.875, 1.822}}; // 100V |
und ab Zeile 1134:
1 | float DAC_ScaleFactor[3][5] = {{ 2.480, 2.480, 2.6456, 2.520, 16.361 }, // 1er ranges |
2 | { 4.940, 4.940, 5.2912, 4.980, 30.503 }, // 2er ranges |
3 | {12.360,12.360,13.2280,12.432, 76.505 }}; // 5er ranges |
(Code bei Sourceforge aktuell halten wäre cool, das erspart uns beiden diese Handarbeit.) Das mögen noch nicht die endgültigen Werte sein, aber zumindest schon mal eine Ausgangsbasis. Es bleibt noch ein Offset-Problem. Mit der automatischen Kalibrierung kriege ich das Ding nicht auf Null. Vielleicht entartet irgendwo die Numerik, die neuen Faktoren sind ja schon recht anders. In den 5er Bereichen ist die Signallinie ca. 1 Kästchen höher als die DC-Marke, in den 2er Bereichen ca. 3 Kästchen, in den 1er Bereichen gut 5,5 Kästchen. Hmm, ich bemerke gerade ein sehr seltsames Verhalten: Der Offset-Regler von Kanal 3 beeinflußt den Offset von Kanal 4, und zwar gegensinnig. Für Kanal 3 hingegen ist der Regler wirkungslos. Damit kriege ich immerhin meinen zur Messung verwendeten Kanal 4 auf Null. Hat noch jemand aktuell so eine Wechselwirkung, oder spinnt meine Hardware? Grüße, Jörg
Jörg H. schrieb: > Hat noch jemand aktuell > so eine Wechselwirkung, oder spinnt meine Hardware? Beim W2024 ohne Hardwareumbauten funktioniert die Offseteinstellung für alle 4 Kanäle ohne Seiteneffekte. Hast du den obligatorischen Default Setup (Utility) durchgeführt? Gruß Rainer
Hallo Jörg, deine Probleme interessieren uns nicht die Bohne. :-)) Wir wollen wissen, wie es mit der Huckepackplatine aussieht! Hast du HF-Messmöglichkeiten? Ich meine ja, sonst müssten wir noch etwas unternehmen. Grüße, Guido
Ich übernehme die neuen Änderungen natürlich sofort und gebe so schnell wie möglich eine neue Version raus. Gruß Hayo
@Guido >deine Probleme interessieren uns nicht die Bohne. :-)) >Wir wollen wissen, wie es mit der Huckepackplatine aussieht! ich nehme an, dass Du das lustig gemeinst hast was Du da in 'unserem' Namen geschrieben hast, diese Art kannst Du aber m.E. -so- ruhig stecken lassen.
Guido schrieb: > deine Probleme interessieren uns nicht die Bohne. :-)) > > Wir wollen wissen, wie es mit der Huckepackplatine aussieht! Oder war das etwa eine Anspielung auf mich...? Soweit ich weiß, wurden die HF alle Messungen (vor langer Zeit) erfolgreich von branadic durchgeführt und auch gründlich dokumentiert. Jörg befasst sich nur noch mit dem Einbau und der Ansteuerung in der Firmware. Außerdem gab es noch ein kleines ESD Problem, dass noch geklärt werden muss. Mfg, Kurt
Robert schrieb: > ich nehme an, dass Du das lustig gemeinst hast Na klar, deshalb auch der Smiley hintendran. Ich denke Jörg wird das schon richtig verstehen. Ich glaube aber nicht, dass ich der einzige bin, der sehr gespannt erwartet, was Walters und Branadics Werk in der Praxis bringen. Jörg ist schließlich der Erste, der es zur Funktion bekommt.
Luc schrieb: > Maybe I found a little bug in a 1.2.BF.4.8C2 firmware. > Setting channel delay in Hardware menu, values are not update by rotary > knob but only by push the buttons, but still on this by changing the > other delay's channel then get corruption on the screen's tag. > DSO is W2022A. Oh man, how did You make it? I tried hard but all is ok, except the gray turn arrows which appear on the empty two places after pushing the button 1 or 2. Hayo
Hui, hier ist ja was los. Passt schon, keine Empfindlichkeiten. Das mit dem Geister-Offset muß ich mir also nochmal auf meiner Hardware anschauen. Ansonsten ist jetzt langsam der Zeitpunkt gekommen, wo auch andere Leute sich die Platinen einbauen können. Dann gibt es auch mehr Erfahrungen damit. Wohlmöglich sogar von Leuten, die das Oszi praktisch einsetzen (ich gehöre nämlich noch nicht dazu). Was ich weiterhin noch schreiben wollte: Die Ansteuerung kann man vermutlich noch insofern optimieren, daß man die Bildschirmhöhe und die Aussteuerung der ADCs mehr zur Deckung bringt. Im Moment kriege ich auch recht weit außerhalb des sichtbaren Bereichs noch sinnvolle Meßwerte, die ADCs sind auch dort noch nicht in Vollaussteuerung. Ich nehme an, das ist nicht so gewollt. Wir verschenken also sichtbare Auflösung und zeigen auch unnötig großes Rauschen. Der Chip auf der Eingangsplatine hat eine programmierbare Verstärkung, wir können die also reduzieren und recht fein aufeinander abstimmen. Ich habe kein HF-Equipment (und auch wenig Ahnung davon). Kann sein, daß da auch noch was zu holen ist. Die Rechtecke des Testgenerators haben mit 1:10 Tastkopf etwas schräge Dächer. Vielleicht ist da noch was suboptimal, oder ich sollte am Tastkopf drehen. Grüße Jörg
Jörg H. schrieb: > Ansonsten ist jetzt langsam der Zeitpunkt gekommen, wo auch andere Leute > sich die Platinen einbauen können. Dann gibt es auch mehr Erfahrungen > damit. Ich komme erstmal nicht dazu weil ich nächste Woche im Urlaub auf Sardinien bin. > Was ich weiterhin noch schreiben wollte: > Die Ansteuerung kann man vermutlich noch insofern optimieren, daß man > die Bildschirmhöhe und die Aussteuerung der ADCs mehr zur Deckung > bringt. Im Moment kriege ich auch recht weit außerhalb des sichtbaren > Bereichs noch sinnvolle Meßwerte, Das ist bei den original Eingangsstufen leider auch so. Wenn man die Verstärkung so umprogrammieren könnte, dass Fullscale knapp über Gridhöhe liegt, dann wäre das auf jeden Fall sehr sachdienlich. Allerdings müßten dann die Scalefaktoren noch mal angepasst werden. Gruß Hayo
@Luc & all others >> When QM is on, changing Time Base sometimes get corruption on the screen >Yes I noticed this too and I'm searching for the reason. I hope I can >fix it soon. Unfortunately I wasn't able to reproduce this problem. Has anyone an idea how to force this error? Otherwise it is a littlebit difficult to analyze the problem. Regards Hayo
Hayo W. schrieb: >> Was ich weiterhin noch schreiben wollte: >> Die Ansteuerung kann man vermutlich noch insofern optimieren, daß man >> die Bildschirmhöhe und die Aussteuerung der ADCs mehr zur Deckung >> bringt. Im Moment kriege ich auch recht weit außerhalb des sichtbaren >> Bereichs noch sinnvolle Meßwerte, > > Das ist bei den original Eingangsstufen leider auch so. Wenn man die > Verstärkung so umprogrammieren könnte, dass Fullscale knapp über > Gridhöhe liegt, dann wäre das auf jeden Fall sehr sachdienlich. Ah so, das ist also nicht gewollt. Hätte ja auch Vorbereitung für hohe "Crestfaktoren" oder tolerante Ablesung sein können. Vielleicht habe mich an der Originalverstärkung orientiert, vielleicht auch nur irgendwas für 1-2-5 Abstufung reinprogrammiert und nix dabei gedacht. ;-) Kann man in irgendeinem Debugmodus die Rohwerte der ADCs ablesen? > Allerdings müßten dann die Scalefaktoren noch mal angepasst werden. Das ist klar. Wie ich schon sagte, obiges ist der erste Wurf. Jörg
Hallo Jörg, das mit der Verstärkung haben wir früher schon diskutiert. Es wäre auch im Original leicht möglich diese besser auf die ADCs anzupassen, aber auf Kosten von Bandbreite (erheblich) und Rauschen. Grüße, Guido
1.2.BF.4.8C2 >Unfortunately I wasn't able to reproduce this problem. Has anyone an >idea how to force this error? Otherwise it is a littlebit difficult to >analyze the problem. Maybe it's for the same reason as this one: Press Utility -> Default Setup wait until screen is redrawn change Time Base => for a short time there is a problem sightable in the first horz. Gridline. Robert
1.2.BF.4.8C2 same problem: Press -> About Oscilloscope Change Time Base Robert
Angehängte Dateien:
-
0004.jpg
39 KB
Hi Hayo, Rainer W., Robert and guys all! Hayo W. schrieb: >> Maybe I found a little bug in a 1.2.BF.4.8C2 firmware. >Oh man, how did You make it? I tried hard but all is ok, except the gray >turn arrows which appear on the empty two places after pushing the >button 1 or 2. I simply try to adjust the delay between the two channels of my W2022A but sometime by the rotary knob does not work, it works only by buttons. While this happens if I try to change the delay of one of the two channels, tags on the screen show itself corrupt. Hayo,please take a look at the screenshot. @Rainer W. Rainer, apologize me. For this time I beg You to bear me, the screenshot is only one. ;-) Hayo W. schrieb: >>> When QM is on, changing Time Base sometimes get corruption on the screen >>Yes I noticed this too and I'm searching for the reason. I hope I can >>fix it soon. > >Unfortunately I wasn't able to reproduce this problem. Has anyone an >idea how to force this error? Otherwise it is a littlebit difficult to >analyze the problem. As I already wrote, for me the bug seemed to gone by installing the last 1.2.BF.4.8C2 firmware release, but unfortunately it is not: it is like Robert says. Anyway the trouble manifested itself simply by changing the Time Base and/or the vertical amplitude when QickMeasure is on, it show itself like in my previous screenshots. Mit freundlichen Grüßen, Luc
@Robert Danke für den Hinweis. Ich probiere das morgen mal aus. Luc schrieb: > I simply try to adjust the delay between the two channels of my W2022A > but sometime by the rotary knob does not work, it works only by buttons. > While this happens if I try to change the delay of one of the two > channels, tags on the screen show itself corrupt. Hmm, really strange. On my DSOs it works and I can't reproduce the Problem. I will try to find it... @all -> has anyone the same problem? > As I already wrote, for me the bug seemed to gone by installing the last > 1.2.BF.4.8C2 firmware release, but unfortunately it is not: it is like > Robert says. > Anyway the trouble manifested itself simply by changing the Time Base > and/or the vertical amplitude when QickMeasure is on, it show itself > like in my previous screenshots. I will try it tomorrow once again. Thanks Hayo
Jörg H. schrieb: > Kann man in irgendeinem Debugmodus die Rohwerte der ADCs ablesen? Ja, kann man. Muß ich aber erst raussuchen. Poste ich morgen. Gruß Hayo
Oops, ich muß mich korrigieren: Jörg H. schrieb: > Die Ansteuerung kann man vermutlich noch insofern optimieren, daß man > die Bildschirmhöhe und die Aussteuerung der ADCs mehr zur Deckung > bringt. Im Moment kriege ich auch recht weit außerhalb des sichtbaren > Bereichs noch sinnvolle Meßwerte, die ADCs sind auch dort noch nicht in > Vollaussteuerung. Das hatte ich mit den alten Skalierungsfaktoren beobachtet. Ich habe es nun mit den aktuellen Faktoren nochmal überprüft: Die Aussteuerung ist perfekt, die Sättigung beginnt kurz hinter der Skala (ca. 20% drüber). Besser kann man das nicht machen. Man könnte den Eindruck haben, die Entwickler der Eingangsplatine haben sich bereits was dabei gedacht. ;-)) Nochmals Entschuldigung für die Panik, Jörg
@Luc As promised I checked the better settings for dso frequency response. The accuracy I can guarantee is 0,1 dB up to 8GHz,using generators and power meters with internal alc and selftest, low loss cable and termination at 50 ohm.These are HP,Tektronix,Wiltron..test instruments is my job. Anyway I tested W2022A, FW 1.2BF 4.8C2 HW with no modifications, up to 100 MHz. To have a good, flat frequency responce, better is: ADC setup=factory Pregain=1.25 Noise filter= IIR stage1 Trigger now works better than version 2.6 , very nice the last FW modifications, let’s say firmware improve the hardware limit of our DSO,proud to have the best of its class. Only a hint ,is useful to have a marker peak on FFT,may be Hayo like to have it. Thanks and regards Sandro
Sandro(Alex) schrieb: > Only a hint ,is useful to have a marker peak on FFT,may be Hayo like to > have it. Hi Sandro, how should it look like? Can You explain a little bit or post a modified screenshot. Regards Hayo
Angehängte Dateien:
-
Spectrum_Peak_.png
5,8 KB
Hi Hayo, enclosed you'll find the image,pushing one menu key a dot goes to the maximum peak on the screen,then display frequency and level. Regards, Sandro
@Sandro Nice idea. I will check if it is possible to implement something in this way. Regards Hayo
>@all -> has anyone the same problem? W2022A 1.2.BF.4.8C2 Two Gray arrows: Same here > Setting channel delay in Hardware menu, values are not update by rotary > knob but only by push the buttons, Well this is a little bit different here Luc/Hayo Utility -> More -> CH1 Delay Press button to next value -> no Update in the below line. Value still the same as before. You may press thru all values, no changes in the bottom line. Using the rotary knop -> all ok then, values are changing. This is the same for CH2 Delay. Scope turned off and on, same problem with CH-Delay as before. Robert
@Luc You where right, I found it and fixed it. ;-) But I couldn't reproduce the problem with the delay popup. Is it also present on the DSO of Your friend? @all Die gemeldeten Probleme sollten erledigt sein. Leider mußte ich für die Lösung des QM-Cursorproblems die beschleunigte Timebase und Spannungsverstellung wieder rückgängig machen, da diese mit dem Interrupthandler die Cursorausgabe abgewürgt hat und so die Cursorreste auf dem Bildschirm produziert hat. Hat jemand von Euch auch das Problem von Luc mit den Delay-Popups? Bei mir funktioniert das alles einwandfrei. Gruß Hayo
Ahhh, ok thanks Robert. I found it. Will be fixed soon. Hayo
1.2.BF.4.9C2 die von mir o. a. 'Probleme' sind (bei mir) damit behoben. Danke Hayo! Robert
Hi Hayo, Robert, Sandro(Alex) and guys all! Hayo W. schrieb: >You where right, I found it and fixed it. ;-) As always I thank You very much Hayo for the great job and free time You provided generously to us!!! Great work, no words... RESPECT!!!!!!! Hayo W. schrieb: >But I couldn't reproduce the problem with the delay popup. Is it also >present on the DSO of Your friend? Hayo do not worry because seems to me by installing latest 1.2.BF.4.9C2 version problem is gone! I have tried to replicate the problem but with the 1.2.BF.4.9C2 I am unable to get it, for a very short time can happen there is corruption in the tags, but they settle themselves quickly when screen is refreshed, hard to see now if You deliberately do not pay attention! Really an amazing and great job: RESPECT!!!!!!! Anyway, going to answer to your question, yes the problem was also with my friend's W2012A. The two oscilloscopes are like follow: W2022A 8C7.0C W2012A 8C7.0B @Hayo Hayo thank You so much also for the rewriting of the ADC's Setup menu, for me very very useful: RESPECT!!!!!!! @Robert Press thru all values but no changes in the bottom line sometimes happens to me too. Robert, thanks for reporting! Sandro(Alex) schrieb: >Only a hint ,is useful to have a marker peak on FFT,may be Hayo like to >have it. Sandro, I agree too. It is roughly the same I meant when I asked for the centre and span features for the FFT. @Sandro(Alex) Very impressive instrumentations, congratulation Sandro! I have a unmodified W2022A too, but unfortunately I have not a calibrate signal's I prefer to use ADC Setup= High Frequency 2, Pregain=1.25 and no filters. The W2022A is visibly better than the W2012A. Because I have not a calibrate signal's generator I usually compare between the two by measuring a very fast 300pS pulse.generator. Seems to me the unmodified W2022A can easy reach up 150MHz but maybe I am wrong. Sure the linearity is not the best but I believe the 150MHz perhaps are workable. If I am not wrong in the Hardware Forum Hayo and others put some screenshots where the W2022A were good at 140MHz, seems to me it were a resistors modified W2022A. I am enough interested about the Welec DSO's bandwidth. I read You use Noise filter= IIR stage1 when You make your measurements, but does not this introduce a bandwidth reduction? (IIR 1 Stage ca. 70 - 80Mhz IIR-filter with 1 stage and coefficient 0.5) Seem to me it bit introduce a offset level, too. Is not Smooth filter better for the purpose? (Smooth ca. 80 - 90Mhz -> in all other TB cutoff frequ. is half sample rate that means lossless!) However I believe no filter is better choice when bandwidth is under test. Vielen Dank!!!!!!! Mit freundlichen Grüßen, Luc
@Luc With the ADC high freq setting you have an overshoot in frequency response,this the reason because you can go over 150 MHz with an input stage that is hardware bandwidth limited,you may see the datasheet. High freq.-> the flatness isn't the best in the whole frequency range. IIR1 limits the bandwidth,but compensate the Pre gain 1.25 Accurate measure up to 100 MHz with this setting ADC setup=factory Pregain=1.25 Noise filter= IIR stage1 /smooth filter With no filter e high freq setting ADC goes in saturation with your settings,try to change the vertical sensitivity to see it,not suggested for sine wave. Let's wait for the improvement in the other features of the firmware, than we may do together a DSO specifications datasheet. @Hayo Thank you,I am available for further details @ all Have a nice day Sandro
Hi Sandro(Alex) and guys all! Sandro(Alex) schrieb: >With the ADC high freq setting you have an overshoot in frequency >response,this the reason because you can go over 150 MHz Sandro, what You write is of course correct. Due the fact I read about it, I know there is a linearity lack on the Welec's DSO when I performed the measures. Without the Piggyback board the only cure is to change some line and termination's resistors for the MAX121. Due this issue I subsequently opted for a pulse generator to evaluate the bandwidth, because linearity lack make difficult the measures. Sandro(Alex) schrieb: >with an input stage that is hardware bandwidth limited,you may see the >datasheet. Yes, of course I agree but You mean the filter bandwidth, not the oscilloscope one. Specifications says about 70-80Mhz bandwidth for IIR 1 Stage and about 80-90Mhz bandwidth for Smooth filter. I wanted to try evaluate real DSO's bandwidth. I know the W2022A is better of the W2012A, if I use the same filter then the performances are identical on both the DSOs and this make no sense for my purpose. Anyway, if even there is an overshoot, I can observe the differences between the two DSO. I know it is no much and it is not formally correct, but this is better than nothing. However, during the firsts attemps I tried with Factory's ADS Setup even if this no change much the things. Sandro(Alex) schrieb: >High freq.-> the flatness isn't the best in the whole frequency range. Due of the overt linearity lack caused by wrong gain setting of the MAX121. Sandro(Alex) schrieb: >IIR1 limits the bandwidth,but compensate the Pre gain 1.25 I did not know this, thanks for saying it to me! Sandro(Alex) schrieb: >Accurate measure up to 100 MHz with this setting >ADC setup=factory Pregain=1.25 Noise filter= IIR stage1 /smooth filter Anyway, I think the Smooth filter is better than the IIR stage 1, also under the aspect of the bandwidth's response. Sandro(Alex) schrieb: >With no filter e high freq setting ADC goes in saturation with your >settings,try to change the vertical sensitivity to see it,not suggested >for sine wave. I understand the overshoot matter, but not about the vertical sensitivity issue. Can You kindly explain to me? I used a no professional sine wave's generator up to 170MHz, it has no a calibrated level output but both unmodified W2022A and W2012A can show the waveforms on their screen. Also, unfortunately the output of the my RF wave generator is not adjustable. Glad to read You again, Sandro. Thank You very much for your report! Vielen Dank!!!!!!! Mit freundlichen Grüßen, Luc
Hi Luc and Sandro, just a little hint to check out the effect of the software filters and the bandwidth limiter. Take a signal with fast rise time and activate QM with the option "Rise Time". Switching through the filters You will see how the rise time is affected by the different filters. This is easy to do and shows very impressive how much bandwidth is cut off by the filters. Regards Hayo
Rainer W. schrieb: > Korrektur: > Es geht doch, allerdings mit mir völlig unverständlichen Zeitlimits. > Solange die Summe der beiden Werte für die Länge des > Pulstriggerfensters in dem gezeigten Fall gerade noch unterhalb von > 287µs liegt, kriegt die Triggerfunktion den genau genommen 192µs langen > Puls zu fassen. Es ist egal, ob man z.B. (<100, >187), (<140, >147) oder > gar (>187, <100) einstellt. > Einen komischen "Hystereseeffekt" gibt es, wenn man den ">"-Wert in der > Nähe der Pulsdauer variiert, d.h. z.B. <50µs fest eingestellt hat und > dann Hallo Rainer, ich konnte dies eben noch mal mit dem Probe Comp Signal nachvollziehen. Das schau ich mir nochmal an! Da läßt sich sicher etwas machen. Gruß Jürgen
Hi Hayo and guys all! @Hayo Yes, that is what I did and it is because I say the better choise is to disable any filter when trying to evaluate the DSO's bandwidth. In fact it is very simple to make the test, because stopping the DSO then it is easy to view how filters act by changing the filters setup. Hayo, thank You very much for your suggestion! Vielen Dank!!!!!!! Mit freundlichen Grüßen, Luc
Schönen guten Abend, habe jetzt ja das W2022 von Helmut auf dem Schreibtisch und wollte jetzt das Update auf W2022A machen leider ist die Datei EPC16_W2022A.jcc nicht mehr unter dem angegebenen Link zu bekommen. Hat einer von euch die Datei noch auf dem Rechner? Hoffe ihr könnt hier helfen. Jan
Ich weiß nicht ob es das ist was Du suchst? Gruß Hayo
Hallo, Ich habe damals auch mal eine Wittig W2024 gekauft, aber bis jetzt nich zu viel Zeit gehabt die auch zu gebrauchen. Ich habe nun mal herumgeschaut, und gesehen das es bessere Software und Hardware gibt. Jetzt wollte ich gerne die Huckepack Platinen einbauen, aber konnte nich finden ob die irgentwo zu kaufen sind. Also die frage, kan ich die Platinen irgendwo kaufen, brauchen nicht bestuckt zu sein, das kann ich mir selber machen. Wann noch Firmware anderungen notig sind dafur, werde ich mich damit auch gerne beschaftigen. Grusse, Gertjan. (Niederlande, also entschuldige mein schlechtes Deutch.)
So, hab bis eben an der neuen Version gearbeitet. Das neue Feature wird Euch gefallen. Jetzt muß ich den Koffer packen und bin dann erstmal eine Woche auf Sardinien. Bis dann Hayo
das ist GEMEIN , schon wieder anfuettern und dann abhauen :P wuensch dir einen schoenen Urlaub und bring mir was schoenes mit .... vlG Charly
Hi, schöne Grüße von Sardinien. Glücklicherweise gibts hier nen Hotspot, so dass ich hier nicht ganz abgeschnitten bin. Das neue Feature - was es ist wird noch nicht verraten, muß erstmal sehen ob es funktioniert - ist etwas umfangreicher. Wenn ich wieder zu hause bin werde ich noch etwas brauchen um es fertigzustellen. @Gertjan Willkommen in der Gemeinde :-) Für die Unterstützung der Addon-Platine ist Jörg hier der Ansprechpartner. Also bei Fragen zur Softwareansteuerung einfach direkt an ihn wenden. - und Dein Deutsch ist doch wirklich gut! Gruß Hayo
Hayo W. schrieb: > schöne Grüße von Sardinien. Glücklicherweise gibts hier nen Hotspot, so > dass ich hier nicht ganz abgeschnitten bin. Das hättest du zu Hause einfacher haben können ;-) Bin gespannt, was du jetzt wieder an neuen Features ausheckst. Schöne Tage am Mittelmeer. Gruß Rainer
Hallo, unter http://welecw2000a.sourceforge.net/docs/Hardware/Welec-Huckepack-Settings-ScaleFactors.xls findet sich unterstützend zur Softwareentwicklung der Huckepackplatine ein Tabellenkalkulation-Dokument, anhand dessen man die notwendigen Einstellungen des LMH6518 und der Eingangsspannungsteiler ablesen und die Software-Skalierungsfaktoren entnehmen kann. Mit der Huckepackplatine stehen in allen bisherigen Vertikalablenkungen 224 bis 226 LSB zur Verfügung, der ADC ist also deutlich weiter und in allen Bereichen bis auf ±1LSB gleich ausgesteuert. Damit wird auch das Rauschen in den 1er und 2er Bereichen um Welten besser und in den 5er Bereichen auch noch einmal um gute 10% besser. Zum Vergleich, in den originalen Einstellungen waren es nur 131 LSB in den 1er und 2er bzw. 204 LSB in den 5er-Bereichen. Dies konnte durch die feste Verstärkung von G=1.25 des ersten Verstärkers auf 163 LSB in den 1er und 2er-Bereichen verbessert werden, was aber immer noch 20% weniger gegenüber den 5er Bereichen ist und somit das deutlich größere Rauschen erklärt. Diese einfache Gegenüberstellung zeigt noch einmal in eindrucksvoller Weise was die Huckepackplatine zu leisten vermag. Um das in allen bisherigen Vertikalablenkungen auch mal mit Zahlen nachvollziehen zu können soll das Dokument zur Aufklärung beitragen. Darüber hinaus besteht mit dem LMH6518 generell die Möglichkeit die Vertikalablenkung fließend zu gestalten und nicht auf feste Vertikalablenkungen in 1er, 2er, 5er-Teilung zurückgreifen zu müssen. branadic
Hallo Branadic, danke für den Hinweis. Gruß Hayo
1094 Beiträge sind genug, hier geht es weiter: Beitrag "Wittig(welec) DSO W20xxA Open Source Firmware (Teil5)"
Jürgen schrieb: > Rainer W. schrieb: >> Korrektur: >> Es geht doch, allerdings mit mir völlig unverständlichen Zeitlimits. >> Solange die Summe der beiden Werte für die Länge des >> Pulstriggerfensters in dem gezeigten Fall gerade noch unterhalb von >> 287µs liegt, kriegt die Triggerfunktion den genau genommen 192µs langen >> Puls zu fassen. Es ist egal, ob man z.B. (<100, >187), (<140, >147) oder >> gar (>187, <100) einstellt. >> Einen komischen "Hystereseeffekt" gibt es, wenn man den ">"-Wert in der >> Nähe der Pulsdauer variiert, d.h. z.B. <50µs fest eingestellt hat und >> dann > > Hallo Rainer, > > ich konnte dies eben noch mal mit dem Probe Comp Signal nachvollziehen. > Das schau ich mir nochmal an! Da läßt sich sicher etwas machen. > > Gruß Jürgen @Rainer Ich hab mal wieder einen Blick zurück getan und die Lösung gefunden :-) Als Anhang mal eine Probe für die Pulse Width Problematik. Du kannst ja mal den Anhang ausprobieren, ob es so passt. Es fehlen allerdings noch die gesamten Prüfungen zu den Eingabebereichen in der Firmware. Gruß Jürgen
@Mods: Bitte hier schließen, wir diskutieren dort weiter: Beitrag "Wittig(welec) DSO W20xxA Open Source Firmware (Teil5)"
Thread beobachten
Seitenaufteilung abschalten
