Ich habe den Eindruck, dass die Refresh-Rate mit Noise Filter höher als früher ist, kann das sein? Beim Speichern und Laden von Signalen gibt es nach wie vor Probleme: Das Oszi verstellt beim Laden nicht mehr den Trigger, steht aber immer auf "Stop" und als ich versuchsweise eine Einstellung mit drei Signalen gespeichert und geladen habe und anschließend das ganze mit nur einem Signal, wurden die Nulllinienmarkierungen aller vier Kanäle mit eingeblendet, Ergebnis war: 2x Kanal 1, die anderen drei jeweils einmal. Das ist aber wohl nur ein Refresh-Problem, da alles verschwand nachdem ich einmal auf Kanal 2 gedrückt hatte. Ich konnte es auch reproduzieren: ein Signal speichern, laden und anschließend auf "Run/Stop" drücken liefert bei mir den beschriebenen Fehler. Sonst habe ich noch nichts getestet, aber ich bin sicher, dass das Welec damit wieder einen großen Schritt nach vorn gemacht hat. Danke schonmal für die Verbesserungen! Michael
Hallo, Danke hab jetzt den Changelog gefunden, sourceforge.net finde ich ein bisschen unübersichtlich. Ist echt Wahnsinn was ihr schon erreicht habt. Morgen müsste mein Oszi los geschickt werden. Wenn es ankommt kann ich beim Testen helfen. Für mehr werden meine Programmierkenntnisse nicht reichen.
Angehängte Dateien:
-
screenshot-0000.png
6,8 KB
@Hayo Danke fuer die HE, bei mir treten die spikes in AUTO mode nun nicht mehr auf, dafuer habe ich nun manchmal spikes im Normal mode! Die sind leider viel schwieriger zu erkennen weil sie nicht immer an der selben stelle im Speicher sind! N.b. die Delayed Funktion scheint bei 1Gs/sec nicht richtig zu funkzionieren: Bis zu 50ns/div ist sie OK (die Darstellung hat einen kleinen Versatz), aber wen ich weiter zoome (was meiner Meinung nach nicht moeglich sein sollte) wird nur eine Linie dargestellt (vermutlich ein falscher Bereich der Daten). und ich kann nicht mehr nach 50ns/div zurueck gehen. Martin
Danke schon mal für die ersten Testberichte. @Michael H. > Ich habe den Eindruck, dass die Refresh-Rate mit Noise Filter höher als > früher ist, kann das sein? Jein, das kommt auf die eingestellte Zeitbasis an, da je nach ungenutzten Samplewerten mit unterschiedlicher Filtertiefe gearbeitet wird. Den Bereich <= 100nS habe ich auf schnelle Shift-Operation umgestellt statt wie vorher normale Division, weiß aber nicht ob das schon in der letzten Version drin war oder ob das jetzt neu ist. > Beim Speichern und Laden von Signalen gibt es nach wie vor Probleme: > Das Oszi verstellt beim Laden nicht mehr den Trigger, steht aber > immer auf "Stop" Ja natürlich! Da ist wohl die Funktionsweise des Recall unklar. Also das gespeicherte Signal wird mit allen zugehörigen Einstellungen aus dem Flash geladen. Damit dann im nächsten Durchlauf das geladene Signal nicht gleich wieder vom aktuellen Signal überschrieben wird, geht das Gerät in den Stop-Modus. Durch das Drücken der Stoptaste wird dann der Stop-Modus und damit auch der Recall beendet -> die alten Einstellungen werden aus dem Flash wieder hergestellt und der normale Betrieb wieder gestartet. > und als ich versuchsweise eine Einstellung mit drei Signalen > gespeichert und geladen habe und anschließend das ganze mit > nur einem Signal, wurden die Nulllinienmarkierungen aller > vier Kanäle mit eingeblendet, Ergebnis war: 2x Kanal 1, > die anderen drei jeweils einmal. Diese Testkonstellation hate ich noch nicht. Danke für den Tip, werde ich mal checken. @Sven Programmierkenntnisse sind nicht nötig. Mit den Tests helft Ihr mir erheblich weiter. Da ich nicht die Zeit habe alle Konstellationen zu testen bin ich auf diese Hilfe angewiesen. @Martin H. > Danke fuer die HE, bei mir treten die spikes in AUTO mode nun > nicht mehr auf, dafuer habe ich nun manchmal spikes im Normal mode! > Die sind leider viel schwieriger zu erkennen weil sie nicht immer > an der selben stelle im Speicher sind! Ok werde ich mal checken. Ich habe alle Tests bislang im AUTO-Modus gemacht. > N.b. die Delayed Funktion scheint bei 1Gs/sec nicht richtig zu > funkzionieren: Da habe ich in dieser Version nichts dran geändert. Das müßte also ein Fall für die offizielle "OS"-Version (Ticket) sein. Gruß und danke Hayo
Angehängte Dateien:
-
screenshot-0000.png
4,7 KB
Hallo Hayo, Ich habe gerade deine Firmware aufgespielt. Im FFT Menü gibt es einen Fehler beim Anzeigen des Menüs "Mode". Siehe Screenshot. Ein weiterer kleiner Bug (war schon in vorigen Versionen). Wenn man "Autoscale" drückt und danach "Undo Autoscale), werden im oberen Menü die Spannungsberecihe aller Kanäle angezeigt obwohl nur einer aktiviert ist. (siehe Screenshot im zweiten Posting). Der DAC Abgleich funktioniert bei mir nicht korrekt oder ich mach etwas falsch. Ich stelle alle Kanäle auf 5V/div und starte "Search Zero Lines" und danach "Calibrate DAC". Danach stelle ich alle Kanäle auf 2V/div und mach das gleiche. Stelle ich nun wieder zurück auf 5V/div habe ich auf Kanal 3 und 4 einen Offset von -0.5div ud auf Kanal einen Offset von +0.25div. Auf Kanal 2 ca einen Offset von +2 Pixel. Mache ich etwas falsch? lg Robert
Hallo Robert, du machst was falsch. ;-) "Search Zero Lines" nur einmal im 5er Bereich drücken, in den anderen Bereichen dann nur noch "Calibrate DAC". Gruß, Guido
@Robert S. Zum Kalibrieren hat Guido schon alles gesagt. Ansonsten danke für den Fehlerreport, da hab ich ja wieder was zu tun, bevor das in die "OS"-Version einfließen kann. Gruß Hayo
Danke für die Hilfe!! Ich hab noch zwei Fehler beim Delayed Mode gefunden. #1: Ist der Delayed Mode aktive und man schaltet das Gerät aus und wieder an, muss man am Timebase Rad einmal drehen, damit ein Signal angezeigt wird. #2: Im Delays Mode wird das Softmenü der Gritintensität nicht aktualisiert wenn man im Display Menü am zugehörigen Drehencoder dreht (die Gridintensität ändert sich schon). Wenn man den Delayed Mode beendet wird wieder die Gridintensität vor aktivieren des Delayed Modes angezeigt. Sollte man im Delayed Mode einen Screenshot machen, wird die Grid-Plane mit der Intensität aus dem Main Mode angezeigt, nicht mit der geänderten. lg Robert
Auch ein Fall für ein Ticket, da dieses Problem auch die "OS"-Version betrifft. Die 0.92HE-Änderungen findet Ihr im Changelog. Hayo
Hallo Ich hab mein Oszi erst sehr kurz und benutze aufgrund der Spikes noch immer die firmware 90. Nun hab ich eine Frage wieso ist das "Rauschen" bei 1V größer als bei 500mV sollte es da nicht größer werden je kleiner die V Basis ist... also der Ausschlag? Weil bei mir ist es genau umgekehrt. Im Anhang sind 2 Bilder das bei 1V hat deutliche hügel das bei 500mV nicht mehr so sehr. (Ich weiß handy Kamera aber gibts ne MAC oder Linux software zum Screenshot auslesen?) http://img255.imageshack.us/i/67664861.jpg/ http://img171.imageshack.us/i/500mv.jpg/ lg Mike
Hallo Mike, es gibt auch eine Linuxversion, die ist auch bei der HE dabei. Die Messbereiche sind grundsätzlich in drei Hauptbereiche eingeteilt, die sich durch den Skalierungsfaktor unterscheiden. Alle 5er Bereiche haben einen günstigenren Faktor als die 2er oder 1er. Daher haben aller 5er Bereiche ein geringeres Rauschen als die 2er und 1er Bereiche. Gruß Hayo
Wie darf ich mir das mit dem Faktor vorstellen? Und ist das ganze schon "fertig" oder schraubt ihr dort noch herum? Danke für die schnelle Antwort. lg Mike
Mike K. schrieb: > Wie darf ich mir das mit dem Faktor vorstellen? Und ist das ganze schon > "fertig" oder schraubt ihr dort noch herum? "fertig"? - Was für ein Wort ;) Wie Du aus dem Text von brunowe weiter oben entnehmen kannst, hat das DSO vier Verstärker, aus denen sich die Verstärkungsstufen (1; 1,25)*(1;2;4) -> (1;1,25;2;2.5;4;5) einstellen lassen. Das Rauschen der ersten beiden Verstärker bleibt etwa gleich (7nV/sqrt(Hz)+ 20nV/sqrt(Hz) -> 27nV/sqrt(Hz) (ohne Rauschstrom)) und wird mit den nächsten Stufen entsprechend verstärkt. Jeder der beiden nächsten Verstärker steuert nochmal 20nV/sqrt(Hz) zu. Entsprechend verhält sich das Signal/Rauschverhältniss reziprok zur Amplitude des Eingangssignals. An der hardwareseitigen Behebung dieses Problems arbeiten derzeit Leute. Eine Umstellung der Verstärkungsfaktoren (1,25; 2; 4 -> 1;2,5;5) erfodert weitere Messungen (es gibt hier verschiedene Ergebnisse zur Durchlasskurve des Gerätes zwischen beiden Serien (W201X, W202X)) und hätte derzeit nur evtl. Vorteile für die Firmware (Geschwindigkeit, Speicherbedarf ;) Die dekadischen Stufen (1V, 100mV, ...) werden über ein Widerstandsnetzwerk abgebildet. > > Danke für die schnelle Antwort. > > lg Mike Grüße, rowue
Gerade habe ich versucht, die oben beschriebenen Spikes im "Normal" Mode zu beobachten. Testsignal 5V, 325kHz Rechteck. Es gibt Ausreißer, die ich aber wohl von dem vom Controller erzeugten Signal kommen - die diversen Rechtecksignale die ich damit generiere koppeln ganz gut gegenseitig über. Vielleicht kann das noch jemand mit professionelleren Mitteln testen? Obwohl: wenn ich mit Single Shot eine Aufnahme nach der anderen mache, erwische ich - selten, aber immerhin - einen Spike mit ca. derselben Amplitude wie das Rechteck, der eigentlich nicht vom Signal herrühren kann. Leider ist bei der HE das alte Problem mit dem zerstückelten Screenshot wieder da (ja, ich habe screenshot_0.4BF verwendet), so dass ich keinen ansehnlichen Shot erstellen konnte. Der Spike erschien bei mir stets recht nah am rechten Bildschirmrand und hatte immer gleiches Aussehen. Obwohl ich nur mit Kanal 4 gemessen habe, war übrigens die ganze Zeit das Triggersymbol von Kanal 2 eingeblendet - wahrscheinlich hilft ein Refresh an passender Stelle? Die anderen Spikes scheinen wirklich verschwunden zu sein, sehr schön. Gruß Michael
Angehängte Dateien:
-
screenshot-0000.png
4,6 KB
Nachtrag zum Triggersymbol: Siehe Screenshot. Ich habe mit Kanal 4 gemessen, Trigger stand auf Source 4. Trotzdem war auch das Triggersymbol von Kanal 2 eingeblendet. Also habe ich mal auf Source 2 geschaltet und am Trigger gedreht - dabei entstand dann das Bild, das ihr hier sehen könnt. Wenn ich Source 1 wähle, kann ich entsprechend nochmal beliebig viele 1er Triggersymbole dazuzaubern usw. Gruß Michael
Sorry wenn ich nochmal ne blöde Frage stelle. Mein oszi ist heute gekommen. Hab erstmal ein backup von allem gemacht, das ging 3 1/2 Stunden. Jetzt will ich zum test mal euere Firmware drauf machen, dies dauer jetzt aber ca. 6h. Ist das normal? Ich habe ein USB to RS232 converter vom Reichelt. Kann ich das update jetzt einfach abbrechen und dann über das perl Script machen? Da solls ja schneller gehen.
Danke für die Erklärung Rolf Würdemann. Jetzt wart ich nur mehr auf 0.92, aber zurzeit glüht der svn nur so vor updates. lg Mike
Ich habe vor ewigkeiten ja schonmal davon geredet, dass "bald" eine Version des FPGA-Redesigns zur verfügung stünde, mit dem man schonmal "spielen" kann. Neben Studiums-Endspurt-Stress kamen diverse Probleme mit dem Design hinzu, und große Teile wurden seitdem überarbeitet oder neu implementiert. Außerdem habe ich nun tatkräftige Unterstützung bei der Entwicklung! Nach langer Zeit gibt's also mal wieder was zu zeigen: http://www.youtube.com/watch?v=vwSE2alpnYQ Viel Spaß damit Daniel
Michael H. schrieb: > Leider ist bei der HE das alte Problem mit dem zerstückelten > Screenshot wieder da (ja, ich habe screenshot_0.4BF verwendet), so dass > ich keinen ansehnlichen Shot erstellen konnte. Den Effekt hatte ich mal unter Linux. Bei mir funktioniert allerdings jetzt alles. Sonst unter Windows das BMP-Format verwenden. Hayo
Hallo Sven, für das schnelle Update benötigst Du Pearl! Unter Windows sollte es so gehen (Zitat von viel weiter oben): ----- Ich verwende ActivePerl 5.8.8 (habe ich von http://www.oldapps.com/Perl.php geladen). Zusaetzlich benoetigst du das Modul Win32:SerialPort Am einfachsten ist die Installierung via Perl Package Manager (PPM): 1. Neues Repository eintragen via Edit -> Preferences und den Reiter Repositories Name: Bribes Location: http://www.bribes.org/perl/ppm (ein ausfuerliches help findest du unter http://www.bribes.org/perl/ppmdir.html) 2. Jezt kannst du das Modul Win32-SerialPort installieren: Zeile mit Win32-SerialPort suchen und an klicken Action -> Install Win32-Serialport 0.19 Das sollte alles sein. ----- Ich hatte Anfangs auch Probleme mit Pearl und habe später gemerkt, dass ein Nullmodemkabel das Problem dann behoben hat! Man ist versucht, den Reichelt-Adapter direkt mit dem Scope zu verbinden (passt ja!), allerdings sind dann RX und TX vertauscht. Also: Nullmodem-Kabel! Den Rest findest Du im Updatepaket beschrieben. Michel
Hi Michael, habs gestern dann einfach weiter laufen lassen, weil ich nicht wusste was passiert wenn ichs abbreche. Heute morgen warens angeblich nur noch 18s bis es fertig ist, aber es kamen nur timeout Fehler. Also musst ichs abbrechen, aber die Firmware von hayo ist nun drauf und funktioniert auch so weit. Hatte den adapter direkt (ohne nullmodem- Kabel) drauf gesteckt. Wenn TxD und RxD vertauscht wären dürfte ich doch gar keine Verbindung bekommen, oder? Ist das beiligende RS232 Kabel ein Nullmodem- Kabel? mit diesem hab ich grad mal einen Software Download gestartet, das geht auch nicht scneller.
@Sven Beim downloaden mit Perl der Original Firmware brauchst du zirka 1Std fürs spätere uploaden der hier erhältlichen firmware per perlskript brauchst du 5min lg Mike
Nachtrag: Stimmt, mit dem perlscript gehts nur mit dem beiligenden Kabel, mit dem welecupdater gehts auch ohne. Danke
hast du denn auch die Baudrate von 115200 am Port eingestellt? Also ich hatte heute das erste mal das Perlskript benutzt, nach 3min war alles drinnen, ich dachte schon, es wäre nur die Hälfte angekommen, war aber alles i.O. Wie kann so ein extremer Zeitunterschied zwischen den beiden Flash-Methoden sein??? Gruß, Michael
Zu Ticket #40: wenn ich das richtig in Erinnerung habe, existieren keine Samplerates von 50 oder 100MSa/s, weil zwischen 250 und 25MSa/s der Übergang von 16k auf 4k Speichertiefe stattfindet. Stimmt das so? Zu #38: Auch bei mir kommt es mit der HE immer wieder vor, dass nichts angezeigt wird, obwohl alle Einstellungen korrekt sind. Nach einiger Rumdreherei erscheint das Signal dann auf einmal wieder. Ich werde auch nochmal versuchen, das nachzustellen. Gruß Michael
Michael H. schrieb: > Zu Ticket #40: wenn ich das richtig in Erinnerung habe, existieren keine > Samplerates von 50 oder 100MSa/s, weil zwischen 250 und 25MSa/s der > Übergang von 16k auf 4k Speichertiefe stattfindet. Stimmt das so? > Es existieren Samplerates von 50 und 100 MSa/s, diese sind aber auch in der Zeitbasis schwer auszuselektieren. > Zu #38: Auch bei mir kommt es mit der HE immer wieder vor, dass nichts > angezeigt wird, obwohl alle Einstellungen korrekt sind. Nach einiger > Rumdreherei erscheint das Signal dann auf einmal wieder. > Ich werde auch nochmal versuchen, das nachzustellen. Ich konnte mittlerweile das Signal durch Drehung der Verstärkereinstellung wieder "sichtbar" machen. > > Gruß > Michael Grüße, rowue PS: Sachdienliche Hinweise zu den Tickets können gerne an die entsprechenden Tickets angehängt werden ;) PPS: Die neue FW sieht gut aus, hat aber leider einige neue Bugs. QM mit Zeitbasen <50ns funktioniert leider immer noch nicht (Skalierungsproblem?)
Hallo Leute, ich war zwischenzeitlich etwas beruflich eingespannt, so dass ich leider nicht zu meiner Lieblingsbeschäftigung gekommen bin. Eure Beiträge und Fehlermeldungen habe ich dennoch verfolgt und werde eine korrigierte Fassung der HE in Kürze hier posten damit wir das dann mal endlich in die OS Version reinpatchen können. Ich war aber trotz alledem nicht untätig. In der Zwischenzeit habe ich mich mit anständigem Mess-Equipment eingedeckt, um mal zuverlässige Aussagen zum Einsatzbereich (Bandbreite und Signalintegrität) der W201x und W202x Geräte machen zu können (HP3325A Präzisionssignalgenerator, Tektronix 2465A 350MHz Oszilloskop). Wollen doch mal sehen was die W20xx so hergeben mit den neuesten Firmwareänderungen. @Rolf Kein Skalierungsproblem. Wie schon weiter oben gesagt liegt es mit ziemlicher Sicherheit daran, dass die interpolierten Daten in anderen Speicherbereichen liegen. Ob ich dazu auch noch komme weiß ich allerdings nicht. Gruß Hayo
Michael H. schrieb: > Zu Ticket #40: wenn ich das richtig in Erinnerung habe, existieren keine > Samplerates von 50 oder 100MSa/s, weil zwischen 250 und 25MSa/s der > Übergang von 16k auf 4k Speichertiefe stattfindet. Stimmt das so? Nein, der Grund ist entweder ein Fehler im FPGA-Design oder nur die vergurkte Firmwareprogrammierung. Ob Ersteres zutrifft ergründe ich noch. Wenn es nur die Firmware ist werde ich das auf jeden Fall nachrüsten, beim FPGA-Design kann ich nicht viel machen, außer die Sampletiefe und die Samplerate etwas geschickter zu verteilen als momentan. Da bleibt dann nur der Umstieg auf eins der neuen FPGA-Designs (siehe Hardware-Thread). Gruß Hayo
Hi Hajo,
bei mir steht auch noch ein HP8116A und ein Grundig FG100,
ersterer könnte interessant sein, wenn wir mal in höhere
Bereiche gehen wollen ;)
Btw:was hältst Du davon, die Verstärker malauf 1,2.5,5
umzuschalten - dann hätten wir in allen Bereichen die
gleiche Aussteuertiefe (habe schon etwas dran gespielt,
muss da aber noch mal ran;)
Grüße,
rowue
rowue schrieb: > Hi Hajo, > > bei mir steht auch noch ein HP8116A und ein Grundig FG100, > ersterer könnte interessant sein, wenn wir mal in höhere > Bereiche gehen wollen ;) Nette Ausrüstung, kann der HP auch noch mehr als 50MHz (via Rear Panel Ausgang) ? > Btw:was hältst Du davon, die Verstärker malauf 1,2.5,5 > umzuschalten - dann hätten wir in allen Bereichen die > gleiche Aussteuertiefe (habe schon etwas dran gespielt, > muss da aber noch mal ran;) Wie hast Du die Umschaltung gemacht (Softwareseitig oder Hardwareseitig)? Werde gleich mal die ersten Ergebnisse meiner Vergleichstests veröffentlichen, allerdings wie es sich gehört im Hardwarethread. Gruß Hayo
Hayo W. schrieb: > rowue schrieb: >> Hi Hajo, >> >> bei mir steht auch noch ein HP8116A und ein Grundig FG100, >> ersterer könnte interessant sein, wenn wir mal in höhere >> Bereiche gehen wollen ;) > > Nette Ausrüstung, kann der HP auch noch mehr als 50MHz (via Rear Panel > Ausgang) ? Müsste ich mal prüfen - tendentiell eher nicht, wobei ich allerdings in der FFT auch bei 50MHz die Oberwellen bis 200MHz klar erkennen kann (inkl. des von Andre beschriebenen "überziehens") > >> Btw:was hältst Du davon, die Verstärker malauf 1,2.5,5 >> umzuschalten - dann hätten wir in allen Bereichen die >> gleiche Aussteuertiefe (habe schon etwas dran gespielt, >> muss da aber noch mal ran;) > > Wie hast Du die Umschaltung gemacht (Softwareseitig oder > Hardwareseitig)? Über die Bit-Register - also Hardwareseitig - ich habe als Skalierungsfaktoren (auf die 400 px) mittels Messung 2,55;2,56;2,55 herausbekommen (wobei der theor. Wert bei 2,4606 liegt) und will als nächstes Nachschauen, wie ich den "ZeroScaleFactor" bestimme, auch, wenn mir die Werte bekannt vorkommen ;) Neben dem evtl. Vorteil, nur zwei Werte (delayed, normal) für die Darstellung auf dem Bildschirm zu haben, hätte das noch in der Auswertung den Vorteil nicht ständig die veränderten Verstärkungen der einzelnen Stufen einbeziehen zu müssen. Dafür hätten wir halt nur um die 156 Bit zur Verfügung :( > > > Werde gleich mal die ersten Ergebnisse meiner Vergleichstests > veröffentlichen, allerdings wie es sich gehört im Hardwarethread. > o.k. ;) - Oder im SF-Forum ;) > Gruß Hayo Grüße, rowue (Sorry für "Hajo" ;)
Hmm, ist doch etwas später geworden beim Griechen, daher gibt es die Fotoserie zu meinen Messungen erst morgen (also nachher). Sorry Hayo
Hallo Hayo und Rolf, die Verstärkungen 1, 2.5, 5 habe ich in BF0.56 schon mal getestet. Ich habe dafür folgende Einstellung in Hardware::Setswitches verwendet:
1 | case 0 : dat_buf = 0x0005; break; |
2 | case 1 : dat_buf = 0x0005; break; |
3 | case 2 : dat_buf = 0x0005; break; |
4 | case 3 : dat_buf = 0x0005; break;// 10 mV |
5 | case 4 : dat_buf = 0x0045; break;// 20 mV |
6 | case 5 : dat_buf = 0x00D5; break;// 50 mV |
7 | case 6 : dat_buf = 0x0009; break;// 100 mV |
8 | case 7 : dat_buf = 0x0049; break;// 200 mV |
9 | case 8 : dat_buf = 0x00D9; break;// 500 mV |
10 | case 9 : dat_buf = 0x000A; break;// 1 V |
11 | case 10 : dat_buf = 0x004A; break;// 2 V |
12 | case 11 : dat_buf = 0x00DA; break;// 5 V |
@ Rolf: Hast du das auch so? Gruß, Guido
Guido schrieb: > Hallo Hayo und Rolf, > > die Verstärkungen 1, 2.5, 5 habe ich in BF0.56 schon mal getestet. > Ich habe dafür folgende Einstellung in Hardware::Setswitches verwendet: > >
1 | >
|
2 | > case 0 : dat_buf = 0x0005; break; |
3 | > [...] |
4 | >
|
5 | >
|
> > @ Rolf: Hast du das auch so? Genau so ;) Ich habe dann mit dem HP in den 50, 20, 10 mV/DIV Stufen jeweils die Gleich-Spannungen in 1DIV Schritten von -4 DIV bis 4 DIV(*) eingestellt, mit dem Multimeter kontrolliert (0,3% Messgenauigkeit, in der weiteren Fehlerfortpflanzung vernachlässigt) und die (Roh-)Daten (bandbreitenbegrenzt) ausgelesen. Von diesen Rohdaten habe ich jeweils die ersten 2048 Sätze genommen und die Mittelwerte gebildet. Mit diesen Mittelwerten (inkl. Fehler) habe ich dann eine lineare Regression (Fit mit Polynom ersten Grades) im Bezug auf Bits/DIV durchgeführt. Es ergaben sich folgende Zusammenhänge:
1 | 10 mV/DIV: 19,4926 pm 0,1738 Bits/DIV (rel. Fehler: 0,8916%) |
2 | 20 mV/DIV: 19,5195 pm 0,1507 Bits/DIV (rel. Fehler: 0,7720%) |
3 | 50 mV/DIV: 19,6316 pm 0,1337 Bits/DIV (rel. Fehler: 0,681%) |
Als Skalierungsfaktoren für die Software hätte ich somit (**)
1 | 10mV/DIV: 2,5651 pm 0,0229 |
2 | 20mV/DIV: 2,5615 pm 0,0198 |
3 | 50mV/DIV: 2,5469 pm 0,0173 |
Mit folgenden Auflösungen [mV/Bit]:
1 | 10 mV/DIV: 0,513 pm 0,0046 |
2 | 20 mV/DIV: 1,0246 pm 0,0079 |
3 | 50 mV/DIV: 2,5469 pm 0,0173 |
Wenn gewünscht, kann ich die Änderungen an tc_hardware.cpp mal in's svn spühlen, dann können hier weitere Messungen zur Auflösung, etc vorgenommen werden - ich gehe da schon von - leichten - Unterschieden auf Grund der Bauteilstreuung aus. Die angegebenen Fehler beziehen sich auf die Fehler der Anpassung (wie gut passt eine Kurve mit dieser Steigung auf die Messpunkte). Für die Fehler der berechneten Mittelwerte habe ich mal den mittleren relativen Fehler berechnet:
1 | 10 mV/DIV: 1,3653% |
2 | 20 mV/DIV: 1,0736% |
3 | 50 mV/DIV: 0,8531% |
(ja, ich habe gepfuscht und die Standardabweichung des Fehlers nicht angegeben ;) > > Gruß, Guido Grüße, rowue (*) Also für 200mV/DIV z.B. von -200mV bis 200mV in 50mV Schritten. (**) Ich habe die Daten gerade noch mal ausgewertet, deshalb der Unterschied zum vorherigen Posting.
Hi, muß Euch leider noch mal auf morgen vertrösten mit meiner Bilderserie. Gruß Hayo
Rolf Würdemann schrieb: > Guido schrieb: >> [...] > > (*) Also für 200mV/DIV z.B. von -200mV bis 200mV in 50mV Schritten. Soll natürlich 50mV/DIV heissen ;) > [...]
@Rolf Ich habe mal die Messungen in den Hardwarethread gestellt. Leider stehen mir nur bis 10 MHz die präzisen Rechtecksignale zur Verfügung. Darüber habe ich nur ein nicht ganz so sauberes Hilfssignal, dass ich auf der Rückseite des Funktionsgenerators abgreifen kann. Zudem habe ich da auch nur einen nicht einstellbaren recht kleinen Signalpegel. Da wäre eine Meßreihe mit Deinem 50 MHz Pulsgenerator sicher ganz interessant, zumal man da dann auch die verschiedenen Spannungsbereiche miteinander vergleichen könnte. Gruß Hayo
moin erstmal, ich habe folgendes bei der Nullinienkalibrierung in fast allen Bereichen (Feintuning nur mit der DAC-Taste) festgestellt: bei mehrmaligen betätigen, war der erste Kanal nicht auf null zu bekommen, erst nach mehrmaligen verschieben des 1. Kanals (W2022A)nach oben(dann jedes mal die DAC-Taste betätigt), hat sich die Kalibrierung auf null eingestellt ! Im Quickmeasure habe ich zwischen beiden Kanälen einen Messunterschied (egal ob 1V, 2V oder 5V-Bereich) von 0,5V -0,7V! Erst wenn ich beide Kanäle in den unteren Bereich des Bildschirms verschiebe, sind die gemessenen Spannungen gleich! Ich hoffe, die Info war nützlich... Gruß, Michael
@mike0815 Ok, danke das ist ein praktischer Hinweis zum Kalibrieren. Gruß Hayo
Hayo W. schrieb: > @Rolf > > [Pulsgenerator] Hi Hayo, sorry erstmal für die späte Antwort - ich hatte die letzten Tage etwas sehr mit den 1;2.5;5 Faktoren und ihrer Abbildung im Source gespielt ;) Ich sehe mal zu, dass ich mir am WE noch das 2022A von 'nem Kollegen ausleihen kann, um dann mit beiden Geräten entsprechende Aufnahmen zu machen. Allerdings könnte es noch interessant sein, dies mit Deinem Tek zu vergleichen (da ja die Bandbreite, etc. des HP nicht bekannt ist). Alternativ könnte ich mit einigen Annahmen die "theoretischen" Ausgangssignale des HP simulieren und dagegen stellen. > > Gruß Hayo Grüße, rowue
mike0815 schrieb: > moin erstmal, Mohltiet ;) > [Problem mit der DAC-Kalibrierung] @mike0815: Welche Version nutzt Du? Die 0.92HE oder die 0.91OS? @Hayo: Auf welche Version setzt Du auf? Die aus dem svn oder Deiner letzten? Ich weiss, dass Falk was an der ADC-Kalibrierung geändert hat (r176, r178, die vor Deinem Urlaub war r172). Ich habe bei meinen Spielereien (Faktoren) das Problem symmetrisch zur Null-Linie (leicht, proportional zum Abstand). > > Gruß, Michael Grüße, rowue
Rolf Würdemann schrieb: > @Hayo: Auf welche Version setzt Du auf? Die aus dem svn oder > Deiner letzten? Meiner letzten! Die Änderungen von Falk sind also nicht drin. Was hat er denn geändert? Hat er die Kalibrierung verbessert, oder "nur" das Handling verändert? Gruß Hayo
Hayo W. schrieb: > Rolf Würdemann schrieb: > >> @Hayo: Auf welche Version setzt Du auf? Die aus dem svn oder >> Deiner letzten? > > Meiner letzten! Die Änderungen von Falk sind also nicht drin. Was hat er > denn geändert? Hat er die Kalibrierung verbessert, oder "nur" das > Handling verändert? Generell? Oder bezogen auf die ADC-Kalibrierung? Letzteres: http://sourceforge.net/apps/trac/welecw2000a/changeset/176/fpga/nios/oss/trunk/src/hardware_t.cpp Wenn Du eine Übersicht haben möchtest: http://sourceforge.net/apps/trac/welecw2000a/log/fpga/nios/oss/trunk > > Gruß Hayo Grüße, rowue
Hallo Rolf,
> [Problem mit der DAC-Kalibrierung]
...ich nutze die letze Ver.92HE auf W2022 (Hardwarever. 8C7.0L)
...du meine Fres.., eben mach ich das Teil an, da sind beide Nullinien
(Kanal 1+2 1V-Div)1,5 Teilstriche nach unten gerutscht, nach 1x
Dac-Abgleich, geht der 2.Kanal exakt auf null, der 1.Kanal zickt noch
herum.
Wenn ich die Nulllinie (nur 1.Kanal)mehrmals nach unten u. oben
verschiebe und nach jedem schieben die DAC drücke, bequemt auch er sich
endlich aufzusetzen!
Ich dachte, die Kalibrierung wird nach dem Abgleich in die Config
geschrieben und dann abgespeichert, nein, doch???
Jetzt hatte ich nochmal abgeschaltet und neu hochgefahren, die
Nulllinien waren wieder etwas verschoben, nach 1x DAC drücken war's dann
wieder Ok.
...liegt das jetzt explizit nur an meinem Gerät, oder habt ihr dasselbe
Problem???
Gruß, Michael
mike0815 schrieb: > Ich dachte, die Kalibrierung wird nach dem Abgleich in die Config > geschrieben und dann abgespeichert, nein, doch??? Jupp, wird sie. > Jetzt hatte ich nochmal abgeschaltet und neu hochgefahren, die > Nulllinien waren wieder etwas verschoben, nach 1x DAC drücken war's dann > wieder Ok. > ...liegt das jetzt explizit nur an meinem Gerät, oder habt ihr dasselbe > Problem??? Hmm, das muß ich mal überprüfen. Die 0.93HE steht in den Startlöchern. Da hat sich einiges getan. Unter anderem habe ich die Startupsequenz komplett geändert um den Reload aus dem Flash für jede Ausgangssituation zu gewährleisten und nebenbei das gemeldete Problem mit dem Restart nach Delayed-Betrieb zu beseitigen. Vielleicht läßt sich das dann gleich mit erledigen. Gruß Hayo
Nur mal so ne dumme frage aber woher bekommt man eigentlich das Bin für die Holiday edition? lg Mike
Da es sich nicht um offizielle Releases handelt, sondern um Testversionen poste ich sie hier. Die 0.92HE findest Du etwas weiter oben, die 0.93HE kommt in Kürze auch hier. Dabei handelt es sich im Wesentlichen um eine Fehlerkorrektur der in der 0.92HE gemeldeten Fehler. Allerdings habe ich dafür einige Sachen komplett umgestrickt, so dass es über eine einfache Korrektur doch schon hinausgeht. Hayo
Hallo Hayo, > Die 0.93HE steht in den Startlöchern. < ach, das wird wieder eine HE?? Ist ja wurscht, ich bin schon ganz gespannt, wann ist denn mit der 093HE zu rechnen? Jedenfalls, macht es hier einen riesen Spass! Ich selber bin noch in der Aufbauphase was den Umgang mit Oszilloskopen betrifft, da es mein Erstes ist...nach 35 Jahren...'lach' Immerhin habe ich keine Probleme beim Backup und Flashen, Quartus und der USB-Treiber von Slog ist ebenfalls installiert und funzt ohne Probleme, würde ja gerne mehr experimentieren, nur habe ich so manche Bedenken, beim Aufspielen z.B. EPCS16N aufzuspielen, nicht das ich da noch was versaue!!! Schade, das die Google-Groups nicht mehr so gepflegt wird, da ich diese für übersichtlicher halte als die SVN. Vielleicht könnte man von dem Projekt einige Kopien dort hinein setzen und somit auch die eine oder andere Anleitung zusätzlich auf Deutsch übersetzen, (so wie es z.B. in den Flashversionen) damit auch der eine oder andere Anfänger, so wie ich es bin, einen besseren Durchblick erhalten!!! Hoffentlich gibt's jetzt kein Augenrollen bei den Profis... Mein Gedanke dabei ist, das sich dann auch weniger Versierte hier beteiligen und ihren Beitrag zum Projekt leisten können, denn viele Augen, sehen auch mehr...und wenn es auch nur Kleinigkeiten sind (vielleicht mit großer Wirkung), die Andere nicht sehen oder gesehen haben. Wie auch immer, wäre nur ein Vorschlag von mir... Grüsse an alle aus dem Hessenland
@ mike0815: kleine Korrektur noch: Die Kalibrierwerte werden im Flash gespeichert wenn du die Zeitbasis verstellst. Erst danach ausschalten. Gruß, Guido
mike0815 schrieb: > ach, das wird wieder eine HE?? Ja ich dachte mir da es im Prinzip eine fehlerkorrigierte 0.92HE ist werde ich das HE mal mit anhängen um den Bezug herzustellen und um klarzustellen, dass es keine offizielle Version aus dem SFN ist. > Jedenfalls, macht es hier einen riesen Spass! Das geht uns allen auch so, daher verbraten wir hier ja auch soviel Zeit anstatt soziale Kontakte zu pflegen ;-) > Ich selber bin noch in der Aufbauphase was den Umgang mit Oszilloskopen > betrifft, da es mein Erstes ist...nach 35 Jahren...'lach' Ist doch zum Kennenlernen von Theorie und Praxis geradezu ideal dieses Projekt! > Immerhin habe ich keine Probleme beim Backup und Flashen, Quartus und > der USB-Treiber von Slog ist ebenfalls installiert und funzt ohne > Probleme, würde ja gerne mehr experimentieren, nur habe ich so manche > Bedenken, beim Aufspielen z.B. EPCS16N aufzuspielen, nicht das ich da > noch was versaue!!! Da kann ich wenig zu sagen, da ich mich bislang größtenteils auf die reine FW-Entwicklung konzentriert habe. Allerdings wollte ich das bei Gelegenheit auch mal ausprobieren. > Schade, das die Google-Groups nicht mehr so gepflegt wird, da ich diese > für übersichtlicher halte als die SVN. Das fand ich auch, da ließen sich recht unkompliziert einfach mal ein paar Dokus oder Softwarebundles ablegen. > Vielleicht könnte man von dem Projekt einige Kopien dort hinein setzen > und somit auch die eine oder andere Anleitung zusätzlich auf Deutsch > übersetzen, (so wie es z.B. in den Flashversionen) damit auch der eine > oder andere Anfänger, so wie ich es bin, einen besseren Durchblick > erhalten!!! Leider wurde die Seite für den Upload gesperrt und wird vermutlich auch nicht wieder geöffnet um den Fokus auf die SFN-Seite zu setzen. Gruß Hayo
Guido schrieb: > @ mike0815: kleine Korrektur noch: Die Kalibrierwerte werden im > Flash gespeichert wenn du die Zeitbasis verstellst. Erst danach > ausschalten. Hi Guido, kleine Korrektur meinerseits, seit einigen Versionen (frag mich jetzt nicht nach der genauen) werden die Einstellungen direkt gespeichert. Das erkennst Du an folgendem Coding: //Save new values to flash config_changed = true; Diese Variable wird beim Durchlauf der Hauptschleife jeweils einmal ausgewertet und wenn sie gesetzt ist werden alle gerade aktuellen Konfigurationsdaten ins Flash geschrieben. Gruß Hayo
Hallo, > > Die 0.93HE steht in den Startlöchern. < >ach, das wird wieder eine HE?? Ist ja wurscht... Also mir ist das ganz und gar nicht wurscht! Ab dem 05.10 werde ich wieder an der GUI weiter entwickeln (Mein Co-Programmierer ist derzeit anderweitig beschäftigt). Leider ist in den HE Versionen der Datentransfer nicht im vollen Umfang verwirklicht (Befehlssatz gem. SF), demzufolge kann ich diese nicht zur Entwicklung heranziehen! Die in den Grundzügen bereits vorhandene GUI baut ergo auf die OS 0.91 auf.... schade, da mit dieser Version bei mir massive Probl. bei höheren Freq. auf Ch1 auftreten. Gruß, brunowe
hallo Hayo, > Ja ich dachte mir da es im Prinzip eine fehlerkorrigierte 0.92HE ist...< ...stimmt, bin ich ganz deiner Meinung!!! > ...anstatt soziale Kontakte zu pflegen ;-) < nun ja, man(Mann) sollte das tun, was ihm Spass macht, das Leben ist kurz... > Ist doch zum Kennenlernen von Theorie und Praxis geradezu ideal dieses Projekt! < ABSOLUT!!! > Da kann ich wenig zu sagen, da ich mich bislang größtenteils auf die reine FW-Entwicklung konzentriert habe. Allerdings wollte ich das bei Gelegenheit auch mal ausprobieren. < Das ist auch gut so, denn so hat jeder seinen Part, der Tag hat ja nur 24 Std.(leider) > Das fand ich auch, da ließen sich recht unkompliziert einfach mal ein paar Dokus oder Softwarebundles ablegen. < ist das denn im SVN nicht auch möglich??? Ja ich weiß, Innternational (Die Russen sehr aktiv...) Nur könnte das eine oder andere in Englisch falsch verstanden werden, also mir geht's manchmal so, dann komme ich in's schleudern, wie wäre es mit Kopien in deutscher Sprache??? Ich denke, das das der eine oder andere Hobbyist begrüssen würde, da ja nicht alle der englischen Sprache (z.B. Spezialausdrücke...) mächtig sind. > Leider wurde die Seite für den Upload gesperrt... < hmm, wieso das denn? Könnte man das nicht parallel bestücken, oder wäre da der Aufwand zu groß??? Gruß Michael
Hayo W. schrieb: > Diese Variable wird beim Durchlauf der Hauptschleife jeweils einmal > ausgewertet und wenn sie gesetzt ist werden alle gerade aktuellen > Konfigurationsdaten ins Flash geschrieben. Erfolgt das Setzen in Interrupt-Handlern? Dann erfolgt das Rücksetzen&Flashen hoffentlich unter Ausschluss von weiteren Interrupt? ;)
hallo brunowe,
>Also mir ist das ganz und gar nicht wurscht!<
...das konnte ich ja nicht wissen, wie werdet ihr euch denn da jetzt
einig? Jetzt wird's kompliziert, wenn sich die Versionen dermaßen
unterscheiden?!?
...un nu?
Gruß Michael
@Bruno Wenn die 0.93HE hier getestet wurde und keine größeren Fehler mehr auftreten, können die Änderungen in die OS-Version einfließen. Bislang war das Ganze noch nicht ausgereift genug um es einfach da rein zu mergen. Es handelt sich doch zum Teil um recht umfangreiche Änderungen, daher möchte ich vorher sichergehen das da dann nicht neue Fehler mit in die OS-Version eingebaut werden (so wie sie ja in der 0.92HE vorhanden waren). Die wären ja ansonsten jetzt schon mit drin. Andererseits muß ich erst prüfen ob ich alle Änderungen der OS-Version auch in meiner eigenen Version haben möchte. Mir fehlt da momentan der Überblick ob das alles stabil läuft und ungeprüft will ich das nicht einfach so übernehmen. Gruß Hayo
Ich nochmal zum "DAC-Abgleich" ...habe festgestellt(W2022A-092HE), das wenn ich die DAC-Kalibrierung durchgeführt habe und dann den NOIS Filter einschalte, ich nochmals einen Abgleich durchführen muß (DAC-Taste drücken), diesmal nur 1x in den 5er-Bereichen, in allen anderen Bereichen, muß ich mindestenst 1-4x die DAC-Taste drücken, dann erst ist alles hübsch! Dann hätte ich noch eine Frage zum Coupling-Mode, was für eine Bewandnis hat es mit dem PROBE-Softkey? Welche Funktion hat er? Kann ich intern 1:1 - 1000:1 schalten oder was hat er für eine Funktion? Gruß Michael
Wenn du einen Tastkopf mit Vorteiler anschließt, muss das Oszi das doch wissen, damit trotzdem die richtigen Spannungswerte angezeigt werden. Wenn du den Tastkopf von 1:1 auf 10:1 umschaltest, wird doch sonst Mist angezeigt. Gruß Michael
Michael H. schrieb: > Wenn du einen Tastkopf mit Vorteiler anschließt, muss das Oszi das doch > wissen, damit trotzdem die richtigen Spannungswerte angezeigt werden. > Wenn du den Tastkopf von 1:1 auf 10:1 umschaltest, wird doch sonst Mist > angezeigt. > > Gruß > Michael ...logisch! Ist denn der 'MIST', der da angezeigt wird, so erheblich bzw. die Werte falsch? Wenn ich am Tastkopf 10:1 eingestellt habe, dann habe ich z.B. 680mV als 6,8V umgerechnet... ...nun ja, das ist dann natürlich eine angenhme Sache, d.h. wenn ich den Tastkopp auf 10:1 stelle muß ichh den PROBE-Knopp auch auf 10:1 schalten? Habe das eben mal gestestest: Tastknopp 10:1 und Probeknopp ebenfalls auf 10:1 und wieder zurück auf 1:1... Es gibt vom Messverhalten keinen Unterschied beim verstellen des PROBE-Knopp's! ...und stimmt, bei Tastkoppschalter 1:10 kommt Müll raus, ist da jetzt der Eingang hinüber, oder was? Gruß Michael
Hallo Michael, bevor du noch lange weiterfragst, würde ich dir folgenden Link einmal empfehlen: http://www.google.de/#hl=de&source=hp&q=messen+mit+dem+oszilloskop&btnG=Google-Suche&meta=&aq=0&oq=messen+mit+dem+oszilloskop&fp=8fee3db28befc153 Danach solltest du dir einen Großteil deiner Fragen selbst beantworten können. Gruß, branadic
Ansonsten bleibt noch zu erinnern: Man kann an 2 Orten den Vorteiler einstellen: Im Kanal- und im Trigger-Menü...
@Michael Kauf dir ein Tek - das erkennt, wenn du am Tastkopf 10:1 eingestellt hast... ;-)
...jetzt hab' ich mein Fett weg... ...ein Tek, ja genau, vielleicht mach ich noch ne' Sammlung auf.
So, jetzt muss ich doch mal meinen Senf dazu geben! Hayo W. schrieb: >Da es sich nicht um offizielle Releases handelt, sondern um >Testversionen poste ich sie hier. Die 0.92HE findest Du etwas weiter >oben, die 0.93HE kommt in Kürze auch hier. Dabei handelt es sich im >Wesentlichen um eine Fehlerkorrektur der in der 0.92HE gemeldeten >Fehler. Allerdings habe ich dafür einige Sachen komplett umgestrickt, so >dass es über eine einfache Korrektur doch schon hinausgeht. >Hayo Was heisst hier"nicht offizielle Releases"? Du hast doch mindestens 90% der bisherigen (NIOS1-) Firmware Entwicklungsarbeit geleistet und hast mittlerweile den besten Überblick über Struktur und Konzept! Für mich und sicher auch andere ist es immer noch das offizielle Release, da nicht nur punktuell an einigen Ecken geändert wurde! Und, so umfangreich waren die bisherigen Änderungen in der 0.91 ja wohl nun doch nicht, daß sie nicht mit einer 0.93HE zusammen geführt werden könnten. Deshalb bitte: Die 0.93HE wieder mit Sourcen veröffentlichen, damit man sich ein Bild machen kann, wo denn nun die Ergänzungen der sogenannten"offiziellen Version"liegen! Musste ich mal loswerden. Gruß Jürgen
Hallo Jürgen, mein Vorschlag als einer der Ersten der das Projekt überhaupt zum Leben gebracht hat... melde dich bei SF an, und merge die Versionen!!! Trotz SVN ist genau das die Arbeit, vor der sich derzeit jeder etwas scheut... Gruß, brunowe
Hi, der Grund warum ich erstmal keine Sourcen beigelegt habe ist, dass ich eine Abspaltung der Entwicklungslinie verhindern wollte. Wenn jemand die Sourcen in die OS-Version mergen möchte lege ich die Sourcen aber gerne bei. Ich selbst entwickle zur Zeit immer noch auf der Basis meiner eigenen FW da mir die Änderungen an der OS-Version nicht verifiziert bzw. validiert genug sind. Mir fehlt da momentan der Überblick wer da alles an welchen Baustellen herumflickt und ob das alles richtig gestestet wird. Daher ist es mir (zumindest momentan) lieber, die Änderungen die ich in meiner FW ausgiebig getestet habe nachträglich in die OS-Version einfließen zu lassen, bzw. sinnige Änderungen aus der OS-Version zu übernehmen. By the way: gibt es einen konkreten Status zur Remoteschnittstelle und zur Screenshotfunktion? Läuft das stabil? Gruß Hayo
Hallo Hayo, der Status der implementierten Befehle ist hier dokumentiert: http://sourceforge.net/apps/trac/welecw2000a/wiki/RemoteControlAPI Das USB Protokoll ist hier beschrieben: http://sourceforge.net/apps/trac/welecw2000a/wiki/USB-Protocol Der Datentransfer via RS232 läuft absolut stabil. Leider lassen die derzeit möglichen 115kBd keine tolle refresh- rate bei meiner GUI zu. Die RS232 ist da eindeutig der limitierende Faktor was z.B. die live Darstellung einer FFT betrifft (ca. 2-3 Bilder/s). Im neuen VHDL Design kann die Transfer- Rate wohl zumindest auf 230kBd gesteigert werden, aber da sollen sich die VHDL Profis ruhig noch etwas spielen. Gruß, brunowe
Bruno We schrieb: > Im neuen VHDL Design > kann die Transfer- Rate wohl zumindest auf 230kBd gesteigert werden, Nee, auch im originalen Design von den Wittigs ist doch die 2. UART, die mit dem FX1 verbunden ist, in ihrer Baudrate konfigurierbar. Das einzige was zu 230KBd fehlt, ist eine USB-UART-Firmware für den FX1.
Hayo W. schrieb: > Hi, > > der Grund warum ich erstmal keine Sourcen beigelegt habe ist, dass ich > eine Abspaltung der Entwicklungslinie verhindern wollte. Wenn jemand die > Sourcen in die OS-Version mergen möchte lege ich die Sourcen aber gerne > bei. Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware"
Hallo, > Nee, auch im originalen Design von den Wittigs ist doch die 2. UART, die > mit dem FX1 verbunden ist, in ihrer Baudrate konfigurierbar. Das einzige > was zu 230KBd fehlt, ist eine USB-UART-Firmware für den FX1.... Ok... soweit logisch. Dachte allerdings das der FPGA die Daten dann auch in der dementsprechenden Geschwindigkeit "weiter schieben" muss?! Oder ist die Geschwindigkeit via FW anpassbar, also nicht via HW fix vorgegeben? Gruß, brunowe
Hallo brunowe, >mein Vorschlag als einer der Ersten der das Projekt überhaupt zum Leben >gebracht hat... Danke sehr dafür ! >melde dich bei SF an, und merge die Versionen!!! >Trotz SVN ist genau das die Arbeit, vor der sich derzeit jeder etwas >scheut... Das ist wohl nicht der wirkliche Grund. Ich bin erstmal zufrieden, daß ich mir die aktuellen Sourcen z.Zt.in einem Stück herunter laden kann u hab jedenfalls keine Lust mich erst wieder durch seitenlange Help-Files zu kämpfen und am Ende vom System unverständliche Fehlermeldungen zu bekommen. Gruß Jürgen
@ brunowe Brunowe schrieb: >Das USB Protokoll ist hier beschrieben: >http://sourceforge.net/apps/trac/welecw2000a/wiki/... Diese Beschreibung ist doch wohl sehr unvollständig! Was ist denn mit der original Protokollbeschreibung von Welec, zusammengestellt von Jochen Schäuble? http://schaeuble.info/de/category/jochen/w2000a Das USB Protokoll funktioniert so noch in der OS 0.91. Allerdings ist dieses Protokoll überhaupt nicht auf Geschwindigkeit optimiert. Oder soll Deine GUI nur über RS232 laufen und das USB-Protokoll hat darauf keinen Einfluß? Beste Grüße, Jürgen
Hi ...
Nach dem ich einige Tage Don Quichotte gespielt habe, nun einige
Kommentare zum Thema svn/sfn von mir:
Begriffsunterscheidung:
svn: Abkürzung für Subversion - System zur Versionsverwaltung
(Source-Code, Messdaten, Texte) - ich verwende dieses z.B.
für Messdaten ebenso wie für Texte (u.a. meine damalige DA)
als auch für Sourcen.
svn bietet hier die nette Möglichkeit, Änderungen zu
dokumentieren und ggf. wieder Rückgängig zu machen.
trac: System zur Verwaltung von Projekt-Daten - spielt wunderbar
mit svn, enthält u.a. ein Wiki ein Ticketsystem und bietet
die Möglichkeit, Änderungen im Source und Tickets zu
verlinken (damit mensch nachher sehen kann, wofür die
Änderung gemacht wurde (Bugfixes))
sfn: Plattform für Open-Source Projekte, u.a. mit verteilter
Distribution und Angebot, svn, und trac zu verwenden.
Wenn jemand nun auf die Seite:
http://sourceforge.net/apps/trac/welecw2000a/
geht, landet man im Trac-Wiki des SFN-Projektes und kann sich
z.B. die Sourcen (mit Änderungen) im svn oder offene/geschlossene
Tickets ansehen.
Oben auf der Seite steht:
"Visit project welecw2000a", ebenso wie "Welec W2000A". Beide
Links führen auf die Seite:
http://sourceforge.net/projects/welecw2000a/
Dort befindet sich eine Sektion "Files". In dieser Sektion
findet man die Releases - also die herausgegebenen Versionen.
Während im svn (derzeit) nur die Sourcen drin sind, sind hier
auch die compilierten Versionen (soweit verfügbar) drin, welche
sich dann einfach in das DSO hochladen lassen.
Die Sourcen einiger Releases (es sollten eigentlich alle sein ;)
findet man im svn unter:
http://sourceforge.net/apps/trac/welecw2000a/browser/fpga/nios/oss/tags
Das Verzeichnis
http://sourceforge.net/apps/trac/welecw2000a/browser/fpga/nios/oss/trunk
enthält den derzeitigen Entwicklungstand (der OS Version).
Über das Verzeichnis
http://sourceforge.net/apps/trac/welecw2000a/browser/fpga/nios/oss/branches
können z.B. Abzweigungen im Source-Tree (tiefgreifende Änderungen,
Version 2.0, etc) verwaltet werden (um diese dann später wieder
in den trunk einzupflegen)
Wird auf Basis des svn(-Tree) gearbeitet, so lassen sich
Versionskonflikte zumeist sehr einfach lösen. Hier könnten wir aber das
Problem haben,
dass der Dateiaufbau der BF und der der OS sich unterscheiden. Falk
hatte damals die Änderungen von Hayo eingepflegt, das war aber eben mal
drei Stunden Arbeit (und händisches einpflegen ist eher fehleranfällig).
Die Arbeit mit svn scheint erstmal sehr viel Overhead zu haben,
hat sie aber nicht - ist der Client der Wahl (gerne auch cli) gefunden,
so ist die Lernkurve sehr steil (Nach dem Motto: einen Tag für den
Client der Wahl, 'nen viertel Tag für das svn) und die Vorzüge einer
Versionsverwaltung sind in einem Projekt (egal ob Text, Source oder
Messdaten) nicht zu unterschätzen (wer einmal Rohdaten weggeworfen hat
und sie nachher wieder brauchte wird dies bestätigen können).
Wenn ich mir die Tickets im Trac ansehe
(http://sourceforge.net/apps/trac/welecw2000a/report/1)
sieht man, dass sowohl in der BF als auch in der OS Fehler offen sind.
Wir können nun daraus zwei Baustellen machen. Oder gemeinsam an
einer
arbeiten.
Grüße,
rowue
PS: Zur Qualität der Änderungen: Ich arbeite hier gerade an einer
Abweichung von 1,8% ...
> PS: Zur Qualität der Änderungen: Ich arbeite hier gerade an einer > Abweichung von 1,8% ... Dann möchte ich dich vielleicht auf den unteren Teil dieser Seite aufmerksam machen: http://sourceforge.net/apps/trac/welecw2000a/wiki/HardwareImprovement Gruß, branadic
branadic schrieb: >> PS: Zur Qualität der Änderungen: Ich arbeite hier gerade an einer >> Abweichung von 1,8% ... > > Dann möchte ich dich vielleicht auf den unteren Teil dieser Seite > aufmerksam machen: > > http://sourceforge.net/apps/trac/welecw2000a/wiki/HardwareImprovement merci ;) > > Gruß, branadic Beste Grüße, rowue
Hallo Leute! Hat jemand von Euch mit dem Vinculum Board weitergearbeitet? Der USB Stick hat leider sehr unterschiedliche Zugriffszeiten sodass wahrscheinlich ein FIFO und ein Handshake in die Kommunikation mit dem Oszi eingebaut werden muss. Es wäre schön, wenn jemand der das bisherige Protokoll versteht es mal im Klartext notieren könnte. Damit meine ich die den Teil der den Screenshot einleitet, die Lauflängendekodierung und die Bilderstellung. Dann könnte man das Protokoll in Richtung Handshake optimieren und auf den Mikocntroller portieren. Mfg, Kurt
Hallo zusammen, da viele scheinbar ja ein unglaubliches Problem mit der englischen Sprache haben, gibt es jetzt im SourceForge phpBoard einen deutschsprachigen Bereich. Zu finden ist das Ganze hier: http://sourceforge.net/apps/phpbb/welecw2000a/ Eine Anmeldung bei SourceForge ist natürlich notwendig, dafür sind die wichtigen Diskussionen dann unmittelbar mit der Haupt-Projektseite verbunden und nur wirklich Projektinvolvierte nehmen an der Diskussion teil. Das Forum bitte nicht mit sinnlosen Kommentaren füllen, die allgemeinen Regeln einhalten und bei Fragen, einfach eine Mail an die Administration senden, bspw. wenn ein neues Unterforum angelegt werden müsste/könnte. Topics dürft ihr selbst starten. Bitte haltet die Struktur ein. Für Anregungen ist euere Meinung aber gern gefragt. Topics bitte hinreichend genau benennen, damit alles auch übersichtlich bleibt. So ist im Firmware-Bereich die Struktur: NIOS - Problemstellung ZPU - Problemstellung LEON3 - Problemstellung denkbar, allerdings könnten hier auch extra Unterforen für die 3 Prozessoren angelegt werden. Ich denke wir kommen damit den nicht englischsprachigen Leuten sehr weit entgegen, nutzt die Plattform bitte auch. Beste Grüße, branadic
Hi, hat etwas gedauert mit der nächsten Version, aber zum Ende des Sommers müssen halt erst die restlichen Arbeiten im Garten fertig werden, sonst gibts Ärger von der Chefin. Auch wenn sich oberflächlich außer der Fehlerkorrektur scheinbar nicht so viel getan hat, sind die Änderungen unter der Haube recht umfangreich. Das DSO startet jetzt nach dem Ausschalten immer mit der letzten (gespeicherten) Einstellung vor dem Ausschalten. Neu ist hierbei unter Anderem die Unterstützung für den Math-Betrieb (auch FFT) und den USTB-Betrieb. Um etwas kompatibler zur OS-Version zu sein habe ich Falks aktuelle Version der Remoteschnittstelle mit eingebaut. Ich habe es allerdings nicht mehr geschafft die Screenshot-Version umzurüsten, daher bitte wieder die beigelegte Version verwenden. Da es letztens hier angefragt wurde lege ich die Sourcen diesmal bei. Achtung - dies ist keine Entwicklerversion für das SFN! Nach erfolgreichen Tests können die Änderungen je nach Zustimmung in die SFN-Version übernommen werden. Ob ich das mache oder jemand anderes können wir ja noch klären. Gruß Hayo
Hallo zusammen, ich habe ja lange nichts mehr von mir hören lassen. Aber ab nächster Woche ist wieder mehr Zeit. Da werde ich sicher wieder die eine oder andere Sache beisteuern können. @Hayo Leg dir doch im SFN einen branch an. Dann kannst du ungestört deine Sourcen einpflegen, während du gleichzeitig alle Änderungen im trunk mitbekommst.
Stefan E. schrieb: > Hallo zusammen, > > ich habe ja lange nichts mehr von mir hören lassen. Aber ab nächster > Woche ist wieder mehr Zeit. Da werde ich sicher wieder die eine oder > andere Sache beisteuern können. Super! > Leg dir doch im SFN einen branch an. Dann kannst du ungestört deine > Sourcen einpflegen, während du gleichzeitig alle Änderungen im trunk > mitbekommst. Da muß ich zu meiner Schande gestehen, dass ich noch keine Zeit gefunden habe mich mit SVN und drumherum auseinanderzusetzen. Wenn ich zwischendurch Zeit hatte hab ich nur an der FW rumgeschraubt. Muß ich also noch ran. Dann werde ich Deinen Vorschlag mal aufgreifen. Ansonsten noch an alle viel Spaß beim Testen, Gruß Hayo
Hayo W. schrieb: > Hi, > hat etwas gedauert mit der nächsten Version, aber zum Ende des Sommers > müssen halt erst die restlichen Arbeiten im Garten fertig werden, sonst > gibts Ärger von der Chefin. Das wollen wir ja nicht! ;) > > [1.2.BF.094.HE] Ich habe die Version in's Ticket-System eingetragen, dann können evtl. Fehler dort gleich eingetragen werden ;) URL: http://sourceforge.net/apps/trac/welecw2000a/report > > Achtung - dies ist keine Entwicklerversion für das SFN! Nach > erfolgreichen Tests können die Änderungen je nach Zustimmung in die > SFN-Version übernommen werden. Ob ich das mache oder jemand anderes > können wir ja noch klären. Vorschlag: lass uns beide das doch gemeinsam machen ;) > > Gruß Hayo Grüße, rowue
Hayo W. schrieb: > Ok, > > wie hattest Du Dir das vorgestellt? Wir treffen uns Samstag (früher Nachmittag), erstellen erstmal einen unified diff Deiner aktuellen Sourcen zum Stand 0.88 (war glaube ich der, den Hayo zum einpatchen vervendet hat) und patchen mit Hilfe dieses Diffs die Sachen in das svn. Treffen könne wir uns (von meiner Seite aus) bei Dir, bei mir oder bei mir in der Firma. Zu Dir müsste ich mit Bus/Bahn und (ggf.) Fahrrad. Bei mir stände uns ein grosser Schreibtisch und eine seperate Werkbank zur Verfügung. Da ich gerade zwei Geräte (W2014A, W2022A) zur Verfügung habe, könnten wir die Patches auch gleich auf beiden Geräte testen. Wenn Du das Tek mitbringst, könnten wir uns ebenso die Ausgaben des HP auf den drei Geräten ansehen. Bei mir in der Firma hätten wir in der Werkstat viel Platz und Internet bis zum Abwinken, müssten aber evtl. unsere Geräte (falls wir was testen möchten) rantragen (ISP). > > Gruß Hayo Grüße, rowue
Hi allerseits, hier die aktualisierte 0.95HE - Bruno war aufgefallen dass die Remoteschnittstelle nicht funktioniert, daher habe ich nochmal gesucht und festgestellt, dass ich vergessen hatte die UART-ISR mit nachzuziehen. Das sollte jetzt also funktionieren. Falls es noch Probleme gibt immer raus damit. @Rolf Hört sich echt gut an, leider bin ich jetzt am WE komplett ausgebucht, da ich Besuch aus dem Ruhrpott bekomme. Grundsätzlich können wir das aber gerne machen. Welche der Örtlichkeiten wir dann wählen können wir dann ja kurzfristig abstimmen. Gruß Hayo
Hi Hayo, konnte zwar gestern nur kurz testen, aber bei 1Gs/s-50ns/div und Noise Filter on und im Single Shot wandert die die Anzeige im Stop unweigerlich nach links aus dem Bildschirm hinaus. Passiert aber nur mit eingeschaltetem Noise Filter. Bei Normal und Averaging nicht! Gruß Jürgen
Hayo W. schrieb: > Hi allerseits, > > [0.95HE] Habe das Ticket-System angepasst (und die 0.94HE dort gelöscht) Es wäre nett, wenn Fehlermeldungen (überwiegend) dort landen ;) > > @Rolf > > [Besuch aus dem Pütt] O.K. - wollen wir dann das nächste Wochenende (10./11.10., preferiert: Samstag, den 10.10) in's Auge fassen? ;) > > Gruß Hayo Grüße, rowue
@Jürgen Ok, habs mir mal angesehen. Scheint vorher noch niemendem aufgefallen zu sein, denn das Problem müßte eigentlich auch bei den älteren Versionen auftreten. Ich weiß auch schon so ungefähr woran es liegt. Danke für den Hinweis Hayo
Ok, Bug erkannt - Gefahr gebannt. Ist erledigt. Nebenbei habe ich noch die Start/Stop-Logik beim Singleshot optimiert. Gruß Hayo
Hayo W. schrieb: > @Jürgen > > Ok, habs mir mal angesehen. Scheint vorher noch niemendem aufgefallen zu > sein, denn das Problem müßte eigentlich auch bei den älteren Versionen > auftreten. Schau mal in's Ticket-System ;) http://sourceforge.net/apps/trac/welecw2000a/report/1 > Ich weiß auch schon so ungefähr woran es liegt. > > Danke für den Hinweis > > Hayo Grüße, rowue
Du meinst Ticket 39?? Das hatte ich nicht damit in Verbindung gebracht, da die Beschreibung eher in eine andere Richtung wies. Werde ich dann resolven wenn die Korrektur raus ist. Hayo
So, da nach über 50 Downloads jetzt keine weiteren Rückmeldungen vorliegen scheint es zumindest keine gravierenden Schnitzer zu geben. Die Remoteschnittstelle scheint daher wohl auch zu funktionieren. Daher hier nochmals eine fehlerkorrigierte HE. Das wegdriftende Signal im Stopmodus bei eingeschaltetem Noise-Filter ist gefixed. Bei der Gelegenheit habe ich die Run/Stop/Single-Logik komplett überarbeitet, so dass diese jetzt vernünftig funktioniert. Nebenbei habe ich noch weiter das Coding aufgeräumt und tote Variablen und Coding gelöscht. Beim ersten Start könnte es leichte Nebeneffekte geben, da sich das Flashlayout mal wieder etwas geändert hat. Ein einfaches Default-Setup sollte das aber beheben. Gruß Hayo
Hayo W. schrieb: > Du meinst Ticket 39?? > Jupp ;) > Das hatte ich nicht damit in Verbindung gebracht, da die Beschreibung > eher in eine andere Richtung wies. Werde ich dann resolven wenn die > Korrektur raus ist. Die Beschreibung war nicht allzu gut - sorry ... ich hatte das Phänomen, dass am linken Rand (des Signals) dieses bei Betätigen der Stop-Taste an den oberen Bildschirm-Rand zog. > > Hayo Grüße, rowue PS: Du hast ja heute morgen gut im Ticket-System aufgeräumt
Die Single/Run Logik kapiere ich noch nicht so recht - hilfst du mir auf die Sprünge? Michael
Ah da stimmte noch was nicht mit meiner Masse, jetzt macht das ganze Sinn und scheint auch gut zu funktionieren. Michael
Zum Singlemodus ist noch anzumerken, dass der Triggermode zwangsweise in den Normalmodus geschaltet wird, damit auch wirklich nur dann ein neues Ereignis ausgelöst wird wenn die Triggerschwelle überschritten wird. Sollte da aber nichts kommen (zu hoher Triggerlevel oder so) wartet das DSO natürlich bis zum Sankt Nimmerleinstag. Der Singlemodus steht jetzt nur noch dann zur Verfügung wenn der Single-Druckknopf grün hinterleuchtet ist - dazu muß man die Run/Stop-Taste drücken. Im aktivierten Zustand ist der Druckknopf orange hinterleuchtet. Nach erfolgtem Triggerereignis ist er wieder grün und signalisiert damit Bereitschaft. Das Ganze wird durch erneutes Drücken der Run/Stop-Taste beendet. Gruß Hayo
Rolf Würdemann schrieb:
> PS: Du hast ja heute morgen gut im Ticket-System aufgeräumt
Sind aber noch genug für alle da... ;-)
Gruß Hayo
Hayo W. schrieb: > Rolf Würdemann schrieb: >> PS: Du hast ja heute morgen gut im Ticket-System aufgeräumt > > Sind aber noch genug für alle da... ;-) Wink verstanden ;) Ich hoffe mal, dass ich Fr/Sa mit der Geschichte an der ich gerade bin durch bin, dann kann ich mir das eine oder andere "greifen" ;) > > Gruß Hayo Grüße, rowue
Hallo, ist es Absicht, dass wenn ich Quickmeasure aus und dann wieder einschalte die Kanalwahl der einzelnen Messfunktionen überschrieben wird? Denke ja hoffentlich mal nicht. Hab das mal rausgenommen. Jetzt bleibt die Kanalwahl der einzelnen Messfunktionen beim Aus- und Einschalten von Quickmeasurement erhalten. Ich werde die Änderungen in den aktuellen trunk der OSS ablegen. Ich hoffe odch, dass irgendwann hier auch mal deine Änderungen erscheinen. Es ist schon ein Aufwand in zwei Verisonen immer nachzuschauen, ob jemand anderes das Problem vielleicht schon gefixt hat.
@Hayo Ich habe mich mal daran veruscht, die HE0.96 und die OSS.91 zusammenzuführen, damit wir wieder an einem Strang ziehen. Hat auch fast alles geklappt. Kannst du mal schauen, ob noch alles drinnen ist, was du die letzte Zeit gemacht hast. Außerdem habe ich bei der RS232-Verbindung irgendwas vermischt. Jedenfalls geht die Screenshot-Funktion derzeit nicht. In tc_vars.cpp Zeile 2570 & 2450 habe ich den Überblick verloren, was den nun eigentlich ins Menü für den Screenshot rein muss. Bin da gerade nicht so auf dem laufenden. Vielleicht kannst du die Screenshot-Funktion wieder richten. Blicke da gerade nicht durch ;-)
Hallo Stefan, hallo Hayo, schön das du am mergen bist Stefan! Ich hoffe du nimmst die Remote Control Funktionen aus der OS.91 da die in der HE 0.96 definitiv noch einige Probleme haben! Wollte ein Ticket aufmachen, da aber die 0.96 nicht im Ticketsystem ist, hab ich's erst mal gelassen (ob der Fehler auch in der 0.95 auftaucht, hab ich nicht getestet). Ich Hatte auch keine Lust das Ganze ausführlich zu testen, da mich das bei meiner GUI Programmierung nur behindert. Der "Dump data STX ASCII 03" liefert definitiv falsche Daten, Die continious dump Befehle zeigen gar keine Wirkung... Hier hab ich mal einen Screenshot der neuen GUI veröffentlicht, damit man auch sieht wo das Ganze hinführen wird... http://sourceforge.net/apps/phpbb/welecw2000a/viewtopic.php?f=18&t=34 Gruß, brunowe
Hallo brunowe, ich hab nochmal ein paar Änderungen gemacht. Kannst du die nochmal mit deiner GUI testen? Die Screenshoot-Funktionen sind jetzt wieder aus der OSS und die Remote-Steuerung habe ich veruscht komplett zu übernehmen. Wenn du und grünes Licht gibst, dass dein Zeug noch funktioniert übernehme ich es heute Abend in SF.
Stefan E. schrieb: > Hallo brunowe, > > ich hab nochmal ein paar Änderungen gemacht. Kannst du die nochmal mit > deiner GUI testen? > > Die Screenshoot-Funktionen sind jetzt wieder aus der OSS und die > Remote-Steuerung habe ich veruscht komplett zu übernehmen. Wenn du und > grünes Licht gibst, dass dein Zeug noch funktioniert übernehme ich es > heute Abend in SF. Committe meinetwegen einfach, wenn es Probleme mit der PC-Kommunikation gibt, kümmere ich mich darum. Falk http://sourceforge.net/apps/phpbb/welecw2000a/
Hi, besten Dank schonmal an Stefan für das Mergen der Versionen, ich weiß nicht wann Rolf und ich sonst dazu gekommen wären. Zur Remote-Schnittstelle: Da mir die Testmöglichkeiten fehlen habe ich die OS-Sourcen nach offensichtlichen Änderungen durchsucht und diese dann bei mir eingebaut. Kann gut sein, dass noch eine Kleinigkeit fehlt, die mir nicht aufgefallen ist, hier sollte aber die OS-Version die Vorgabe liefern. Zum Screenshot: Ich hatte das Druckmenü bei mir so geändert, dass die einzelnen Funktionen vom DSO aus anwählbar sind und daher die Screenshotfunktionen mit einem Parameter versehen. Um mit der aktuellen PC-Software kompatibel zu sein, müssen die Screenshotfunktionen der OS-Version verwendet werden - auch die RLE Encoderfunction! Um das Ganze zu mergen gibt es zwei Varianten: Entweder muß die Menüstruktur der OS-Version verwendet werden, dann werden keine Parameter gebraucht, oder die Screenshotfunktionen und die PC-Software werden um diese Parameter erweitert, dann kann meine Menüstruktur verwendet werden (Definition in tc_vars 2450/2570/2607). Die flash_t kann vermutlich komplett von mir übernommen werden, da dort wahrscheinlich keiner etwas geändert hat. In hardware_t gibt es die neuen Funktionen Reset_To_Default() und Restore_From_Flash() die bei der neuen Startupsequenz genauso zum Einsatz kommen wie bei der Recall-Funktion und der Autoscale-Undo-Funktion. -> handle_ADC() hat sich unter Anderem geändert! In userif_t hat sich ebenfalls einiges getan, unter anderem die neue Run/Stop/Single-Logik im Button handler. commif_t kann größtenteils von der OS-Version übernommen werden, hier habe ich nur im USB-Transfer einige tote Variablen entfernt (CH1_DAC_1 usw.) In display_t haben sich die Draw-Routinen etwas geändert. In signal_t hat sich die Noise Suppression etwas geändert (if-Bedingung - siehe Ticket 39) Ich werde aber noch mal über Deine gemergten Files drüberschauen und mal sehen ob mir da was auffällt. Gruß Hayo
Wollte eben mal Deine gemergten Sachen besichtigen, kann aber in den ZIPs nichts finden. Hast Du eine exotische ZIP-Version, oder ist da einfach was schiefgelaufen? Gruß Hayo
Hayo W. schrieb: > Wollte eben mal Deine gemergten Sachen besichtigen, kann aber in den > ZIPs nichts finden. Hast Du eine exotische ZIP-Version, oder ist da > einfach was schiefgelaufen? Da sind nur ziemlich lange relative Pfade drin. Ich habs mal für Winzip vorverdaut ;-) Falk
@Falk Danke. @Stefan Ich habe mal userif_t.cpp geprüft - es gibt noch 5 Stellen die geändert werden müssen und je nach wunsch evtl. die Quick Print Menüfunktionen. Ich prüfe noch die anderen und stelle die überarbeiteten Files dann hier ein. Gruß Hayo
Hayo W. schrieb: > > Bei der > Gelegenheit habe ich die Run/Stop/Single-Logik komplett überarbeitet, so > dass diese jetzt vernünftig funktioniert. Mir gefiel das vorher besser! Mit der 0.96HE ist es nicht mehr möglich das Signal im stop mode zu analisieren (strecken, verschieben usw.) überdies wenn ich in den delay modus wechsle sind die Signale weg! grüss Martin
@Martin Ich habe im Stop-Modus das Drehgeberinterface blockiert, da sich die Nullpunktlage verschieben ließ, ohne dass das Signal folgte. Wenn das vom Handling gefälliger ist mit der Möglichkeit was zu verstellen, kann ich das auch wieder rausnehmen oder etwas feiner einschränken. Gruß Hayo
Martin H. schrieb:
> wenn ich in den delaymodus wechsle sind die Signale weg!
Das war mir noch nicht aufgefallen, ist in Arbeit...
Hayo
Hayo W. schrieb: > Martin H. schrieb: > >> wenn ich in den delaymodus wechsle sind die Signale weg! > > Das war mir noch nicht aufgefallen, ist in Arbeit... Können wir vielleicht endlich mal versuchen, eine Version zu pflegen? Wer einen Bug findet, meldet den hier: http://sourceforge.net/apps/trac/welecw2000a/report Der wird dann gefixt, der Bugreport wird bearbeitet, die Änderungen werden committed und ggfs. wird eine Release daraus gemacht, das man dann unter http://sourceforge.net/projects/welecw2000a/ herunterladen kann. Sonst wird das Durcheinander noch größer. Falk
@Falk Wenn ich noch was ändere, baue ich das in die gemergte Version mit ein, evtl. ändere ich aber auch erst nach dem Mergen direkt in der OS Version. Keine Sorge, ich mach jetzt deswegen keine neue Version auf. Gruß Hayo
@Stefan Beim Prüfen der gemergten userif_t.cpp ist mir aufgefallen, dass da an der QM-Funktion was geändert wurde. Da steht allerdings kein Änderer dabei. @all Sind diese Änderungen konsolidiert, oder ist das noch im experimentellen Status? Gruß Hayo
Hayo W. schrieb: > @Stefan > > Beim Prüfen der gemergten userif_t.cpp ist mir aufgefallen, dass da an > der QM-Funktion was geändert wurde. Da steht allerdings kein Änderer > dabei. > > @all > > Sind diese Änderungen konsolidiert, oder ist das noch im experimentellen > Status? Ich habe eben Stefans Files commited (revision 245). Falk
Bruno We schrieb: > Hallo Stefan, hallo Hayo, > > [....] Wollte ein Ticket aufmachen, da aber die 0.96 > nicht im Ticketsystem ist, hab ich's erst mal gelassen (ob der Fehler > auch in der 0.95 auftaucht, hab ich nicht getestet).[...] Habe die 0.96HE im Ticket-System nachgetragen > > Gruß, brunowe Grüße, rowue
>@Stefan >Beim Prüfen der gemergten userif_t.cpp ist mir aufgefallen, dass da an >der QM-Funktion was geändert wurde. Da steht allerdings kein Änderer >dabei. Das war ich. Hab mich wohl nicht eingetragen. Vorher wurden beim Ein-und Ausschalten von QM die ausgewählten Kanäle der Messfunktionen geändert. Das hab ich abgestellt. >Können wir vielleicht endlich mal versuchen, eine Version zu >pflegen? >Wer einen Bug findet, meldet den hier: >http://sourceforge.net/apps/trac/welecw2000a/report >Der wird dann gefixt, der Bugreport wird bearbeitet, die Änderungen >werden committed und ggfs. wird eine Release daraus gemacht, das man >dann unter http://sourceforge.net/projects/welecw2000a/ herunterladen >kann. >Sonst wird das Durcheinander noch größer Ganz meiner Meinung. Deshalb ja jetzt der "Gewaltschritt". Darauf kann ich jetzt aufbauen. Habe am Schluss nicht mehr gewusst, was schon in welcher Version behoben war. @Hayo Wenn du noch die letzten Änderungen schickst, aktualisiere ich das in SF, bis du dich damit mal selber befasst. Lieber viele kleine Schritte, als so ein großer. Danach würde ich die 0.92_OSS rausbringen, auf der wir alle weiterentwickeln.
>Da sind nur ziemlich lange relative Pfade drin. >Ich habs mal für Winzip vorverdaut ;-) Hab das unter OpenSuse gezippt. Das da dann überhaupt die Pfade mit drinnen sind ist mir neu. Das WinZip ein Mist ist dachte ich mir ja schon immer ... ;-)
@ Hayo Danke für die Erklärung zum QuickMeasure mit mehreren Kanälen. Ich hatte bis dahin nicht verstanden, dass das überhaupt möglich ist... Wenn ich mal auf Energiereserven in mir stoße, fange ich vielleicht mit einem kleinen Handbuch zur Firmware an, sicher haben andere auch Probleme, alle Möglichkeiten zu entdecken. Achja: bei mir funktioniert der delayed modus mit der 0.96 tadellos. Ich fände es auch gut, wenn man im Stop Mode die Möglichkeit zum Scrollen oder Zoomen (wo möglich) wieder bekommen könnte. Gruß Michael
Falk Willberg schrieb:
> Ich habe eben Stefans Files commited (revision 245).
Allein in der userif_t.cpp waren noch 5 fehlerhafte Stellen, die anderen
sind noch nicht geprüft.
Ist das so gewollt?
Gruß Hayo
Stefan E. schrieb: > Ganz meiner Meinung. Deshalb ja jetzt der "Gewaltschritt". Darauf kann > ich jetzt aufbauen. Habe am Schluss nicht mehr gewusst, was schon in > welcher Version behoben war. Damit testen kann, wer testen will, hier noch eine TomCat.ram aus den SVN-Sourcen: http://falk-willberg.de/tmp/TomCat.ram.gz Falk
Hallo werte W20xxA Besitzer und Interessierte! Da der Thread hier schon sehr sehr sehr lange geworden ist, habe ich mal einen zweiten Teil davon aufgemacht! Bitte hier weiterschreiben: Beitrag "Wittig(welec) DSO W20xxA Open Source Firmware (Teil2)" Danke ! l.G. Roberto
>Danke für die Erklärung zum QuickMeasure mit mehreren Kanälen. Ich hatte >bis dahin nicht verstanden, dass das überhaupt möglich ist.. Wir haben uns doch nicht irgendeinen billigen Oskar gekauft, bei dem QM nur auf einem Kanal gleichzeitig möglich ist. ;-) Ich denke, dass du dich auf #33 beziehst. Da hab ich versucht das zu erklären. ;-)
Roberto schrieb: > Hallo werte W20xxA Besitzer und Interessierte! > > Da der Thread hier schon sehr sehr sehr lange geworden ist, habe ich mal > einen zweiten Teil davon aufgemacht! > Bitte hier weiterschreiben: > Beitrag "Wittig(welec) DSO W20xxA Open Source Firmware (Teil2)" Ohne mich! Falk
Oh, da habe ich doch glatt dem falschen die Lorbeeren zugeschustert, so war das nicht gedacht. Stimmt, du warst ja der QM-Fachmann! Dann also danke nochmal an dich für die Erklärung und die gute Arbeit an den Messfunktionen. Ein gutes Beispiel für die Nützlichkeit habe ich hier gerade laufen: ein I2C Farbsensor, dessen Werte ich mit nem Controller als dreikanalige PWM ausgebe (RGB). Da kann man sehr schön sehen und messen, was für Farbanteile man da gerade hat. Jaja, die Welec-Kiste hat zwar noch ihre Macken, aber irgendwie ist sie mir doch schon ans Herz gewachsen :) Wie aufwändig ist es denn, die Messerei für die schnellen timebases zu fixen? Deinen Vorstoß zur Zusammenführung der Versionen finde ich auch klasse, es bahnte sich ja schon der eine oder andere Streit an deswegen. Gruß Michael
Hayo W. schrieb: > Falk Willberg schrieb: > >> Ich habe eben Stefans Files commited (revision 245). > > Allein in der userif_t.cpp waren noch 5 fehlerhafte Stellen, die anderen > sind noch nicht geprüft. Dann pflege die Fixes doch ein. > Ist das so gewollt? Ich wollte endlich wieder eine Basis haben, auf der ich sinnvoll weitermachen kann. Es gibt da ein paar Erweiterungen, auf die jemand wartet. Falk
@Hayo Es wäre schön wenn das Strecken und Verschieben des Signals im Stop-Modus wieder ginge ...
hi, wollte mal fragen, was schief läuft, wenn das screenshotprogramm nur ganz kurz auf geht und dann gleich wieder weg ist? ich hatte es schonmal, da liefs tip top... jetzt hab ich nen anderen laptop und da gehts nur kurz auf und ist nach ner halben sekunde wieder weg... danke schonmal
ok, hat sich schon erledigt! hab den falschen com-port gehabt. (konnte nur die fehlermeldung nicht lesen, weils so schnell wieder weg war...sogar zu schnell für nen screenshot. bin dann einfach mal auf der entertaste geblieben, dass es so oft auf und zu ging dass ichs lesen konnte)
Manuel schrieb: > hi, wollte mal fragen, was schief läuft, wenn das screenshotprogramm nur > ganz kurz auf geht und dann gleich wieder weg ist? > > ich hatte es schonmal, da liefs tip top... jetzt hab ich nen anderen > laptop und da gehts nur kurz auf und ist nach ner halben sekunde wieder > weg... Das screenshot-Programm ist ein Kommandozeilen-Tool. Im Terminal (oder wie heißt das unter Win?) siehst Du auch die Fehlermeldung. Wahrscheinlich ist das Problem, daß am Laptop keine COM1 vorhanden ist, auf die das Tool ohne Parameter zugreift. Alternativ installiere Linux, damit gehen auch andere Sachen besser. Vielleicht könnte sich mal ein Windows-User des Screenshot-Tools annehmen? Da sollte sich doch bei >95% Marktanteil jemand finden... Falk P.S.: Solche Fragen sind bei http://sourceforge.net/apps/phpbb/welecw2000a/ besser aufgehoben.
...das ist die Dos-Eingabeaufforderung "CMD.exe" meistens unter C:\Windows\system32 zu finden oder unter dem Reiter "Zubehör" Gruß Michael
@alle Roberto hat doch nun schon den neuen Thread aufgemacht. Beitrag "Wittig(welec) DSO W20xxA Open Source Firmware (Teil2)" Schreibt doch bitte alle dort weiter, damit dieser Thread nicht noch länger wird! Gruß Jürgen
Jürgen schrieb: > @alle > > Roberto hat doch nun schon den neuen Thread aufgemacht. > > Beitrag "Wittig(welec) DSO W20xxA Open Source Firmware (Teil2)" > > Schreibt doch bitte alle dort weiter, damit dieser Thread nicht noch > länger wird! Nein, http://sourceforge.net/apps/phpbb/welecw2000a/ ist besser geeignet. Falk
egal, hauptsache nicht mehr hier rein. finde es inzwischen auch sehr ätzend und unübersichtlich
...also was dann jetz? Mir geht das jetzt auf'n S..., wann sind wir uns denn hier einich??? Ich versuche so gut wie möglich hier den Überblick zu behalten was aber bald unmöglich sein wird, da der Thread hier wirklich schon 100km lang ist! Ich fände es jetzt nicht schlecht, wenn es, wie FALK es schon vorgeschlagen hat, im SF weiter ginge, da ja schon 3 Thread's (ENTWICKLER, HARDWARE, SOFTWARE) aufgemacht worden sind!!! Ich selbst bin dort als KASTOR7 registriert(mike0815 war schon vergeben)! Bei Fragen oder Beiträgen von hier, kann ja verlinkt werden... ...das wäre jetzt mein Vorschlag, was hält denn der Rest davon??? Gruß Michael
Hallo Michael, allein schon weil wir auf SF (innerhalb unseres Projekts) Admin Rechte haben, bin ich stark dafür! P.S.: Ich hab mal hier: http://sourceforge.net/apps/phpbb/welecw2000a/viewtopic.php?f=18&t=34 ein aktuelles Foto von der GUI eingestellt. Derzeit bin ich dabei einige Programme der Profis zu analysieren, um mal zu sehen wie die das ein oder andere Problem in der Programmierung und Darstellung gelöst haben. Da ich derzeit schon ca. 3000 Zeilen Programmcode geschrieben habe wird's langsam Zeit für eine ordentliche Programmstruktur... Gruß, brunowe
Meine Meinung dazu könnt Ihr hier Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil2)" lesen und kommentieren. Danke!
Hallo zu allen! entschuldigt sich für meinen bösesten Deutschen, aber ich habe ein Problem mit dem W2012A und ich brauche eure Hilfe.. Ich versuchte die Fortbildung der Firmware mit der Software von Welec zu machen (W2000-Update)und während es für Fehler entlud, schloß ich das Fenster. es scheint jetzt, daß ich keine firware mehr installiert habe und wenn ich wieder das Programm den upload losgehen lasse, fängt es nicht an.. wie ich kann wiedergutmachen?
Sorry, konnte mich nicht zurückhalten - die Online-Übersetzter sind manchmal so lustig ;-)))) "entschuldigt sich für meinen bösesten Deutschen" Oooooohhohhohho, ROFL-ROFL :-D
Hallo an alle! Ich kaufte den Umfang von welec und ausgeliefert haben, den Artikel regelmäßig bezahlt denn es ist eine Schande, nicht um E-Mail zu reagieren. Ich dachte, dass die Deutschen richtigen Leute waren. Enttäuschung total! Ich möchte eine Antwort von Ingenieur. Hello everyone! I purchased the scope from welec and have shipped the item regularly paid for it is a shame not respond to email. I thought that the Germans were right people. Disappointment total! Ciao a tutti ! Ho acquistato l'oscilloscopio dalla welec e non hanno spedito l'oggetto regolarmente pagato è una vergogna non risponde ad email . Credevo che i tedeschi erano persone corrette .Delusione totale!
Hallo, ich hatte bereits 2010 ein W2014A von Michael Wittig über ebay ersteigert. Hardwareversion 1c9.0d, Softwareversion 1.4. wegen der bekannten probleme satnd es bei mir jahrelang nahezu ungenutzt herum. Nun bin ich endlich dazu gekommendie neueste BlueFlash firmware 1.2.BF.7.13C2 zu flashen und auch den External Trigger Mod und den LB-Mod vorzunehmen. Das Gerät ist jetzt wirklich brauchbar! Vielen Dank an alle Beteiligten für die große Mühe! Leider zeigen sich zuweilen immer noch die lästigen Spikes. Im Forum habe ich gelesen, dass unter Umständen ein Umflashen des FPGA auf Version 8C7.0L Besserung versprechen könnte. Leider finde ich nirgendwo das benötigte sof File für diese Version. Könnte mir jemand einen Link benennen? Vielen Dank! Dietmar
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.