Stefan E. schrieb: > Hallo Rolf, > > er hatte meine Branch-Version drauf, die noch einem älteren Stand war. > Ich vermute da liegt der Fehler. Zwischen 0.91 und 0.92 gibt es, soweit ich weiß, keine Unterschiede. Allerdings habe ich inzwischen schon öfter von Problemen mit den Screenshot unter Windows gehört. Vielleicht kann sich ein Windows-Nutzer mal der Sache annehmen. Das ist alles recht einfacher C-Code ohne Tricks und Schliche. Die "Windows"-Versionen der screenshot.exe sind seit 0.91 immer nur Dinger, die ich irgendwie kompiliert, aber nie getestet habe, weil ich Windows nur benutze, wenn es sich nicht vermeiden läßt. Falk
also, ich habe erst die 092er vom Falk drauf vom 20091025 ohne 3. Trigger! Dann die vom Stefan, 092er Alpha vom 20091028 mit 3. Trigger! ...meine Festplatte läuft hier bald über... Wann habt ihr denn die Aktuelle rein gesetzt? Ich blick hier nicht mehr durch, seid doch so lieb und setzt die aktuellste Version mal hier rein, heißt da der 3. Trigger auch STANDART? Falk, Ich habe die 47 Ohmler wieder rausgeschmissen und 33er rein gesetzt(2. Kanal), denn irgendwie sehe ich mit den 47ern keine Besserung! Morgen Abend setze ich mal ein paar Aufnahmen hier rein, damit ihr den Unterschied seht! Der 2. Kanal wird wohl etwas besser mit den (33) Ohmlern, aber irgendwie zickt der noch rum! Kann das sein, das das an den Leitungen (2. Kanal)liegt, die nachträglich verlegt worden sind? Gruß Michael
Michael D. schrieb: > also, ich habe erst die 092er vom Falk drauf vom 20091025 ohne 3. > Trigger! > Dann die vom Stefan, 092er Alpha vom 20091028 mit 3. Trigger! > ...meine Festplatte läuft hier bald über... > Wann habt ihr denn die Aktuelle rein gesetzt? Ich blick hier nicht mehr > durch, seid doch so lieb und setzt die aktuellste Version mal hier rein, > heißt da der 3. Trigger auch STANDART? Die OS 0.92a (Bugfix) findest Du hier: Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil2)" oder hier http://sourceforge.net/projects/welecw2000a/files/ die Ram-Version von Stefan ist hier: Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil2)" Wenn Du es aktueller haben möchtest, musst Dir die entsprechende Version aus dem svn auschecken und selbst durch den Compiler treten, allerdings können da noch ungetestete Änderungen drin sein. > > Falk, > [Widerstände] > > Gruß Michael Grüße, rowue
Genau so ist es. In der Datei die ich hier gepostet habe sind evtl noch nicht alle Änderungen enthalten gewesen, die bereits im svn waren. Im svn sind die Änderungen mittlerweile auch enthalten. Außerdem versuche ich dem Oskar noch beizubringen, das es gefälligst an der Mittelachse vom Bildschirm zu zoomen hat, falls die Timebase im Stop-Modus geändert wird. Momentan verschiebt sich das immer gewaltig.
Hi. Den neuen Trigger finde ich eine gute Idee, das Ticket bzgl. Triggerproblemen deshalb zu schließen ist aber nicht korrekt - schließlich sind die Probleme nach wie vor vorhanden, wenn man den Normaltrigger benutzt. Und dieser hat durchaus seinen Sinn, vor allem wenn man eher selten auftretende Ereignisse betrachten möchte. Dazu eignen sich weder Auto-, noch Standard-, noch Singletrigger. Ich freue mich, dass an dieser Front gearbeitet wird und bin schon gespannt auf das Ergebnis, möchte aber nochmal betonen, dass der Normaltrigger aus gutem Grund in allen gängigen Oszis vorhanden ist. Gruß Michael
Hm, ich konnte keinen Fehler mehr beobachten. Ich arbeite selber oft im Normal-Modus und das geht eigentlich alles mittlerweile so wie es soll. Ich werde es aber weiter im Auge behalten.
Bitteschön: http://consult42.com/W20XXA-prereleases/TomCat-31102009.ram Was geht: ADC-Kalibrierung, Trigger von Stefan. Was nicht geht (unvollständig): Quick-Measure, DAC-Kalibrierung, Zeichnen im Stop-Modus, Delayed. Falk
Wird schon. Die Geschwindigkeit ist angenehm. Ein paar Fehler sind noch drinnen. Aber die bekommen wir auch noch raus ;-)
...no? Seid ihr noch am Leben? Was gibt's Neues an der Entwicklerfront? Gruß Michael
Ich lebe noch. Bin aber gerade gut eingedeckt mit anderem Zeugs. Es kommt schon mal wieder mehr Zeit...
ich lebe auch noch, hatte/habe aber im Job auch etwas zu tun, nebenher habe ich die Widerstände mal zum Test eingelötet und musste einen Bug (Signalverzerrung bei W2022A, siehe http://sourceforge.net/apps/trac/welecw2000a/ticket/45) "filen" ;) Grüße, rowue
Hallo rowue, sehe ich das richtig, dass die Störung nur auf dem 2. Kanal sichtbar ist? Da kann ich fast nicht glauben, dass es an der Firmware liegt. 5-MHz-Dreieck, mein Funktionsgenerator geht nur bis 2 MHz. Werde aber morgen mal probieren. Gruß, Guido
Angehängte Dateien:
-
screenshot-0002.png
4,9 KB -
screenshot-0001.png
4,3 KB
das ist schön, das ihr noch lebt! Ich hab's mal getestet, liegt definitiv an der FW. Linkes Foto ist die 092er, rechtes die 091er...kaum zu glauben! Gruß Michael
Das Problem hat sich bei mir durch drehen an der Timebase aufgelöst. Mal Default-Setup gemacht?
Jedes mal, auch mal zwischendurch, falls da noch Reste gewesen wären... Ab 100nS fängt's (zuckt)an, dann bei 50nS wird es extrem und bei 20nS gibt's dann richtige Treppchen, egal welche Spannung ich einstelle. Der 1. Kanal funzt einwandfrei. Bei der 91er tritt es auf keinen Fall auf! Was da wohl schiefläuft? Wie bist du vor gegangen mit der Timebase? Stefan:(hast du meine Mail nicht bekommen?) Gruß Michael
Michael D. schrieb: > das ist schön, das ihr noch lebt! > Ich hab's mal getestet, liegt definitiv an der FW. > Linkes Foto ist die 092er, rechtes die 091er...kaum zu glauben! Erstmal würde ich mich freuen, wenn Fehler im Ticket diskutiert werden - hier können schnell mal drei-vier Posts dazwischen kommen und dann wird's unübersichtlich. Wie aus dem Ticket ersichtlich, tritt der Fehler beim Übergang von 0.91 zu 0.92a ab r245 auf. Das ist der Punkt, wo "wir" Hayos 0.96HE "reingemerged" haben. Bei Hayo verläuft der Übergang zwischen 0.87Beta und 0.92HE. Es scheint nur die Hardware-Version /C7.0L/ betroffen zu sein, welche für Problematiken mit Spikes bekannt ist (wurden die damals beseitigt- wenn ja: wie?). Die anscheinende Zeitbasenabhängigkeit des Fehlers liegt in der Darstellung - für Zeitbasen >= 100ns werden Werte entfernt/gemittelt, bei 50ns haben wir etwa eine 1/1 Darstellung, bei Zeitbasen <= 20ns werden die Linien interpoliert - da fällt der einzelne "Ausreisser" stärker in's Gewicht. > > Gruß Michael Grüße, rowue PS: Michael: Du hattest noch festgestellt, dass die Null-Linie nicht ganz sauber mit wandert - hast Du Lust, dazu mal ein Ticket (mit ein-zwei Screenshots) zu erstellen?
Rolf Würdemann schrieb: > Erstmal würde ich mich freuen, wenn Fehler im Ticket diskutiert > werden - hier können schnell mal drei-vier Posts dazwischen kommen > und dann wird's unübersichtlich. gut! > > Es scheint nur die Hardware-Version /C7.0L/ > betroffen zu sein, welche für Problematiken mit Spikes bekannt > ist (wurden die damals beseitigt- wenn ja: wie?). ...hm, die HW-Ver. hab' ich natürlich '8C7.0L' > > Die anscheinende Zeitbasenabhängigkeit des Fehlers liegt in der > Darstellung - für Zeitbasen >= 100ns werden Werte entfernt/gemittelt, > bei 50ns haben wir etwa eine 1/1 Darstellung, bei Zeitbasen <= 20ns > werden die Linien interpoliert - da fällt der einzelne "Ausreisser" > stärker in's Gewicht. ...allerdings, sehr stark! > > Grüße, > > rowue > > PS: Michael: Du hattest noch festgestellt, dass die Null-Linie nicht > ganz sauber mit wandert - hast Du Lust, dazu mal ein Ticket (mit > ein-zwei > Screenshots) zu erstellen? ...mach ich! Stimmt, dadurch das diese nicht gescheit mitwandern, ist dann auch bei beiden Kanälen, je nach Stellung, mehr oder weniger Rauschen zu verzeichnen! Gruß Michael
Sagt mal wurde eigentlich jemals geklärt, wo man ansetzen müssten, um den zeitlichen Versatz zwischend den Kanälen zu entfernen? Vermutlich führt da kein Weg am neuen VHDL Design vorbei, weil es an der Ansteuerung der ADCs liegt, oder? Kürzlich bin ich da nämlich wieder drübergestolpert, ist schon ziemlich hässlich. Gruß Michael
so, ich hab' jetzt mal das Ticket 46 (Zeroline-Correktion) in's SF rein gesetzt, hier mal der link dazu: https://sourceforge.net/apps/trac/welecw2000a/ticket/46 hoffe es kommt einigermaßen ruber. Gruß Michael
Michael H. schrieb: > Sagt mal wurde eigentlich jemals geklärt, wo man ansetzen müssten, um > den zeitlichen Versatz zwischend den Kanälen zu entfernen? Wir können in der Signal-Aquise ansetzen und einen "Shift" der Werte einbeziehen ;) > Vermutlich führt da kein Weg am neuen VHDL Design vorbei, weil es an der > Ansteuerung der ADCs liegt, oder? Wir können es auch in der Nios-FW - bis zu einem gewissen Grad korrigieren - ein Vorschlag war damals über viele Geräte die Offsets zu messen, allerdings denke ich, dass da auch ein selbstkonsistenter Abgleich am Gerät möglich ist ;) > Kürzlich bin ich da nämlich wieder drübergestolpert, ist schon ziemlich > hässlich. Sieht nicht gut aus ;) - Hast Du Lust da auch mal ein Ticket zu "filen" ;) > > Gruß > > Michael Grüße, rowue
Michael D. schrieb: > so, ich hab' jetzt mal das Ticket 46 (Zeroline-Correktion) in's SF rein > gesetzt, hier mal der link dazu: > http://sourceforge.net/apps/trac/welecw2000a/ticket/46 Sieht doch schon mal sehr gut aus ;) > > hoffe es kommt einigermaßen ruber. Kommt es - wobei das Rauschen selbst von dem Fehler nicht beeinflusst wird ;) Vorschlag 1: Evtl. wäre eine englische Fehlerbeschreibung netter, es gibt zwar anscheinend nicht so viele nicht deutschsprachige Nutzer, aber so sieht jmd., der der deutschen Sprache nicht mächtig ist, dass der Fehler bekannt ist ... Vorschlag 2: Wenn Du mal in Ticket 45 schaust, kannst Du sehen, wie Bilder gleich im Ticket angezeigt werden, spart den Aufruf des Links ;) Vorschlag 3: Beim Posten des Links "https" gegen "http" austauschen, dann brauchen sich die Leute beim Anschauen nicht einzuloggen ;) > > Gruß Michael Grüße, rowue
Rolf Würdemann schrieb: > Sieht doch schon mal sehr gut aus ;) ...danke. > Kommt es - wobei das Rauschen selbst von dem Fehler nicht beeinflusst > wird ;) ok, werde ich korrigieren! > Vorschlag 1: Evtl. wäre eine englische Fehlerbeschreibung netter, > es gibt zwar anscheinend nicht so viele nicht deutschsprachige > Nutzer, aber so sieht jmd., der der deutschen Sprache nicht > mächtig ist, dass der Fehler bekannt ist ... ...dann werde ich das auch noch auf englisch ergänzen! > Vorschlag 2: Wenn Du mal in Ticket 45 schaust, kannst Du sehen, > wie Bilder gleich im Ticket angezeigt werden, spart den Aufruf > des Links ;) ...das ist ja dumm, habe es gerade bemerkt. Wie kann ich denn, statt der Links, die Fotos gleich sichbar mmachen? Finde irgendwie die Option nicht, komisch... > Vorschlag 3: Beim Posten des Links "https" gegen "http" austauschen, > dann brauchen sich die Leute beim Anschauen nicht einzuloggen ;) ...stimmt, hatte ich garnicht dran gedacht. >> > > Grüße, > > rowue Gruß Michael
Michael D. schrieb: > Rolf Würdemann schrieb: >> [...] >> Kommt es - wobei das Rauschen selbst von dem Fehler nicht beeinflusst >> wird ;) > ok, werde ich korrigieren! O.K. ;) > >> Vorschlag 1: Evtl. wäre eine englische Fehlerbeschreibung netter, >> es gibt zwar anscheinend nicht so viele nicht deutschsprachige >> Nutzer, aber so sieht jmd., der der deutschen Sprache nicht >> mächtig ist, dass der Fehler bekannt ist ... > ...dann werde ich das auch noch auf englisch ergänzen! Wunderbar - Schau mal nach, ob Du unten den Ticket-Text ändern darfst (oder ob das auf "Ticket-Admin" beschränkt ist ;) > >> Vorschlag 2: Wenn Du mal in Ticket 45 schaust, kannst Du sehen, >> wie Bilder gleich im Ticket angezeigt werden, spart den Aufruf >> des Links ;) > ...das ist ja dumm, habe es gerade bemerkt. > Wie kann ich denn, statt der Links, die Fotos gleich sichbar mmachen? > Finde irgendwie die Option nicht, komisch...
1 | [[Image(screenshot-0000.png)]] |
z.B. - das findest Du auch, wenn Du auf das "Bild-Symbol" rechts in der Leiste unten clickst ;) > >> Vorschlag 3: Beim Posten des Links "https" gegen "http" austauschen, >> dann brauchen sich die Leute beim Anschauen nicht einzuloggen ;) > ...stimmt, hatte ich garnicht dran gedacht. Wird uns allen noch 42.000 Mal passieren ;) BTW: Für Committer empfehlen sich noch folgende Tags: #TICKETNUMMER in der Commit-Msg: erzeugt Verweis auf die Ticketnummer rREVISION im Ticket: verweist auf die Revisionsnummer des commit ;) >>> >> >> Grüße, >> >> rowue > > Gruß Michael Grüße, rowue
ich kann den Text nicht mehr ändern! Aber die Fotos mit gleichen Namen ersetzen, hängt sich aber unten an...so'n Käse! Das mit dem Imsge einsetzen habe ich jetzt gepeilt! Am besten wäre das ganze Ticket zu löschen, dann kreiere ich ein Neues!!! Wer kann das Löschen, oder wer ist befugt??? Ich wart's mal ab, bevor das aussieht als wäre da was eingeschlagen... Gruß Michael
Michael D. schrieb: > ich kann den Text nicht mehr ändern! > Aber die Fotos mit gleichen Namen ersetzen, hängt sich aber unten > an...so'n Käse! > Das mit dem Imsge einsetzen habe ich jetzt gepeilt! > Am besten wäre das ganze Ticket zu löschen, dann kreiere ich ein > Neues!!! > Wer kann das Löschen, oder wer ist befugt??? Mach das neue Ticket fertig, dann setze ich das alte auf "close", "duplicate" ;) > > Ich wart's mal ab, bevor das aussieht als wäre da was eingeschlagen... > > Gruß Michael Grüße, rowue
Hallo, nachdem ich die tollen Fortschritte bei der Firmware nun schon eine Weile mitlese, wollte ich meinen W2024A endlich updaten, bin aber gleich beim Backup gescheitert. Ziel: Backup mit WelecUpdater.exe über USB-Seriell Wandler. Vorweg: Ich würde ungern nur deswegen auf Verdacht 100 MB Perl installieren und einen echten Com-Port hat mein PC leider auch nicht. Nach dem Lesen vom SF-Wiki und vergeblicher Suche bei http://sourceforge.net/projects/welecw2000a/files/ unter PC-Software, habe ich unter http://groups.google.com/group/welec-dso/files die Version 0.4.8A22 für WinXP gefunden. Der Download damit ist ziemlich kläglich gescheitert, weil es zu Übertragungsfehlern kommt und er dann mit "Reinitalisierung ..." hängt (siehe angehängtes Debug-Log, Ads in Statuszeile läuft nicht weiter). Es sieht so aus, als ob der Handshake und das nochmalige Abrufen von Speicherblöcken nicht funktioniert. Gibt es da eine aktuellere Version? Nächste Frage: Welches sind die relevanten Speicherbereiche, wenn ich nicht stundenlang auf den ganzen Bereich 00040000-007FFFFF warten möchte. Für die Gerätefunktion/-kalibrierung sind doch mindestens die ganzen Signale (0x00100000-0x005FFFFF) und wohl auch 0x00600000-0x006BFFFF nicht weiter relevant, oder? Für Nicht-Insider wäre die Info hierzu im SF-Wiki unter Backup ganz prima. Danke für jeden Tipp. Gruß, Rainer
Hallo Rainer, Du hast warscheinlich die falsche Welec-Updater Version benutzt! Melde dich mal hier an damit ich dir eine PN schicken kann, oder schick mir eine, wie auch immer... Gruß Michael
Die WelecUpdater Version 0.4.8A22 war schon ok. Das Backup hat damit jetzt an einem PC mit echtem Com-Port prima geklappt. Der USB-Seriell Wandler (mit Prolific Chip, Treiber V.2.0.2.1) war wohl bei 115kBd etwas an seiner Grenze. Bei Screenshots mit dem W2000a-screenshot V0.91 sind damit auch oft Macken drin. Danke nochmal, Rainer
Angehängte Dateien:
-
Screen_OS-0.91cal.png
27 KB -
Screen_OS-0.92cal.png
26 KB -
Screen_OS-0.92calB.png
10 KB
Michael D. schrieb: > Ich hab's mal getestet, liegt definitiv an der FW. > Linkes Foto ist die 092er, rechtes die 091er...kaum zu glauben! Ich habe den Test auch noch mal auf meinem W2024A gemacht, d.h. Flanke des ProbeComp-Signals mit FW 1.2.OS.0.91 (Build: Falk 10. Aug. 16:43, RAM ) bzw. FW 1.2.OS.0.92 (Build: falk - 20091025, Flash), jeweils nach "Default Setup" und Kalibierung (ADC, Zero, DAC) mit Norm-Trigger. Ich sehe manchmal die gleichen Fehler, aber mir ist unklar unter welchen Bedingungen sie auftreten. Eine Versionszuordnung sehe ich nicht so klar. (Graphiken sind für bessere Lesbarkeit nachbearbeitet) Gruß, Rainer
Rainer W. schrieb: > Michael D. schrieb: >> Ich hab's mal getestet, liegt definitiv an der FW. >> Linkes Foto ist die 092er, rechtes die 091er...kaum zu glauben! > > Ich habe den Test auch noch mal auf meinem W2024A gemacht, d.h. Flanke > des ProbeComp-Signals mit FW 1.2.OS.0.91 (Build: Falk 10. Aug. 16:43, > RAM ) bzw. FW 1.2.OS.0.92 (Build: falk - 20091025, Flash), jeweils nach > "Default Setup" und Kalibierung (ADC, Zero, DAC) mit Norm-Trigger. Ich > sehe manchmal die gleichen Fehler, aber mir ist unklar unter welchen > Bedingungen sie auftreten. Eine Versionszuordnung sehe ich nicht so > klar. > (Graphiken sind für bessere Lesbarkeit nachbearbeitet) Die Versionszuordnung dürfte dann klarer werden, wenn Du schaust, ob der Fehler in der 0.91 überhaupt auftritt. Dies scheint nicht der Fall zu sein. Das der Fehler in der 0.92a alternierend auftritt ist hingegen eine sehr interessante Info. Wenn Du mal rausfindest, wie Du das ein- und ausschalten kannst, wäre das eine interessante Info für das Ticket-System ;) > > Gruß, Rainer Grüße, rowue
Hallo Rolf, ich kann mich entsinnen, das ich dasselbe Phänomen wie bei Rainer, schonmal beobachtet hatte! Es war allerdings nur ein einziges Mal aufgetreten (92er Ver.), das beide Kanäle ( beim Rainer 4 Kanäle) schön gleich waren, da hatte ich ein 27MHz. Rechteck-Signal gemessen! Wie schon mehrmals beschrieben worden ist, tritt die Flankenferkelei, ja erst bei 1GSa/s 100nSek. abwärts an ! Gruß Michael
Angehängte Dateien:
-
screenshot-0000.JPG
35 KB -
screenshot-0001.JPG
34 KB -
screenshot-0003.JPG
53 KB -
screenshot-0004.JPG
36 KB
Hallo, Ich habe das problem nur auf kanal1 bemerkt und screenshots gemacht, allerdings ist es nun nach einem default setup nichtmehr vorhanden... Beide Kanäle sehen jetzt aus wie Kanal 2. Nicht Reproduzierbar, bisher... Kann eventuell starttemperatur mit reinspielen? Was mir noch aufgefallen ist, ist das Linien verschwinden wenn man vom XY betrieb zurück auf Main wechselt. Wenn man Quickmeasur aufruft deutet die anzeige und die Cursor darauf hin das diese allerdings nur unsichtbar sind. Abhilfe Neustart oder Autoscale drücken. Im 4. Bild sieht man artefakte im menue. Diese entstehen bei mir nur wenn ich die settings im Math Menue aufrufe. Aufgefallen ist mir auch das die gelbe "1" in der Tittelzeile neben dem spannungsbereich verschwindet wenn man die 0 Linie von kanal1 nach unten verscheibt. Kleinigkeiten... Hardware:8C7.0H Software:0.92a Gruß Torsten
Hallo Torsten, Torsten Otten schrieb: > Hallo, > > > Was mir noch aufgefallen ist, ist das Linien verschwinden wenn man vom > XY betrieb zurück auf Main wechselt. > Wenn man Quickmeasur aufruft deutet die anzeige und die Cursor darauf > hin das diese allerdings nur unsichtbar sind. > Abhilfe Neustart oder Autoscale drücken. ...einmal den Triggerknob vor u. wieder zurück betätigen, dann sind die auch wieder da! > > > Aufgefallen ist mir auch das die gelbe "1" in der Tittelzeile neben dem > spannungsbereich verschwindet wenn man die 0 Linie von kanal1 nach unten > verscheibt. > > Kleinigkeiten... ...wohl wahr! > Hardware:8C7.0H > Software:0.92a > > Gruß > Torsten
Wie sieht son Firmwaredownload eigentlich aus? Muss der während des ganzen Vorgangs die Daten sichtbar durchlaufen lassen? Bei mir ists so dass sie am Anfang laufen und dann nach mehr oder weniger Zeit stehn bleiben. Die Uhr läuft noch weiter, zuerst noch rückwärts und irgendwann wird die Zeit wieder mehr. Ne Meldung kommt auch nach 2 Stunden noch nicht. Getestet hab ichs auf 2 verschiedenen Rechnern, bei beiden ist XP drauf mit nem richtigen COM Port. Als Updater hab ich V0.4,8A22 genommen
Eine kurze Rückmeldung zum USB-Host: Prinzipiell funktioniert er jetzt. Farb- und S/W-Screenshots können in verschiedenen Dateiformaten (bmp, ppm, pbm) abgespeichert werden. Auch die CSV Daten können verarbeitet werden. Nur die raw-CSV Daten können nicht gespeichert werden weil sie in der falschen Reihenfolge reinkommen. Evtl. fällt mir da noch eine Lösung ein. Zur Zeit kommen die screenshot Daten von einer PC Software weil sie in 2kByte Blöcken gesendet werden müssen und die Software nach jedem Block auf eine Bestätigung vom µC warten muss. Die Möglichkeit auf eine Bestätigung über RS-232 warten zu können ist auf dem Oszi leider noch nicht gegeben und mir fehlt der Durchblick um es selber zu realisieren. Es wäre schön wenn einer der Firmware Profis sich daran versuchen könnte. Z.B. für die CSV Daten:
1 | for(i=0;i<16384;i++) //16k Samples |
2 | {
|
3 | for(j=0;j<4;j++) //4 Kanäle |
4 | {
|
5 | putchar(...); //sieht auf dem Oszi anderes aus |
6 | outcount = outcount + 1; |
7 | |
8 | //Wenn 2kB übertragen wurden, auf Bestätigung vom PC/µC warten
|
9 | if(outcount == 2048) |
10 | {
|
11 | while(ComRead(comport) != 'w'); //Warte auf Bestätigung |
12 | outcount=0; |
13 | }
|
14 | }
|
15 | }
|
Jetzt hats bei mir doch funktioniert mit der Sicherungskopie und dem Updaten der neuen Software. Aber son Paar Fragen sind noch offen: - Ich habe als Testsignal ein PWM mit 5V Amplitude, etwa 5kHz und 25% Pulsweite. Warum zappelt das Signal laufend und steht nicht stabil? - Früher war auf der rechten Seite mal ein Menü wo man z.B. Werte ablesen konnte wie Deltas zwischen Cursoren oder so, jetzt geht das Oszillogramm über den ganzen Schirm. Wo krieg ich jetzt das Menü wieder her? - Zum Mode: Sollte es nicht so sein dass im Normal Mode das Bild nach einem einzelnen Triggerpuls stehen bleibt wenn weitere Triggerpulse ausbleiben, während im Auto Mode das Bild laufend aktualisiert wird? Oder wars andersrum? Bei mir ists auf jeden Fall so dass egal was ich einstelle das Signal nie stehenbleibt, was ich ziemlich unpraktisch finde, wie soll ich denn da Schaltverhalten ansehen?
Zu 1.: Dein Oszilloskop triggert nicht richtig. Deshalb steht das Signal nicht stabil. Zu 3.: Auto Mode heißt, dass nach einer gewissen zeit automatisch ein Triggerimpuls ausgelöst wird, ob eine Flanke da war oder auch nicht (Bild zappelt, wenn keine richtige Flanke da ist). Normal Mode wartet bis eine gültige Flanke erkannt wurde. Was du suchst ist der Single-Shot-Modus. MfG Marius
Hallo Chris
>Als Updater hab ich V0.4,8A22 genommen
nimm das Perl-Skript, das den Releases beiliegt. Das spart Nerven und
Zeit.
Die Anzeige der Cursor-Daten erhältst du wenn du zweimal auf Cursors
drückt. Dann müsste die Freequenz und so sichtbar werden.
Normal und Auto-Modus hast du richtig erklärt. Zumindest der
Normal-Modus funktioniert eigentlich ordentlich. FÜr den Auto-Modus gibt
es im nächsten Release Ersatz.. Wenn du darauf nicht warten möchtest,
musst du dir selber die aktuellen Dateien aus dem Sourceforge-Trunk
compilieren.
@Kurt,
ich kann mir dein Problem mal anschauen. Vielleicht schreibst du mir
eine PM, was du genau willst brauchst. Hab das noch nicht genau
verstanden.
Ich werde jetzt mal die Sourcen zwischen 0.91 und 0.92 durchforsten, ob
daa etwas auffällig wegen den Flanken ist. Bitte unbedingt an der Stelle
weiter testen, wann, wo, unterr welchen Umständen.
Gruß,
Stefan
Hallo Chris, siehe hier: Beitrag "Re: Wittig(Welec) W2022A Firmware sichern und Update durchfüren?" ...und im Dateianhang ein Log von einer FW-Einspielung! Gruß Michael
Vielen Dank für all die Erklärungen. Dass das mit dem Normal Mode nicht richtig funktioniert in der aktuellen Version ist ja kein Problem, dachte nur dass ich vielleicht was falsch mache oder falsch verstanden habe. Wenn aber nach euren Aussagen der Normal Mode funktionieren sollte, bei mir das Bild aber nicht stehen bleibt, dann befürchte ich fast dass ich eine defekte Hardware habe. Bei der Original Software war das schon genau das gleiche Problem. Wie ists mit dem Trigger? Gibts da noch Probleme mit der Software dass er nicht alle erkennt? Wenn ich ein PWM Signal mit konstanter Frequenz habe springt es immer mal wieder, d.h. der Triggerzeitpunkt wird scheinbar wo anders erkannt. Wenn ihr mir bestätigen könnt dass das kein Softwarefehler ist, dann wäre das ein weiteres Indiz dafür dass in der Triggerung ein Hardwaredefekt vorliegt, das würde auch erklären dass beim Normal Mode nie das Bild stehen bleibt. Noch hätte ich Garantie...
Ahso, nochwas: Ist auch sowas wie ein Force Trig angedacht? Das fehlt mir oft sehr.
Hallo Chris, also wenn du ein Bild auf dem Schirm siehst sollte dein FPGA laufen und damit auch dein Trigger soweit funktionieren ;-) Es gibt, schlagt mich, wenn es anderst ist, da keine weitere Hardware dafür außer dem FPGA. Erkläre doch mal was du wo misst und wie du genau auf welchem Kanal triggerst, bei welchen Einstellungen, Triggerlevel, Firmware-Version usw. Schalte mal den Modus um und wieder zurück, mach ein Default-Setup. Also ich denke wirklich nicht, dass es ein Hardwarefehler ist.
Hallo Chris, zuverlässiges Triggern geht meist besser, wenn du den Triggerpegel sehr hoch drehst. Knapp unter die eingeschaltete Spannung. Auch die sonstigen Triggereinstellungen solltest du überprüfen. Was ist ein "Force-Trigger"? @ Stefan E.: Ich bin mir mit der Hardware nicht so sicher. Vielleicht hat das schon jemand rausgefunden? Es gibt ja die Extraschaltung zur Triggerung mit Video-Lineseparator usw. Hätte ich die Schaltung entworfen, hätte ich nur den Eingang dieser Schaltung auf alle (max.) 5 Eingänge umschaltbar gemacht. Ich weiß aber bisher nicht, ob es so realisiert ist. Gruß, Guido
Ich messe ein PWM Signal mit etwa 5kHz Frequnz, 5V Amplitude und verschiedenen Tastverhältnissen (zum Zeitpunkt der Messung natürlich ein konstantes Tastverhältnis). Das Signal generiere ich mit einem ATtiny13. Dass der Trigger besser funktioniert wenn man höher dreht hab ich auch schon festgestellt, aber dadurch kann ich das Problem nicht beseitigen. Angeschlossen ist das Signal auf Ch1, Ch2 ist aus. Ich benutze 1.2-OS-0.92a auf einem W2012A. Ob ich auf steigende oder fallende Flanke triggere ändert nichts am zappeln. Soweit ich das sehe ists auch nicht so dass das Gerät wenn es zappelt mal zwischen steigender und fallender Flanke nicht unterscheiden kann, sondern triggert an ner stelle wo das Signal auf Null ist. Default Setup ändert auch nichts. Force Trigger kann man im Normal Mode benutzen wenn nichts angezeigt wird und grad keine Triggerbedingung kommt. Durch Drücken von Force Trig löst er einen Triggervorgang manuell aus. Das kann man gut nutzen um zu sehen was das Signal gerade treibt, z.b. ob es low oder high ist oder völlig außerhalb des eingestellten Messbereichs. Wenn man beim Welec auf dem Stop Modus ist kann man sowas ähnliches mit Druck auf Single auslösen. Wobei da aber auch schon wieder die Frage ist: was sollte das Gerät eigentlich machen? Nichts bis ein Triggerimpuls kommt und nach diesem einen Puls anzeigen und stehen lassen? Oder ist das wirklich die Auslösung einen Triggerimpulses in dem Moment wo ich auf den Knopf drücke?
Der USB Host funktioniert schon für CSV Daten. Ich muss noch ein paar Tests machen und die restlichen screenshot Funktionen anpassen. Danach werde ich ausführlicher berichten.
Hallo, ich glaube ich habe eine möglichkeit gefunden das sporadische auftreten der flanken zu reproduzieren. 1. Ich mache defaultsetup, gerät aus, nochmal defaultsetup. (nur so reproduzierbar bei mir) 2. Internes Testsignal anhängen. 3. Ohne kalibrierung Autoscale. Das gerät geht in stopmodus und auf normtrigger. 4. Stop/Run taste drücken, Zeitbasis auf 10ns ggf. Pretrigger verstellen, und die zackigen flanken sind da. Wenn ich vorher die Adc calibrierung mache tritt das Problem nicht auf. Frage: Setzt defaultsetup wirklich alles zurück? Gruß Torsten
Hallo Torsten, du mußt nach dem defaultsetup die Timebase verstellen, damit die Anderungen geseichert werden.
Hallo Kurt, gerade probiert, dann ist das problem auch ohne ausschalten reproduzierbar. Gruß Torsten
Wenigstens etwas... Du könntest mal eine ältere Firmware probieren, z.B. 0.91. Wenn der Fehler dann noch auftritt könnte es an der Hardware liegen.
Angehängte Dateien:
-
0.91__zacken.JPG
38 KB -
0.92a__zacken.JPG
42 KB
Hallo Kurt, hab die 0.91 mal in den Ram geschoben und ein wenig getestet. Die Zacken waren immer auf kanal1, hab sie auch nicht wegbekommen. Die Zacken sahen aus wie bei der frisch eingespielten 0.92a. Bei der 0.92a die ich zur zeit drauf habe kann ich die alte form der zacken, wie hier Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil2)" nichtmehr reproduzieren. Ich habe die zacken auch entweder garnicht oder auf beiden Kanälen... Sehr seltsam, der fehler sieht auf jedenfall nicht immer gleich aus... Gruß Torsten
Hast du mal Beitrag "Wittig(welec) DSO W20xxA Open Source Firmware" durchgearbeitet? Da gab es solche Probleme schonmal. Was sagen die anderen dazu?
morn, der Rainer (Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil2)") hatte dasselbe Prob. mit seinem 4 Kanal ! Bei der 092a Ver. war der 1. Kanal ok, die Anderen nicht. Nach dem einspielen der 091er Ver. in das RAM, hatte er dasselbe wie der Torsten beobachtet, also auch nur sporadisch! Ansonsten tritt der Fehler bei mir (W2022)überhaupt nicht bei der 091er auf, nur bei der 092a! Weiter oben hat ja Rolf schon beschrieben, das es ein BUG in der 092a ist(Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil2)") !!! Also definitiv kein Hardwarefehler !!! Ic würde sagen, wir warten ab, bis dieser BUG behoben ist und dann sehen wir weiter! Vielleicht hat ja Stefan oder Rolf schonmal eine Vorabversion, wo dieser schon gefixt ist. Gruß Michael
Angehängte Dateien:
-
OS092atest.png
6,5 KB
Moin ;) nach dem kleinen Wink mit dem berühmten Zaunpfahl habe ich mich dann mal hingesetzt und die Zeit wo ich hier noch das W2022A habe ausgenutzt: http://sourceforge.net/apps/trac/welecw2000a/ticket/45#comment:3 Wer die Version testen möchte: Flash- und Ram-Version anbei. Wie sieht das eigentlich aus: Kann man sich als normaler Nutzer beim Trac/Sourceforge auf ein Ticket "CCen" (also gibt es da (unten) ein Feld mit CC, wo mensch sich eintragen kann)? - Damit bekommt man alle Staus-Meldungen zum Ticket mit. Es wäre mir lieb, wenn jmd. anderes die Version (am besten flashen und Kaltstart) mal testen kann, dann kann ich die Änderungen comitten und das Ticket schliessen. Grüße, rowue PS: Screenshot: 5MHz Dreieck
Hallo rowue, habe gerade mal angefangen, den Fehler mit der Verzerrung zu suchen. Problem bei mir ist, dass die Verzerrung bei der .91er (r244) auftritt und bei der .92er (r245) alles OK ist. Ich werde mal deine Flash testen.
@rowue Nach deiner Änderung bring ich jetzt die Verzerrungen (nur Kanal 1) nicht mehr weg ;-) Davor hats gepasst g
Hallo Rolf, das war fies, gelle? Aber nicht so gemeint! Bevor das hier überläuft, dachte ich... Was eine Reaktion, ich bin beeindruckt und werde es gleich mal testen! Ist sonst noch was geändert worden, was du (mit meinen bescheidenen Mitteln) getestet haben möchtest? Oh man, ich wollte doch noch das Ticket #46 (Zeroline-Correction)bearbeiten, voll verpeilt, wer war denn da so nett? Gruß Michael
Rolf W. schrieb: > Die Versionszuordnung dürfte dann klarer werden, wenn Du schaust, > ob der Fehler in der 0.91 überhaupt auftritt. Dies scheint nicht > der Fall zu sein. Das der Fehler in der 0.92a alternierend auftritt > ist hingegen eine sehr interessante Info. Wenn Du mal rausfindest, > wie Du das ein- und ausschalten kannst, wäre das eine interessante > Info für das Ticket-System ;) > Grüße, > > rowue Unter FW OS-0.92 sind die 250 MHz Störungen auf der Flanke reproduzierbar an- und abschaltbar. Die gleiche Bedienungssequenz führt bei der FW OS-0.91 nie zu Störungen. @Michael D.: Du hattest Recht Ich habe das mal als Ticket eingetragen http://sourceforge.net/apps/trac/welecw2000a/ticket/49 Was mir auch noch in der 0.92 (Build stefan 20091030) aufgefallen ist: "Autotrigger" endet (oft) im Stop-Zustand, aber mit grüner "Run/Stop"-Taste und wenn die Störungen da sind, muß ich unrealistisch hohe Pretrigger-Werte einstellen, damit ich die triggernde Flanke zu sehen bekomme. Gruß Rainer
Stefan E. schrieb: > @rowue > > Nach deiner Änderung bring ich jetzt die Verzerrungen (nur Kanal 1) > nicht mehr weg ;-) Davor hats gepasst *g* Hi Stefan ... ich beim Test so vorgegangen, dass ich erstmal mit der 0.91 geflasht habe, Kaltstart, flashen mit der 0.92a-test, Kaltstart und dann geschaut habe .. Weisst Du noch aus dem Kopf, ob der Fehler bei der alten 0.91 auftauchte (kannst Du auch von SVN ziehen) - könnte sonst evtl. ein Einspielen Deines alten Backup von der Orginal-FW eine Option sein? Hayo hatte am Start-Up-Code was geändert und einige Werte "festgenagelt". Allerdings unterscheiden sich die Werte aus dem "Protected" von den eingestellten. Grüße, rowue
Rainer W. schrieb: > Rolf W. schrieb: >> Die Versionszuordnung dürfte dann klarer werden, wenn Du schaust, >> ob der Fehler in der 0.91 überhaupt auftritt. Dies scheint nicht >> der Fall zu sein. Das der Fehler in der 0.92a alternierend auftritt >> ist hingegen eine sehr interessante Info. Wenn Du mal rausfindest, >> wie Du das ein- und ausschalten kannst, wäre das eine interessante >> Info für das Ticket-System ;) >> Grüße, >> >> rowue > > Unter FW OS-0.92 sind die 250 MHz Störungen auf der Flanke > reproduzierbar an- und abschaltbar. Die gleiche Bedienungssequenz führt > bei der FW OS-0.91 nie zu Störungen. > > @Michael D.: Du hattest Recht > > Ich habe das mal als Ticket eingetragen > http://sourceforge.net/apps/trac/welecw2000a/ticket/49 Danke für das schöne Ticket! Der Fehler tritt btw. bei mir mit beiden Geräten auf. Ich würde diesen Fehler im Autoscale suchen. > > [Trigger] > > Gruß Rainer Grüße, rowue
Hallo Rainer/Michael, #49 funktioniert bei mir auch. Es scheint, also ob durch den Aufruf von Autoscale und die damit verbundenen Registerwechsel der FPGA verstellt wird. Hallo rowue, ja mit dem Einspielen der "original" FW (ich habe nur noch die von brunow) hat sich der Fehler bisher immer beseitigen lassen. Dann kommt eine neue FW drauf und irgendwann verstellen sich die Register so, dass das Signal verzerrt ist. Ich versuch mal, meine Originalregistereinstellungen zu dumpen und im laufenden Betrieb zu ändern.
Stefan E. schrieb: > Hallo Rainer/Michael, > > #49 funktioniert bei mir auch. Es scheint, also ob durch den Aufruf von > Autoscale und die damit verbundenen Registerwechsel der FPGA verstellt > wird. > > Hallo rowue, > ja mit dem Einspielen der "original" FW (ich habe nur noch die von > brunow) hat sich der Fehler bisher immer beseitigen lassen. > > Dann kommt eine neue FW drauf und irgendwann verstellen sich die > Register so, dass das Signal verzerrt ist. > > Ich versuch mal, meine Originalregistereinstellungen zu dumpen und im > laufenden Betrieb zu ändern. setvars.pl aus dem Trunk (misc-tools) kennst Du?
Hallo Rolf, ich habe gerade deine ram raufgespielt (build rowue - 20091116 aus Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil2)") Bei mir auf dem W2024A sind damit die Flankenstörungen definitiv noch da. Hast du meine Sequenz zum Reproduzieren des Störungen-Modus mal probiert? Rolf W. schrieb: > Es wäre mir lieb, wenn jmd. anderes die Version (am besten flashen > und Kaltstart) mal testen kann, dann kann ich die Änderungen > comitten und das Ticket schliessen. > > PS: Screenshot: 5MHz Dreieck Gruß Rainer
Rainer W. schrieb: > Hallo Rolf, > > ich habe gerade deine ram raufgespielt (build rowue - 20091116 aus > Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil2)") > > Bei mir auf dem W2024A sind damit die Flankenstörungen definitiv noch > da. > Hast du meine Sequenz zum Reproduzieren des Störungen-Modus mal > probiert? > Ja, der (#49) Fehler lag woanders .... es fehlten im Autoscale die Zeilen:
1 | triggering_bak = triggering; |
2 | ctrl_reg_bak = ctrl_reg; |
3 | adc_ctrl_reg_bak = adc_ctrl_reg; |
die irgendwann wohl den Weg des Zeitlichen gefunden haben müssen. Leider werden die Register nach dem Autoscale mit den Werten aus den [c]_bak[/b] geladen - und da kann es durchaus interessante Effekte geben. Gerade im trunk gefixt. > Rolf W. schrieb: >> [...] >> >> PS: Screenshot: 5MHz Dreieck > > Gruß Rainer Grüße, rowue @Rainer: prüfst Du mal Deine Hardware-Version - das waren hier zwei Fehler: einmal ein falscher Umgang mit der Hardware (#45, .0L) und einmal der Autoscale (#49). PS: Willst Du 'nen Flash "mit den Eiern oben drauf"? ;)
Rolf W. schrieb: > Rainer W. schrieb: >> [...] > PS: Hier der Flash
Michael D. schrieb: > Hallo Rolf, Hi Michael, > das war fies, gelle? Aber nicht so gemeint! Bevor das hier überläuft, > dachte ich... Du Socke ;) - rate mal, weshalb ich das Ticket-System des Trac bevorzuge ;) > > Was eine Reaktion, ich bin beeindruckt und werde es gleich mal testen! > Ist sonst noch was geändert worden, was du (mit meinen bescheidenen > Mitteln) getestet haben möchtest? Generell nur das. Eins nach dem anderen - wenn Du sagst, dass der Fehler bei Dir auch weg ist, dann committe ich das schon mal und vielleicht finden wir dann (irgendwann) das Problem, was Stefan hat. > > Oh man, ich wollte doch noch das Ticket #46 > (Zeroline-Correction)bearbeiten, voll verpeilt, wer war denn da so nett? > 5 ;) > Gruß Michael Grüße, rowue
Rolf W. schrieb: > [...] > @Rainer: prüfst Du mal Deine Hardware-Version - das waren hier > zwei Fehler: einmal ein falscher Umgang mit der Hardware (#45, .0L) > und einmal der Autoscale (#49). > PS: Willst Du 'nen Flash "mit den Eiern oben drauf"? ;) Mein W2024A hat die HW 1C9.0L Rainer
Stefan E. schrieb: > Hallo Rainer/Michael, > > [Autoscale] > > Hallo rowue, > ja mit dem Einspielen der "original" FW (ich habe nur noch die von > brunow) hat sich der Fehler bisher immer beseitigen lassen. > > Dann kommt eine neue FW drauf und irgendwann verstellen sich die > Register so, dass das Signal verzerrt ist. > > Ich versuch mal, meine Originalregistereinstellungen zu dumpen und im > laufenden Betrieb zu ändern. Also ich kann mir vorstellen, dass es da im Source noch einige Spielereien a'la #49 gibt - und die zerlegen Dir irgendwann die Register (branadic hatte da ja auch schon "Spass" ;) Im trunk sind in "flash_t.cpp" einige Zeilen auskommentiert, die Dir die Inhalte aus dem Protected auf die Serielle dumpen. adc_change12_reg: OrginalFW: 0x2020800 Falk : 0x20000 Hayo: : 0x1000000 chan_adr_add: Protected: 0x570a Hayo : 0x5f0a chan_adr_add2: Protected: 0x5f5f Hayo : 0x0000 /* not used */ Die Zeilen sind ~2516ff, wenn Du möchtest, kannst Du Dir auch noch das diff aus dem Ticket ziehen und Deinen trunk damit patche (dann werden wieder die Werte aus dem Flash genommen und nicht die genagelten) Grüße, rowue
Rainer W. schrieb: > Rolf W. schrieb: >> [...] >> @Rainer: prüfst Du mal Deine Hardware-Version - das waren hier >> zwei Fehler: einmal ein falscher Umgang mit der Hardware (#45, .0L) >> und einmal der Autoscale (#49). >> PS: Willst Du 'nen Flash "mit den Eiern oben drauf"? ;) > > Mein W2024A hat die HW 1C9.0L Interessantes Gerät ;) probier mal das Flash aus: Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil2)" das sollte Deinem Problem abhelfen ;) > > Rainer Grüße, rowue
Rolf W. schrieb: > Michael D. schrieb: >> Hallo Rolf, > > Hi Michael, > >> das war fies, gelle? Aber nicht so gemeint! Bevor das hier überläuft, >> dachte ich... > > Du Socke ;) "ICH HABE GERADE KEINE AN"- rate mal, weshalb ich das Ticket-System des Trac > bevorzuge ;) >> ...ich kann'S mir vorstellen... > Generell nur das. Eins nach dem anderen - wenn Du sagst, dass der > Fehler bei Dir auch weg ist, dann committe ich das schon mal ...der Fehler is'wech (freu) Habe auch beim 'switschern' auf 'AUTOSCALE' keine Treppen mehr auf Kanal 2, außer das Gezappel im Automodus (Triggerlevel keine Wirkung)! Aber das war ja voher schon so! 'RUN/STOP dann SINGLE-Shot, PRE-Triggern bis Flanke da ist... > und vielleicht finden wir dann (irgendwann) das Problem, was > Stefan hat. Er hat eine andere HW-Version als ich! Ich habe (W2022) die besagte 8C7.0L >> >> Oh man, ich wollte doch noch das Ticket #46 >> (Zeroline-Correction)bearbeiten, voll verpeilt, wer war denn da so nett? >> > > 5 ;) hmpf...danke schön. >> Gruß Michael > > Grüße, > > rowue Gruß Michael PS. Was hier los ist?!?
Michael D. schrieb: > Rolf W. schrieb: >> Michael D. schrieb: >>> Hallo Rolf, >> >> Hi Michael, >> >>> [Trac und µPC] >>> > ...ich kann'S mir vorstellen... > >> Generell nur das. Eins nach dem anderen - wenn Du sagst, dass der >> Fehler bei Dir auch weg ist, dann committe ich das schon mal > ...der Fehler is'wech (freu) O.K. - habe den patch jetzt committet und das Ticket dicht gemacht ;) > [...] > >> und vielleicht finden wir dann (irgendwann) das Problem, was >> Stefan hat. > Er hat eine andere HW-Version als ich! > Ich habe (W2022) die besagte 8C7.0L Also nach http://sourceforge.net/apps/trac/welecw2000a/wiki/usersinstrument würde ich davon ausgehen, dass Stefan auch ein .0L hat. > >>> >>> Oh man, ich wollte doch noch das Ticket #46 >>> (Zeroline-Correction)bearbeiten, voll verpeilt, wer war denn da so nett? >>> >> >> 5 ;) > hmpf...danke schön. Letzter Stand war, dass Du evtl. ein neues Ticket wg. englischem Text machen wolltest - anyway - wenn ich mit #44 "durch" bin, setze ich mich daran - ich hab's ja auch "verbockt" (und kenne nur zwei Punkte, an denen es liegen kann ;) >>> Gruß Michael >> >> Grüße, >> >> rowue > Gruß Michael > > PS. Was hier los ist?!? Postschweinegrippe/-erkältungswelle ;) Grüße, rowue
Rolf W. schrieb: > probier mal das Flash aus: > > Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil2)" > > das sollte Deinem Problem abhelfen ;) S U P E R - damit sehen bei mir die Signal jetzt immer "sauber" aus. Was noch da ist, ist nach dem "Autoscale" der (meist) gestoppte Zustand mit grüner "Run/Stop" Taste und der merkwürdige Pretrigger-Wert. Gruß Rainer
Angehängte Dateien:
Hallo Rolf, Ich habe jetzt nochmal deine letzte FW (20091116) drauf gespielt und mit dem internen Signal bis (200mV/Div) 5n/S getriggert, allerdings mit dem Standart-Trigger und mal 2 Bildchen gemacht! 1. ist ohne Denoising das 2. mit Denoising (Noise Filter geht jetzt bis 2nS ???) Ich denke es sieht aus wie es soll!!!!!!! Irgend Jemand wollte doch mal den internen Generator auf 25MHz aufpumpen,(Sinus,Rechteck ist ja vorhanden) oder? Das wäre doch mal was, wenn das dann noch optional einstellbar... was ein Highlight!!! Außerdem besteht ja die Möglichkeit das Generatorsignal nach außen zu führen. Gruß Michael
Hallo, ich teste gerade mal noch die Registerwerte aus. Am interessantesten scheint adc_change12_reg zu sein. Wie sieht es aus mit euch? Seid ihr bereit ein paar Registerwerte über Falks-Perl Skript durchzuprobieren, was sie bei euch für Auswirkungen haben? Vielleicht können wir da eine Tabelle ins Wiki stellen.
Wenns unter windows geht bin ich dabei. (versuch grade nen upload mit perlscript)
Angehängte Dateien:
-
testversion.JPG
38 KB
Hab jetzt mal die aktuelle testversion drauf, Kanal1 sieht noch nicht schön aus... Das konnte ich bisher auch nicht beseitigen. Gruß Torsten
was ist das denn? Was für ein Signal hast du da gemessen? Intern oder Extern? Was für eine Frequenz hat Dieses? Gruß Michael
Internes 1khz Mein Generator steigt nämlich noch langsamer...
Angehängte Dateien:
-
screenshot-0003_Normal.png
4,7 KB
Hallo Torsten, also ich jetzt mal deine Messung nachvollzogen, weil ich mich schon gewundert habe, das du so eine niedrige Amplitude hast! Ich nehme mal an, das du den Tastkopp auf 10x stehen hast?!? Habe mal mit deinen Einstellungen einen Shot gemacht ohne Denoising, interne 1KHz, 20mV/Div, 5n/S, Tastkopp auf 10x ohne Anpassung an die Scalierung dann kommt das bei mir raus!!! (Ich sehe gerade, das ich da eine Verschiebung habe, hm) Bedienungsfehler Deinerseits vielleicht? Gruß Michael
Ich messe sowohl mit dem fluke als auch mit dem oszi (mit anpassung der taskopf einstellung 1:10) 370mV RMS Was soll da denn offiziell rauskommen aus dem anschluss? Edit: Sieht doch aus wie bei mir, nur ohne Zacken ;-) Gruß Torsten
hmm, ich habe 250mV RMS gemessen! stimmt, sieht genauso aus, nur hatte ich die Zacken 'früher' auf dem 2.Kanal! Mit der letzten 092a die hier zur Verfügung stand, seit dem nicht mehr, alles wie es sein soll. Gruß Michael
Stefan E. schrieb: > Hallo, > > ich teste gerade mal noch die Registerwerte aus. Am interessantesten > scheint adc_change12_reg zu sein. Wie sieht es aus mit euch? Seid ihr > bereit ein paar Registerwerte über Falks-Perl Skript durchzuprobieren, > was sie bei euch für Auswirkungen haben? Vielleicht können wir da eine > Tabelle ins Wiki stellen. Schau mal auf SFN, da hatte Falk schon einiges aufgeschrieben ;) (im Trac-Wiki ;)
@Rolf W. Jo, dass hab ich mittlerweile auch rausgefunden. Dennoch, wissen wir nicht, wie sich welche Hardware-Version mit welchen Werten verhält. Beim einen läufts mit der einen Einstellung, der andere braucht eine andere. Da hat sich etwas im FPGA geändert. @all Bei der 92a habe ich die beim mergen einen anderen Wert für das eine Register übernommen. Entweder den von Hayo oder den von Falk. Weiß grad nimmer. Der schein bei einigen nicht richtig zu funktionieren. Ich werde deshalb eine Möglichkeit bereitstellen, einen der Werte einfach über das Menü (erstmal nur das Menü der seriellen Schnittstelle) auszuwählen und zu speichern. Außerdem wird man den Standardwert einstellen können, wenn einem die Spikes zu stark nerven und einen die Signalverzerrung bei hohen Frequenzen nicht stört.
Stefan E. schrieb: > @Rolf W. > > Jo, dass hab ich mittlerweile auch rausgefunden. Dennoch, wissen wir > nicht, wie sich welche Hardware-Version mit welchen Werten verhält. Beim > einen läufts mit der einen Einstellung, der andere braucht eine andere. > Da hat sich etwas im FPGA geändert. O.K. - dass heißt viel Spielen mit verschiedenen Hardware-Versionen ... > > @all > Bei der 92a habe ich die beim mergen einen anderen Wert für das eine > Register übernommen. Entweder den von Hayo oder den von Falk. Weiß grad > nimmer. Der schein bei einigen nicht richtig zu funktionieren. Ich werde > deshalb eine Möglichkeit bereitstellen, einen der Werte einfach über das > Menü (erstmal nur das Menü der seriellen Schnittstelle) auszuwählen und > zu speichern. Außerdem wird man den Standardwert einstellen können, wenn > einem die Spikes zu stark nerven und einen die Signalverzerrung bei > hohen Frequenzen nicht stört. Naja, zum Auslesen und Setzen von Werten gibt es zumindest im trunk unter "misc-tools/setvars" setvar.pl - ansonsten würde ich es überwiegend vorziehen, die Werte aus dem Flash zu nehmen. Bis auf die adc_changeXX scheinen die ja noch einigermassen o.k. zu sein (wenn sie nicht aus versehen überschrieben oder auf uninitialisierte Werte) gesetzt werden. Grüße, rowue @Stefan: Was Du gemerged hast, sollte aus dem Diff im trac deutlich ersichtlich sein - geh mal auf "Revision Log" vom trunk, da kannst Du Dir zwei Versionen als diff gegeneinander stellen lassen ;)
Hallo, da ich nicht abschätzen kann wie viel Zeit ich die nächsten zwei Wochen habe, hier der Link zum versprochenen FFTscreener V0.0.2. Das zip enthält das Handbuch (pdf) und die FFTscreener.exe. Da ich die Matlab compiler runtime nach deren Lizenzbed. nicht öffentlich zugänglich machen darf, gibts diese erstmal, wie gehabt auf pers. Anfrage bei mir. http://sourceforge.net/projects/welecw2000a/files/FFTscreener/Version%200.02/FFTscreener_V0.0.2.zip/download Der Umfang der Funktionen im FFTscreener ist gewaltig angestiegen, leider konnte ich noch bei weitem nicht alle Unzulänglichkeiten und Bugs beseitigen, ich bleibe aber weiter dran... Gruß, brunowe
Angehängte Dateien:
-
000-Spike_Persist.png
7,9 KB -
000-Spike_20ns.png
5 KB
Hallo, zum Thema Störungen/Signalerfassung habe ich bei meiner Kiste (W2024A, orig. FPGA, FW OS-0.92 20091116) zwei Merkwürdigkeiten beobachtet, die ich hier einfach mal zur Diskussion stellen möchte, weil dazu im Thread konkret nichts zu finden war. Ich sehe, verstärkt bei eingeschaltetem Noise-Filter, auf den Signalen sporadische 3er-Gruppen von schnellen Spikes, die auf allen 4 Kanälen (fast) synchron auftreten. Die Spikes haben einen Abstand von 8 ns und sind am besten zu sehen, wenn der Persist Modus des Displays aktiviert ist, sonst huschen sie ab- und zu mal durch. Soweit ich das Raw-Datenformat richtig verstehe, sieht es so aus, als ob von jedem Kanal die Daten eines ADCs betroffen sind und der Wert 0 gelesen wird. In dem zeilennummerierten Ausschnitt gehts bei (Original-)Zeilennummer 14820 mit so einem Burst los. Die Spikegruppen haben anscheinend eine feste Struktur: Ch. 1, 2+3, 1+4, 2+3, 1+4, 2+3, 4. Weiter wundert mich der Zeitversatz zwischen den Kanälen. Bezogen auf Ch.1 sind das etwa 9, 11 und 18 ns (ProbeComp Signal, 1:10, Ch3 mit 2x27 Ohm). Mich macht stutzig, dass die Spikes einerseits anscheinen statistisch auftreten und andererseit kräftig mit dem Noise-Filters korreliert sind. So gesehen ist mir nicht klar, ob das Firmware, FPGA oder Hardwaredesign ist. Oder hat mein Scope 'ne unbekannte Macke? Gruß Rainer EDIT: Das kurze sind die richtigen Raw-Daten dazu
> EDIT: Das kurze sind die richtigen Raw-Daten dazu
Neuer Versuch mit wesentlichem Teil des Anhangs
(Mist, die Anhänge lassen sich anscheinend nicht editieren)
Hallo Rainer,
>(Mist, die Anhänge lassen sich anscheinend nicht editieren)
Tja... unter Sourceforge wäre das kein Problem!.
Deine Spikes sind bei weitem keine neue Erscheinung! Bei mir treten
diese Spikes besonders bei kaltem Gerät auf. Diese Spikes hängen ganz
offensichtlich mit dem adc_change12_reg zusammen...dreht sich nicht die
Diskussion hier seit einigen Monaten um nichts anderes mehr?
Auch der Zeitversatz zwischen den einzelnen Kanälen wurde vor einigen
Monaten schon intensiv besprochen- es gibt dazu sogar eine Aufstellung
wie groß der Versatz bei den einzelnen Geräten ist.
Hier sind die einzelnen Posts halt nicht einem spezifischem Thema
zuzuordnen, daher ellenlang und total unübersichtlich!
Gruß, brunowe
Hallo, Ist die Liste mit dem Zeitversatz der einzelnen Planes irgenwo auf SF zu finden? Was mir noch aufgefallen ist: Im Delayed Mode der Build: rowue-2009116 ist mir ein Problem aufgefallen. Es wird die information links NEBEN dem Cursor Window auf der unteren Schirmhälfte angezeigt. Wenn man nun das Fenster an den linken Rand schiebt werden ungültige Daten angezeigt. Ist der Bug bekannt (oder sogar in der 92a gefixt) oder soll ich dazu ein Ticket schreiben? Die Bedienung des Pretriggers könnte noch in soweit verbessert werden als das man den Triggerpunkt Zeitbasisübergreifend per Menueauswahl über der 2. Gridline von links oder über die mittlere Gridline "Festnageln" kann. Eventuell per Tabelle. Punkt für Wishlist? Fehlt unter Mode/Coupling nicht noch ein Punkt "Off" im Rejectmenue? Oder versehe ich das falsch? Gruß Torsten
Bruno We schrieb: > Deine Spikes sind bei weitem keine neue Erscheinung! Ich hatte hier im Thread nur von Spikes auf festen Positionen, auf einzelnen Kanälen usw. gelesen, was für diese 3er-Gruppen nicht zutrifft. Weil bei 50ns/div (oder schneller) immer alle Samples zu sehen sind, hoffte ich, dass die Korrelation mit dem aktiven Noise-Filter und das feste Muster bei der Ursachenforschung helfen könnten. > ... daher ellenlang und total unübersichtlich! wie wahr. ;-) Was tut die Noise Filter Funktion eigentlich genau? Ich hatte die so verstanden, dass sie nur nicht angezeigte Werte zu einem Anzeigewert mittel, d.h. bei 50ns/div sollte sie gar nichts tun. Ist das der Stand der Dinge? Lassen sich solche Algorithmen vielleicht im Wiki dokumentieren unter "Inside of the W20xxA"? Gruß Rainer
Hallo zusammen! Die Spikes entstehen nach meinen neuesten Erkenntnissen anscheinend im Digitalteil der AD-Wandler, falls diese eine Überspannung am Eingang anliegen haben (Fachbegriff signed/unsigned overflow). Das unbekannte change_adc_reg12 könnte sehr ähnlich aufgebaut sein, wie auch ich es bei dem LEON3 FPGA-Design implementiert habe, siehe Dateianhang! In meinem FPGA-Design und mit dessen Software bekam ich ohne eine Addition oder Multiplikation auf das Signal zu machen auch diese Effekte. Dies geschah aber erst zu einem Zeitpunkt, als ich anfing, die analogen Einstellungen zu tätigen (DC-Offset mit dem DAC, analoge Verstärkungseinstellungen,...). Übrigens habe ich es geschafft, den Firmware-Upload des LEON3s mit meiner selbstgeschriebenen Software zu erledigen. Damit kann die Entwicklung völlig ohne kostenpflichtige Software vorangetrieben werden! Ein Demoversion mit verstellbarer Abastzeit und noch ein paar Dingen (vielleicht Spannungsbereiche, Triggerlevel, DC-Offset, ...) wird bald folgen. Bei vorzeitigen Interesse bitte bei mir melden! MfG Alexander
Torsten Otten schrieb: > Hallo, > Ist die Liste mit dem Zeitversatz der einzelnen Planes irgenwo auf SF zu > finden? > > Was mir noch aufgefallen ist: Im Delayed Mode der Build: rowue-2009116 > ist mir ein Problem aufgefallen. Es wird die information links NEBEN dem > Cursor Window auf der unteren Schirmhälfte angezeigt. Wenn man nun das > Fenster an den linken Rand schiebt werden ungültige Daten angezeigt. > > Ist der Bug bekannt (oder sogar in der 92a gefixt) oder soll ich dazu > ein Ticket schreiben? Also wenn das ein Build von mir (rowue-20091116) ist, dürfte er in der 92a nicht gefixt sein - meinst Du evtl. den trunk? Generell würde ich zu jedem Bug, der in einer aktuellen Version auffällt sagen: schreibt ein Ticket, allerdings schaut vorher, ob es dort schon eins gibt (oder ggf. gab) - evtl. sollten wir eine "known-Bugs" Liste schreiben (von Dingern, die wir nicht fixen könne/wollen ;) > > Die Bedienung des Pretriggers könnte noch in soweit verbessert werden > als das man den Triggerpunkt Zeitbasisübergreifend per Menueauswahl über > der 2. Gridline von links oder über die mittlere Gridline "Festnageln" > kann. > Eventuell per Tabelle. > > Punkt für Wishlist? Im Ticket-System gibt es auch den Punkt "Feature Request" ;) > > Fehlt unter Mode/Coupling nicht noch ein Punkt "Off" im Rejectmenue? > Oder versehe ich das falsch? > > Gruß > Torsten Grüße, rowue
alex008_ schrieb: > Die Spikes entstehen nach meinen neuesten Erkenntnissen anscheinend im > Digitalteil der AD-Wandler, falls diese eine Überspannung am Eingang > anliegen haben (Fachbegriff signed/unsigned overflow). Um aus einem Overflow in einem einzelnen Wandler immer 3er Gruppen von Spikes synchron auf allen 4 Kanäle zu erzeugen, auch wenn ein Kanal z.B. auf Masse liegt, muß noch mehr passieren. Und wieso sollte das immer jedes 2te Sample betreffen? Ich denke das hat einen anderen Grund. Gruß Rainer
Beim Vergleich der 3er-Spikes von FW OS-0.91 (Falk 20090810) zu OS-0.92
(rowue 20091116) fällt eine geänderte Sequenz auf:
0.91: Sequenz 1, 2+3+4, 1, 2+3+4, 1, 2+3+4
0.92: Sequenz 1, 2+3, 1+4, 2+3, 1+4, 2+3, 4
In beiden Fällen sieht man im Raw-File, wie die Spikes auf 0 gehen.
OS-0.91 OS-0.92
adc_change12_reg 20000 20000
adc_change34_reg 200000A 20000
@brunowe: Gibt es die bisherigen Erkenntnisse zu den Spikes irgendwo
schon in geordneter Form oder ist das hier auf mehrere Threads gut
verteilt? Bei SF konnte ich nichts dazu finden.
Gruß Rainer
Hallo Rainer, meines Wissens gibt es noch nirgends eine geordnete Sammlung über das Auftreten der Spikes... Da ich in der FW- Entwicklung auch keine Karten habe, kann ich kaum mit nützlichen Informationen dazu dienen. So weit mir bekannt ist, sind da allerdings einige Leute am basteln (Falk, Jörg...). In der FW- Version 0.92 hatte sich bei mir das Problem massiv verschlimmert, weswegen ich immer noch mit der 0.91 OS gearbeitet habe. Im Zuge der FFTscreener- Programmierung werde ich auch direkt auf die OS 0.93 wechseln. Grüße, brunowe
Bruno We schrieb: > Hallo Rainer, > > meines Wissens gibt es noch nirgends eine geordnete Sammlung über das > Auftreten der Spikes... Die Spikes hängen direkt mit dem adc_NN_change Register zusammen. Setzt man das Bit, das die Spikes verhindert, gibt es die elenden Verzerrungen ab ~50MHz. Daher auch das Auftreten des einen oder anderen Problems in 0.91, 0.92, 0.93. Mir war mal aufgefallen, daß die Spikes ohne Trigger (Auto) immer am Ende des Samplebuffers erscheinen. Die Dinger haben auch immer den gleichen Wert, der sich aber bei Änderung an der Zeitbasis ändert. Nach dem Einschalten haben die, wenn ich mich richtig erinnere, immer den Wert 0. Ich habe mal ein paar Raw-dumps animiert: http://www.youtube.com/watch?v=3uFKkHVfNQI Es sollte kein Problem sein, die in der FW zu eliminieren. Ich mir habe die aber immer nur bei 1GS/s angesehen. Falk
Bruno We schrieb: > Hallo Rainer, > > meines Wissens gibt es noch nirgends eine geordnete Sammlung über das > Auftreten der Spikes... Da ich in der FW- Entwicklung auch keine Karten > habe, kann ich kaum mit nützlichen Informationen dazu dienen. So weit > mir bekannt ist, sind da allerdings einige Leute am basteln (Falk, > Jörg...). > In der FW- Version 0.92 hatte sich bei mir das Problem massiv > verschlimmert, weswegen ich immer noch mit der 0.91 OS gearbeitet habe. > Im Zuge der FFTscreener- Programmierung werde ich auch direkt auf die OS > 0.93 wechseln. Hi Bruno, hast Du mal den Build probiert, den ich hier vor einigen Tagen reingestellt habe? Da habe ich auch die adc_change_XX wieder auf die Werte von Falk zurückgedreht .... > > Grüße, brunowe Grüße, rowue
Angehängte Dateien:
-
spikes92a.PNG
4,5 KB
Hallo, also ich habe heute die Build rowue-2009116 wieder durch die aktuelle 0.92a erstezt. Anbei ein Persist über 15min von den Spikes. Das kuriose ist das die spikes bei der Build 2009116 auf der anderen seite der flanke waren und zwar von oben nach unten... Sah da genau so aus. Ein weiteres Puzzelstückchen. Gruß Torsten
Torsten Otten schrieb: ... > Anbei ein Persist über 15min von den Spikes. Das gleiche hatte ich bei 50ns/Div. gemacht: http://consult42.com/tmp/screenshot-0000.gif Edit: Noch eins: http://consult42.com/tmp/triggerprobs3.gif > Ein weiteres Puzzelstückchen. Und noch eins... Falk
Bei mir kam leider nie so ein schönes muster raus, bzw. traten die spikes nicht auf bei so kleinen zeitbasen.
Angehängte Dateien:
Hallo Falk, Falk Willberg schrieb: > Mir war mal aufgefallen, daß die Spikes ohne Trigger (Auto) immer am > Ende des Samplebuffers erscheinen. Die Dinger haben auch immer den > gleichen Wert, der sich aber bei Änderung an der Zeitbasis ändert. Spikes an fester Position sehe ich bei mir auch, und zwar wenn das Scope mit Auto-Trigger (od. Standard) frei läuft, d.h. wenn kein triggerndes Signal anliegt. Dann sehe ich mit 1GSa/s 50nm/div (oder schneller) stabile Spikes bei einer Pretrigger-Einstellung von 8.04 us. Ein fester Zeitbezug zum Autostart der Aufzeichnung macht die Dinger vielleicht etwas greifbarer. Nebenbei sind mir noch drei Dinge in der 0.92 aufgefallen: ---------------------------------------------------------- 1. Im Screenshot zeigt sich noch ein Darstellungsfehler beim genau zeichnenden Linienalgorithmus. Es werden oben manchmal Punkte gezeichnet (hier rote vom Ch4), die anscheinend die "Verlängerung" von zu weit nach unten geschobenen Signalen sind. 2. Die Zahlenangaben für die Cursorpositionen hinken beim Verschieben eines Cursors manchmal endlos (ca. 4s) hinter den dargestellten Linienpositionen hinterher. 3. Wieso sind die Zeitangaben für die Cursor X-Positionen eigentlich auf den Bildschirmrand bezogen? Für's praktische Leben ist doch der Zeitbezug zur Triggerposition die entscheidende Größe. Dann wäre das auch konsistent mit den Y-Angaben, die sich ja auch auf einen bestimmten Signalnullpegel beziehen. -> Verbesserungsvorschlag Gruß Rainer
Huhu, lebt hier noch jemand? @Hayo: Hast du im Delayed Fenster noch eine größere Baustelle offen? Auf jeden Fall ist da noch der Wurm drin: Bei 1 GSa/s habe ich mit der OS-0.92 bei mir Signalverschiebungen von mehr als 1 us zwischen Main und Delayed Fenster beobachtet. Dadurch tritt anscheinend auch das von Torsten beschriebene Problem auf (Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil2)"). Beim Ticket http://sourceforge.net/apps/trac/welecw2000a/ticket/34 habe ich dazu mal ein paar konkrete Beispiele hinzugefügt. Ist das noch "minor"? Gruß Rainer
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?
Musashi, DON'T PANIC! ;-) please see http://sourceforge.net/apps/trac/welecw2000a/wiki/FWdownload and http://sourceforge.net/apps/trac/welecw2000a/wiki/FWupload This should give all information, you will need. A forum, which is not limited to German language, is located here: http://sourceforge.net/apps/phpbb/welecw2000a/ HTH, Falk
hello trying to run fftscreener version 02 and getting C:\Program Files\MATLAB\R2009b\bin\win32>fftscreener Fatal error finding symbol mclMlfFeval in C:\Program Files\MATLAB\R2009b\bin\win 32\mclmcr.dll Error: or C:\Program Files\MATLAB\R2009a\bin\win32>fftscreener Fatal error finding symbol mclMlfFeval in C:\Program Files\MATLAB\R2009b\bin\win 32\mclmcr.dll Error: any help apreciated
hello christi s, to run the fftscreener you have to install the Matlab compiler runtime. If You've got Matlab on your PC installed, the fftscreener.exe should work in a proper way (if the MCR is up to date). I assume Matlab (or the MCR at least) isn't installed on your system. Because of the license agreements of Mathworks/ Matlab it isn't possible to post a unprotected link to the MCR. Anyhow its allowed to share this file ;). To anybody who needs this MCR, please send my a PN (use brunowe@users.sourceforge.net) and I'll post you a link to the needed MCR. For further request and support please use this forum: (splitted in german and english). You could post there (and I also answer) in Spanish or Russian if needed. http://sourceforge.net/apps/phpbb/welecw2000a/ regards brunowe
Hallo Leute, ich habe einen Welce 2014A mit der orignalen FW V1.4. Ich möchte gerne Screenshots von meinen Messungen machen und diese aufm PC als JPG oder BMP oder ein anderes Bildformat abspeichern. Hab mir mal die SW von der Welec- Homepage angeschaut. Dieses scheint aber irgendwie nicht wirklich fertiggestellt worden zu sein. Die Screenshots sind unvollständig und die Angaben über die Zeit- und Spannungsauflösung stimmen überhaupt nicht. Wenn ich mir so eure Screenshots anschaue gefällt mir dass schon besser. Kann mir jemand sagen ob es da schon ne andere SW dafür gibt? Wenn ja, wo finde ich diese? Gruss und Danke, Schorschi.
Hallo, wie ich dass sehen konnte gibts da den sorce. Gibts iegendwo auch eine fertig kompilierte Applikation? gruss, georg
Hallo! Ich habe auch keine Ahnung, wo Hayo's Homepage sein soll. Georg X: Auf unserer Sourceforge Homepage gibt es ein paar vorkompilierte Releases zum Runterladen! http://sourceforge.net/projects/welecw2000a/files/ Das was du suchst, ist unter Open Source Firmware. Das W2000L Release ist das, mit dem ich mich momentan beschäftige. Das ganze ist noch nicht einmal in einem Alpha Stadium. Falls dir aber die Frequenzauflösung und der Spannungsbereich egal ist, und dir ein perfekt funktionierender Trigger gepaart mit einer besseren Signalqualität bei den 2 und 1 V/div wichtiger ist, kann ich dir das schon mal zum Probieren empfehlen! MfG Alexander
Hallo werte W20xx Gemeinde, frohes neues Jahr an alle. Ich war einige Zeit beruflich im Ausland und bin daher zu nichts gekommen. Ich muß mich erstmal hier durch die Beiträge lesen um auf den aktuellen Stand zu kommen, dann werde ich mal sehen wo ich wieder einsteigen kann. Das wird wohl einige Tage dauern bis ich da im Bilde bin. Zu den letzten Beiträgen: Eine eigene Homepage habe ich nicht, aber wie Alex schon geschrieben hat gibt es eigentlich alles Wichtige auf der SF-Projekt-Homepage. Sonst gibt es noch die alte Google-Groups Adresse http://groups.google.de/group/welec-dso/ Hier kann man auch einige Sachen runterladen. Allerdings sind die Firmwareversionen nicht mehr auf dem aktuellen Stand. Gruß und bis bald Hayo
Hi Hayo ein gutes Jahr 2010 wünsche ich Dir! Wir dachten schon alle, dass du dem Welec den Rücken gekehrt hast...ich freue mich, dass dem nicht so ist! Viele Grüße Michael
Moin Leute, ich habe noch immer ein W2012A abzugeben. Schaut mal hier: Beitrag "[V]: Welec W2012A" Sorry wegen der Werbung, aber die Leute, die hier mitlesen, haben sicher am ehesten noch Interesse am Gerät und wissen es zu schätzen ;) LG
Hi Leute, nach längerer Zeit mal wieder eine Rückmeldung von mir. Leider läßt mir der Beruf momentan nicht so viel Zeit zum Programmieren und tüfteln wie ich gerne möchte. Nichtsdestotrotz versuche ich hier weiter am Ball zu bleiben. Hat sich das Problem mit den adc_change_XX Registern inzwischen geklärt? Ansonsten hier noch ein Hinweis: Nachdem Falk herausgefunden hatte dass da ein direkter Zusammenhang mit der Schwingneigung besteht und den Registerwert auf 0x20000 gesetzt hatte hab ich eine ganze Zeit mit diversen Werten rumexperimentiert und festgestellt, dass meine beiden DSOs am besten mit dem Wert 0x1000000 laufen, da sich damit auch hohe Frequenzen prima darstellen lassen und keine störenden Spikes entstehen. Bei mir läuft das damit eigentlich völlig problemlos. Habt Ihr da neue Erkenntnisse, evtl. Unterschiede bei verschidenen Geräten? Bei mir handelt es sich um ein W2014A und ein W2022A. Desweiteren: - Die Datei mit den verschiedenen Kanalversätzen kann ich gerne hier posten wenn Ihr die braucht - irgendwann wollte doch jemand bei Conr... Netzschalter besorgen -> wie sieht es damit aus? - Ja, im Delayedbereich gibt es noch einige Baustellen die liegengeblieben sind, genauso im FFT-Bereich wo ich noch einiges hinzufügen wollte - @Stefan -> wenn Du Hilfe beim Menü brauchst (ist wirklich etwas unübersichtlich mit den ganzen Strukturen für Werte und Texte) um Deine Triggerfunktion da einzuhängen kann ich Dir gerne Tipps geben - meine letzte Baustelle vor meinem Auslandseinsatz war eigentlich die Änderung der Timebases und der Timebasesteuerung. Da wollte ich evtl. wieder ansetzen falls da nicht schon jemand anderes was geklöppelt hat. Gruß an alle Mitstreiter und Welec-Besitzer Hayo
...da isser ja! Du meine Güte, hast ja Recht! Ich muß zu meiner Schande gestehen, das ich die Schalter völlich verpeilt habe, die liegen hier rum und wollen zu ihren neuen Besitzen...du wolltest 2 Stck.? Die Anderen muß ich mal nachschauen oder ihr meldet euch nochmal...wie peinlich! Bei deinen letzten FW's, war ein Fehler (extremes Rauschen bzw. Treppchen im oberen Frequenzbereich vom 2. Kanal), der in der Vers. vom Rolf behoben wurde (Flash_1.2-OS-0.92a, Flash_TomCat_16112009_Rolf(rowue)) ...nur mal zur Info! Schick mir doch mal bitte deine Adr., damit ich dir die Schalter zukommen lassen kann. Grüsse aus Hessen
Hi, @Michael -> die Mail mit meiner Anschrift ist raus! Das Problem mit den Treppchen etc. hatte ich so grob beim Nachlesen mitbekommen. Ist denn nun geklärt woran es lag? @Rolf was hast Du denn im Detail geändert? Gruß Hayo
Hayo W. schrieb: > Hi, > Hi, sorry erstmal für's lange nicht melden, resp. für's späte melden, ich ziehe zum 01.03. für einige Zeit nach Freiburg und bin hier etwas im Umzugsstress.... > [...] > > > @Rolf > > was hast Du denn im Detail geändert? Zwei Dinge: a) werden einige Werte wieder aus dem Flash gelesen b) habe ich die adc_change Regs wieder auf 0x20000 gesetzt Die Änderungen im Detail: http://sourceforge.net/apps/trac/welecw2000a/changeset/316 Das Ticket mit dem Problem: http://sourceforge.net/apps/trac/welecw2000a/ticket/45 <frotzel> Schön, dass es sowas wie svn und trac gibt </frotzel> An der Signalstörung im Bereich 250/500 MSa/s bin ich noch dran, allerdings sieht es so aus, als ob die "Verwürfelungen" Kanal-Abhängig sind und da ich mir den vierten Kanal gerade "verlötet" habe (schwingt jetzt), werden weitere Aktionen da etwas warten müssen. Als ich "routinemässig" den 1GSa/s Bereich mit 'nem Dreieck (zweistellig MHz) gemessen habe, ist mir noch aufgefallen, dass die Sampling-Abstände zwischen den einzelnen ADC's nicht äquidistant sind, sondern, dass es eher so aussieht, als würden zwei zur gleichen Zeit abgefeuert. Dies ist auch sehr schön zu sehen, wenn mensch die Flanke vom Probe-Signal mit 1GSa/s misst (Treppen). Ich sehe mal zu, dass ich da noch was zusammengefasst bekomme. > > Gruß Hayo Beste Grüße, rowue
Hi Rolf, danke für die Antwort. Wie Du siehst ist bei mir die Zeit im Augenblick auch etwas knapp, daher bin ich auch nicht so oft hier online. Will aber auf jeden Fall weitermachen und die Firmware weiterentwickeln. Auf der Softwareseite scheint ja im Moment nicht allzuviel zu passieren, wenn ich das hier so sehe. Wird wohl mal Zeit wieder in dei Hände zu spucken. @Michael Hattest Du meine Mail bzgl. der Schalter bekommen?? Gruß Hayo
Hallo zusammen, ich habe folgendes Problem bei meinem W2014 nach dem Firmware-Update auf Version 0.92a entdeckt. Der Kanal 4 ist grundsätzlich aktiv. Nach drücken der Taste "Kanal 4": + LED "Kanal 4" geht aus, + Mathematik-Funktionen werden aktiviert, "FFT" aktiviert. Nach erneutem drücken der Taste "Kanal 4": + "Kanal 4" wieder aktiviert. Nach drücken der Taste "Math": + Mathematik-Funktionen werden aktiviert, "FFT" aktiviert. Wechsle ich nun auf eine der anderen Funktionen (Mult, Sub, Ass): + Kanal 4 bleibt aktiviert/angezeigt. + mit Taste "Kanal 4" kann ich das magentafarbene Funktionssignal "zuschalten". Kennt jemand von euch ein ähnliches Phänomen? Grüße, Uwe PS: Entschuldigung für das Doppelposting, ich habe aus versehen auf "Neuen Beitrag" anstatt auf "Antwort" geklickt und es erst hinterher bemerkt.
Hallo Uwe Ich habe Version 1.2.OS.092 (W2024A) Wenn ich einschalte ist das Fenster mit der Version, nur mehr ganz kurz sichtbar. (vorher war es länger ..) und Kanal-1 Led leuchtet (Taste). Am Bildschirm habe ich links aber drei gelbe Anzeigen: 1,T, 1T und die grüne Anzeige (2) und die rote(4) Es ist aber nur Kanal 1 ein und oben im Fenster auch nur Kanal 1 sichtbar. Horizontale Linien sehe ich keine.. Wenn ich Kanal 2 Aus und Ein Schalte, ist dann links nur mehr Kanal 1 zu sehen.. Die Linie für Kanal 1 sehe ich aber erst, wenn ich Kanal 4 AUS und EIN schalte :-( l.G. Roberto
Hallo Leute, wer arbeitet denn noch an der Nios Firmware? Es sind in der 1.2.OS.0.92a noch einige Tickets offen. Siehe http://sourceforge.net/apps/trac/welecw2000a/report/2 Mfg, Kurt
oje, der Roberto steht noch im Dunkeln, vielleicht setzt du mal ein paar Bildchen hier rein, dann könnte man das evtl. ewas besser nachgvollziehen??? Gerade das Ticket 46 (Zeroline Correction) geht mir immer wieder auf'm S... ! Bist fertig mit dem Messen und es wird immer noch eine Spannung angezeigt, obewohl alles abgeklemmt is', also wieder alles auf 'NULL' calibrieren, sehr lästig... Das Ticket 37 ist mir noch garnicht aufgefallen, werde das mal testen...hat Jemand, ausser razer6, dasselbe Problem ? Gruß Michael
Hallo Leute, bin grad aus dem Türkeiurlaub zurück (endlich mal wieder Sonne...). @Kurt Hatte leider immer noch nicht viel Zeit für die Entwicklung, wollte aber mal wieder weitermachen. @Michael Eigentlich wollte ich mal die Kanalverschiebung in Angriff nehmen, wie wichtig ist denn Ticket 46, sonst werf ich da erst einen Blick drauf. Eigentlich dachte ich die Nullpunktgeschichte (Kalibrierung) wäre erstmal einigermaßen akzeptabel wenn auch noch nicht so komfortabel. Ach ja, was machen denn die Schalter, hattest Du meine Mail bekommen? Gruß Hayo
Hallo Hayo, Ich hatte vor ein paar Wochen den PC Supergau, (aufgeblasene Kondensatoren) sehr ärgerlich! Ich habe zwar mehrere Rechner, da man ja einen nicht so vollpumpen kann, ich verdiene meine Brötchen mit der Werbetechnik, da reicht einer nicht. Gerade der mit der Buchhaltung und Emailprogramm...bin also immer noch am Daten retten... Schicke dir jetzt noch mal eine PN Ticket 46, also wie beschrieben, die Nulllinien verändern sich manchmal selbstständig während des messens, dann sind die Messwerte auch nicht mehr korrekt! Wenn das schon mal behoben würde, wäre ich etwas glücklicher, vielleicht nicht nur ich... Ach ja, die Schalter- Daten habe ich schonmal gefunden, 2,70€ habe ich hier stehen. Die Verpackung mit Klammern (das die Post hineingucken darf oder muss) und Versand käme dann nochmal auf 1,10 € Immer noch günstiger als die 6,50€ von 'C' denke ich! Also bis dann... Gruß Michael EDIT: Bernd und Hayo, ich hatte noch mal nach geschaut und den Rabatt vergessen, habe ja 10Stck. gekauft da gabs 8% also kommt ein Schalter auf 2,48€ ...wollte mich jetzt nicht an euch bereichern
Michael D. schrieb: > Ich hatte vor ein paar Wochen den PC Supergau, (aufgeblasene > Kondensatoren) sehr ärgerlich! Fu... - das ist in der Tat echt übel. Dann ist das wohl ein eher älterer Rechner oder? Denn die neueren sollten das eigentlich nicht mehr haben. Der Grund meiner etwas längeren Abstinenz ist auch unter Anderem, dass ich auf einen neueren Rechner und auch eine neue Linuxversion umgestiegen bin. Über die damit verbundene Odysse (AMD Linux Grafiktreiber etc.) will ich lieber nicht viel erzählen, aber in der Zeit hätte ich locker eine komplette neue Firmware schreiben können ;-) > Ticket 46, also wie beschrieben, die Nulllinien verändern sich manchmal > selbstständig während des messens, dann sind die Messwerte auch nicht > mehr korrekt! Wenn das schon mal behoben würde, wäre ich etwas > glücklicher, vielleicht nicht nur ich... Das Ticket bzw. das Problem kannte ich noch gar nicht, muß ich mal checken ob das bei mir auch auftritt. Hatte ich jedenfalls bislang noch nicht bewußt wahrgenommen. Gibt es eventuell einen direkten Zusammenhang mit einer bestimmten Firmwareversion, oder gibt es das schon von Anfang an bzw. auch bei der original Firmware? -> hab Dir übrigens nochmal meine Adresse geschickt Gruß Hayo
Hallo Hayo, Du hast Post! Das Zeroline-Problem ist seit dem ich das Teil in Betrieb genommen habe und mit Jeder FW. Bei der Originalen weiß ich es nicht, hatte die ja gleich runter geschmissen, war ja nicht der Reisser!!! Ich denke mal, das die Anderen dasselbe Prob. haben, vielleicht kann das Jemand bestätigen?!? Ich denke, das mit den Tickets noch was geht bevor das Redesign der neuen FW. und Eingangsstufe(Huckepackplatine) fertig ist! Gruß Michael
Auf http://sourceforge.net/apps/trac/welecw2000a/wiki/Leon%20Binaries gibt es die Firmware für das Leon3 Design fertig compiliert zum Ausprobieren. Anleitung zur Installation unter http://sourceforge.net/apps/trac/welecw2000a/wiki/leon3design
Michael D. schrieb: > Das Zeroline-Problem ist seit dem ich das Teil in Betrieb genommen habe > und mit Jeder FW. Das kann eigentlich nicht sein, ich habe mir das mal angesehen und bei mir überprüft. Das ist ein Problem mit den Skalierungsfaktoren. Bei meiner Firmware tritt das definitiv nicht auf. Habe das mal durchgespielt und da stimmt die Nulllinie in der Mitte genauso wie im oberen und unteren Bereich. Auch das Rauschen ist unverändert. Damit Du das mal selbst prüfen kannst hier die Version mit der ich das geprüft habe. Gruß Hayo
Hallo Hayo Schön das Du wieder zurück bist :-) Danke für das einspielen deines Files. Habe das jetzt auf das DSO geladen und alles funktioniert soweit gut :-) Irgendwie habe ich eh schon länger den Überblick über die Versionen verloren :-( Hatte halt das letzte vom Forum draufgespielt.. 1.2-OS-0.92a.zip und das funktionierte nicht so richtig... Aber, gab es da nicht mal eine Trennung von den Firmware-Entwicklern ? Nur weis ich jetzt nicht, was zu wem gehört :-( Und weil ich gerade beim Fragen bin und englisch nicht so gut kann :-(, wie funktioniert das mit dem neuen Leon3 ? Brauche ich dafür eine neue Hardware oder ist der Leon3 nur eine neue Programmierung für den FPGA ? Wie kann ich die Einspielen und bringt die schon was, oder kann man damit noch nicht vernünftig arbeiten ? Danke für Antworten :-) und auch Danke an alle Entwickler, nur fehlt halt leider ein bisschen der Überblick ;-) l.G. Roberto
Roberto schrieb: > Hallo Hayo > Schön das Du wieder zurück bist :-) > Danke für das einspielen deines Files. Gern geschehen > Habe das jetzt auf das DSO geladen und alles funktioniert soweit gut :-) Auch die Nullliniensache? Wie sieht es mit Spikes aus? Siehe Beiträge weiter oben. > Irgendwie habe ich eh schon länger den Überblick über die Versionen > verloren :-( > Hatte halt das letzte vom Forum draufgespielt.. > 1.2-OS-0.92a.zip > und das funktionierte nicht so richtig... Über den Stand der Dinge bei der offiziellen OS Version bin ich zur Zeit nicht im Bilde. > Aber, gab es da nicht mal eine Trennung von den Firmware-Entwicklern ? > Nur weis ich jetzt nicht, was zu wem gehört :-( Die Versionen mit dem BF sind direkt von mir. Das sind keine offiziellen Open Source Versionen, sondern meine eigenen Versionen in denen ich erst die Funktionen ausprobiere bevor ich sie freigebe. Meine Version unterscheidet sich von der OS-Version: - der neue Trigger von Stefan fehlt noch, soll aber noch implementiert werden - die Remotesteuerung von Falk ist noch nicht auf dem aktuellsten Stand - einige zentrale Register werden anders gesetzt - die Screenshotversion passt nicht zu der offiziellen Version > Und weil ich gerade beim Fragen bin und englisch nicht so gut kann :-(, > wie funktioniert das mit dem neuen Leon3 ? > Brauche ich dafür eine neue Hardware oder ist der Leon3 nur eine neue > Programmierung für den FPGA ? > Wie kann ich die Einspielen und bringt die schon was, oder kann man > damit noch nicht vernünftig arbeiten ? Das LEON Design ersetzt das alte NIOS Design im FPGA. Da sich dadurch die Hardware und die Adressen aus Sicht der Firmware komplett ändert ist auch eine neue Firmware notwendig. Wie weit der Stand dort ist weiß ich allerdings nicht. -> siehe Hardwarethread. > Danke für Antworten :-) > und auch Danke an alle Entwickler, nur fehlt halt leider ein bisschen > der Überblick ;-) Jo, kein Problem Gruß Hayo > l.G. Roberto
Hi, ich bin mir nicht so ganz sicher, ob ich beim zusammenstellen der Downloaddatei etwas durcheinander gekommen bin mit den Versionen. (welche Version wird angezeigt?) Daher hier nochmal die richtige BF.0.97 mit Historie Gruß Hayo
Hallo Hayo und Roberto, Roberto, wenn du das neue Nios-Design mal testen möchtest, stehe ich gerne zur Verfügung, denn die Programierung ist nicht ohne... Lade dir schonmal den QUARTUS-Programmer herunter und den USB-Blaster, installiere alles und schicke mir eine PM dann sehen wir weiter!!! Die Benutzeroberfläche ist schon mal eine ganz Andere, es sind nur einige Funktionen verfügbar, das Signal glasklar und null Rauschen, unglaublich, das so etwas mit dem Welec möglich ist! An dieser Stelle ein Lob an die Macher, die hier unglaubliches geleistet haben, Oskarreif... Wenn ich heute dazu komme, setze ich mal ein paar Screenshots rein! Gruß Michael
Angehängte Dateien:
Hallo Hayo, Du hattest weiter oben die BF097_Beta eingesetzt, das war deine letzte Version. Ist die mit der 'Historie' eine Andere??? Zu der Nulllinie: Habe jetzt noch mal 1Std. getestet und Screenshots gemacht. Die ersten beiden Shots sind von Rolfs 092er Version(11162009), erstes Shot ist die Grundstellung mit Auto-Trigger, 5V-DIV, 1GSa/s 1µs und kein Signal anliegen! Der 2. Shot sind die Linien Verschoben! Der 3. Shot ist von deiner Ver., also 097Beta, auch hier die Grundstellung und mit ADC sowie Dac Calibrierung und Einstellungen wie oben! Der 4. Shot ist dann wieder verschoben, 1.Kanal nach unten und 2.Kanal nach oben gezogen, auch hier ist was nicht in Ordnung. Jetzt habe ich aus dieser Stellung eine DAC-Calibrierung durch geführt und habe danach die Kanäle wieder in die Grundstellung gezogen, danach sieht es so wie auf dem 5. Shot aus! Ist das jetzt nur bei mir so, oder hat das jetzt mal noch Jemand getestet??? Gruß Michael EDIT: Zur Info!!! Die screenshot_0.91 funktioniert nur mit der--- FW092 mit 3. Trigger--- vom Rolf(11162009) Für Hayo's FW's nur diese Ver. screenshot_0.4BF ---Hayo 097beta--- Ok, hoffe ihr blickt durch...
Angehängte Dateien:
-
Versionsueberblick.gif
38 KB
Da hier einige Fragen über die bisherigen FW-Versionen gestellt wurden, habe ich mal von meinen Ordnern einen Screenshot von den bisherigen FW-Versionen gemacht: Die BF 1.2 sind vom Hayo. Die FW 1.2.OS sind vom Rolf(rowue), Guido und Stefan mit z.B. 3. Trigger usw. Der Grau unterlegte Ordner sind noch rasche Testversionen mit Datumsangabe! Ich hoffe einen kleinen Überblick verschafft zu haben. (das nimmmt schon bald eine eigene Festplatte in Anspruch) Gruß Michael
Hi, hab soeben nochmal gegengetestet mit W2014 und mit W2022. Keine Verschiebung! Das deutet auf eine Abweichung der Verstärkung auf der Hardwareseite hin - Bauteiletoleranz vermute ich mal. Die Faktoren in der Firmware (Skalierungsfaktor und DAC-Faktor) sind ja abgestimmt auf die Eingangsverstärkung der Eingangsstufe. Wenn es da Abweichungen gibt kommt es zu diesem Verhalten. Ich habe eine ganze Zeit rumgetüftelt bis es stimmte. Allerdings habe ich als Referenz natürlich nur meine beiden Geräte. Würde mich mal interessieren ob das bei anderen auch auftritt, und ob das evtl. mit der Hardwarerevision zusammenhängt. Normalerweise macht man bei ADCs auch noch eine Verstärkungskorrektur die dann sowas auch mit ausbügeln kann, die habe ich aber nach einigen Tests wieder rausgenommen, da die Performance darunter ziemlich gelitten hat. Gruß Hayo
Jetzt fällt mir gerade was ein! Kann mich erinnern, das wir das Thema schonmal hatten. Nämlich der Tausch der NULL-OHM Wiederstände gegen 33 Ohmler, die das Signal-Rauschen um einiges reduzierten! Wir aber keine Softwareanpassung gemacht haben, da haben wir ja die Leiche! Was meinst du, soll ich die Wiederstände wieder raus schmeissen oder wäre eine SW-Anpassung sinnvoller? Evtl. als Kalibrierungsoption könnte man das einbauen oder ist der Auwand dafür zu groß??? Wenn das nicht so eine Popelei wäre würde ich gleich den Lötkolben in die Hand nehmen... Gruß Michael
Angehängte Dateien:
Hier mal ein Foto von dem Umbau. Da wo jetzt der 33 Ohmler sitzt, klebte vorher der Nuller Wiederstand. Das ganze natürlich 2mal pro Kanal!
ich schon wieder... Hayo, Die BF097beta ist mit der BF097-Historie identisch, haben beide dasselbe Datum 21.10.2009 und dieselbe Uhrzeit! Bevor ich das Welec ausschalte, habe ich mal 2 bildchen gemacht. Das 1Khz Rechtecksignal auf dem 1.Kanal ist vom Probcomp. Die Einstellung auf dem 1. Foto ist 50mV/div, Timebase auf 5MS/s. Auf dem 2.Foto 50mV/div und die Timebase auf 1MS/s. Die Signale sind sehr sauber und werden präzise dargestellt, soweit ic das beurteilen kann. Der 2.Kanal hat irgendwie keine Lust etwas anzuzeigen. Bei der Triggerverstellung sowie bei der Spannungswahl, friert ab und zu das Bild ein. Jetzt stand in der Preview nur die W2000a.sof vom 27.11.2009 zur Verfügung, die laut Beschreibung, noch etwas mit Fehlern behaftet ist. Könnte sein, das das der Grund für die Freeser sind! Ansonsten finde ich das neue Design sehr schön gemacht. Meine Vorgehensweise zum aufspielen der Nios-SW: Erst den USB-Blaster installieren, dann meldet sich das DSO als NIOS-Evulation-Board. Nach dem installieren des Quartus-Programmer auf Auto-Detectet drücken. Danach 'ADD-File' und die W2000a.sof auswählen. Jetzt sind 2 x Dateien im Quartusfenster zu sehen, die ober sollte entfernt werden, da es sonst Probleme geben könnte. Jetzt auf Program drücken und warten bis oben rechts im Fenster 100% stehen. Unten ist noch ein Log, der mitteilt ob auch alles glatt gegangen ist! Der Bildschirminhalt vom DSO verschwindet nach der Programmierung, also keine Panik! Quartus kann geschlossen werden, abspeichern kann man, muß man aber nicht. Jetzt die Preview1.0 entpacken, die Parameter von der 'Welec_sram.bat' angleichen Comport, Baudrate, etc... dann Speichern und wieder schliesen. Die neue sram.bin habe ich in der Preview schon umbenannt, muß also alles im selben Verzeichnis sein! Jetzt nur noch die 'Welec_sram.bat' starten die den Waverecorder in gang setzt und die Daten werden im Dosfenster zum DSO übertragen. Jetzt ist das DSO betriebsbereit. Damit sich was tut, muß erst ein Signal dran (1.Kanal, der 2.Kanal zickt) Ich habe noch mal alles zusammen gepackt inkl. 2 Gifbilder vom Quartus-Programmer. Dann mal viel Spass beim testen Gruß Michael
Angehängte Dateien:
-
NiosDesign_01.gif
100 KB -
NiosDesign_02.gif
100 KB
Hier noch die beiden Fotos vom neuen Nios-Design...
Hallo Leute, Ich möchte auch wieder einmal ein Lebenszeichen von mir geben. In den letzten Tagen konnte ich den ersten Commit zum Welec-Projekt geben. Genauergesagt arbeite ich an der Firmware des Softcores des Leon-Designs. Unter http://sourceforge.net/apps/trac/welecw2000a/wiki/Leon%20Binaries kann man eine Binary des letzten Softwarestandes downloaden, die dann mit dem Waverecorder geflasht werden kann. Dieser beinhaltet die erste Version eines modularen GUI-Frameworks angelehnt vom Aussehen an die Orginal GUI. Ich lade die Mitentwickler gerne ein, beim Leon-Design zu helfen. Das FPGA Design ist sehr vielversprechend denn die digitale Signalverarbeitung sowie der Trigger laufen hervorragend. Hier gilt wirklich ein großes Lob an Alexander!! @Michael, hast du die welec_sram.bat im Archiv vergessen? Liebe Grüße Robert
Michael D. schrieb: > er 2.Kanal hat irgendwie keine Lust etwas anzuzeigen. > Bei der Triggerverstellung sowie bei der Spannungswahl, friert ab und zu > das Bild ein. > Jetzt stand in der Preview nur die W2000a.sof vom 27.11.2009 zur > Verfügung, die laut Beschreibung, noch etwas mit Fehlern behaftet ist. > Könnte sein, das das der Grund für die Freeser sind! Der 2. Kanal sollte prinzipell auch funktionieren. Hast du den Trigger auf Kanal 2 umgeschalten? Die Bilddarstellung stoppt sobald nichts mehr getriggert werden kann. Das kann passen wenn der Triggerlevel nichtmehr im Signalbereich ist (Triggerlevel über dem Signal), hervorgerufen durch eine Änderung der Spannung pro Division oder eben des Triggerlevels selbst. Dies Design ist kein NIOS Design ;) Der NIOS ist eine Softcoreimplementierung der Fa. Altera. In diesem Design wird ein Leon3 Softcore von Aeroflex Gaisler verwendet. lg Robert
Robert (RaZer6) schrieb: > Hallo Leute, > > > @Michael, hast du die welec_sram.bat im Archiv vergessen? > > Liebe Grüße > Robert nö, habe eben noch mal nachgeschaut! Wie kommst du darauf? Hast du sie nicht gefunden?
So'n Käse, da fehlt ja noch mehr, ist mir zu hoch!!! Hier nochmal das komplettes File, gebe dem Kind einen anderen Namen! Vielleicht ist ein Moderator so nett und nimmt die obere Preview raus? Gruß Michael
Ich habe eben mehrmal getestet. Im Archiv sind alles Dateien vom 27.11.09 (auch die alte Softcore Firmware). Aber Welec_sram.bat ist da keine drinnen. Folgende Dateien habe ich im Archiv: linux (Ordner) sram.bin Readme.txt WaveRecorder.exe W2000.sof Quartus_Start_Programmer.png Sind alles Dateien aus dem ursprünglichen Preview Package von SF. lg Robert
Robert (RaZer6) schrieb: > Dies Design ist kein NIOS Design ;) Der NIOS ist eine > > Softcoreimplementierung der Fa. Altera. In diesem Design wird ein Leon3 > > Softcore von Aeroflex Gaisler verwendet. Recht hast du!!! Danke für den Hinweis! Natürlich meinte ich das Leon3, hatte ständig das NIOS-Evulations-Board im Kopp entschuldigt den Fehler. Gruß Michael
oh mann, jetzt hat sich das hier überschnitten. Das umbenannte ZIP-File ist jetzt aber komplett! Ist die Anleitung Ok so oder hab' ich was vergessen? Ich konnte dir keine PN schicken, bist nicht angemeldet? Der 2.Kanal hat seine eigene Triggereinstellung? Habt ihr das irgenwo Dokumentiert? Gruß Michael
Ja ist grad blöd gelaufen.... Mods werden es schon richten ;) Im Menü von der Taste "Mode Coupling" kann der Triggerkanal auf Kanal 2 gesetzt werden. Da das der erste GUI-Test ist, gibt es dazu noch keine Doku. lg Robert
au weia, die falsche Preview wurde 32 mal runter geladen, dafür werde ich bestimmt gesteinigt! Robert, Jetzt geht der 2.Kanal... Wie sieht's mit den 10mV/Div aus? Bei 20mV/Div is' schluß! Kann das Signal nach dem Zoomen verschoben werden? Wie kann ich die Flanken Sichtbar machen? Gruß Michael EDIT: noch was, Trigger 'NORMAL' ist klar! Was ist Glitch und was hat es mit dem Externen auf sich? Bei Extern-Trigger zappelt das Signal ja gut ab...
Michael D. schrieb: > Jetzt fällt mir gerade was ein! > Kann mich erinnern, das wir das Thema schonmal hatten. > Nämlich der Tausch der NULL-OHM Wiederstände gegen 33 Ohmler, die das > Signal-Rauschen um einiges reduzierten! > Wir aber keine Softwareanpassung gemacht haben, da haben wir ja die > Leiche! Na das erklärt natürlich einiges. Bei mir ist alles noch im Originalzustand. > Was meinst du, soll ich die Wiederstände wieder raus schmeissen oder > wäre eine SW-Anpassung sinnvoller? Evtl. als Kalibrierungsoption könnte > man das einbauen oder ist der Auwand dafür zu groß??? Mann könnte eine manuelle Umschaltung der Faktoren einbauen, allerdings gibt es glaube ich auch Leute mit andern Widerstandswerten (23.5Ohm). Da wären dann wieder andere Faktoren nötig. Das größte Problem ist allerdings, dass ich die Faktoren nicht ermitteln kann, da ich kein Gerät mit entsprechenden Widerständen habe. Bringen denn die Widerstände tatsächlich soviel? -> Kannst due das Ticket 46 noch entsprechend ändern, damit wir das nicht nochmal irgendwann vergessen? Gruß Hayo
Hallo! Ich möchte nun ein paar Fragen zum Leon3-Design beantworten: Tommi aus dem Skype Forum fragte mich, ob die Signaldarstellung ohne der neuen Huckepackplatine von branadic und Walter so rauschfrei ist, meine Antwort: Ich wüsste nicht, dass jemand außer branadic und Walter diese Platine hätten. Das Leon3-Design ist bei den 2V, 1V, 200mV, 100mV, Spannungsbereichen rauschfreier als das NIOSI-Design. Die andere Rauschreduktion wird mit einen digitalen Tiefpass-Filter vor dem Trigger und der Messwertspeicherung durchgeführt. Das führt unweigerlich zu einer Bandbreitenbegrenzung, die das Signal verfälscht. Nimmt man bspw. Messdaten mit 1MS/s auf und man hat den Filter von 1GS/s -> 100 MS/s eingeschaltet, reduziert sich das Rauschen und die Bandbreite ungefähr um den Faktor 8! (Dieser eine Filter sollte hier momentant immer eingeschalten sein!) Bei dem Beispiel von oben darf man dann die Signalveränderung in der Regel verhachlässigen! Wenn man diese Filter verwendet, verhält sich das Oszilloskop wie ein Oszilloskop mit höherer Genauigkeit und wesentlich geringerer Bandbreite. @Michael --> Wie sieht's mit den 10mV/Div aus? Bei 20mV/Div is' schluß! Aufgrund der Austauschbarkeit von Geschwindigkeit und Messgenauigkeit geben die digitalen TP-Filter ein 16 Bit Signal aus! (ungleich 16 Bit Genauigkeit). Die Trigger-Messwerterfassung ist so aufgebaut, dass Sie entweder 4*8 Bit, 2*16 Bit oder 1*32 Bit mit 1 GS/s aufnehmen kann. Leider hat sich ein kleine Fehler im Trigger eingeschlichen, dass momentan nur der 8 Bit Mode richtig funktioniert. Mit 16 Bit lässt sich dann gefiltert triggerbare Messbereich theoretisch bei geringen Abtastraten um den Faktor 2^8=256 verkleinern. Ungefähr den Faktor 50 halte ich für sehr realistisch. @Michael -->noch was, Trigger 'NORMAL' ist klar! Was ist Glitch ... Der Glitch-Trigger, welcher auf die steigende Flanke triggert, triggert falls die LOW Zeit vor dem Triggerereignis kürzer als ein bestimmter Wert ist, NORMAL-Trigger macht das umgekehrt! Den externen Trigger habe ich noch nicht getestet und es sind theoretisch mehrere externe Trigger möglich (digitale Eingänge, PC-Steuererung,... für andere Plattformen)! Der externe Trigger Nr.0 ist ein interes Togglesignal, welches verwendet wird, um Signale ohne Triggerung aufzunehmen (Auto-Trigger). Der externe Trigger Nr.1 sollte auf der Extern BNC Buchse hängen. Vielen Dank gilt Robert für die neue GUI-Basis! MfG Alexander
Halloo Hayo, Habe mal die Doku's über den Einbau der 33 Ohm Widerstände zusammen gesucht. Der 1. Link zeigt an, wo diese auf dem Board zu finden sind: Beitrag "Re: Wittig(welec) DSO W20xxA Hardware" Der 2. Link zeigt die ausgetauschten Widerstände: Beitrag "Re: Wittig(welec) DSO W20xxA Hardware" Der 3. Link zeigt das Rauschen vom 1.Kanal vor dem Tausch und das 2.Foto nach dem Tausch der Widerstände. Beitrag "Re: Wittig(welec) DSO W20xxA Hardware" Schaue es dir an und sag' mir deine Meinung ob es sich lohnt die jetzt drinnen zu lassen oder nicht. Wenn der Aufwand für die SW-Anpassung zu aufwändig ist, dann schmeiß ich die wieder raus. Im HW-Thread, konnte ich mich erinnern, das der Rolf(war's der Rolf?) meinte, eine SW-Anpassung vorgesehen sei, will mich da jetzt aber nicht festlegen. Das Thema ist hier ja Kilometer lang, bis man da mal was findet... Gruß Michael
ich noch mal... Wie ich sehe, wird die W2000L_Preview1.0.zip (420,6 KB, 37 Downloads) weiter herunter geladen, als Hinweiß: Dies ist die Vorgänger-Version vom letzten Jahr des LEON3 Die aktuelle Datei ist die: ------W2000L_Preview1.0_komplett.zip------ Drinnen muß sein die schon umbenannte 'sram.bin' , und die 'Batchdatei' für den 'Waverecorder' Vielleicht könnten die Mod's mal Hand anlegen und diese Austauschen??? Dann könnte auch mein restlicher Müll hier gelöscht werden... Gruß Michael
Hallo Leute Möchte mich einfach einmal bedanken für die tolle Arbeit, die Ihr macht!!! Sowohl Hayo und Kollegen, die aus dem Welec erstmalig ein einsatzfähiges DSO gemacht haben, als auch der Truppe um Alex, die mit dem Leon3 Design ganz neue Möglichkeiten erschliessen. Habe heute einmal das Leon3 Design aufgespielt. Das sieht ja schon unglaublich gut aus!!! Damit steigt das Welec in ganz andere Dimensionen auf. Also, ehrlich. Vielen Dank für Euer Engagement. Anderer Michael
Hab das neue FPGA design auch gestern mal ausprobiert. Die Geschwindigkeit und Triggerstabilität ist ja wohl absolut geil! Echt Respekt! Weiter so. Gruß Torsten
@Michael D. Hi Michael, ich antworte Dir mal auf diesem Wege, damit alle anderen die auch Interesse an der Sache haben mitlesen können. >Das mit den Widerständen hat mir natürlich keine Ruhe gelassen und habe >bis heute Nacht die Dinger wieder getauscht...mit der 10-Fachlupe, 3 >Pinzetten, Löthonig, Wattestäbchen und Aceton.......was eine Popelei ! >Wie auch immer... wenn man mal ein einigermassen rauschfreies Signal >gewöhnt ist und schaut sich nach dem Tausch das Ergebnis an........ >Ich muß sagen, es besteht ein großer Unterschied ! Die Nullinienkorrektur >hat sich natürlich verbessert, das Rauschen hat aber gewaltig zu >genommen !!! Sieht furchtbar aus, vielleicht könnte man doch eine >Softwareanpassung in Betracht ziehen? Also wenn der Unterschied so groß ist wäre eine Softwareanpassung (umschaltbare Faktoren) sicher ganz praktisch. Damit das Ganze aber nicht zu unübersichtlich wird müßte man sich zumindest auf einen Widerstandswert einigen. Ich habe da Werte zwischen 20 und 33 Ohm in Erinnerung.Welcher Wert ist denn da am meisten vertreten bzw. empfohlen? Dann würde ich bei mir mal ein Gerät umrüsten damit ich die neuen Faktoren ermitteln kann. By the way, was für ein Gehäuse (Bezeichnung) ist das und wo kriegt man die? Ach ja, ich bin übrigens eifrig am Programmieren. Die Kanal-Delay Korrektur funktioniert schon ganz gut. Gruß Hayo
Hallo, jetzt muss ich mich auch mal wieder einmischen. Bei meinem W2012A ist noch immer ein Kanal mit 22-Ohm-Widerständen manipuliert, der 2. Kanal im Originalzustand. Ich kann diese Offsetverschiebung aber nicht nachvollziehen. vielleich kapiere ich das Problem nicht. Wenn ich die Kanäle rauf- und runterschiebe, erhalte ich maximal 1/10 div Offsetänderung am Kanal in Originalzustand. Das würde ich aber auf unzureichendes Warmlaufenlassen schieben. Wie sieht das denn bei den anderen aus? Grüße, Guido P.S. @ Hayo: Kümmer dich lieber um den Delayed-Mode ;-).
Hallo mike0815 und andere
Danke für die Erklärung zu dem Leon3
Bei Gelegenheit werde ich es vielleicht probieren..
Derzeit bin ich froh dass es aber wieder so läuft... siehe unten.
Hallo Hayo
Habe deine Version noch mal getestet.
Nulllinienverschiebung habe ich keine!
>- die Screenshotversion passt nicht zu der offiziellen Version
Ja, leider!
Hatte mir das so schön eingerichtet und jetzt funktioniert das leider
mit deiner Version nicht :-(
Habe dann mal probiert das "About Osciloskop"
Leider komme ich dann aus diesem Fenster nicht mehr raus..
Habe dann ein paar Tasten gedrückt, aber das Versionsfenster geht dann
nicht mehr weg :-(
Hatte versehentlich auch Kanal 3 Eingeschalten (blau)
Irgendwann, kam ich dann irgendwie raus und auf einmal hatte das Gitter
eine blaue Farbe :-( :-(
Wollte dann eine neue Version aufspielen, aber mit dem Hauptrechner ging
es einfach nicht mehr.... Ging dann mit dem Laptop.
Jetzt habe ich wieder die OS Version drauf.
Hier geht der Screenshot wenigstens.
Leider passiert jetzt das, das es zwei verschiedene SW-Versionen gibt
und in jeder gibt es ein paar gute Dinge.
Leider aber nicht alle in einer Version :-(
Wenn man die eine nimmt, muss man leider auf Dinge der anderen
verzichten :-(
Im Anhang zwei Bilder zur SW 1.2.OS.0.92
Bild 2 : ist nach dem Einschalten.
Sehe links die Zahlen für die Kanäle, aber keine Linie!
Hier dürfte aber nur Kanal 1 EIN sein.
Bild1 : das passiert, wenn ich mit dem Trigger nach oben fahre...
Ein Haufen von Trigger-Pfeilen
Die Linie von Kanal1 sehe ich erst, wenn ich am Kanalrad drehe
(Verstärkung)
Die Nummern der anderen Kanäle gehen erst weg, wenn ich einen anderen
Kanal AUS und EIN schalte...
l.G. Roberto
Hallo Hayo, >Also wenn der Unterschied so groß ist wäre eine Softwareanpassung >(umschaltbare Faktoren) sicher ganz praktisch. Damit das Ganze aber >nicht zu unübersichtlich wird müßte man sich zumindest auf einen >Widerstandswert einigen. Ich habe da Werte zwischen 20 und 33 Ohm in >Erinnerung.Welcher Wert ist denn da am meisten vertreten bzw. empfohlen? Die Gehäuse sind '402' mit 1% Tol. ! Man muß aufpassen, das man sie nicht aus Versehen einatmet. Guido hat seine 24 Ohmler aus einem CD-Rom Laufwerk, glaube ich! Die 0603er sind noch vertretbar, hatte in den 2.Kanal mal diese Grösse mit '47 Ohm' bestückt, brachte aber keinen deutlichen Unterschied . Ich denke, das man mit den 33 Ohm am besten fährt! Ich hatte diese vorher durch gemessen und alle 4 hatten den absolut selben Wert. Im Schaltplan, den ich mal hier anhänge, wird an Pin 2 vom AD8131 eine Spannung von 1,4V als Ideale Einstellung für den ADC-Eingang (Adjustment) angegeben. Ich werde das mal messen, mal schauen, was bei raus kommt! Hoffentlich habe ich keinen HW-Defekt! Hallo Guido, Genau, wie es bei den Anderen aussieht, würde mich auch sehr interessieren! Im 'Ticket 46' Zeroline... ist es nochmal beschrieben. http://sourceforge.net/apps/trac/welecw2000a/ticket/46 Hallo Roberto, >Habe dann mal probiert das "About Osciloskop" >Leider komme ich dann aus diesem Fenster nicht mehr raus.. >Habe dann ein paar Tasten gedrückt, aber das Versionsfenster geht dann >nicht mehr weg :-( Dasselbe Problem hatte ich auch mit Hayo's 097er FW !!! Hatte das File mehrmals geflasht, da der Germsloader ja keine Fehlermeldung ausgibt, weißt du nie, ob alles übertragen wurde. Das blaue Gitter kenne ich auch! Gruß Michael
Michael D. schrieb: > >>Habe dann mal probiert das "About Osciloskop" >>Leider komme ich dann aus diesem Fenster nicht mehr raus.. >>Habe dann ein paar Tasten gedrückt, aber das Versionsfenster geht dann >>nicht mehr weg :-( > > Dasselbe Problem hatte ich auch mit Hayo's 097er FW !!! > Hatte das File mehrmals geflasht, da der Germsloader ja keine > Fehlermeldung ausgibt, weißt du nie, ob alles übertragen wurde. > > Das blaue Gitter kenne ich auch! Hallo Jungs, ja das Problem hatte ich auch schon bemerkt - und auch beseitigt. Habe meine neue Version fast fertig mit einigen neuen Guties zum Ausprobieren -> BF.0.98 coming soon... Gruß Hayo
Hallo toll dass es weiter geht!!! wird 0.98 dann schneller anzeigen wie die Version von Rolf oder so langsam wie immer? Welche screenshot.exe braucht man dafür???? R.
He, wer schreibt mit meinem Namen ? Hallo Hayo Mir würde es sehr gefallen, wenn deine Version auch mit der neuen Screenshot funktionieren würde! l.G. Roberto
Hallo Roberto, welchen Vorteil versprichst du dir davon? Alles was Hayo's BF Version kann, sollte doch auch in der OS Version vorhanden sein? Oder kannst du es nur nicht erwarten etwas neues auszuprobieren? ;-) Mfg, Kurt
Roberto schrieb: > He, wer schreibt mit meinem Namen ? Dein Name? > Hallo Hayo > > Mir würde es sehr gefallen, wenn deine Version auch mit der neuen > Screenshot funktionieren würde! mir täte es gefallen wenn die geschwindigkeit so schnell wäre wie bei Rolf (rowü?) l.G. Roberto
Hallo zusammen, ich habe ein Hardware-Problem mit meinem 2024. Als ich das Oszi vor ca. 5 Monaten zum letzten Mal genutzt habe war noch alles in Ordnung. Nun passiert nach dem Einschalten folgendes: Der Lüfter läuft los, die Hintergrundbeleuchtung des Bildschirms leuchtet, sämtliche LEDs gehen an, aus und wieder an - und dann geschieht nichts weiter. Durch Drücken der beiden linken Tasten wird das LCD weiß und der Germs-Loader startet. Ich kann dann beispielsweise ein Flash- oder RAM-Image runterladen. Nach dem Runterladen gehen die LEDs wieder an, aus und wieder an - und das war's. Aus- und wieder Einschalten über den Hauptschalter führt zum gleichen Ergebnis. Wenn das Oszi ca. 15 Minuten in diesem Zustand eingeschaltet bleibt, dann läuft es irgendwann wie erwartet los und alles funktioniert wie erwartet. Auch wenn ich das Oszi dann über den Hauptschalter aus- und wieder einschalte, startet es problemlos. Scheint also ein thermisches Problem zu sein, das sich warum auch immer nur auf die "höheren" Funktionen des Oszis auswirkt. Der Germs-Loader funktioniert aber schon direkt nach dem Einschalten problemlos. Kennt jemand dieses Fehlerbild bzw. kann mir jemand einen Tipp geben, wo ich hier suchen soll? Gruß, Bernd
Hallo Bernd, um den Zeitpunkt des freezing weiter einzugrenzen solltest Du Dir mittels Terminalprogramm während der Startphase die Meldungen anschauen. Wenn die Startmeldungen alle durchlaufen würde ich auf ein Displayproblem tippen, ansonsten müßte man mal sehen welches die letzte Meldung ist. @Roberto (1+2) Ich schau mal was ich machen kann. Gruß Hayo
So Ihr Lieben, ich war bis eben recht fleißig, aber jetzt ist mal Schluß. Irgendwann muß auch mal der gemütliche Teil des Wochenendes anfangen. Ich kann dafür mit etlichen Guties zum Ausprobieren aufwarten - ich denke es wird Euch gefallen: - die Remoteschnittstelle ist jetzt kompatibel zur O.S.92a - die Screenshotfunktion ist jetzt kompatibel zur aktuellen Version Beides habe ich bislang nicht getestet - ich bitte um Rückmeldung. - ich habe den neuen Triggermodus von Stefan eingebaut. Er heißt bei mir allerdings Combi-Trigger (wegen kombiniertem Auto und Normalmodus) - es gibt ein neues Utilitysubmenü, hier findet Ihr: - Eine Auswahlmöglichkeit wie die ADC-Register gesetzt werden - Eine Kanalverschiebungskompensation - Desweiteren habe ich die DAC-Kalibrierung stark überarbeitet. Es braucht jetzt nur noch einmal kalibriert zu werden. Es werden alle Spannungsbereiche auch der nicht aktiven kanäle in einem Durchgang kalibriert. Die DAC-Korrekturwerte stehen jetzt im Protected Flash. Durch die diversen Änderungen muß nach dem Flashupdate erstmal das Scope neu kalibriert werden: 1. default setup drücken 2. Zerolines suchen 3. ADC-Kalibrierung 4. DAC-Kalibirerung Die aktuelle Menüstruktur entnehmt Ihr bitte der beigelegten Programming Map. Alles andere steht im Changelog. Viel Spass Hayo
Hi Hayo, super, dass du dich zurückmeldest und gleich wieder so fleißig bist! Vielen Dank dafür! Ich habe deine Firmware schonmal draufgehaut, allerdings erst ganz flüchtig getestet - mangels Signalgenerator kann ich leider nicht allzuviel probieren. Macht auf jeden Fall einen guten Eindruck! Allerdings wollte ich noch - etwas verspätet - melden, dass ich dasselbe Problem wie der andere Michael habe: wenn ich nen Kanal hoch- oder runterverschiebe, dann verhaut es mir die ganze Kalibrierung, vor allem beim nach oben schieben. Es tritt auf allen Kanälen auf, allerdings unterschiedlich stark und nach jeder Kalibrierung etwas anders. Wenn man den Kanal wieder runterschiebt, passt wieder alles. Haben das noch andere und fällt jemandem dazu eine plausible Erklärung ein? Irgendwie will mir das nicht ganz einleuchten, aber vielleicht hat es doch was mit den Widerständen zu tun, denn ich habe auch 33Ohm in Serie zu den ADCs liegen... Viele Grüße Michael
Der Offset ist sehr merkwürdig: wenn ich die Spannungsbereiche durchschalte, bleibt die Linie auf der Stelle, d.h. der Offset skaliert in der Darstellung immer schön mit, so als würde sich der Absolutwert beim Umschalten von 5V auf 10V verdoppeln. Zum Vergleich wollte ich gerade die Sourceforge Version 0.91 testen, aber die scheint nicht mehr zu funktionieren, nachdem die neue BF drauf war...Scope lässt sich nur noch zu Schnappschüssen überreden, nicht mehr zu Dauersamplen. Leider bin ich mir nicht mehr sicher, ob das Offsetproblem vor dem Einsetzen der Widerstände auch schon so aussah. Wie sieht das beim Rest der Crew aus? Gruß Michael
Keine Sorge, der vorerst letzte Post zu dem Thema: Bei 0.92a Sourceforge tritt das Problem identisch auf. Meine Hardwarerevision ist 8C7.C9. Gruß Michael
Hi Hayo, der 3. Trigger ist eingebaut, totschick... Die Nullliniencalibrierung funzt auch, wie beschrieben, mußte nur 1x den DAC wiederholen, dann hat es gepasst! Kann das sein, das das Rauschen in den 5er DIV.-Bereichen abgenommen hat? Was hat es mit der ADC-Setting: FACTORY, HIGH FREQ. und den TEST1-3 auf sich und wie wird diese bediehnt? Hallo Michael H., Ich hatte auch die 33 Ohmler drinnen, ärgere mich jetzt ein bißchen, das ich diese wieder getauscht habe, da das Grundrauschen um Einiges zu genommen hat! Die Linienverschiebung ist mit den 0 Ohm etwas minimaler, aber trotzdem noch vorhanden. Während der Messungen, hatten sich die Linien verschoben, so das noch Spannungen angezeigt wurden, die garnicht mehr da waren. Werde das mit der neuen FW. mal testen, ist ja Einiges gebaut worden... Unter "UTILITY" ist die Option "MORE" für einen "Channnel-Delay" CH1, CH2, von 0-16nS ! Vielleicht testest du mal einige Einstellungen damit. Je höher der Delay, desto weiter runter kommt die Line. Mußt aber nach jeder Delay-Auswahl neu calibrieren, sonst tut sich nix!!! Wie sieht's denn bei dir mit dem Rauschen nachdem Tausch der Widerstände aus? Gruß Michael
Hi Michael. Wie bei allen anderen ist auch bei mir das Rauschen durch die Widerstände merklich besser geworden, weshalb ich sie auch ungern wieder rausnehmen möchte. Die Delayeinstellungen sind eine tolle Sache, muss ich mal testen. Allerdings bestimmt nicht, um damit den Offset zu kompensieren! Die sind doch dafür da, um den zeitlichen Versatz zwischen den Kanälen auszugleichen, der durch die Verwendung von zwei FPGAs in den Vierkanalgeräten auftritt. Ich kann mir beim besten Willen auch nicht vorstellen, dass das den Offset irgendwie beeinflusse sollte, aber wenn du jedes Mal neu kalibrierst ist es natürlich klar, dass sich was ändert. Die ADC settings sollen es Leuten mit verschiedenen Geräteversionen ermöglichen, die für sie optimale Einstellung zu wählen, es hat sich ja gezeigt, dass es da wohl Unterschiede gibt. Allerdings siehst du den Unterschied nur bei sehr kleinen Zeitbasen / hohen Frequenzen. Michael
Angehängte Dateien:
-
Bild0351_XR2206_Sinus.png
450 KB
Hi Michael H. >Die Delayeinstellungen sind eine tolle Sache, muss ich mal testen. >Allerdings bestimmt nicht, um damit den Offset zu kompensieren! Das hatte ich mir fast gedacht. Deshalb ja meine Frage, was es mit den "MORE-Optionen so auf sich hat! Ich habe das W2022, da besteht das Problem ja nicht. Wenn die Widerstände per SW angeglichen werden könnten, wäre das eine feine Sache, dann würde ich die wieder einbauen! Ich habe heute mal mit einem XR2206 einen FG. auf dem Breadboard zusammen geschustert, der ist wohl nur mit 1MHz angegeben, da ging aber noch was, wie man sieht! Vielleicht wäre das eine vorübergehende Alternative für dich?!? Hier mal ein Foto mit der neuen FW. vom Hayo. Gruß Michael
Noch ein kurzer Kommentar bevor ich für heute abtauche: - die Offsetverschiebung hängt mit Sicherheit mit den Widerständen zusammen. Bei meinen beiden Geräten tritt das nicht auf. Vielleicht kann da jemand mit ebenfalls unveränderter Hardware was zu sagen? - die ADC-Registereinstellungen kann man nach der Einstellung im Utility-Submenü einfach überprüfen indem man sich mittels Terminalprogramm und der Taste "," die Variablen anzeigen läßt. Hier noch mal schnell ein kleiner Überblick_ - High Frequ -> adc_change12 = adc_change34 = 0x01000000 diese Einstellung hat sich bei meinen beiden Geräten insbesondere bei hohen Frequenzen bewährt. - Factory -> die ADC-Register werden mit den Werkseinstellungen aus dem Protected-Flash gesetzt. Bei mir ist das für adc_change12 = 0x02020f00 und für adc_change34 = 0x0200000a. die add-Register werden ebenfalls aus dem Flash geladen (add12 = 0x5f0a, add34 = 0x5f5f). - Test1 -> das ist der Registerwert von Falk, der auch in der O.S. Version benutzt wird (0x00020000) - Test2 -> adc_change12 = adc_change34 = 0x00000000 - Test3 -> adc_change12 = adc_change34 = 0x01020800 - Diese einstellung verursacht bei mir die schon bekannten Störungen auf den Signalflanken Auf Wunsch kann man da auch andere oder zusätzliche Werte hinterlegen. Gruß Hayo
Ab 250MSa/s 5µs aufwärts (bei beiden Kanälen), hauen wieder die Spikes durch den ganzen Bildschirm. Verschiebe ich das Signal nach unten oder oben, werden diese mal mehr, mal weniger! Hatten wir ja schon mal. Michael H. Du hast doch noch die 33 Ohm Widerstände drinnen, wie sieht das bei dir aus mit den Spikes? Gruß Michael
ich noch mal, gestern hatte ich bei der Obigen Messung (Bild XR2206) den 'NOISE-FILTER' an, der die Spikes fast völlig unterdrückt. Währe interessant zu wissen, ab welcher Frequenz der Noise-Filter einsetzt! Gruß...
Michael D. schrieb: > Ab 250MSa/s 5µs aufwärts (bei beiden Kanälen), hauen wieder die Spikes > durch den ganzen Bildschirm. Bei welcher Einstellung? Als Referenz am besten Factory Setting benutzen. Da sollte ja eigentlich alles hinhauen. Wenn nicht -> die anderen Einstellungen ausprobieren! Gruß Hayo
Michael D. schrieb: > gestern hatte ich bei der Obigen Messung (Bild XR2206) den > 'NOISE-FILTER' an, der die Spikes fast völlig unterdrückt. Währe > interessant zu wissen, ab welcher Frequenz der Noise-Filter einsetzt! Der Noise Filter arbeitet bei allen Nicht-USTB Zeitbasen! Die Wirksamkeit hängt allerdings von dem jeweiligen Zeitfaktor ab, da dieser dafür verantwortlich ist wieviel überschüssige Samples für die qualitative Verbesserung des Signals verwendet werden können. Gruß Hayo
Hallo Hayo, die Spikes treten schonmal bei 5v, 2V und 1V division auf! Zeitbasen von 250Msa/s -1Gsa/s Ich teste das mal mit der Factorie-Einstellung, was bewirkt diese denn? Muß ich nach der Auswahl, Factorie z.B., jedes mal eine komplette Neucalibrierung durchführen oder wird diese gleich in das ADC-Register geschrieben? Hayo W. > Der Noise Filter arbeitet bei allen Nicht-USTB Zeitbasen! Die > Wirksamkeit hängt allerdings von dem jeweiligen Zeitfaktor ab, da dieser > dafür verantwortlich ist wieviel überschüssige Samples für die > qualitative Verbesserung des Signals verwendet werden können. > > ...ab 1GSa /s und 10ns ist der NOISE-Filter nicht mehr aktiv, oder wurde das geändert? Gruß Michael
Michael D. schrieb: > ...ab 1GSa /s und 10ns ist der NOISE-Filter nicht mehr aktiv, oder wurde > das geändert? Das war schon immer so! Da das Oszi 1GS hat, woher sollen die zusätzlichen Samples für ein Noise-Filter herkommen? Das Noise-Filter macht doch nichts anderes, als mit den zusätzlichen Samples einen Mittelwert zu bilden. Sprich, bei der Timebase mit 500MS sollten das zwei Werte sein, bei 250MS entsprechend vier. Also kann das Noise-Filter bei 1GS faktisch nicht mehr funktionieren. branadic
Michael D. schrieb: > Ich teste das mal mit der Factorie-Einstellung, was bewirkt diese denn? siehe oben > Muß ich nach der Auswahl, Factorie z.B., jedes mal eine komplette > Neucalibrierung durchführen oder wird diese gleich in das ADC-Register > geschrieben? die neuen Settings sind sofort aktiv. Neukalibrierung ist nicht notwendig, da diese mit den Registereinstellungen nichts zu tun hat Gruß Hayo
branadic schrieb: > Michael D. schrieb: >> ...ab 1GSa /s und 10ns ist der NOISE-Filter nicht mehr aktiv, oder wurde >> das geändert? > > Das war schon immer so! Da das Oszi 1GS hat, woher sollen die > zusätzlichen Samples für ein Noise-Filter herkommen? > Das Noise-Filter macht doch nichts anderes, als mit den zusätzlichen > Samples einen Mittelwert zu bilden. Sprich, bei der Timebase mit 500MS > sollten das zwei Werte sein, bei 250MS entsprechend vier. Also kann das > Noise-Filter bei 1GS faktisch nicht mehr funktionieren. Das ist so nicht korrekt! Der theoretische Vorteil wenn man nur überschüssige Werte verwendet ist, dass keine Bandbreitenbegrenzung auftritt. Das Noise-Filter arbeitet auch bei den 1GSa/s Zeitbasen. Der Unterschied zu den Zeitbasen mit Werteüberschuss (draw_factor > 1) ist jedoch, dass die Werteüberlappung zu einer Bandbreitenbegrenzung führt. Ich habe die Überlappung jedoch so klein gewählt, dass der Bandbreitenverlust nur die Frequenzen betrifft, die das Scope ohnehin nicht mehr brauchbar sampeln kann. Man kann die Filterfunktion also ohne Verlustängste haben zu müssen einsetzen. Gruß Hayo
Hallo Hayo, also handelt es sich bei 1GS-Zeitbasen um ein gleitendes Mittelwertfilter? Irgendwoher muss ja die Information genommen werden!? brandic
Ja, die Informationen stammen von den Nachbarwerten. In diesem Fall zwei Werte davor und ein Wert danach. Bei den anderen Zeitbasen sind es je nach Faktor mehr Werte. Je mehr Werte verwendet werden, desto besser arbeitet das Filter. Gruß Hayo
Hallo Hayo, Das Filter arbeitet wirklich gut, bei den 5V, 500mV und 50mV/DIV sind die Signale auch ohne Filter gut. Bei den restlichen Spannungsbereichen sieht das ohne Filter nicht so toll aus, wurde in der Bedienungsanleitung von Welek ja auch so beschrieben! ...ich bekomme die Spikes nicht in den Griff, egal welche Einstellung(Factory...etc.) ich teste, auch nach einer mehrstündigen Warmlaufzeit nicht! Ab 250Msa/s -1Gsa/s und allen Spannungsbereichen, sobald ein Signal anliegt, egal ob internes 1KHz-Rechteck-Signal oder Externes! Gruß Michael
Ich muss meinem Namensvetter leider zustimmen: die Spikes sind bei mir auch nicht kleinzukriegen, sie treten bei den verschiedenen ADC settings lediglich unterschiedlich oft auf. Vielleicht ist das mal wieder ein Punkt, in dem sich die Geräteversionen merklich unterscheiden und für die Revision von uns Michaels bräuchte man noch eine andere Einstellung? Da das Oszi in letzter Zeit nicht benutzt wurde, bin ich mir nicht mehr völlig sicher, ob die Spikes bei der letzten Version auch auftraten oder nicht, ich werde das aber gleich nochmal überprüfen. Die Idee mit der Umschaltung finde ich auf jeden Fall recht gut, so kann man vielleicht nach und die optimalen Einstellungen für alle Osziversionen finden und dort einpflegen. Gruß Michael
Also bei der 0.92 SF tritt das Spike-Problem bei mir ebenfalls auf, es ist also definitiv kein Problem von Hayos neuer Firmware. Das hatte ich mir auch schon gedacht, war mir aber nicht mehr völlig sicher. Die neue Bf 0.98 ist meines Erachtens also im Moment definitiv die beste Wahl. Gab es denn nicht schonmal eine Lösung, die sowohl die Spikes als auch die hässliche Treppenbildung im Signal unterbindet? Kann mir jemand sagen (Alex weiß das doch bestimmt), ob es noch unbenutzte IOs an den FPGAs gibt und ob Welec davon welche rausgeführt hat? Gruß Michael
Angehängte Dateien:
Na, da bin ich ja beruhigt, das das nicht bei mir nur so ist, dachte schon, ich hätte was kaputt gemacht... Nach RUN-Stop habe ich mal die Zeitbasen bei 250Msa/s durch geschaltet, in der 2µs, 5µs Stellung sind die Spikes am heftigsten, habe mal ein Foto davon gemacht. Komischerweise ist ab 1Gsa/ nicht's mehr zu sehen, blick da net mehr durch Michael H. Du hast doch ein W2024, oder? Ich habe das W2022A HW-Ver. 8C7.OL Gruß Michael
Hallo Michael D. Habe mal deinen Versuch nachgestellt... Bei mir kommen ab und zu Striche, im letzen Wellenberg von der Sinusschwingung. Passiert max. bis zum zweiten Wellenberg von rechts. Der Strich geht dann aber nach unten! Habe aber jetzt wieder die OS verion drauf.. 1.2.OS.0.92 W2024A Hardware Verson 8C7.C9 Signal 200kHz pk-pk 10V Eingestellt 2V/div Warum zeigt es bei dir eigentlich 21V an ? Misst er da die Spikes mit ? Bei mir kann ich aber nur 250MSa/5us und 500MSa/2,5us einstellen ?! Habe jetzt nochmal gemessen: Bei mir tritt das jetzt auf von ca. 25MSa/s 10us bis 1GSa/s 100us Das Ganze ist auch stark abhängig von der Frequenz. z.B. habe ich mit 200kHz bei 1GSa/s 200ns nix, aber wieder bei 20kHz etwas. Teilweise ist es so, je weniger von der Schwingung dargestellt wird, je mehr Störungen gibt es.. l.G. Roberto
ups.... Du hattes ja nur 100kHz Je nach Frequenz tritt der Effekt dann auch am ganzen Schirm auf (link bis rechts)
Hallo Roberto, hast Recht, bei 200KHz sind die Spikes etwas weniger! Und je nach dem, wohin das Signal verschoben wird(hoch o. runter), wird's mehr oder weniger...komisch Die 21V sind natürlich nicht korrekt, hatte aus versehen den Prob auf 2:1, hatte mich schon gewundert wo die hohe Spannung plötzlich herkommt. Gruß Michael
Hi, kurzer Zwischenbericht: Ich experimentiere gerade an einer Umschaltung für die Verstärkung herum, dammit wir eine Lösung sowohl für die "Standard" Geräte als auch für die modifizierten finden. Gruß Hayo
Michael D. schrieb: > Na, da bin ich ja beruhigt, das das nicht bei mir nur so ist, dachte > schon, ich hätte was kaputt gemacht... > > Nach RUN-Stop habe ich mal die Zeitbasen bei 250Msa/s durch geschaltet, > in der 2µs, 5µs Stellung sind die Spikes am heftigsten, habe mal ein > Foto davon gemacht. > Komischerweise ist ab 1Gsa/ nicht's mehr zu sehen, blick da net mehr > durch So, habe mir die Sache mit den Spikes noch mal näher angesehen und festgestellt, das diese bei mir ebenfalls wie beschrieben auftreten, nur war mir das nie so aufgefallen, da ich meistens in den 1 GSa Bereichen teste. Das Ganze hängt definitiv nicht an der Firmware, sondern unter anderem am ADC-Register Setting. So konnte ich bei mir beobachten, dass die Spikes beim Factory Setting am geringsten sind und auch bevorzugt am Ende der Meßstrecke auftauchen. D.h. wenn man im Memoryfenster bis an den Anfang kurbelt treten sie fast überhaupt nicht mehr auf. Eine Erklärung habe ich dafür Momentan nicht. An dieser Stelle möchte ich allerdings Stefan nochmal mein dickes Lob aussprechen für den sehr gelungenen neuen Triggermodus, der die Signale mit eiserner Faust im Griff hält wo der Automodus nur am hin und her zappeln ist - super! Gruß Hayo
Hayo W. schrieb: ... > So, habe mir die Sache mit den Spikes noch mal näher angesehen und > festgestellt, das diese bei mir ebenfalls wie beschrieben auftreten, nur > war mir das nie so aufgefallen, da ich meistens in den 1 GSa Bereichen > teste. > Das Ganze hängt definitiv nicht an der Firmware, sondern unter anderem > am ADC-Register Setting. So ist es: Entweder man hat übel verzerrte Signale oder Spikes. (http://www.youtube.com/watch?v=aD_A3JPSxlc) Wenn ich mich richtig erinnere, erscheinen die Spikes immer am Ende des Readout-Buffers, wenn der Trigger durchlief und hatten immer den gleichen Wert und den gleichen Abstand. Dieser änderte sich, wenn die TB geändert wurde. Hier sieht man das ganz schön: http://www.youtube.com/watch?v=5tb16NtTws0 Falk, der momentan kaum zum Basteln kommt.
Hi Hayo, Hayo W. schrieb: > Ich experimentiere gerade an einer Umschaltung für die Verstärkung > > herum, dammit wir eine Lösung sowohl für die "Standard" Geräte als auch > > für die modifizierten finden. ...sag' blos, das das möglich ist! Da käme Freude auf, denn in den 1er, 2er, 100, 200mV/DIV, usw. -Bereichen, macht das Messen ohne Nois-Filter keinen Spaß! Hayo W. schrieb: > Das Ganze hängt definitiv nicht an der Firmware, sondern unter anderem > > am ADC-Register Setting. ...je nach Stellung der Nulllinie, verändern sich diese (Spikes) ebenfalls. Es reicht manchmal nur ein 'Klick', nach oben oder unten. Der 3. Trigger ist wirklich eine feine Sache, da brauch man den Auto-Modus nicht unbedingt und kann diesen vernachlässigen! Im HW-Thread, hat branadic noch an der Vorstufe getüfftelt, mal sehen, was dabei heraus kommt. Bin schon ganz gespannt! Gruß Michael
Also mein Workaround für die Spikes ist folgender: - ADC-Setting auf "Factory" - den Memorybrowser ganz zum Anfang kurbeln - Noisefilter an Mit diesen Einstellungen sind die Spikes so gut wie verschwunden @Michael Ja die Umschaltung ist schon eingebaut. Aber das Problem ist, wie schon beschrieben, die richtigen Faktoren zu ermitteln da ich noch kein umgerüstetes Gerät habe. Dazu kommt das es noch keine einheitlichen Werte gibt. Wenn ich mich recht entsinne empfiehlt der Reference Guide 24 Ohm. Einige von Euch haben 33 Ohm oder 47 Ohm oder 22 Ohm oder auch 11 Ohm. Ich suche gerade auf alten Platinen nach geeigneten Widerständen - mal sehen. Gruß Hayo
Hayo W. schrieb: > - ADC-Setting auf "Factory" > > - den Memorybrowser ganz zum Anfang kurbeln > > - Noisefilter an > > > > Mit diesen Einstellungen sind die Spikes so gut wie verschwunden ...sag' ich doch! Ich denke, damit könnte man leben. Ich hatte die 24 Ohm, 33 Ohm und dann die 47er drinnen! Die 33 Ohm waren am effektivsten, die 47 Ohm brachten keine merkliche Besserung! Das mal zur Info. Gruß Michael
Na dann werde ich mal nach 33 Ohm Ausschau halten. Ich werde nachher noch eine neue Oster-Version hier einstellen, da könnt Ihr dann schon mal mit den Verstärkungen rumspielen. Gruß Hayo
Also hier ist sie, die Easter Edition.
Die Verstärkung läßt sich erstmal nur via Terminal und Shift + G (für
Gain) umstellen (Menü kommt später).
Gain Index 0: Standard gain und standard Faktoren
Gain Index 1: alle Bereiche mit gain 1.25 (statt 1 in den 1er + 2er)
die Faktoren sind auf Null Ohm Widerstände ausgelegt.
Gain Index 2: wie 1, aber mit geändertem Zeroscale Faktor.
Voreingestellt ist Gain Index 1. Bitte beachten das für Gain Index 2 die
Faktoren erst mal aus dem hohlen Bauch heraus gewählt sind und natürlich
noch angepasst werden müssen wenn ich erstmal die Widerstände drin habe.
Nach dem Ändern des Gain Index immer erstmal DAC-Kalibrierung
durchführen!
Ich bin dann erstmal über Ostern weg. Ich wünsche Euch schöne
Feiertage...
Bis dann
Hayo
p.s. @Michael wie sieht es mit den Netzschaltern aus? Wollte die mal nach Ostern tauschen. Gruß Hayo
Thread beobachten
Seitenaufteilung abschalten
